From davidch at broadcom.com Sat Aug 1 01:27:48 2009 From: davidch at broadcom.com (David Christensen) Date: Sat Aug 1 01:27:55 2009 Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. In-Reply-To: <5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk> References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org> <5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339EC2B524E@IRVEXCHCCR01.corp.ad.broadcom.com> > Anyone point me in the right direction on how to add the phy > to support these machine? > > Seems like its just a matter of adding the PHY details to > miidevs but how do I find out the specifics of that? Sorry, this is the 5709S and I haven't had an opportunity to implement this PHY yet. Unfortunately it's more than just a change to miidevs since the SerDes is actually an IEEE clause 45 compliant device (instead of the more common Clause 22 devices found in 1GbE controllers). The registers are diffrerent so the effort is more substantial. No estimate yet on when I can get to it. Dave From aragon at phat.za.net Sat Aug 1 02:53:01 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Sat Aug 1 02:53:08 2009 Subject: anyone know libalias(3) well? Message-ID: <4A73AE00.2050702@phat.za.net> Hi, In sys/netinet/libalias/alias_db.c, SetStateIn() and SetStateOut() reference ALIAS_TCP_STATE_CONNECTED and ALIAS_TCP_STATE_DISCONNECTED. Does anyone know where/how these macros are defined? Thanks, Aragon From bz at FreeBSD.org Sat Aug 1 08:51:55 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Sat Aug 1 08:52:01 2009 Subject: kern/137309: [ipsec] sequence number in a SADB_X_SPDGET response is set to zero Message-ID: <200908010851.n718psbF061529@freefall.freebsd.org> Synopsis: [ipsec] sequence number in a SADB_X_SPDGET response is set to zero Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Aug 1 08:51:39 UTC 2009 Responsible-Changed-Why: Take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=137309 From marius at nuenneri.ch Sat Aug 1 09:15:27 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sat Aug 1 09:15:34 2009 Subject: anyone know libalias(3) well? In-Reply-To: <4A73AE00.2050702@phat.za.net> References: <4A73AE00.2050702@phat.za.net> Message-ID: On Sat, Aug 1, 2009 at 04:52, Aragon Gouveia wrote: > Hi, > > In sys/netinet/libalias/alias_db.c, SetStateIn() and SetStateOut() reference > ALIAS_TCP_STATE_CONNECTED and ALIAS_TCP_STATE_DISCONNECTED. Does anyone know > where/how these macros are defined? > > > Thanks, > Aragon http://fxr.watson.org/fxr/source/netinet/libalias/alias_local.h?im=bigexcerpts#L367 From alexpalias-bsdnet at yahoo.com Sat Aug 1 13:32:20 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Sat Aug 1 13:32:27 2009 Subject: em driver input errors Message-ID: <11420.28890.qm@web56404.mail.re3.yahoo.com> Good day I'm running a FreeBSD 7.2 router and I am seeing a lot of input errors on one of the em interfaces (em0), coupled with (at approximately the same times) much fewer errors on em1 and em2.? Monitoring is done with SNMP from another machine, and the CPU load as reported via SNMP is mostly below 30%, with a couple of spikes up to 35%. Software description: - FreeBSD 7.2-RELEASE-p2, amd64 - bsnmpd with modules: hostres and (from ports) snmp_ucd - quagga 0.99.12 (running only zebra and bgpd) - netgraph (ng_ether and ng_netflow) Hardware description: - Dell machine, dual Xeon 3.20 GHz, 4 GB RAM - 2 x built-in gigabit interfaces (em0, em1) - 1 x dual-port gigabit interface, PCI-X (em2, em3) [see pciconf near the end] The machine receives the global routing table ("netstat -nr | wc -l" gives 289115 currently). All of the em interfaces are just configured "up", with various vlan interfaces on them.? Note that I use "kpps" to mean "thousands of packets per second", sorry if that's the wrong shorthand. - em0 sees a traffic of 10...22 kpps in, and 15...35 kpps out.? In bits, it's 30...120Mbits/s in, and 100...210Mbits/s out.? Vlans configured are vlan100 and vlan200, and most of the traffic is on vlan100 (vlan200 sees 4kpps in / 0.5kpps out maximum, with the average at about one third of this).? em0 is the external interface, and its traffic corresponds to the sum of traffic through em1 and em2 - em1 has 5 vlans, and sees about 22kpps in / 11kpps out (maximum) - em2 has a single VLAN, and sees about 4...13kpps both in and out (almost equal in/out during most of the day) - em3 is a backup interface, with 2 VLANS, and is the only one which has seen no errors. Only the vlans on em0 are analyzed by ng_netflow, and the errors I'm seeing have started appearing days before netgraph was even loaded in the kernel. Tuning done: /boot/loader.conf: hw.em.rxd=4096 hw.em.txd=4096 Witout the above we were seeing way more errors, now they are reduced, but still come in bursts of over 1000 errors on em0. /etc/sysctl.conf: net.inet.ip.fastforwarding=1 dev.em.0.rx_processing_limit=300 dev.em.1.rx_processing_limit=300 dev.em.2.rx_processing_limit=300 dev.em.3.rx_processing_limit=300 Still seeing errros, after some searching the mailing lists we also added: # the four lines below are repeated for em1, em2, em3 dev.em.0.rx_int_delay=0 dev.em.0.rx_abs_int_delay=0 dev.em.0.tx_int_delay=0 dev.em.0.tx_abs_int_delay=0 Still getting errors, so I also added: net.inet.ip.intr_queue_maxlen=4096 net.route.netisr_maxqlen=1024 and kern.ipc.nmbclusters=655360 Also tried with rx_processing_limit set to -1 on all em interfaces, still getting errors. Looking at the shape of the error and packet graphs, there seems to be a correlation between the number of packets per second on em0 and the height of the error "spikes" on the error graph.? These spikes are spread throughout the day, with spaces (zones with no errors) of various lengths (10 minutes ... 2 hours spaces within the last 24 hours), but sometimes there are errors even in the lowest kpps times of the day. em0 and em1 error times are correlated, with all errors on the graph for em0 having a smaller corresponding error spike on em1 at the same time, and sometimes an error spike on em2. The old router was seeing about the same traffic, and had em0, em1, re0 and re1 network cards, and was only seeing errors on the em cards.? It was running 7.2-PRERELEASE/i386 Any suggestions would be greatly appreciated.? Please note that this is a live router, and I can't reboot it (unless absolutely necessary).? Tuning that can be applied without rebooting will be tried first. Here are some more details: Trimmed output of netstat -ni (sorry if there are line breaks): Name? ? Mtu Network? ? ???Address? ? ? ? ? ? ? Ipkts Ierrs? ? Opkts Oerrs? Coll em0? ? 1500 ? ? ? 00:14:22:xx:xx:xx 19744458839 15494721 24284439443? ???0? ???0 em1? ? 1500 ? ? ? 00:14:22:xx:xx:xx 12832245469 123181 10105031790? ???0? ???0 em2? ? 1500 ? ? ? 00:04:23:xx:xx:xx 12082552403 10964 10339416865? ???0? ???0 em3? ? 1500 ? ? ? 00:04:23:xx:xx:xx 79912337? ???0 48178737? ???0? ???0 Relevant part of pciconf -vl: em0@pci0:6:7:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 ? ? vendor? ???= 'Intel Corporation' ? ? device? ???= '82541EI Gigabit Ethernet Controller' ? ? class? ? ? = network ? ? subclass???= ethernet em1@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 ? ? vendor? ???= 'Intel Corporation' ? ? device? ???= '82541EI Gigabit Ethernet Controller' ? ? class? ? ? = network ? ? subclass???= ethernet em2@pci0:9:4:0: class=0x020000 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 ? ? vendor? ???= 'Intel Corporation' ? ? device? ???= '82546EB Dual Port Gigabit Ethernet Controller (Copper)' ? ? class? ? ? = network ? ? subclass???= ethernet em3@pci0:9:4:1: class=0x020000 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 ? ? vendor? ???= 'Intel Corporation' ? ? device? ???= '82546EB Dual Port Gigabit Ethernet Controller (Copper)' ? ? class? ? ? = network ? ? subclass???= ethernet Kernel messages after sysctl dev.em.0.stats=1: (note that I've removed the lines which only showed zeros in the second and third outputs) em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 15435312 em0: Receive No Buffers = 16446113 em0: Receive Length Errors = 0 em0: Receive errors = 1 em0: Crc errors = 2 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 96826 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 19002068797 em0: Good Packets Xmtd = 23168462599 em0: TSO Contexts Xmtd = 0 em0: TSO Contexts Failed = 0 [later] em0: Excessive collisions = 0 em0: Missed Packets = 15459111 em0: Receive No Buffers = 16447082 em0: Receive errors = 1 em0: Crc errors = 2 em0: RX overruns = 96835 em0: Good Packets Rcvd = 19165047284 em0: Good Packets Xmtd = 23386976960 [later] em0: Excessive collisions = 0 em0: Missed Packets = 15470583 em0: Receive No Buffers = 16447686 em0: Receive errors = 1 em0: Crc errors = 2 em0: RX overruns = 96840 em0: Good Packets Rcvd = 19255466068 em0: Good Packets Xmtd = 23519004546 Thank you for your time. From killing at multiplay.co.uk Sat Aug 1 23:14:35 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Aug 1 23:14:41 2009 Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org><5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk> <5D267A3F22FD854F8F48B3D2B523819339EC2B524E@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: Thanks for the update David, if there is anything we can do to help let us know. Regards Steve ----- Original Message ----- From: "David Christensen" > Anyone point me in the right direction on how to add the phy > to support these machine? > > Seems like its just a matter of adding the PHY details to > miidevs but how do I find out the specifics of that? Sorry, this is the 5709S and I haven't had an opportunity to implement this PHY yet. Unfortunately it's more than just a change to miidevs since the SerDes is actually an IEEE clause 45 compliant device (instead of the more common Clause 22 devices found in 1GbE controllers). The registers are diffrerent so the effort is more substantial. No estimate yet on when I can get to it. Dave _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From peterjeremy at optushome.com.au Sun Aug 2 12:35:08 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Aug 2 12:35:15 2009 Subject: kern/137317: [tcp] logs full of syncache problems In-Reply-To: <200907312352.n6VNqEge015819@freefall.freebsd.org> References: <200907312352.n6VNqEge015819@freefall.freebsd.org> Message-ID: <20090802100644.GA74485@server.vk2pj.dyndns.org> I've run into what appears to be the same issue. Approaching it from the other direction: I have a pair on boxes running 7.2-RELEASE/i386 and have found that they are generating stray RST packets. As an example, ssh server echo hello will generate a sequence like the following (as seen on the server): 10:03:29.277427 IP client.55871 > server.22: S 1808736437:1808736437(0) win 49640 10:03:29.277674 IP server.22 > client.55871: S 3948204651:3948204651(0) ack 1808736438 win 65535 10:03:29.278202 IP client.55871 > server.22: . ack 3948204652 win 49640 ... 10:03:30.078227 IP client.55871 > server.22: . ack 3948207204 win 49640 10:03:30.078637 IP client.55871 > server.22: P 1808738140:1808738172(32) ack 3948207204 win 49640 10:03:30.078732 IP client.55871 > server.22: F 1808738172:1808738172(0) ack 3948207204 win 49640 10:03:30.078751 IP server.22 > client.55871: . ack 1808738173 win 8212 10:03:30.079135 IP server.22 > client.55871: F 3948207204:3948207204(0) ack 1808738173 win 8212 10:03:30.079528 IP client.55871 > server.22: . ack 3948207205 win 49640 10:03:32.798071 IP server.22 > client.55871: R 3948207204:3948207204(0) win 0 10:03:32.798086 IP server.22 > client.55871: . ack 1808738173 win 0 10:03:32.798518 IP client.55871 > server.22: . ack 3948207205 win 49640 10:03:32.798608 IP server.22 > client.55871: R 3948207205:3948207205(0) win 0 The delay between the FIN/ACK and subsequent RST is normally about a second but varies between about 150msec and 3 seconds (and occasionally it doesn't generate a RST at all). When there are two sessions close together, RSTs for both sessions may be generated together: 10:37:25.345622 IP client.58124 > server.22: S 2602521411:2602521411(0) win 49640 10:37:25.345818 IP server.22 > client.58124: S 954205035:954205035(0) ack 2602521412 win 65535 10:37:25.346400 IP client.58124 > server.22: . ack 954205036 win 49640 ... 10:37:26.012584 IP client.58124 > server.22: . ack 954207508 win 49640 10:37:26.013295 IP client.58124 > server.22: P 2602523114:2602523146(32) ack 954207604 win 49640 10:37:26.013391 IP client.58124 > server.22: F 2602523146:2602523146(0) ack 954207604 win 49640 10:37:26.013421 IP server.22 > client.58124: . ack 2602523147 win 8208 10:37:26.014119 IP server.22 > client.58124: F 954207604:954207604(0) ack 2602523147 win 8208 10:37:26.014493 IP client.58124 > server.22: . ack 954207605 win 49640 10:37:27.264149 IP client.58128 > server.22: S 2603683222:2603683222(0) win 49640 10:37:27.264229 IP server.22 > client.58128: S 2795742829:2795742829(0) ack 2603683223 win 65535 10:37:27.264630 IP client.58128 > server.22: . ack 2795742830 win 49640 ... 10:37:27.889755 IP client.58128 > server.22: . ack 2795745382 win 49640 10:37:27.890051 IP client.58128 > server.22: P 2603684941:2603684973(32) ack 2795745382 win 49640 10:37:27.890146 IP client.58128 > server.22: F 2603684973:2603684973(0) ack 2795745382 win 49640 10:37:27.890203 IP server.22 > client.58128: . ack 2603684974 win 8212 10:37:27.890924 IP server.22 > client.58128: F 2795745382:2795745382(0) ack 2603684974 win 8212 10:37:27.891353 IP client.58128 > server.22: . ack 2795745383 win 49640 10:37:28.038288 IP server.22 > client.58124: R 954207604:954207604(0) win 0 10:37:28.038353 IP server.22 > client.58124: . ack 2602523147 win 0 10:37:28.038543 IP server.22 > client.58128: R 2795745382:2795745382(0) win 0 10:37:28.038556 IP server.22 > client.58128: . ack 2603684974 win 0 10:37:28.038754 IP client.58124 > server.22: . ack 954207605 win 49640 10:37:28.038869 IP server.22 > client.58124: R 954207605:954207605(0) win 0 10:37:28.038887 IP client.58128 > server.22: . ack 2795745383 win 49640 10:37:28.038984 IP server.22 > client.58128: R 2795745383:2795745383(0) win 0 The systems are using ipfw and have dummynet in the kernel but it isn't used. The type of client doesn't seem to matter (same behaviour with FreeBSD or Solaris clients) and it's not limited to ssh (that was just where I first noticed it). In conjection with the stray RST packets, I am also seeing TCP error messages in syslog: Jul 29 10:03:32 aalp05 kernel: TCP: [client]:55871 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:03:32 aalp05 kernel: TCP: [client]:55871 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58124 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58128 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58124 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58128 to [server]:22 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Note that the syslog message implies there is an incoming packet but tcpdump doesn't show one. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090802/73ced46e/attachment.pgp From barney_cordoba at yahoo.com Sun Aug 2 16:54:42 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Sun Aug 2 16:54:49 2009 Subject: em driver input errors In-Reply-To: <11420.28890.qm@web56404.mail.re3.yahoo.com> Message-ID: <210006.36085.qm@web63904.mail.re1.yahoo.com> --- On Sat, 8/1/09, alexpalias-bsdnet@yahoo.com wrote: > From: alexpalias-bsdnet@yahoo.com > Subject: em driver input errors > To: freebsd-net@freebsd.org > Date: Saturday, August 1, 2009, 9:05 AM > Good day > > I'm running a FreeBSD 7.2 router and I am seeing a lot of > input errors on one of the em interfaces (em0), coupled with > (at approximately the same times) much fewer errors on em1 > and em2.? Monitoring is done with SNMP from another > machine, and the CPU load as reported via SNMP is mostly > below 30%, with a couple of spikes up to 35%. > > Software description: > > - FreeBSD 7.2-RELEASE-p2, amd64 > - bsnmpd with modules: hostres and (from ports) snmp_ucd > - quagga 0.99.12 (running only zebra and bgpd) > - netgraph (ng_ether and ng_netflow) > > Hardware description: > > - Dell machine, dual Xeon 3.20 GHz, 4 GB RAM > - 2 x built-in gigabit interfaces (em0, em1) > - 1 x dual-port gigabit interface, PCI-X (em2, em3) [see > pciconf near the end] > > > The machine receives the global routing table ("netstat -nr > | wc -l" gives 289115 currently). > > All of the em interfaces are just configured "up", with > various vlan interfaces on them.? Note that I use "kpps" to > mean "thousands of packets per second", sorry if that's the > wrong shorthand. > > - em0 sees a traffic of 10...22 kpps in, and 15...35 kpps > out.? In bits, it's 30...120Mbits/s in, and > 100...210Mbits/s out.? Vlans configured are vlan100 and > vlan200, and most of the traffic is on vlan100 (vlan200 sees > 4kpps in / 0.5kpps out maximum, with the average at about > one third of this).? em0 is the external interface, and its > traffic corresponds to the sum of traffic through em1 and > em2 > > - em1 has 5 vlans, and sees about 22kpps in / 11kpps out > (maximum) > > - em2 has a single VLAN, and sees about 4...13kpps both in > and out (almost equal in/out during most of the day) > > - em3 is a backup interface, with 2 VLANS, and is the only > one which has seen no errors. > > Only the vlans on em0 are analyzed by ng_netflow, and the > errors I'm seeing have started appearing days before > netgraph was even loaded in the kernel. > > Tuning done: > > /boot/loader.conf: > hw.em.rxd=4096 > hw.em.txd=4096 > > Witout the above we were seeing way more errors, now they > are reduced, but still come in bursts of over 1000 errors on > em0. > > /etc/sysctl.conf: > net.inet.ip.fastforwarding=1 > dev.em.0.rx_processing_limit=300 > dev.em.1.rx_processing_limit=300 > dev.em.2.rx_processing_limit=300 > dev.em.3.rx_processing_limit=300 > > Still seeing errros, after some searching the mailing lists > we also added: > > # the four lines below are repeated for em1, em2, em3 > dev.em.0.rx_int_delay=0 > dev.em.0.rx_abs_int_delay=0 > dev.em.0.tx_int_delay=0 > dev.em.0.tx_abs_int_delay=0 > > Still getting errors, so I also added: > > net.inet.ip.intr_queue_maxlen=4096 > net.route.netisr_maxqlen=1024 > > and > > kern.ipc.nmbclusters=655360 > > > Also tried with rx_processing_limit set to -1 on all em > interfaces, still getting errors. > > Looking at the shape of the error and packet graphs, there > seems to be a correlation between the number of packets per > second on em0 and the height of the error "spikes" on the > error graph.? These spikes are spread throughout the day, > with spaces (zones with no errors) of various lengths (10 > minutes ... 2 hours spaces within the last 24 hours), but > sometimes there are errors even in the lowest kpps times of > the day. > > em0 and em1 error times are correlated, with all errors on > the graph for em0 having a smaller corresponding error spike > on em1 at the same time, and sometimes an error spike on > em2. > > The old router was seeing about the same traffic, and had > em0, em1, re0 and re1 network cards, and was only seeing > errors on the em cards.? It was running > 7.2-PRERELEASE/i386 > > > Any suggestions would be greatly appreciated.? Please note > that this is a live router, and I can't reboot it (unless > absolutely necessary).? Tuning that can be applied without > rebooting will be tried first. > > Here are some more details: > > Trimmed output of netstat -ni (sorry if there are line > breaks): > Name? ? Mtu Network? ? ???Address? ? ? ? ? ? > ? Ipkts Ierrs? ? Opkts Oerrs? Coll > em0? ? 1500 ? ? ? 00:14:22:xx:xx:xx > 19744458839 15494721 24284439443? ???0? ???0 > em1? ? 1500 ? ? ? 00:14:22:xx:xx:xx > 12832245469 123181 10105031790? ???0? ???0 > em2? ? 1500 ? ? ? 00:04:23:xx:xx:xx > 12082552403 10964 10339416865? ???0? ???0 > em3? ? 1500 ? ? ? 00:04:23:xx:xx:xx > 79912337? ???0 48178737? ???0? ???0 > > Relevant part of pciconf -vl: > > em0@pci0:6:7:0: class=0x020000 card=0x016d1028 > chip=0x10768086 rev=0x05 hdr=0x00 > ? ? vendor? ???= 'Intel Corporation' > ? ? device? ???= '82541EI Gigabit Ethernet > Controller' > ? ? class? ? ? = network > ? ? subclass???= ethernet > em1@pci0:7:8:0: class=0x020000 card=0x016d1028 > chip=0x10768086 rev=0x05 hdr=0x00 > ? ? vendor? ???= 'Intel Corporation' > ? ? device? ???= '82541EI Gigabit Ethernet > Controller' > ? ? class? ? ? = network > ? ? subclass???= ethernet > em2@pci0:9:4:0: class=0x020000 card=0x10128086 > chip=0x10108086 rev=0x01 hdr=0x00 > ? ? vendor? ???= 'Intel Corporation' > ? ? device? ???= '82546EB Dual Port Gigabit Ethernet > Controller (Copper)' > ? ? class? ? ? = network > ? ? subclass???= ethernet > em3@pci0:9:4:1: class=0x020000 card=0x10128086 > chip=0x10108086 rev=0x01 hdr=0x00 > ? ? vendor? ???= 'Intel Corporation' > ? ? device? ???= '82546EB Dual Port Gigabit Ethernet > Controller (Copper)' > ? ? class? ? ? = network > ? ? subclass???= ethernet > > Kernel messages after sysctl dev.em.0.stats=1: > (note that I've removed the lines which only showed zeros > in the second and third outputs) > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 15435312 > em0: Receive No Buffers = 16446113 > em0: Receive Length Errors = 0 > em0: Receive errors = 1 > em0: Crc errors = 2 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 96826 > em0: watchdog timeouts = 0 > em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 19002068797 > em0: Good Packets Xmtd = 23168462599 > em0: TSO Contexts Xmtd = 0 > em0: TSO Contexts Failed = 0 > > [later] > em0: Excessive collisions = 0 > em0: Missed Packets = 15459111 > em0: Receive No Buffers = 16447082 > em0: Receive errors = 1 > em0: Crc errors = 2 > em0: RX overruns = 96835 > em0: Good Packets Rcvd = 19165047284 > em0: Good Packets Xmtd = 23386976960 > > [later] > em0: Excessive collisions = 0 > em0: Missed Packets = 15470583 > em0: Receive No Buffers = 16447686 > em0: Receive errors = 1 > em0: Crc errors = 2 > em0: RX overruns = 96840 > em0: Good Packets Rcvd = 19255466068 > em0: Good Packets Xmtd = 23519004546 > Note that "most" pcix motherboards wire onboard NICs to 32bits and 33Mhz, mainly because its apparently easier to do so. Its likely that your add-on card is running at 64bits and 133Mhz. 32bits/33Mhz isn't really fast enough to manage gigabit traffic flows, as its max burst is only 1 Gb/s, so you really can't use them for any sort of primary traffic flow. Check with you MB manufacturer as they usually don't advertise it. Barney From linimon at FreeBSD.org Mon Aug 3 02:27:37 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 3 02:27:48 2009 Subject: kern/137372: [ral] FreeBSD doesn't support wireless interface from Asus Eee PC 1000H Message-ID: <200908030227.n732RaeS007077@freefall.freebsd.org> Old Synopsis: freeBSD doesn't support wireless interface from Asus Eee PC 1000H New Synopsis: [ral] FreeBSD doesn't support wireless interface from Asus Eee PC 1000H Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 3 02:27:06 UTC 2009 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=137372 From linimon at FreeBSD.org Mon Aug 3 02:29:40 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 3 02:29:51 2009 Subject: kern/137292: [ste] DFE-580TX not working properly Message-ID: <200908030229.n732Tct0007270@freefall.freebsd.org> Old Synopsis: DFE-580TX not working properly New Synopsis: [ste] DFE-580TX not working properly Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 3 02:29:09 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137292 From bugmaster at FreeBSD.org Mon Aug 3 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:09:23 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200908031107.n73B73Lv088721@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/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136803 net [sctp] [panic] Kernel panic and hanging on using SCTP o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/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 bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/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 o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [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 [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal 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 bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] 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/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 317 problems total. From vova at parallels.com Mon Aug 3 14:04:39 2009 From: vova at parallels.com (Vladimir Grebenschikov) Date: Mon Aug 3 14:04:46 2009 Subject: net/haproxy - some ideas Message-ID: <1249308273.1712.23.camel@localhost> Hi Recently I've looked into net/haproxy port on FreeBSD. Contrary to recent Linux there is no splice() functionality, so all data move between sockets is done through user-space. First idea - to use ksocket netgraph node to accept connections, and send data to both directions, theoretically it may give even better performance then using splice() syscall per every block of data. On first stage (while haproxy read/rewrite http headers) both ksocket nodes to be ended in user-space, initial negotiation finished - these nodes just connected to each other in kernel and no user-space interaction required for further data send through that pair. Second, probably you have tried ongoing splice work Suleiman Souhlal ? (not sure about current status) http://p4db.freebsd.org/branchView.cgi?BRANCH=ssouhlal_splice -- Vladimir B. Grebenschikov Project Manager, Automation Parallels Inc. vgrebenschikov@parallels.com From linimon at FreeBSD.org Mon Aug 3 15:22:32 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 3 15:22:44 2009 Subject: kern/137392: [ip] [panic] crash in ip_nat.c line 2577 Message-ID: <200908031522.n73FMVFn093313@freefall.freebsd.org> Old Synopsis: crash in ip_nat.c line 2577 New Synopsis: [ip] [panic] crash in ip_nat.c line 2577 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 3 15:21:16 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137392 From seklecki at noc.cfi.pgh.pa.us Mon Aug 3 18:57:48 2009 From: seklecki at noc.cfi.pgh.pa.us (Brian A. Seklecki) Date: Mon Aug 3 18:58:09 2009 Subject: net.inet.tcp.keepidle and friends Message-ID: <1249325867.19746.9.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> All: The description on this sysctl was just recently added in -CURRENT. It was missing during all of RELENG_6 and RELENG_7? Do we not trust it entirely, ergo the two hour initial threshold and lack of documentation? It also seems like the description could be bit more insightful; looks like it was rushed hence pith / lack of capitalization. netbsd5# sysctl -d net.inet.tcp.keepidle net.inet.tcp.keepidle: Allowed connection idle ticks before a keepalive probe is sent fbsdhead$ sysctl -d net.inet.tcp.keepidle net.inet.tcp.keepidle: time before keepalive probes begin keepalive probe is sent ~BAS From delphij at delphij.net Mon Aug 3 19:41:22 2009 From: delphij at delphij.net (Xin LI) Date: Mon Aug 3 19:41:29 2009 Subject: em(4): sending ARP regardless of NOARP flag Message-ID: <4A773D09.3030404@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Jack, I have observed that, even if -arp is specified when adding an IP address to the em(4) interface, an ARP request is still being sent. Here is a tcpdump from my network environment: 11:15:01.370256 00:13:72:66:b5:d7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has *.*.152.120 tell *.*.152.120, length 46 11:15:01.370270 00:15:17:92:39:0e > 00:13:72:66:b5:d7, ethertype ARP (0x0806), length 42: Reply *.*.152.120 is-at 00:00:5e:00:01:07, length 28 (The first ARP request was sent from a Dell branded Intel 82541EI based NIC, the latter is from a cheaper server that is part of CARP configuration which is unrelated to the problem in response to the ARP request) I was originally under the impression that there is some bug in our ARP code but with a bce(4) card, the problem does not exist. After a glance at e1000 driver code, it looks like that the e1000 NIC has a feature of hardware interception of ARP, can this be somehow connected? The hardware in question is 82541EI based: em1@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet Thanks in advance! Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkp3PQkACgkQi+vbBBjt66A2CQCgt+8prSPRDKdOb61gdfj1zpcF q28An1/UXuo0bcEi4nwlUpYuqD8hR5Lo =56SA -----END PGP SIGNATURE----- From bms at incunabulum.net Tue Aug 4 07:39:41 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Aug 4 07:39:48 2009 Subject: net.inet.tcp.keepidle and friends In-Reply-To: <1249325867.19746.9.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> References: <1249325867.19746.9.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <4A77E5B9.3060902@incunabulum.net> Brian A. Seklecki wrote: > All: > > The description on this sysctl was just recently added in -CURRENT. It > was missing during all of RELENG_6 and RELENG_7? Do we not trust it > entirely, ergo the two hour initial threshold and lack of documentation? > I believe this has just been down to a lack of free time. I keep a copy of TII vol 2 around just in case I ever have to hack TCP; most of the time, it's a doorstop (all the code in almost every chapter of that book has significantly changed). > ... > fbsdhead$ sysctl -d net.inet.tcp.keepidle > net.inet.tcp.keepidle: time before keepalive probes > begin keepalive probe is sent > This is orthogonal, but: When responding to a bug report at $DAYJOB, I eyeballed the SYN-SENT timer code a week ago Sunday, and it looked to me like this knob was also controlling that TCP timer. However, correct me if I'm wrong: in RELENG_7 at least, it looked to me as though unacknowledged initial SYNs are not going to be retransmitted for an active TCP open due to connect() by FreeBSD, which looks like a regression. Is this really the case? The bug report in question was about a component wrapper for TCP sockets, which can't provide an API guarantee about TCP socket behaviour; it is implementation defined behaviour, and in this case, FreeBSD's TCP is the implementation. From reko.turja at liukuma.net Tue Aug 4 10:30:06 2009 From: reko.turja at liukuma.net (Reko Turja) Date: Tue Aug 4 10:30:12 2009 Subject: kern/129352: [xl] [patch] xl0 watchdog timeout Message-ID: <200908041030.n74AU5sj003737@freefall.freebsd.org> The following reply was made to PR kern/129352; it has been noted by GNATS. From: "Reko Turja" To: , Cc: Subject: Re: kern/129352: [xl] [patch] xl0 watchdog timeout Date: Tue, 4 Aug 2009 13:10:07 +0300 After updating my firewall box to 7.2-STABLE I started getting the=20 watchdog timeouts with the link state going down and returning back up=20 after couple of seconds on the xl interface. Some seeking from gnats=20 returned this bug report. I applied the patch succesfully on: src/sys/pci/if_xl.c,v 1.210.2.2 2008/04/23 21:28:29 and will give it a shot for some days in order to see if it breaks=20 something or if the watchdog timeouts still keep occurring. So far=20 rebooting after fresh kernel seems to be ok. =20 From jfvogel at gmail.com Tue Aug 4 17:11:55 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Aug 4 17:12:02 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <4A773D09.3030404@delphij.net> References: <4A773D09.3030404@delphij.net> Message-ID: <2a41acea0908041011kaba6ab0ra6fec3b309fc42ef@mail.gmail.com> I don't see how arping or not can be a driver problem, the driver just sends packets queued by the stack, there exists NO mechanism to communicate that kind of thing down into the driver, -arp is something that must be negotiated in the stack somewhere, as for it working with broadcom... Jack On Mon, Aug 3, 2009 at 12:39 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Jack, > > I have observed that, even if -arp is specified when adding an IP > address to the em(4) interface, an ARP request is still being sent. > Here is a tcpdump from my network environment: > > 11:15:01.370256 00:13:72:66:b5:d7 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has *.*.152.120 tell *.*.152.120, length > 46 > 11:15:01.370270 00:15:17:92:39:0e > 00:13:72:66:b5:d7, ethertype ARP > (0x0806), length 42: Reply *.*.152.120 is-at 00:00:5e:00:01:07, length 28 > > (The first ARP request was sent from a Dell branded Intel 82541EI based > NIC, the latter is from a cheaper server that is part of CARP > configuration which is unrelated to the problem in response to the ARP > request) > > I was originally under the impression that there is some bug in our ARP > code but with a bce(4) card, the problem does not exist. After a glance > at e1000 driver code, it looks like that the e1000 NIC has a feature of > hardware interception of ARP, can this be somehow connected? The > hardware in question is 82541EI based: > > em1@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > > Thanks in advance! > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (FreeBSD) > > iEYEARECAAYFAkp3PQkACgkQi+vbBBjt66A2CQCgt+8prSPRDKdOb61gdfj1zpcF > q28An1/UXuo0bcEi4nwlUpYuqD8hR5Lo > =56SA > -----END PGP SIGNATURE----- > From julian at elischer.org Tue Aug 4 17:22:55 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 17:23:01 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <2a41acea0908041011kaba6ab0ra6fec3b309fc42ef@mail.gmail.com> References: <4A773D09.3030404@delphij.net> <2a41acea0908041011kaba6ab0ra6fec3b309fc42ef@mail.gmail.com> Message-ID: <4A786E80.5020201@elischer.org> Jack Vogel wrote: > I don't see how arping or not can be a driver problem, the driver just sends > packets queued by the stack, there exists NO mechanism to communicate > that kind of thing down into the driver, -arp is something that must be > negotiated in the stack somewhere, as for it working with broadcom... > > except for the system management stuff. From jfvogel at gmail.com Tue Aug 4 18:02:46 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Aug 4 18:02:52 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <4A786E80.5020201@elischer.org> References: <4A773D09.3030404@delphij.net> <2a41acea0908041011kaba6ab0ra6fec3b309fc42ef@mail.gmail.com> <4A786E80.5020201@elischer.org> Message-ID: <2a41acea0908041102h4249faa4r8db4f9178f0ca172@mail.gmail.com> Ya, except that's when the hardware 'eats' the arp that the OS sends, not one where it sends one the OS doesn't want :) This is the first I've even heard of this option, but I can't see how its a driver thing, either the stack sends an arp packet or it doesnt, right? jack On Tue, Aug 4, 2009 at 10:23 AM, Julian Elischer wrote: > Jack Vogel wrote: > >> I don't see how arping or not can be a driver problem, the driver just >> sends >> packets queued by the stack, there exists NO mechanism to communicate >> that kind of thing down into the driver, -arp is something that must be >> negotiated in the stack somewhere, as for it working with broadcom... >> >> >> > except for the system management stuff. > From qing.li at bluecoat.com Tue Aug 4 18:40:09 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Tue Aug 4 18:40:17 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <4A773D09.3030404@delphij.net> References: <4A773D09.3030404@delphij.net> Message-ID: Is this on -CURRENT ? --Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Xin LI > Sent: Monday, August 03, 2009 12:40 PM > To: Jack F Vogel > Cc: freebsd-net@freebsd.org > Subject: em(4): sending ARP regardless of NOARP flag > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Jack, > > I have observed that, even if -arp is specified when adding an IP > address to the em(4) interface, an ARP request is still being sent. > Here is a tcpdump from my network environment: > > 11:15:01.370256 00:13:72:66:b5:d7 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has *.*.152.120 tell *.*.152.120, > length 46 > 11:15:01.370270 00:15:17:92:39:0e > 00:13:72:66:b5:d7, ethertype ARP > (0x0806), length 42: Reply *.*.152.120 is-at 00:00:5e:00:01:07, length > 28 > > (The first ARP request was sent from a Dell branded Intel 82541EI based > NIC, the latter is from a cheaper server that is part of CARP > configuration which is unrelated to the problem in response to the ARP > request) > > I was originally under the impression that there is some bug in our ARP > code but with a bce(4) card, the problem does not exist. After a > glance > at e1000 driver code, it looks like that the e1000 NIC has a feature of > hardware interception of ARP, can this be somehow connected? The > hardware in question is 82541EI based: > > em1@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 > rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > > Thanks in advance! > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (FreeBSD) > > iEYEARECAAYFAkp3PQkACgkQi+vbBBjt66A2CQCgt+8prSPRDKdOb61gdfj1zpcF > q28An1/UXuo0bcEi4nwlUpYuqD8hR5Lo > =56SA > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Aug 4 18:46:51 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 18:46:58 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <2a41acea0908041102h4249faa4r8db4f9178f0ca172@mail.gmail.com> References: <4A773D09.3030404@delphij.net> <2a41acea0908041011kaba6ab0ra6fec3b309fc42ef@mail.gmail.com> <4A786E80.5020201@elischer.org> <2a41acea0908041102h4249faa4r8db4f9178f0ca172@mail.gmail.com> Message-ID: <4A78822D.1080507@elischer.org> Jack Vogel wrote: > Ya, except that's when the hardware 'eats' the arp that the OS sends, > not one > where it sends one the OS doesn't want :) > > This is the first I've even heard of this option, but I can't see how its a > driver thing, either the stack sends an arp packet or it doesnt, right? noarp is supposed to stop it responding to arps too. it won't stop IPMI from doing it though. just an idea > > jack > > > On Tue, Aug 4, 2009 at 10:23 AM, Julian Elischer > wrote: > > Jack Vogel wrote: > > I don't see how arping or not can be a driver problem, the > driver just sends > packets queued by the stack, there exists NO mechanism to > communicate > that kind of thing down into the driver, -arp is something that > must be > negotiated in the stack somewhere, as for it working with > broadcom... > > > > except for the system management stuff. > > From delphij at delphij.net Tue Aug 4 18:59:59 2009 From: delphij at delphij.net (Xin LI) Date: Tue Aug 4 19:00:07 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: References: <4A773D09.3030404@delphij.net> Message-ID: <4A7884DA.2020006@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Li, Qing wrote: > Is this on -CURRENT ? No, it's 7.2-RELEASE-p2. > --Qing > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Xin LI >> Sent: Monday, August 03, 2009 12:40 PM >> To: Jack F Vogel >> Cc: freebsd-net@freebsd.org >> Subject: em(4): sending ARP regardless of NOARP flag >> > Hi, Jack, > > I have observed that, even if -arp is specified when adding an IP > address to the em(4) interface, an ARP request is still being sent. > Here is a tcpdump from my network environment: > > 11:15:01.370256 00:13:72:66:b5:d7 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has *.*.152.120 tell *.*.152.120, > length 46 > 11:15:01.370270 00:15:17:92:39:0e > 00:13:72:66:b5:d7, ethertype ARP > (0x0806), length 42: Reply *.*.152.120 is-at 00:00:5e:00:01:07, length > 28 > > (The first ARP request was sent from a Dell branded Intel 82541EI >> based > NIC, the latter is from a cheaper server that is part of CARP > configuration which is unrelated to the problem in response to the ARP > request) > > I was originally under the impression that there is some bug in our >> ARP > code but with a bce(4) card, the problem does not exist. After a > glance > at e1000 driver code, it looks like that the e1000 NIC has a feature >> of > hardware interception of ARP, can this be somehow connected? The > hardware in question is 82541EI based: > > em1@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 > rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > > Thanks in advance! > > Cheers, _______________________________________________ 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" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkp4hNkACgkQi+vbBBjt66Bo0ACbBWVUdrEmwqaiRUYmezoMukqA lskAnRPsFHa+BssSt4sBnPDKDhj+sczw =dKzv -----END PGP SIGNATURE----- From maxiter at inetu.net Wed Aug 5 13:20:08 2009 From: maxiter at inetu.net (Mark Rekai) Date: Wed Aug 5 13:20:15 2009 Subject: kern/137392: [ip] [panic] crash in ip_nat.c line 2577 Message-ID: <200908051320.n75DK8eO013540@freefall.freebsd.org> The following reply was made to PR kern/137392; it has been noted by GNATS. From: Mark Rekai To: "bug-followup@FreeBSD.org" , "mark@inetu.net" Cc: Subject: Re: kern/137392: [ip] [panic] crash in ip_nat.c line 2577 Date: Wed, 5 Aug 2009 08:57:15 -0400 This appears to duplicate http://www.freebsd.org/cgi/query-pr.cgi?pr=3D1316= 01&cat=3D. I have inspected the last packet handled. The IP header appears intact and= valid, but everything from that point onward (TCP header and payload) is g= arbage.= From davidch at broadcom.com Wed Aug 5 20:55:50 2009 From: davidch at broadcom.com (David Christensen) Date: Wed Aug 5 20:55:56 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <2a41acea0908041102h4249faa4r8db4f9178f0ca172@mail.gmail.com> References: <4A773D09.3030404@delphij.net> <2a41acea0908041011kaba6ab0ra6fec3b309fc42ef@mail.gmail.com> <4A786E80.5020201@elischer.org> <2a41acea0908041102h4249faa4r8db4f9178f0ca172@mail.gmail.com> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> > >> I don't see how arping or not can be a driver problem, the driver > >> just sends packets queued by the stack, there exists NO > mechanism to > >> communicate that kind of thing down into the driver, -arp is > >> something that must be negotiated in the stack somewhere, > as for it > >> working with broadcom... > >> > >> > >> > > except for the system management stuff. On the bce(9) driver does it display the "MFW" flag during driver load? That would indicate whether NC-SI style management firmware is running which would be unexpected on a NIC card. If the Intel LOM is connected to a baseboard management controller or service processor then the BMC or SP are likely generating the ARP. What's the source MAC address of the ARP? Does it match the LOM's MAC address or the MAC address of any BMC or SP? The latter would generally be printed on a tag on the system or perhaps in a BMC setup screen visible during POST. Dave From sergv326 at gmail.com Thu Aug 6 06:08:43 2009 From: sergv326 at gmail.com (serg vasilyev) Date: Thu Aug 6 06:08:49 2009 Subject: LACP support and if_tap interface Message-ID: Hi everyone. Can anyone modify if_tap interface to achieve LACP needs (probably add a virtual media i suspect)? I want to create an Ethernet tunnel with aggregation via openvpn but if_tap interface cannot give right internal capabilities for lagg and LACP to work properly From boseatjntu at yahoo.com Thu Aug 6 06:45:48 2009 From: boseatjntu at yahoo.com (bose vemuri) Date: Thu Aug 6 06:45:59 2009 Subject: How to build TCP/IP Stack. Message-ID: <764002.27248.qm@web62108.mail.re1.yahoo.com> Hi All, ? I have Installed FreeBSD on my Home PC. I would like to build TCP/IP stack module. please guide/help me to build the stack. ? Thank in advance, Bose. From julian at elischer.org Thu Aug 6 07:38:21 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 6 07:38:28 2009 Subject: How to build TCP/IP Stack. In-Reply-To: <764002.27248.qm@web62108.mail.re1.yahoo.com> References: <764002.27248.qm@web62108.mail.re1.yahoo.com> Message-ID: <4A7A886B.3060900@elischer.org> bose vemuri wrote: > Hi All, > > I have Installed FreeBSD on my Home PC. I would like to build TCP/IP stack module. please guide/help me to build the stack. > > Thank in advance, > Bose. > The tcp stackis not a separate module. there are parts of the system that are, but TCP/IP is not one of them. if you explained a bit more about what you want to do maybe we can help you... to recompile the system, assuming you have /usr/src installed. cd /usr/src; make buildkernel && make installkernel && reboot > > > _______________________________________________ > 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 denis.berezhnoy at gmail.com Thu Aug 6 08:38:06 2009 From: denis.berezhnoy at gmail.com (Denis Berezhnoy) Date: Thu Aug 6 08:38:12 2009 Subject: kevent behavior with TCP socket Message-ID: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> Hi guys, I have question regarding kevent behavior with TCP socket. Hope you can advise anything. I am trying to connect the server in non block mode. When I call connect it returns -1 and errno=EINPROGRESS. Then I use kqueue and kevent with EVFILT_WRITE and timeout 100 msec to wait when server will be available to accept connection. kevent returns me 1 event without any timeout (filters = -2 (EVFILT_WRITE) flags = 0 data = 43008) So I consider this as server is ready to accept connection but when I check socket error after kevent returns by getsockopt with SOL_SOCKET and SO_ERROR params it returns me socket error 54 ECONNRESET /* Connection reset by peer */ and no connection can be established using this socket. I am confused why kevent returns event that seems to indicate good condition but actual socket status indicates error. What I am doing wrong? Sorry for this rough description of the problem my code is the part of large system so I can not simply copy paste code. I am using: FreeBSD freebsd 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Best regards Denis From barney_cordoba at yahoo.com Thu Aug 6 11:20:03 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Aug 6 11:20:09 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <692150.91493.qm@web63906.mail.re1.yahoo.com> --- On Wed, 8/5/09, David Christensen wrote: > From: David Christensen > Subject: RE: em(4): sending ARP regardless of NOARP flag > To: "Jack Vogel" , "Julian Elischer" > Cc: "Jack F Vogel" , "freebsd-net@freebsd.org" , "d@delphij.net" > Date: Wednesday, August 5, 2009, 3:54 PM > > >> I don't see how arping > or not can be a driver problem, the driver > > >> just sends packets queued by the stack, there > exists NO > > mechanism to > > >> communicate that kind of thing down into the > driver, -arp is > > >> something that must be negotiated in the > stack somewhere, > > as for it > > >> working with broadcom... > > >> > > >> > > >> > > > except for the system management stuff. > > On the bce(9) driver does it display the "MFW" flag during > driver load?? That would indicate whether NC-SI style > management > firmware is running which would be unexpected on a NIC > card. > If the Intel LOM is connected to a baseboard management > controller > or service processor then the BMC or SP are likely > generating > the ARP.? What's the source MAC address of the > ARP?? Does it > match the LOM's MAC address or the MAC address of any BMC > or SP? > The latter would generally be printed on a tag on the > system or > perhaps in a BMC setup screen visible during POST. The em driver calls arp_ifinit() when an address is set which causes an ARP to go out when a new address is set. It seems that the ARP logic should know not to send it out, but you could certainly add a check in if_em to avoid calling that. It seems that Bill Paul cloned drivers don't use such logic so the broadcoms don't have it. Barney From boseatjntu at yahoo.com Thu Aug 6 12:59:05 2009 From: boseatjntu at yahoo.com (bose vemuri) Date: Thu Aug 6 12:59:12 2009 Subject: How to port/build TCP/IP Stack. In-Reply-To: <4A7A886B.3060900@elischer.org> Message-ID: <429535.52145.qm@web62106.mail.re1.yahoo.com> Hi, ? Thank you?for your reply. Actually we need to implement TCP/IP stack on Boot Loader(MIPS). We are planning to port FreeBSD TCP/IP Stack. Please help me out how can i proceed further.? ? Thanks in advance, Bose. --- On Thu, 8/6/09, Julian Elischer wrote: From: Julian Elischer Subject: Re: How to build TCP/IP Stack. To: "bose vemuri" Cc: freebsd-net@freebsd.org Date: Thursday, August 6, 2009, 1:08 PM bose vemuri wrote: > Hi All, >? I have Installed FreeBSD on my Home PC. I would like to build TCP/IP stack module. please guide/help me to build the stack. >? Thank in advance, > Bose. > The tcp stackis not a separate module. there are parts of the system that are, but TCP/IP is not one of them. if you explained a bit more about what you want to do maybe we can help you... to recompile the system, assuming you have /usr/src installed. cd /usr/src; make buildkernel && make installkernel && reboot > >? ? ???_______________________________________________ > 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 jfvogel at gmail.com Thu Aug 6 16:05:55 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Aug 6 16:06:02 2009 Subject: em(4): sending ARP regardless of NOARP flag In-Reply-To: <692150.91493.qm@web63906.mail.re1.yahoo.com> References: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> <692150.91493.qm@web63906.mail.re1.yahoo.com> Message-ID: <2a41acea0908060905n69edf1dfkbf993d9f8a4edf37@mail.gmail.com> Oh, hmmm, ok I'll look into that code. Thanks Barney. Jack On Thu, Aug 6, 2009 at 4:20 AM, Barney Cordoba wrote: > > > --- On Wed, 8/5/09, David Christensen wrote: > > > From: David Christensen > > Subject: RE: em(4): sending ARP regardless of NOARP flag > > To: "Jack Vogel" , "Julian Elischer" < > julian@elischer.org> > > Cc: "Jack F Vogel" , "freebsd-net@freebsd.org" < > freebsd-net@freebsd.org>, "d@delphij.net" > > Date: Wednesday, August 5, 2009, 3:54 PM > > > >> I don't see how arping > > or not can be a driver problem, the driver > > > >> just sends packets queued by the stack, there > > exists NO > > > mechanism to > > > >> communicate that kind of thing down into the > > driver, -arp is > > > >> something that must be negotiated in the > > stack somewhere, > > > as for it > > > >> working with broadcom... > > > >> > > > >> > > > >> > > > > except for the system management stuff. > > > > On the bce(9) driver does it display the "MFW" flag during > > driver load? That would indicate whether NC-SI style > > management > > firmware is running which would be unexpected on a NIC > > card. > > If the Intel LOM is connected to a baseboard management > > controller > > or service processor then the BMC or SP are likely > > generating > > the ARP. What's the source MAC address of the > > ARP? Does it > > match the LOM's MAC address or the MAC address of any BMC > > or SP? > > The latter would generally be printed on a tag on the > > system or > > perhaps in a BMC setup screen visible during POST. > > The em driver calls arp_ifinit() when an address is set which causes > an ARP to go out when a new address is set. It seems that > the ARP logic should know not to send it out, but you could certainly > add a check in if_em to avoid calling that. It seems that Bill Paul > cloned drivers don't use such logic so the broadcoms don't have it. > > Barney > > > > From ericx at ericx.net Thu Aug 6 20:58:34 2009 From: ericx at ericx.net (Eric W. Bates) Date: Thu Aug 6 20:58:45 2009 Subject: ipfw forwarding in GENERIC Message-ID: <4A7B40DE.8050301@ericx.net> I'm trying to wrap my head around freebsd-update. Is there a way to activate IPSEC and IPFIREWALL-FORWARD without building a custom kernel? Thanks for your time. From linimon at FreeBSD.org Thu Aug 6 22:29:32 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Aug 6 22:29:44 2009 Subject: bin/137484: [patch] Integer overflow in wpa_supplicant(8) base64 encoder Message-ID: <200908062229.n76MTVlV017817@freefall.freebsd.org> Old Synopsis: Integer overflow in wpa_supplicant base64 encoder New Synopsis: [patch] Integer overflow in wpa_supplicant(8) base64 encoder Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 6 22:28:46 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137484 From sergv326 at gmail.com Fri Aug 7 04:51:38 2009 From: sergv326 at gmail.com (serg vasilyev) Date: Fri Aug 7 04:51:44 2009 Subject: LACP support and if_tap interface In-Reply-To: References: Message-ID: Now i'm able to emulate a media and status on if_tap interface... tap0: flags=8802 metric 0 mtu 1500 ether 00:bd:49:f7:a6:00 media: Ethernet 100baseTX status: active BUT i suspect that there must be some another flag or capability of if_tap to work with LACP... can somebody tell me what flags exactly responsible for LACP functionality ? 2009/8/6, serg vasilyev : > Hi everyone. > Can anyone modify if_tap interface to achieve LACP needs (probably add > a virtual media i suspect)? > I want to create an Ethernet tunnel with aggregation via openvpn but > if_tap interface cannot give right internal capabilities for lagg and > LACP to work properly > From r.a.s.rajan at gmail.com Fri Aug 7 11:32:09 2009 From: r.a.s.rajan at gmail.com (Rajan (Algates)) Date: Fri Aug 7 11:32:16 2009 Subject: request for traffic generator tool for BSD Message-ID: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> Hi Friends, I am looking for a open source traffic generator tools for freebsd boxes, If any one using or can suggest any such tool, it would be really your help for me. Regards, Rajan From mike at sentex.net Fri Aug 7 12:14:28 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 7 12:14:34 2009 Subject: request for traffic generator tool for BSD In-Reply-To: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com > References: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> Message-ID: <200908071146.n77BknLt008289@lava.sentex.ca> At 07:08 AM 8/7/2009, Rajan (Algates) wrote: >Hi Friends, > >I am looking for a open source traffic generator tools for freebsd boxes, If >any one using or can suggest any such tool, it would be really your help for >me. cd /usr/ports/net/benchmarks/netperf or /usr/src/tools/tools/netrate/ for a start ---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 aurelien.ansel at netasq.com Fri Aug 7 12:35:18 2009 From: aurelien.ansel at netasq.com (=?ISO-8859-1?Q?Aur=E9lien_Ansel?=) Date: Fri Aug 7 12:35:25 2009 Subject: request for traffic generator tool for BSD In-Reply-To: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> References: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> Message-ID: <4A7C1BEB.6020606@netasq.com> Hi, you can take a look on Scapy, a open source packet crafter in Python: http://www.secdev.org/projects/scapy/doc/index.html Rajan (Algates) wrote: > Hi Friends, > > I am looking for a open source traffic generator tools for freebsd boxes, If > any one using or can suggest any such tool, it would be really your help for > me. > > Regards, > Rajan > _______________________________________________ > 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 r.a.s.rajan at gmail.com Fri Aug 7 15:55:30 2009 From: r.a.s.rajan at gmail.com (Rajan (Algates)) Date: Fri Aug 7 15:55:37 2009 Subject: request for traffic generator tool for BSD In-Reply-To: <200908071146.n77BknLt008289@lava.sentex.ca> References: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> <200908071146.n77BknLt008289@lava.sentex.ca> Message-ID: <3846aa350908070855l2b34920pb00e928832c1468b@mail.gmail.com> Mike, Great Thanks!! --Rajan On Fri, Aug 7, 2009 at 5:19 PM, Mike Tancsa wrote: > At 07:08 AM 8/7/2009, Rajan (Algates) wrote: > >> Hi Friends, >> >> I am looking for a open source traffic generator tools for freebsd boxes, >> If >> any one using or can suggest any such tool, it would be really your help >> for >> me. >> > > cd /usr/ports/net/benchmarks/netperf > or > /usr/src/tools/tools/netrate/ > > for a start > > ---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 barney_cordoba at yahoo.com Fri Aug 7 17:43:26 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri Aug 7 17:43:32 2009 Subject: request for traffic generator tool for BSD In-Reply-To: <200908071146.n77BknLt008289@lava.sentex.ca> Message-ID: <103469.71394.qm@web63903.mail.re1.yahoo.com> --- On Fri, 8/7/09, Mike Tancsa wrote: > From: Mike Tancsa > Subject: Re: request for traffic generator tool for BSD > To: "Rajan (Algates)" , freebsd-net@freebsd.org > Date: Friday, August 7, 2009, 7:49 AM > At 07:08 AM 8/7/2009, Rajan (Algates) > wrote: > >Hi Friends, > > > >I am looking for a open source traffic generator tools > for freebsd boxes, If > >any one using or can suggest any such tool, it would be > really your help for > >me. > > cd /usr/ports/net/benchmarks/netperf > or > /usr/src/tools/tools/netrate/ > > for a start > > ? ? ? ???---Mike What ever happened to the multi-threaded version of netperf? Barney From brampton+freebsd-net at gmail.com Fri Aug 7 22:46:24 2009 From: brampton+freebsd-net at gmail.com (Andrew Brampton) Date: Fri Aug 7 22:46:30 2009 Subject: request for traffic generator tool for BSD In-Reply-To: <103469.71394.qm@web63903.mail.re1.yahoo.com> References: <200908071146.n77BknLt008289@lava.sentex.ca> <103469.71394.qm@web63903.mail.re1.yahoo.com> Message-ID: 2009/8/7 Barney Cordoba : > > What ever happened to the multi-threaded version of netperf? > > Barney > A shameless plug, but a couple of years ago I needed a multi-threaded netperf app for my research, so instead of waiting for netperf to become multithreaded I wrote a similar app called "threadnetperf". It was a completely written from scratch and has little in common with netperf, but works exceedingly well, and has been used as the basis of a few academic papers. You can find it here: http://bramp.net/blog/threadnetperf-v1-0 Most of the testing has been done on Linux, but last time I checked it works on FreeBSD. I hope someone finds it useful. Andrew From bruce at cran.org.uk Fri Aug 7 23:00:15 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Aug 7 23:00:55 2009 Subject: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP Message-ID: <200908072300.n77N0ERJ077545@freefall.freebsd.org> The following reply was made to PR kern/136803; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, netch@segfault.kiev.ua Cc: Subject: Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP Date: Fri, 7 Aug 2009 23:41:13 +0100 It looks like revision 1.62.2.17 of /sys/netinet/sctp_pcb.c fixed this crash. Could you confirm whether the problem has been fixed? -- Bruce From netch at netch.kiev.ua Sat Aug 8 07:20:05 2009 From: netch at netch.kiev.ua (Valentin Nechayev) Date: Sat Aug 8 07:20:11 2009 Subject: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP Message-ID: <200908080720.n787K4tL075307@freefall.freebsd.org> The following reply was made to PR kern/136803; it has been noted by GNATS. From: Valentin Nechayev To: Bruce Cran Cc: bug-followup@FreeBSD.org Subject: Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP Date: Sat, 8 Aug 2009 10:06:06 +0300 Hi, Fri, Aug 07, 2009 at 23:41:13, bruce wrote about "Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP": > It looks like revision 1.62.2.17 of /sys/netinet/sctp_pcb.c fixed this > crash. Could you confirm whether the problem has been fixed? With this version, can't reproduce anymore. Thanks! -netch- From denis.berezhnoy at gmail.com Sat Aug 8 08:42:57 2009 From: denis.berezhnoy at gmail.com (Denis Berezhnoy) Date: Sat Aug 8 08:43:04 2009 Subject: kevent behavior with TCP socket In-Reply-To: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> Message-ID: <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> Hi, Sorry for my previous post it was completely unclear I believe. Here is problem description in pure C. Can you please take a look at the code below: #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct sockaddr_in addr; struct sockaddr_in addr2; int sd, cd, port, sRet; int sHandle; int sEventNum = 0; struct kevent sChange; struct kevent sEvent; struct timespec *sTimeoutPtr; struct timespec sTimeout; struct timeval sTimeVal1 = {0,0}; struct timeval sTimeVal2 = {0,0}; printf("Socket test start\n"); sd = socket(PF_INET, SOCK_STREAM, 0); if ( sd < 0 ) { printf("Server socket error\n"); return 0; } port = htons(10000); memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = port; addr.sin_addr.s_addr = htonl(INADDR_ANY); if ( bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0 ) { printf ("Server bind errror\n"); return 0; } if ( listen(sd, 1) != 0 ) { printf ("Server listen error \n"); return 0; } cd = socket(PF_INET, SOCK_STREAM, 0); if ( cd < 0 ) { printf("Client socket error\n"); return 0; } sRet = fcntl(cd, F_GETFL, 0); sRet |= O_NONBLOCK; sRet = fcntl(cd, F_SETFL, sRet); if (sRet < 0) { printf("can not set non block\n"); } port = htons(10000); memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ addr2.sin_family = AF_INET; /* Internet/IP */ addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ addr2.sin_port = port; /* server port */ /* Establish connection */ if ((sRet = connect(cd, (struct sockaddr *) &addr2, sizeof(addr2))) < 0) { printf("Failed to connect with server %d\n", errno); } sHandle = kqueue(); if (sHandle == -1) { printf("Poll can not created queue\n"); } sTimeout.tv_sec = 0; sTimeout.tv_nsec = 100000000;; EV_SET(&sChange, cd, EVFILT_WRITE, EV_ADD,0, 0, 0); gettimeofday(&sTimeVal1, NULL); sEventNum = kevent(sHandle, &sChange, 1, &sEvent, 1, &sTimeout); gettimeofday(&sTimeVal2, NULL); printf ("Kevent event num %d wait time %d \n", sEventNum, sTimeVal2.tv_usec - sTimeVal1.tv_usec); if (sEventNum == 1) { printf ("Event filter %d flag %d data %d \n", sEvent.filter, sEvent.flags, sEvent.data); } close(sHandle); close(cd); close(sd); printf("Socket test end\n"); } Program output Socket test start Failed to connect with server 36 Kevent event num 1 wait time 26 Event filter -2 flag 0 data 43008 Socket test end The question is why kevent returns 1 event when server does not accept connections from clients. Best regards, Denis 2009/8/6 Denis Berezhnoy > Hi guys, > > > I have question regarding kevent behavior with TCP socket. Hope you can > advise anything. > > > I am trying to connect the server in non block mode. When I call connect it > returns -1 and errno=EINPROGRESS. Then I use kqueue and kevent with > EVFILT_WRITE and timeout 100 msec to wait when server will be available to > accept connection. > > > kevent returns me 1 event without any timeout (filters = -2 (EVFILT_WRITE) > flags = 0 data = 43008) > > > > So I consider this as server is ready to accept connection but when I check > socket error after kevent returns by > > getsockopt with SOL_SOCKET and SO_ERROR params it returns me socket error > 54 ECONNRESET /* Connection reset by peer */ > > and no connection can be established using this socket. > > > I am confused why kevent returns event that seems to indicate good > condition but actual socket status indicates error. What I am doing wrong? > > > Sorry for this rough description of the problem my code is the part of > large system so I can not simply copy paste code. > > > I am using: > > > FreeBSD freebsd 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC > 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > > Best regards > > Denis > From simon at FreeBSD.org Sat Aug 8 09:39:52 2009 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Sat Aug 8 09:39:59 2009 Subject: request for traffic generator tool for BSD In-Reply-To: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> References: <3846aa350908070408g40a53f3o708b8f6bfd66396a@mail.gmail.com> Message-ID: <20090808093949.GA1252@arthur.nitro.dk> On 2009.08.07 16:38:12 +0530, Rajan (Algates) wrote: > I am looking for a open source traffic generator tools for freebsd boxes, If > any one using or can suggest any such tool, it would be really your help for > me. If you need something simple to send data very fast I would suggest looking at ng_source(4). Since it's kernel based it can achieve very high data rates, but it's less flexible in what you send than some of the useland generator programs. -- Simon L. Nielsen From pz-freebsd-net at ziemba.us Sun Aug 9 04:27:18 2009 From: pz-freebsd-net at ziemba.us (G. Paul Ziemba) Date: Sun Aug 9 04:27:25 2009 Subject: How to port/build TCP/IP Stack. References: <4A7A886B.3060900@elischer.org> <429535.52145.qm@web62106.mail.re1.yahoo.com> Message-ID: boseatjntu@yahoo.com (bose vemuri) writes: >Actually we need to implement TCP/IP stack on B >oot Loader(MIPS). We are planning to port FreeBSD TCP/IP Stack. Please help > me out how can i proceed further. An experienced developer could port IP, UDP, and TCP to an existing embedded system that already has an ethernet (or whatever lower layer you need) driver in a few weeks. You'll need to grab appropriate files from /usr/src/sys/netinet as well as the socket and mbuf related files from /usr/src/sys/kern and then connect it to the network driver for your physical interface. -- G. Paul Ziemba FreeBSD unix: 9:01PM up 13:05, 11 users, load averages: 0.02, 0.07, 0.07 From bms at FreeBSD.org Sun Aug 9 09:49:24 2009 From: bms at FreeBSD.org (bms@FreeBSD.org) Date: Sun Aug 9 09:49:30 2009 Subject: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP Message-ID: <200908090949.n799nN3K082156@freefall.freebsd.org> Synopsis: [sctp] [panic] Kernel panic and hanging on using SCTP State-Changed-From-To: open->closed State-Changed-By: bms State-Changed-When: Sun 9 Aug 2009 09:49:09 UTC State-Changed-Why: I committed the fix. Oops http://www.freebsd.org/cgi/query-pr.cgi?pr=136803 From ady at freebsd.ady.ro Sun Aug 9 12:09:31 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Aug 9 12:09:38 2009 Subject: kevent behavior with TCP socket In-Reply-To: <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> Message-ID: <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> Hi, On Sat, Aug 8, 2009 at 10:42 AM, Denis Berezhnoy wrote: > Hi, > > Sorry for my previous post it was completely unclear I believe. Here is > problem description in pure C. Can you please take a look at the code > below: > > #include > #include > #include > #include > #include > #include > #include > > #include > #include > #include > #include > > > > int main(int argc, char *argv[]) > { > struct sockaddr_in addr; > struct sockaddr_in addr2; > > int sd, cd, port, sRet; > > int sHandle; > int sEventNum = 0; > > struct kevent sChange; > struct kevent sEvent; > > struct timespec *sTimeoutPtr; > struct timespec sTimeout; > > struct timeval sTimeVal1 = {0,0}; > struct timeval sTimeVal2 = {0,0}; > > printf("Socket test start\n"); > > sd = socket(PF_INET, SOCK_STREAM, 0); > > if ( sd < 0 ) > { > printf("Server socket error\n"); > return 0; > } > > port = htons(10000); > > > memset(&addr, 0, sizeof(addr)); > addr.sin_family = AF_INET; > addr.sin_port = port; > addr.sin_addr.s_addr = htonl(INADDR_ANY); > > if ( bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0 ) > > { > printf ("Server bind errror\n"); > return 0; > } > > > > if ( listen(sd, 1) != 0 ) > { > printf ("Server listen error \n"); > return 0; > } > > > cd = socket(PF_INET, SOCK_STREAM, 0); > > if ( cd < 0 ) > { > printf("Client socket error\n"); > return 0; > } > > sRet = fcntl(cd, F_GETFL, 0); > > sRet |= O_NONBLOCK; > > sRet = fcntl(cd, F_SETFL, sRet); > > if (sRet < 0) > { > printf("can not set non block\n"); > } > > port = htons(10000); > > memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ > addr2.sin_family = AF_INET; /* Internet/IP */ > addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ > addr2.sin_port = port; /* server port */ > > /* Establish connection */ > > if ((sRet = connect(cd, > (struct sockaddr *) &addr2, > sizeof(addr2))) < 0) > { > > printf("Failed to connect with server %d\n", errno); > > } > > > sHandle = kqueue(); > > > if (sHandle == -1) > { > printf("Poll can not created queue\n"); > } > > sTimeout.tv_sec = 0; > sTimeout.tv_nsec = 100000000;; > > EV_SET(&sChange, cd, EVFILT_WRITE, EV_ADD,0, 0, 0); > > > gettimeofday(&sTimeVal1, NULL); > > sEventNum = kevent(sHandle, > &sChange, > 1, > &sEvent, > 1, > &sTimeout); > > gettimeofday(&sTimeVal2, NULL); > > printf ("Kevent event num %d wait time %d \n", sEventNum, sTimeVal2.tv_usec > - sTimeVal1.tv_usec); > > if (sEventNum == 1) > { > printf ("Event filter %d flag %d data %d \n", sEvent.filter, sEvent.flags, > sEvent.data); > } > > close(sHandle); > > close(cd); > > close(sd); > > printf("Socket test end\n"); > } > > Program output > > Socket test start > Failed to connect with server 36 > Kevent event num 1 wait time 26 > Event filter -2 flag 0 data 43008 > Socket test end > > The question is why kevent returns 1 event when server does not accept > connections from clients. > Question: is there something listening on your loopback address (127.0.0.1) or all addresses at port 10000 (sockstat -4 output should be evident) ? If not, have you also tested with something listening on that address ? If there is nothing to connect onto the loopback address then the connection will immediately fail. Then I believe kevent should return with a failure filter flag set. One problem I see is that you are checking the action flags (kevent.flags) instead of the filter flags (kevent.fflags). Please re-run checking the sEvent.fflags field and compare with values in and let us/me know what do you get. Regards, Adrian Penisoara EnterpriseBSD From ignatz at liukuma.net Sun Aug 9 12:50:28 2009 From: ignatz at liukuma.net (Reko Turja) Date: Sun Aug 9 12:52:19 2009 Subject: kern/129352: [xl] [patch] xl0 watchdog timeout Message-ID: <200908091250.n79CoRTv056645@freefall.freebsd.org> The following reply was made to PR kern/129352; it has been noted by GNATS. From: Reko Turja To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129352: [xl] [patch] xl0 watchdog timeout Date: Sun, 9 Aug 2009 14:56:44 +0300 (EEST) After running the patch from this PR for some days I still got some watchdog timeouts. As another approach, I'm trying the driver revision 1.4 from /src/sys/dev/xl/ (8.x sourcetree) which compiled clean on my system with sources updated as of today. My uname -a: FreeBSD xxx.org 7.2-STABLE FreeBSD 7.2-STABLE #10: Sun Aug 9 14:13:47 EEST 2009 root@xxx.org:/usr/obj/usr/src/sys/MORIA i386 The reason for trying 1.4 was the commit message: SVN rev 191345 on 2009-04-21 00:42:11Z by yongari To make it easy whether xl(4) missed Tx completion interrupt check number of queued packets in watchdog timeout handler. If there are no queued packets just print a informational message and return without resetting controller. Also fix to invoke correct Tx completion handler as 3C905B needs different handler. I will send a followup after testing the driver for a while - if it seems to work, is there any chance of backporting it for 7.x? -Reko From alireza.torabi at gmail.com Sun Aug 9 14:13:54 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Sun Aug 9 14:14:00 2009 Subject: 8. Current and Intel 5100 AGN wifi Message-ID: folks, Can anyone please shet any lights on this. are iwn & iwnfw going to support 5100 agn wifi? I've updated mine to 8. Current with iwn & iwnfw and still not going anywhere with the card. Thanks From linimon at FreeBSD.org Sun Aug 9 16:27:02 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Aug 9 16:27:08 2009 Subject: kern/137592: [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on network Message-ID: <200908091627.n79GR2lM021733@freefall.freebsd.org> Synopsis: [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on network Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 9 16:26:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137592 From denis.berezhnoy at gmail.com Mon Aug 10 03:17:23 2009 From: denis.berezhnoy at gmail.com (Denis Berezhnoy) Date: Mon Aug 10 03:17:31 2009 Subject: kevent behavior with TCP socket In-Reply-To: <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> Message-ID: <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> Hi Adrian, Thank for your answer! I checked that nobody listens for loopback address: [denis@freebsd ~]$ sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS denis sshd 95390 3 tcp4 192.168.1.103:22 192.168.11.26:53616 root sshd 95387 3 tcp4 192.168.1.103:22 192.168.11.26:53616 denis sshd 95324 3 tcp4 192.168.1.103:22 192.168.11.26:53608 root sshd 95321 3 tcp4 192.168.1.103:22 192.168.11.26:53608 root sshd 8149 4 tcp4 *:22 *:* root inetd 870 5 tcp4 *:21 *:* root inetd 870 6 tcp4 *:23 *:* root sendmail 821 4 tcp4 127.0.0.1:25 *:* root syslogd 689 7 udp4 *:514 *:* [denis@freebsd ~]$ I printed out fflags. Here is the result: Kevent event num 1 wait time 46 Event filter -2 flag 0 filter flags 0 data 43008 When I comment out the part of the code that listens socket then I have the following output: Kevent event num 1 wait time 23 Event filter -2 flag 32768 filter flags 61 data 32768 61 is ECONNREFUSED And more when I make loopback address listening and try to connect it I still get the same output: Socket test start Failed to connect with server 36 Kevent event num 1 wait time 23 Event filter -2 flag 0 filter flags 0 data 43008 Socket test end but connection is actually accepted. I am totally confused here. Best regards, Denis 2009/8/9 Adrian Penisoara > Hi, > > > On Sat, Aug 8, 2009 at 10:42 AM, Denis Berezhnoy < > denis.berezhnoy@gmail.com> wrote: > >> Hi, >> >> Sorry for my previous post it was completely unclear I believe. Here is >> problem description in pure C. Can you please take a look at the code >> below: >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #include >> #include >> #include >> #include >> >> >> >> int main(int argc, char *argv[]) >> { >> struct sockaddr_in addr; >> struct sockaddr_in addr2; >> >> int sd, cd, port, sRet; >> >> int sHandle; >> int sEventNum = 0; >> >> struct kevent sChange; >> struct kevent sEvent; >> >> struct timespec *sTimeoutPtr; >> struct timespec sTimeout; >> >> struct timeval sTimeVal1 = {0,0}; >> struct timeval sTimeVal2 = {0,0}; >> >> printf("Socket test start\n"); >> >> sd = socket(PF_INET, SOCK_STREAM, 0); >> >> if ( sd < 0 ) >> { >> printf("Server socket error\n"); >> return 0; >> } >> >> port = htons(10000); >> >> >> memset(&addr, 0, sizeof(addr)); >> addr.sin_family = AF_INET; >> addr.sin_port = port; >> addr.sin_addr.s_addr = htonl(INADDR_ANY); >> >> if ( bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0 ) >> >> { >> printf ("Server bind errror\n"); >> return 0; >> } >> >> >> >> if ( listen(sd, 1) != 0 ) >> { >> printf ("Server listen error \n"); >> return 0; >> } >> >> >> cd = socket(PF_INET, SOCK_STREAM, 0); >> >> if ( cd < 0 ) >> { >> printf("Client socket error\n"); >> return 0; >> } >> >> sRet = fcntl(cd, F_GETFL, 0); >> >> sRet |= O_NONBLOCK; >> >> sRet = fcntl(cd, F_SETFL, sRet); >> >> if (sRet < 0) >> { >> printf("can not set non block\n"); >> } >> >> port = htons(10000); >> >> memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ >> addr2.sin_family = AF_INET; /* Internet/IP */ >> addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ >> addr2.sin_port = port; /* server port */ >> >> /* Establish connection */ >> >> if ((sRet = connect(cd, >> (struct sockaddr *) &addr2, >> sizeof(addr2))) < 0) >> { >> >> printf("Failed to connect with server %d\n", errno); >> >> } >> >> >> sHandle = kqueue(); >> >> >> if (sHandle == -1) >> { >> printf("Poll can not created queue\n"); >> } >> >> sTimeout.tv_sec = 0; >> sTimeout.tv_nsec = 100000000;; >> >> EV_SET(&sChange, cd, EVFILT_WRITE, EV_ADD,0, 0, 0); >> >> >> gettimeofday(&sTimeVal1, NULL); >> >> sEventNum = kevent(sHandle, >> &sChange, >> 1, >> &sEvent, >> 1, >> &sTimeout); >> >> gettimeofday(&sTimeVal2, NULL); >> >> printf ("Kevent event num %d wait time %d \n", sEventNum, >> sTimeVal2.tv_usec >> - sTimeVal1.tv_usec); >> >> if (sEventNum == 1) >> { >> printf ("Event filter %d flag %d data %d \n", sEvent.filter, sEvent.flags, >> sEvent.data); >> } >> >> close(sHandle); >> >> close(cd); >> >> close(sd); >> >> printf("Socket test end\n"); >> } >> >> Program output >> >> Socket test start >> Failed to connect with server 36 >> Kevent event num 1 wait time 26 >> Event filter -2 flag 0 data 43008 >> Socket test end >> >> The question is why kevent returns 1 event when server does not accept >> connections from clients. >> > > Question: is there something listening on your loopback address > (127.0.0.1) or all addresses at port 10000 (sockstat -4 output should be > evident) ? If not, have you also tested with something listening on that > address ? > > If there is nothing to connect onto the loopback address then the > connection will immediately fail. Then I believe kevent should return with a > failure filter flag set. > > One problem I see is that you are checking the action flags > (kevent.flags) instead of the filter flags (kevent.fflags). Please re-run > checking the sEvent.fflags field and compare with values in > and let us/me know what do you get. > > Regards, > Adrian Penisoara > EnterpriseBSD > From ady at freebsd.ady.ro Mon Aug 10 07:31:46 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Mon Aug 10 07:31:52 2009 Subject: kevent behavior with TCP socket In-Reply-To: <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> Message-ID: <78cb3d3f0908100031k73301f88xef1bc9bf04730d09@mail.gmail.com> Hi, On Mon, Aug 10, 2009 at 5:17 AM, Denis Berezhnoy wrote: > Hi Adrian, > Thank for your answer! I checked that nobody listens for loopback address: > > [denis@freebsd ~]$ sockstat -4 > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > > denis sshd 95390 3 tcp4 192.168.1.103:22 > 192.168.11.26:53616 > root sshd 95387 3 tcp4 192.168.1.103:22 > 192.168.11.26:53616 > denis sshd 95324 3 tcp4 192.168.1.103:22 > 192.168.11.26:53608 > root sshd 95321 3 tcp4 192.168.1.103:22 > 192.168.11.26:53608 > root sshd 8149 4 tcp4 *:22 *:* > root inetd 870 5 tcp4 *:21 *:* > root inetd 870 6 tcp4 *:23 *:* > root sendmail 821 4 tcp4 127.0.0.1:25 *:* > root syslogd 689 7 udp4 *:514 *:* > [denis@freebsd ~]$ > > > I printed out fflags. Here is the result: > > Kevent event num 1 wait time 46 > Event filter -2 flag 0 filter flags 0 data 43008 > > > When I comment out the part of the code that listens socket then I have the > following output: > > Kevent event num 1 wait time 23 > Event filter -2 flag 32768 filter flags 61 data 32768 > > > 61 is ECONNREFUSED > > > And more when I make loopback address listening and try to connect it I > still get the same output: > > Socket test start > Failed to connect with server 36 > Kevent event num 1 wait time 23 > Event filter -2 flag 0 filter flags 0 data 43008 > Socket test end > > but connection is actually accepted. I am totally confused here. > Well, actually it's very much evident: * When you don't make the listen() first, then the connection is correctly reported as refused * When you make the listen() on the INADDR_ANY then you will open port 10000 on all local IP addresses, _including_ the loopback address -- that's why the client connect() succeeds and kevent reports a success event. This is an expected behavior. Try to bind the sd descriptor to another port than the one used to connect onto the loopback address and you will see the connection being refused. Regards, Adrian EnterpriseBSD From bugmaster at FreeBSD.org Mon Aug 10 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:08:53 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200908101107.n7AB70vT025240@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/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/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 bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/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 o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [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 [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal 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 bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] 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/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 319 problems total. From remko at FreeBSD.org Mon Aug 10 15:36:16 2009 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Aug 10 15:36:28 2009 Subject: misc/137641: Various problems with "vlan_device.vlan_id" syntax Message-ID: <200908101536.n7AFaFnB045951@freefall.freebsd.org> Synopsis: Various problems with "vlan_device.vlan_id" syntax Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Aug 10 15:36:01 UTC 2009 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=137641 From artis.caune at gmail.com Mon Aug 10 18:40:04 2009 From: artis.caune at gmail.com (Artis Caune) Date: Mon Aug 10 18:40:10 2009 Subject: bin/137641: ifconfig(8): various problems with "vlan_device.vlan_id" syntax Message-ID: <200908101840.n7AIe3Zf084075@freefall.freebsd.org> The following reply was made to PR bin/137641; it has been noted by GNATS. From: Artis Caune To: bug-followup@FreeBSD.org, vladimir.shebaldenkov@gmail.com Cc: Subject: Re: bin/137641: ifconfig(8): various problems with "vlan_device.vlan_id" syntax Date: Mon, 10 Aug 2009 21:33:20 +0300 --0016e659fbf0f99c790470cdd17e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, attached patch should fix automatic loading of if_vlan when creating interface as device.vlan_id and vlan module is not loaded. -- Artis Caune Everything should be made as simple as possible, but not simpler. --0016e659fbf0f99c790470cdd17e Content-Type: text/plain; charset=US-ASCII; name="device.vlan_id.patch.txt" Content-Disposition: attachment; filename="device.vlan_id.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fy7jgzm40 SW5kZXg6IGlmY29uZmlnLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaWZjb25maWcuYwkocmV2aXNpb24gMTk2 MDQ3KQorKysgaWZjb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtOTk4LDYgKzk5OCwxMCBAQAog CQkJYnJlYWs7CiAJCX0KIAorCS8qIHRyeSB0byBsb2FkIHZsYW4gbW9kdWxlIGlmIGludGVyZmFj ZSBuYW1lIGlzIGRldmljZS52bGFuX2lkICovCisJaWYgKGluZGV4KG5hbWUsICcuJykgIT0gTlVM TCkKKwkJc3RybGNweShpZm5hbWUsICJ2bGFuIiwgc2l6ZW9mKGlmbmFtZSkpOworCiAJLyogdHVy biBpbnRlcmZhY2UgYW5kIHVuaXQgaW50byBtb2R1bGUgbmFtZSAqLwogCXN0cmNweShpZmtpbmQs ICJpZl8iKTsKIAlzdHJsY3B5KGlma2luZCArIE1PRF9QUkVGSVhfTEVOLCBpZm5hbWUsCg== --0016e659fbf0f99c790470cdd17e-- From artis.caune at gmail.com Mon Aug 10 18:52:28 2009 From: artis.caune at gmail.com (Artis Caune) Date: Mon Aug 10 18:52:35 2009 Subject: bin/137641: ifconfig(8): various problems with "vlan_device.vlan_id" syntax In-Reply-To: <200908101840.n7AIe3Zf084075@freefall.freebsd.org> References: <200908101840.n7AIe3Zf084075@freefall.freebsd.org> Message-ID: <9e20d71e0908101152tcaf4cc3p83ff6de3ac1f1280@mail.gmail.com> 2009/8/10 Artis Caune : > The following reply was made to PR bin/137641; it has been noted by GNATS. > > ?Hi, > > ?attached patch should fix automatic loading of if_vlan when creating > ?interface as device.vlan_id and vlan module is not loaded. Here is a patch. -- Artis Caune Everything should be made as simple as possible, but not simpler. -------------- next part -------------- Index: ifconfig.c =================================================================== --- ifconfig.c (revision 196047) +++ ifconfig.c (working copy) @@ -998,6 +998,10 @@ break; } + /* try to load vlan module if interface name is device.vlan_id */ + if (index(name, '.') != NULL) + strlcpy(ifname, "vlan", sizeof(ifname)); + /* turn interface and unit into module name */ strcpy(ifkind, "if_"); strlcpy(ifkind + MOD_PREFIX_LEN, ifname, From denis.berezhnoy at gmail.com Wed Aug 12 01:15:13 2009 From: denis.berezhnoy at gmail.com (Denis Berezhnoy) Date: Wed Aug 12 01:15:20 2009 Subject: kevent behavior with TCP socket In-Reply-To: <78cb3d3f0908100031k73301f88xef1bc9bf04730d09@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> <78cb3d3f0908100031k73301f88xef1bc9bf04730d09@mail.gmail.com> Message-ID: <18b5e36e0908111815i6fe3322cu36fe6093097ce59f@mail.gmail.com> Hi Adrian, Thank you very much for clarification! Now it is clear for me. I have the last question. When I try to make mulltiple connections (loop over 100 client sockets) and check status of sockets by getsockopt then for the first couple connections everything seems OK, no error code but for the following connections I got socket error 54 ECONNRESET. I am concerned about it since I expected to get ECONNREFUSED. Here is code snippet (client thread the server part which listens socket is the same as in my previous example) and output void *ThreadFunc(void *arg) { struct sockaddr_in addr2; int cd[100], port; int sRet, i; int sHandle; int sEventNum = 0; struct kevent sChange; struct kevent sEvent; struct timespec *sTimeoutPtr; struct timespec sTimeout; struct timeval sTimeVal1 = {0,0}; struct timeval sTimeVal2 = {0,0}; for (i=0;i < 100; i++) { cd[i] = socket(AF_INET, SOCK_STREAM, 0); if ( cd[i] < 0 ) { printf("Client socket error\n"); return 0; } sRet = fcntl(cd[i], F_GETFL, 0); sRet |= O_NONBLOCK; sRet = fcntl(cd[i], F_SETFL, sRet); if (sRet < 0) { printf("can not set non block\n"); } port = htons(10000); memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ addr2.sin_family = AF_INET; /* Internet/IP */ addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ addr2.sin_port = port; /* server port */ /* Establish connection */ if ((sRet = connect(cd[i], (struct sockaddr *) &addr2, sizeof(addr2))) < 0) { printf("Failed to connect with server %d\n", errno); } sHandle = kqueue(); if (sHandle == -1) { printf("Poll can not created queue\n"); } sTimeout.tv_sec = 0; sTimeout.tv_nsec = 100000000;; EV_SET(&sChange, cd[i], EVFILT_WRITE, EV_ADD,0, 0, 0); gettimeofday(&sTimeVal1, NULL); sEventNum = kevent(sHandle, &sChange, 1, &sEvent, 1, &sTimeout); gettimeofday(&sTimeVal2, NULL); printf ("Kevent event num %d wait time %d \n", sEventNum, sTimeVal2.tv_usec - sTimeVal1.tv_usec); if (sEventNum == 1) { int aOptVal = 0; int aOptLen = sizeof(aOptVal); printf ("Event filter %d flag %d filter flags %d data %d \n", sEvent.filter, sEvent.flags, sEvent.fflags, sEvent.data); sRet = getsockopt(cd[i], SOL_SOCKET, SO_ERROR, &aOptVal, &aOptLen); printf("error %d sockopt ret %d\n", aOptVal, sRet); } close(sHandle); close(cd[i]); } pthread_exit(NULL); } OutputL Socket test start Failed to connect with server 36 Kevent event num 1 wait time 24 Event filter -2 flag 0 filter flags 0 data 43008 error 0 sockopt ret 0 Failed to connect with server 36 Kevent event num 1 wait time 21 Event filter -2 flag 0 filter flags 0 data 43008 error 0 sockopt ret 0 Failed to connect with server 36 Kevent event num 1 wait time 13 Event filter -2 flag 0 filter flags 0 data 43008 error 54 sockopt ret 0 Failed to connect with server 36 Kevent event num 1 wait time 20 Event filter -2 flag 0 filter flags 0 data 43008 error 54 sockopt ret 0 Best regards, Denis 2009/8/10 Adrian Penisoara > Hi, > > On Mon, Aug 10, 2009 at 5:17 AM, Denis Berezhnoy < > denis.berezhnoy@gmail.com> wrote: > >> Hi Adrian, >> Thank for your answer! I checked that nobody listens for loopback address: >> >> [denis@freebsd ~]$ sockstat -4 >> USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS >> >> denis sshd 95390 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53616 >> root sshd 95387 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53616 >> denis sshd 95324 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53608 >> root sshd 95321 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53608 >> root sshd 8149 4 tcp4 *:22 *:* >> root inetd 870 5 tcp4 *:21 *:* >> root inetd 870 6 tcp4 *:23 *:* >> root sendmail 821 4 tcp4 127.0.0.1:25 *:* >> root syslogd 689 7 udp4 *:514 *:* >> [denis@freebsd ~]$ >> >> >> I printed out fflags. Here is the result: >> >> Kevent event num 1 wait time 46 >> Event filter -2 flag 0 filter flags 0 data 43008 >> >> >> When I comment out the part of the code that listens socket then I have >> the following output: >> >> Kevent event num 1 wait time 23 >> Event filter -2 flag 32768 filter flags 61 data 32768 >> >> >> 61 is ECONNREFUSED >> >> >> And more when I make loopback address listening and try to connect it I >> still get the same output: >> >> Socket test start >> Failed to connect with server 36 >> Kevent event num 1 wait time 23 >> Event filter -2 flag 0 filter flags 0 data 43008 >> Socket test end >> >> but connection is actually accepted. I am totally confused here. >> > > Well, actually it's very much evident: > * When you don't make the listen() first, then the connection is correctly > reported as refused > * When you make the listen() on the INADDR_ANY then you will open port > 10000 on all local IP addresses, _including_ the loopback address -- that's > why the client connect() succeeds and kevent reports a success event. This > is an expected behavior. > > Try to bind the sd descriptor to another port than the one used to connect > onto the loopback address and you will see the connection being refused. > > Regards, > Adrian > EnterpriseBSD > From Jens.Kassel at birdstep.com Wed Aug 12 11:00:18 2009 From: Jens.Kassel at birdstep.com (Jens Kassel) Date: Wed Aug 12 11:00:26 2009 Subject: bin/127192: routed(8) removes the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 Message-ID: <200908121100.n7CB0I2m027373@freefall.freebsd.org> The following reply was made to PR bin/127192; it has been noted by GNATS. From: "Jens Kassel" To: , Cc: Subject: Re: bin/127192: routed(8) removes the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 Date: Wed, 12 Aug 2009 12:30:14 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1B37.E9011F13 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA1B37.E9011F13" ------_=_NextPart_002_01CA1B37.E9011F13 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I got a similar (or same) problem. I'm running FreeBSD 7.2 and running = RIP with following configuration. =20 # cat /etc/gateways if=3Drl0 no_ripv1_in no_ripv2_in ripv2_out rdisc_adv redirect_ok if=3Drl1 no_rip no_solicit no_rdisc_adv if=3Drl2 no_rip no_solicit no_rdisc_adv if=3Dvr0 no_rip no_solicit no_rdisc_adv if=3Dvlan1 no_rip no_solicit no_rdisc_adv if=3Dvlan3 no_rip no_solicit no_rdisc_adv if=3Dvlan4 no_rip no_solicit no_rdisc_adv if=3Dvlan2 no_rip no_solicit no_rdisc_adv if=3Dvlan99 no_rip no_solicit no_rdisc_adv if=3Dvlan313 no_rip no_solicit no_rdisc_adv if=3Dvlan9 no_rip no_solicit no_rdisc_adv if=3Dng0 no_rip no_solicit no_rdisc_adv if=3Dng1 no_rip no_solicit no_rdisc_adv subnet=3D10.1.1.0/24 subnet=3D172.16.99.0/24 if=3Dlo1 passive if=3Dlo2 passive if=3Dlo3 passive =20 # cat /etc/rc.conf.d/routed router_enable=3D"YES" router_flags=3D"-s" =20 Default route exists on rl0. =20 If I only have 1 IP address configured at rl0 it works fine. If I add a secondary (alias) address on rl0 routed will change the route = to default router to point to itself (primary rl0 address). =20 And it will toggle between "correct" and "incorrect" routing. =20 E.g rl0 has IP 217.13.255.147 255.255.255.192 and default router = 217.13.255.129. If adding a alias IP address the routing table will periodically = (toggle) have destination 217.13.255.129 pointed to 217.13.255.147 = (itself). =20 Also noted that with same version of routed (2.31) running on FreeBSD = 6.4 works fine. =20 Regards, =20 Jens =20 Jens Kassel Senior System Engineer Mobile: + 46 678 60 61 Email: jens.kassel@birdstep.com =20 =20 Birdstep Technology H=E4singegatan 32, 7th Floor SE-113 43 Stockholm, Sweden www.birdstep.com =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_002_01CA1B37.E9011F13 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I got a similar (or same) = =A0problem. I’m running FreeBSD 7.2 and running RIP with following = configuration.

 

# cat = /etc/gateways

if=3Drl0 no_ripv1_in no_ripv2_in = ripv2_out rdisc_adv redirect_ok

if=3Drl1 no_rip no_solicit = no_rdisc_adv

if=3Drl2 no_rip no_solicit = no_rdisc_adv

if=3Dvr0 no_rip no_solicit = no_rdisc_adv

if=3Dvlan1 no_rip no_solicit = no_rdisc_adv

if=3Dvlan3 no_rip no_solicit = no_rdisc_adv

if=3Dvlan4 no_rip no_solicit = no_rdisc_adv

if=3Dvlan2 no_rip no_solicit = no_rdisc_adv

if=3Dvlan99 no_rip no_solicit = no_rdisc_adv

if=3Dvlan313 no_rip no_solicit = no_rdisc_adv

if=3Dvlan9 no_rip no_solicit = no_rdisc_adv

if=3Dng0 no_rip no_solicit = no_rdisc_adv

if=3Dng1 no_rip no_solicit = no_rdisc_adv

subnet=3D10.1.1.0/24

subnet=3D172.16.99.0/24

if=3Dlo1 = passive

if=3Dlo2 = passive

if=3Dlo3 = passive

 

# cat = /etc/rc.conf.d/routed

router_enable=3D"YES"

router_flags=3D"-s"

 

Default route exists on = rl0.

 

If I only have 1 IP address = configured at rl0 it works fine.

If I add a secondary (alias) = address on rl0 routed will change the route to default router to point to itself = (primary rl0 address). =A0

And it will toggle between = “correct” and “incorrect” routing.

 

E.g rl0 has IP 217.13.255.147 = 255.255.255.192 and default router 217.13.255.129.

If adding a alias IP address the = routing table will periodically (toggle) have destination 217.13.255.129 pointed = to 217.13.255.147 (itself).

 

Also noted that with same = version of routed (2.31) running on FreeBSD 6.4 works fine.

 

Regards,

 

Jens

 

Jens Kassel

Senior System Engineer

Mobile: + 46 678 60 61

Email: jens.kassel@birdstep.com

 

Birdstep Technology

H=E4singegatan= 32, 7th Floor

SE-113 43 Stockholm, Sweden

www.birdstep.com

 

 

3D"mail_footer"=

 

 

 

------_=_NextPart_002_01CA1B37.E9011F13-- ------_=_NextPart_001_01CA1B37.E9011F13 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAUoAAAAnCAIAAADmVpZiAAAABGdBTUEAAK/INwWK6QAAABl0RVh0 U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAACxnSURBVHja3H15kF1nded3vnvf603qVmtX a5e8STaxIhskA2GzLSbYJFM4TKoGMlAsIZUayPzF1AyQqVQglZCpqcIhzFSmBkwWT6ocmyEawMYG 4gEby9iyjRfJ8oIkt6TW1upN6n7LvWfO+fbv3vteP5lhUkVbll7fd+93v+2c8zvrB5+55zkAEB1+ UAio+vz/9odbBvXPL8sPCoRf1Gz9Mw7K/PyyDeyX9yedmG6EZAVd17ELAULxS1j0QctV6FG0T9jP FTfRN1h6g7pf84YCk6h+Zec+gaVL23DFbUFfArYkVB/KrwJUXfa32Htcl10b6oq9r2r4wZMBo8VO 8y0qpyp4O6gPCEE/9Cfs/PLSjAFg8CroxAnc+sZzFU6Nf1k874UBop97P8X6bnW9JyFht4zfdFXb IFjraE7NegkBGN9ftc0Qq7ckz5xqDYLdJMqT0XEPF7dKtBMDukiTVBYX0ax6V0aOVcvfiwRQUxS2 j3pd7OIBQlEOFraTiHa4/Re6iBYzlT13N19cRkF8Q6eXQmGk4VKW51k9IrtQt9lU6sFcNfLzCVLo RRiXUZubH9CEBUWGA93YKlS2X3oLlHdj9Dm4KS/M2mKC6PWCF9Az3wuMDTeqwIodUx5g1X7ozuqh LDmC9eK/UrScL2wGe9sY+Dp3VEX7ZiQMagtdxjKAxxK1LPZSuKzehi13QaR4+S/F8EN5nt3ehZCa K1pGzxn/v8LyilHIAPL0ODMd2kfRbbCVOxNjjuN/5C9maoKZ731cWtrjYm1W7AcJiujNTsBOgBk6 LlBqyOl1S4FuFNabtt79FgkR+1SjNJqtA/KwmIKIl0XXpScgAhHVnceqdsCy546DXGSK8J9RzYVq zOmgEDqBAwaqaBzWdbxdJu31221+HimNxaWGy3s1VCEWLL3CqyGlN3QHGhbGK1LvTnQBhLJyIkWo hq3YwxSFShf0PMHlBcGy1gNQ0QHQGiL9LxWdg2Vt4YNm00UgRkLPO7qz5a8rBqvGXXYsooP6g5ev 3zhwjr9IExeKjspXiCRdN+wOArwsnQ0usz8dmuiufAWzXdFCF3rGSmW88OrK/V/UL50BCSo0X1iE dfn7ocsr/EDCTZVq8YidGUInZgveomUsxR2nDotGEqziEqHJJWauUBKOdjilXa5sWVITuX8dlG0g ENzjjTbghxy/UQOsiikCUS3aocK24jQOiPHt5YBD1YjECtWsdzLqHcxAyWLgt5MBjTFsBL++6Dvc bSNjZ8xQXvci04UQcEHHsbuvMN7MUIV5RRdNpDOqKaMAjTHd310130DqxnsS/TSKjiopFvG5I6U0 4CyAi6izVVwHu2F7AL8QWFpuKM64fwirzD+hVh5ubQxfJKUFQVBloIAOxgoo8R1YxJrWEweO1W+A RTk29KbS/1w2ost7EKqgJwAIXKRB6GQejAcLnR7s8G3B+gOL23iDbyGi0tc9jbDoQNBvJyjJyI67 BSBsB6JmobM1tGQbdzenWgaGMMMLnq4Th4tOjnNkScDQGgeLCBFc7I1YBU6KvbI8gAne8kGMTHla XEectZp/+BUMmRN0FZ8QS77QFQNFn9BlCdYy21qkJ/Fuwar7O3SmF56FrwMYAETbo6PdofO4ehxy 2dKJ+HpgTJfJr2ynMJ/RtpEWBlZwcnSiTRF6hAgqh1x+UdwbDc6hk1no59LvoDebxy/K+IueF0g1 c9LTnIUzUuR5hUjXf7Ds7oGYt8ausQL10t/S/R3PBki/iovw9c6zYxpRI1KYpcIbU4TMbgjBuIrL BD1b0KGrUaWA1kpzBbF1O8Kfjp/KznqDfF37QV5+fFaswXl1EDrgroCSRaz8mcVy+wE863dUaqSR eyr0ocuug7I3B4wg7by6l0fYr59mf1EGIgh5mTICITjjJf+qbpCJFUbG3ouYI1bAYChaIkSVViGi WbZ/GxNU5CqDEhSHKq0OuhgmMcBvICJPCUT2C98UgujIuwEWczhA7wsJVshDSdsMTKdQUH0wfFBA Z728Eh5XRL6U+9Mlaqn7uGx/1JwDdLux7CKQ8V7yzjC/b9CryW4dgy0BHTWCaA+YJYZAemPPK9iZ fXdEmdCD9b93P0HvLCS2haH1tyuLEDisbN0Oasb1XEq1FCzrE4GZyDN+PHcxTrHXRya8U/N2AThB URPzT0ExZDVqEHoSJnFTyh6L1tjZ2W6D4vIcP4tMcZcxlobjlSBLZtVXINq72MsrRNUjVSgosqVh DGNehyTvZSZjo2NogQMRjz36rPZmfH/1wkERMhTNWWk5TqwbSYKPLinFxsWYR2JEYQC9GJD4ukQf YYghloNqg2Voeyizboey7XeYpOLiBfHiw9hqiPqg2PFO6BtiiW2s/8jTISV9C+ePw/BKHFoBBOAT dKqrYQhaME2NY6sJKzez8w3QwXm0u9f+A5HCxRzBWxujXsPikxTPt/dFYQ9SqOilWMToA5dD+l2i ocCFYKKlDief7fYDrHwq6h5gJ16HpTEWBHogvUFxdYQKOLSYeHPgB7Da/1NYNxBlwzt4EBGCEYwX FEPmjxX2pjJkQCEKPDwVoU8QO4tna6gE2vqgAS1JtEwpQcBXeMuyrFP8QookUQ/kQt9TCG0qqqkB iNYTRw0qA6CNYbXboxBvzO9W6wQ21NVK5Cic2Vl7+aPErCnOvCIas6J/GK9+m0hIA6e2pGGZ3GQO zz4gxp/NB0fEG9+Py9ZBnhkuJkk3ynl3JjVx4nk8+E2Rt/GKt8KOd3KzBTgPoZvNqm0aI0s9Kyaq MnJMTp2CZ79j5unXPlq5AT2BRFsbqlwFoe8HquzeVqwBlp0EVbFSTqoU9IvQTgkl3IwFUKkXFSK5 Gu1BK3icAy7cQiGx6JvK5AUFo7XruYE8BtIFT5bioQNnMgpRCNaE2EwQcAsoK+0V2CcaqY+Yh2hO AKs1uY6OiGjtUoSSBwRLwW7Wv86rdPhhMXGEP1zxZth8PWZtcWlaPLMfFy7yFh/bQTQPJB6f+kfR buCKrXDtzSgDvmKNCSENBIZNfZFNBayu6A2Tm6iFwkbVEtISME8EOmMV+PXmf3K9ilZJIQol4pQ1 kdSF1JOr/9KcBUSGojknWguikQJRb5IwwRt+o/dkzk+0FqA1L9qZaM3JmuF6OVr0gQ4yB+5DCx4t f1M7OJdgLpbFB0SWTox9vIEmHWwAMGwzNDCW/MDeFCggslXEuzv0JkNkpzNCIYjrgPB6V83KrzXa UaBnxxByHb+Q0aiqpKL5xhqmSvIOiygGsKxgRlwCMMTR3fyYsuQuBuxgxgKzicDaeoI1MgbzqJM9 2DIxfNyzM4TUaPkQ8DcQPswVIxMgpnUgcDv5Gl9fsUlsuV6kNZw9BWePIRHD5Disv5bIEmdOi/Ov CUK/a67CtEYUYiwHxiuQeXzoLdsRllZmbivsHEaLNz8qvReYoHK0iEuYt+RR9okM+KqEOL6e5LAm cdSUyySe9uH17xGrtoqRNWLFBu4/d1xaglQGcYIqG69D4hQ0zA0786xtok8TdRvfTM3mhjflunHg njpaZNSjLklDSEaPWLrSdG7JSrNt3KjzINnIBfaBX6hQSHpBKjHaDHkcVxPpuzYQw8GNOPzPX8HS coRiFTv7zrGafVUg27LZCCokdLTVzcQYvahSa45kgtP/wV/0d0qocN4VRxGEjfiMCMDOChZKowK6 NS3Mht3JHWB/hVoF3NUcXR8sniVwXhXM5/O3pEaOzqaJYnRM9C+lPQ0Ls6LdJMVVzJylzS7q/WJm QmQN6BsUs+f5JcQLVmwQMuU3JylrsISHqY3+JTwAogeFckNrv9pgUjKFADYvkXgUaZ/oG2KazdpG FspUB2bK5iWRtZjY6I00COI7tAGb89hui4Eh7nqWKVaBYTirSEK7JT1Vg1aD3zUwAmlKz/LMY5sJ mzA53dNusuhmVqJ4U3sBmgvcTq0fqG/b38TtZC36QyNB6hvDjSxvzJEOoDo/yH5/aEn6ln6k+o2w A92zQAChhfUBaod5H+N/BgU8k/qn1mfN7zYqUIqipq1HhrEfJfTdmGfB+1pkMa5IRLF/BUxbgNng 3TZl27zbiLIDvWo3YYV0L2UAuo2YdzAtVf4KUJ2dW4i2KIUGRXFQ5TuhClnH43AwRKjNK3KrChQS XRGLHLA4V4gQB4G6kCtvNyzmvjLnNXtDhspEqvXosl0CwcV3o9dsqZ3hVXl9gDa9mD0rswZmNTF7 Tg0tEdOnZbsh+gfx4iRT79AoLBnlbtGGPvYMHj2Ic+e5xaWrxBVvkmPXMPlJ0xUl25XobTXzl57E 00fExWnW5ImuiNKu2gurtgJkHI959qg49jS9i/ACthuwYpN84x1ECXz9pR/npLgSIyAOsmmX3P5G kqWYK/4kFQrW06lhEV3K2vkT32BLG9HVwDD1Cja+gcfdXsDH78ELp3LiNLtuk2u24ex58epP8Nxx 0bwoWk1B19/2O3j6ZTz0TzzV666S179btFs4/lM8dVjMnCP2l5OSQhxnyUrYdqMYu5q7gcoPR2T/ yk/y8WdxdhKoa7U69i2Vm98gN1+f82LkeR479xC9STOSzODVPQmxcQoCEIulcAaXBGIDAQCiUByP AqJ9/Zaxr9+y8ct/dOCJG1bf9+rUnsnmmCMI89VjP4nsuSjesp6u/8UfHfgJBvgfPbPJrSXAsAbF W/1Y9Lc3rLnv5o1f/t8/+48vTN5s8EXIOHzcZGDCicgDRaFNZ8RCo367GVWUaejohlXfeHV6z4Xm WABquIc3rrrvlk1f3v+z//D85C3+SdcuBKhESeoq7uASjXxECs/q9JsuNNaH4tfpLehcciLW9TR7 d8p7kGPG5J0E/hQMM7GtGgAhA6NpGxptDS7DSzM4PwckvdNGNn1aJBz9hvQr0Xz/YOvSBb55cFgu XcGa7OH/kz/3PbpHjq4ngsTTL+H548nu98qtu0XWZP4BVknl8AzMjz4hLs0A0VtaEwtzePKwOHcU 3vYhWLGR+p699AieOMTQoDbAsnxkdTK4JHvt+fzAPYKE8MhaQgdi8gQ+8228NJnsug0TF6wFbO4j GCNlprkbYY2Zs9QxbFzCS9Ni6mSS9sGG60S7kc1N4tRpkaaQNWRaxzOvtl/4Pktj0jXovYMjyeBo PvFyRvdQy8vWJHTPwlz+3ENi7gI/1beE1Hu6ImYniQukb7wDSJEhkJ+320/ux6NPM5MZXc8mgMlx MXOGuirXXiGJG2JG2KVliUGmkqcmN1szt6sk49UN1Cq7qURB4+rs1qrOcDD/3L71C7tX37fQHv6b w19xvIGImf6dOvO+wD2hyURGZhvpeiCh8GqzsdV1o1oFXzm1TSVg3L71Tx45+eFDk7ca0RX4hQNC im05EHsjoORlLpobAoZoPxJvog4ePP2+QsO3b9P92SfDJyFWHhzAweo4aDAOafj4dR98YfIWalDP 6sEzG6OkEE/nEA1ZWBUwjBgozDCTt7Lu2AIPTiDY5L7Ya8bsLklg+XoWlXkLLk4Sjm3PnicpzTKT KGTmNIyu4y1OGHvpilr/cDZxJD/yKEmtdOc7k+veReTaeuTv84mX8iM/qq2/miCuWl5pGWqOfQO1 3b/JFLJ8DOqD2fFnW4/dI0hQH3sqXb1JZLT9a0wVAtKd70iu3Es8hdrMn/8+/Z1s+pX0pn9F5No+ +J3syKP50adw03Vy1RbIMjSC0CSc5PpzbaD2tt+Ro2Ptpx9oH/6hoCGMv5Bu2IESMmJYaUpNMYkR JGdrXB9rBCu31N/+b4gdiHqdp4Z7gizMlS0QFP3TLKZv/dfJyk3Z4R+1fvog4fb8+FP1jTtEfSA7 9EOmbcIkV+yp7b4N52eb/3QXTp9mHUGrXEo5h+FVOHNWDq9KqbfsgHcmX73nbeJY7rMOlKJvBIUM gnlKPtjQNQrdE2hv3vAXRNt/e+S/EnlPLOzYvuxxvS9H+04M1Gbow5vX3XXzhjtJ4Bw8+z791ceu /cCFxob7Xv7TcCN++sZ3UpPfH/8U3bas78Qd2z+9bugQ/frIxIfXDb7w5rV3DaSz3xv/5LrBQ/TG +Wzpfa/82clLOzXivG3L5xVwuGtifgfd9q4Nd9Kv33vtk9TU2NBh6kB/MkNNnby4g8a6Y/RBuoG6 R1362cyenaMP8c303nPvG1XvHa2feGTiQ4+e+vA6epbfS89+cu3gYRqFeu8XT17a4Yyc9MhgOnvt yod0mzQJ3zr2ma3DB1x/Tl3cccf2f09f0UB+fOpDNKib1n19IJmhsdBAaDj96cwLk7eO9o3TV9Sf f3jlz3avuvcta79O16n/3zr6mds2f4G+oj9TzQ38utqslHDTurvesu6uCwvr733lixcaYx+8+vfp BhqmauFPqRtWjmvqtKLRKN7KQ2uVa0nygeM4FH1JsAGZ6n+deQU+SpNvp6fT5esZzVK7F6cEia92 U46sIaomSqNNKeanSWrRBk6Wb+BmT71ChCeHltWu2pskiSRBx/ST4MVpnDol01S9x+JlpeDKDdek 66/mPXrhBKu1TEICZ86zAYH7ajciMZo0kf1DeP41agrqAwlh/oGlSV9/uvV6IA2W9PCzx5KUKUea BDMdg6tN5crLV6tTH+TytYrsJWFvyImWwQcWstC32XHGM5jKWp/0kkpLL7DWe/6PhDlL3uVjzCNI C6AJIQW+1chOHuIH+gaSrbuB7nHeMWbEkr1uUr2RtG66Ruq9XjQ0blrJxhJIgUEXzWWtntbqSa2W prWE3pamCf2h66oRyc3pUYHS92lJeAZBv4Kv6NvUtCZqlIn9NmEDiNy5/CHaUsdn956Z35lYVpGo f+me9UuYKr597LPfePXPtemfNiXt0fuPfVa6d6jr/+Xphw9duPVdG++kC0SuR2f3fvWFu4lm1g8d 3j7yOL3l6XN3NPOR27Z84auH/u7whX3v2fKFRC+2hO8c/xy18P0Tn5pubHjP5s/f9+oX6Q/dSc9u Gz5A9PzUuTtOX9qZqnfR2+nPF544SK/Yveq+rzy7/9DUrTdvvJNau23z54kw7j7y34jw1i95cfvI gZ3LH3z67PsaGb338//jsH7v580UAQ9fc6flqs0/eeIpaoree7/tz+GpffTrQjZ890vU5p1jQy9u G3585+iDNJYzl64lLkAd+8pz++ktR2f30AzQlRtX3/fi1L6/fHb/Xz63n7pH7FKP7gcnPkXX9euI Z1Fr1E9qmTpG3eCmzt6hW7hh9TfU0qgu6v/Uj95/+iu11ry49HcqB+osBLT5mf7J0abzMQejJzEI oNEaMuFh0TckGhfF9ESWsvgiSZvUB/LXnid9Mjv9itZEklWbMWvkc2c4/ItItLWQTY7nFy9kp46w oW9+Or80RUJdGaXA22XozrnzzZcP5CdfzOemjBnRcBqjpgkbWGqiAC5OkuAlUczmz9OvkLKQnTuO eYakDM+e5w9SPacylBm4RgFt4D0urHRJZOIO7D/6sRCyShNXCP4udYd0Lgd+mVRUaR2XHAiAjTlk XAPQvyRZMsIeRGsI0zda1hPoydImo2rsAT7USqN1/YUMcFohUoVXEdHq6wok5RibkSAqHxag32V9 47Q1fXpOnJ21bfgx+vun5+6g61vVZ5Kl9x//bDMblt5sZHDtdHMDyR+aWtqj9Jk2PV1f0XdCN3r4 wq3XjPKVHcsfXDf0Ask9t9p6fkmr2jrCYvPYzB7dgW0jj+tnj0zt4zBt5djQXIYY2ZTSYBv5CH3g 94IgAfjYxIfPzu/QPdfNEolqCX/t6EOEI+i9EmIrhRMlIKYaG3RTekSJbfOMEvhbRx7Td744davO AGhkS4kl0Qci1GY+bNYTBBHt2kHm8qP1k8elMwmayd2mhkn8lDjUTWu/pr+mpogNWbuRtd9F3n+I giKsEyltzl4ini8JpNdYaqC22WOeE53n2iRnvQMmsDPHoWWwZAVJJJw5p0RVTS5fzyb0JM3nzokz rOGyUW1whK3l7RZfn5+Zv//L/JmIgjb36m2kIcvhNRzyKb37haX69JnmI3+P58YJDtR27SNKaD75 LXY+GbKByATJmc85++TYLp01HmUYz+Kq1gfL1kmCAOu2MdCAMLQLwqqBTFLWA+m9xsL7fpRpAMJk Mm32wNB0DIzMMch/Z0SSSOfF1B4BZjekjROzkzJXLBi9oRuFaUEz0FX8VL0v0N/AqbjoI5SN6M91 LGOhfojRemWxhgeaybNB+EFNCrRWNWUNoQ1NFC5tkLj+oElIOpXT/Ur7uD28ZekBohmwBQDMXgQR ul+pzRfn9339xbsnLu7cu+Zr9gbDDp4591sPHP+sBCgYBqRwrDXKmwDhaw+4Z8zN0vOXUDsG6ztJ ABxPe+b8bz0w/jmA2AXnYwtFqGlLH6IPViGC0G5miFmam8Gu1r/c+umJSzv/6rn9n77hVyWg9Qub mPTQe26u2JwFzTLsdRsaaaPAMAwnAMuYSHo3p+aV5GGHLUPlmiS0R1iNwB6JdmuORBOmoWI3YWip HF6RTb7GRjX6vW9Qjq5hB9iS5Qy5p88Q0RIIh8El/I7+IR22Xdvxa3LVRhgagTozAiAdlfdZO8zE oI+tI4/i+RMwOFzf8xtyyy6cPOk98xBZiUDrpQRXB5ZyD7Ms3byDHoHBpUAvJaaT1hnPEioOzREy cgSGfn5vyfCbSGhXVvxeJWclRFYdiNMMItcRmv1H05vWOdyVeQwanSQ0ZoHZOOk1b46Mw1ARV+If AvC+3FJWjXXniygUzFnCgkwLxcp97iwxzmfO3/H2sS/tWn0vyZ+jM3uidBQQR+f2vl18adeqeycu 7tAXH3jtc799xSdenN5Hkke4SKKIsIT6CgkUkBKuOJrp6On5ncwg8mHSaUk1Fc3iSOiRt4s7r1HC lsX43N7NSx4ruMRCdmJYj+3AxKUdm4cPTMxfS79RU5uXHtBPnVLvnc+HT+n3KnkbOelcalDRPKjb fGxCtXB0bs8W1abylpsuIRRzjWjUhMMNNVuxMUJTAUaAUjtvF2LLyAFqjdp3hYbc5IMC1JZeAK1b AEVYidTY10nIKBzJJumsvdBozc4vTM7MT85eOjdDfxamLrYuLuStjEE7ofl6kvYntb56unoTe8KI bluNZPkYKcBEVHJ0jI3DpPHSDJM2TtSV1FmtpeZJbg8sSbffQAo5kPAfGFZBKRr3as1BfWDt/TzH ivQNkvglZZW9wc4VAFJEgpYpijAGM5e+AZE12aa1dVeyeotcspy0fUxraOMfw58oB9ZaFSJrKrhd b0sOxfZWEd5jCqKCT+6E4B7vx0IaNSxdITDD+VkO9Uv7lHbsnPAy7CieH4feftAFmoIfqnt7PPJS tWStlyGawHg1OazLEINP5eOTH39m8v3v3vjH9Gd0yYSKRxAiMXKEtvXDp/6AvvrNbZ/WQzh68SYS 3XRF35BbyYZeOssHXvvD/mT2EztvJ8bRR+RkCFJOtTb9r2N/Thfpq6uJho3pAEyuK8DEwnXEPt69 6Y/pzwPjf3iKCNW0CagJSUqMQ2U87LLvJe7z8Kl/R005pjDd2vTNY//5HWNf+r2dt1+z7CHUmhk1 FVOgi4bCxOlfQN3oT1WbJ/9gYuFatCSq+xwyZtca3Xn9yns/ce3tNHvMF6SkK7tW3qt1E2A2d91j Zz7y29s/QZPzwPh/sqUQwcWHoJEuduforho7B5h5U3+YoD76P5+LSxe5pbeRubbsEQF41uJTKfvY ydz4wV088sZC36/e3LfnvSjTxoH9jYPfZaqW0Pfm9ycke/M2yfPmd/97PnuWBHJy1V45ug6ydk4y eXhlcuWbIGv5N6td1Xj03vaRH5OEr+/+9fTqPYQF5h/8qrh0IVl3Rd+/+D2R5Y2H/zY7/jy9uvam 3yApBwrwNx6+u330Gaj3J1t3pWNXMhKeOYNZu/6Gd0UBmDw1SX7hZON7XxfzM6Q+DOz7XTm6tvnS gdYj9xJvStZfU3/HB+lD43tfy88cE2mt720foDbbh37UfPQfaE7SjTv6bvkYqQM0zNbzD7ee/DZn qWzd1f+OD+ZzUwvf/StSWGhm+2/7pFyxIRs/1Hj470hfgGVr+vd9nJBL84n7208/QEgn2for9Rvf S9p44wd/zVbDkdV9t3xEDo1yBHur0XzsG/n0mWTdlbUbfr1zBlh1BBcGcruAYwvCXzOd0InqMl9K ecpgs9OktVwgxKnliC4XK6ia0Lna/OKFkMoFDLqkfHQop7xYkg1gUGkj7FLH6m7VlSSgol5sZdBQ DKwq4/WqZyZK5upSwSr6UUGpgOU4HgjKj+nG8yxjMd4QMN8WYpBtYKRJCtHuXw4LbSlbQBp4kog2 B66lazbJGkd/iWUrxd73Nh69D2cvtJ68nyPD2FZwKVmzLd2+W1nxoxIrtZ1vxbPHmAJ/8s3m4R9C lhEdYpY7uUosg6hPheGhTn0neVK78d04P5OfOdo+/Gj75ccZlZAS3jdY2/IGdtRlWawBqFi0VpNZ gyrnwn1oM1Iwdj4VVMdufM2mlemG7hcK41hGyRYKFdOGQkXd8iRlTQ74AZu1z8pHS9CLMtZBaCz1 a9+Kk+PZ+OHslYPzx18wQEul30jj0QLiaETb7JU/9VId3lO5bNJHDEdBKFEWEoCo8PvG6Rix/9tG RoSb2wepGouNL7CurBrsEVRZREp4gi90bU15IkizE0bLK4WSuaipYtRalCUjSyGhoarZOcOtXGgC fL3NwGDYueR4lIFWebZEGF+AvnK/DHI8SyEG0CEjPc5KMaHWyh4CIOLs7nJKZlg6MsXEKxZYkfkd RGgj67lmMmr9YvteMXNWpP3Z4Jr25BRv+dpyseUGNoMNjbZlf9Josm0e27Vt16crx1ovP5mdHcfG PPT1w9KVJCcVGJQqzVfph8iBmemKdXLfR9vHns/OHRdzU4RgYf1VybK1ydhVTEUEv8eulATFhUyW reL14ECvLGHx+JHsZz/NTr2cz8+yG3loGQl8gugqqBuiNPD+wfSK3YQ7oH9Q1usstIdX1K7aS7AZ RteqeAOZbtyJy9YQYmFVImvJ4ZW1q1lplMvX8a5mtTlPlq/Dq/YwIa/exK70WppuuR7n56iTCfUQ czk0XLviBmYZg8sku89zGnvfOz7Q/tkz2bHnSYsRS5blp4/hxSlwwSEgkjWbk7Ers5MvEafzJqyK /QphFali2hN0lmkyChIN81FdvJkMBUYxDbtQYcBoF4jO4On1PxOMGJcmwLDIpnogB2sqBYMCgu2I jvWUQabbx+XKTZXHKujkQzemuJ62AroulxF86k8c92cV8rAEUuG4ldhmAhC5HDpVSjdKXkXNHxna zIpc2iSHR8DNi8uP3nOop6ILpXxvNo/pmFIuZpAbTkV0pbg6yzFl2WanHOH5tJbUUkhZo0tYWLHo w7xlasMa012up5wgOmvmZjPlKiyWVOycoT4Hv9aU0AN2iWNuxAs74hIO+YT4tCK+pyqiXtZRS0Dq Z65mUHnXWTFWySGiVmfWg6qFPOeyDWmqxFGOHOiuZoIu0iQoDVZdpI7XjBbdbqhNmkCio9BJsLdB i7taH0EYugJpLZs6Pb//y/nMOeIaA+/+mBxYisoM2RUdFgpWBBHTVadJFSuzlhOrEQqHp4SZo5Ul CkB0rqzvc81EVATHRqBGORtRAZmoqm7o4kOXZIgx7DdfWFytpRaKqMRBXCwmiiLrHcmX1qKng0pi CNDLUTk9VnTu/lR4WyqS6jOrinRiyUKozBQ1ublKgcgDG5Lg+DC96tLICA61bmWi2QbrW1A5XYkK p2HXu2QzvXLPp4n1sOdsUffx95nNtOJcayRiI6yuqi64uhYsn/NceXTRRXLFmXwYbei8qXK5lGai 7SBZA01Qp2otaxsfIavrnFjDdj7rYTFl1nlsTZvDqpgBPQW5tV+qbLCs4YgBle2wefAHhAXk0uXU 89bLB/OL0zQiuWw1AQ1hM8bBZLkVUrVFUT0rpG9D4Ie3Bxqh9Xd1qguBEqPmZTEDATBKLItTni02 QIxQucQIK2gdX0KQoWXAQ1zcMoxH9/nm4HR1n7fnXovltBYdAmRrUAdx5hHdW6dkGeZUMdYoQ96W SxPYLdcN4vB7H9wdQ6qwY7JwT6EYp4yO+EHv74S4fonLZSfdW+uvUdaqX0+AUkdAWrO7tWY7tm8v A/g6JcJmtoY4h73qjaxtO21uYOmXmICpREXI6Ygx5gsJGG4tmYaZP0mVCmo4iynxYshRSQxpDjSy MStBASP7FYILG9MNmARnMIlKBp1I9Sv/g1IHnygqkJozeGkC4EKNpdmwOkAQTRGotN46/kLjsf0M DfoGmTs055lLLVvdd/27+N5MliKLoXN9DagouBE6bHsQ/6Kq/n4R5y5yjE2pFHFlTSb02yLgIMbv g2FFCLdrw8RtnyuCBggAxDooBP7S0HYoRYjMhY/aMreb9Fi0YRVGXzA5Fxi4710ejjQQGiHgqBjW KUXLPjBKsBdR2rXxL4CuMSIwzh/XA5Uhm8TyTFeHtNu5Bvjdf3yplBFfgiJ2LFHtCAMJseCcxQIw FLHeEB/qaPh+VCrYIF8t5FWIoKqRwqJespAk6A7OE4QuU9ul4AHmwosib4Iq1EPMTbyaMB+txgeB fqkDdXOXaxPrRRiUGggNVlFtEs/mABM22rdffjo/N57PXSChDf1D6dpttR03yZGVpKpArwUo4zqn WFVxHOPaLgU0Xra7V2YmVwWjw6Km/OjY0wBjAxY1g67Hay5W76RDKxAcIOFrYmJxwN6oJ03abIBT oFDYRIMhn+6u9gSUNKVydaZSnTLwrMQYLXJTP8BtFlsQEMPsOGeccImhEeWFqxiFUv7+/lf8aR16 14NnJIUzef0JQRiAtLg8D0bGnw7+kYoyw1Fqo7PTBLUDELwjVwW06LBp5aolmmd5ChDgDFc0z8Vl xiXHIWDphlrN/IEoaJ7ozvNVcTIIAUv25s2YmzqbjXsDczKOsZc5p47lJmWKVBKOC8ggLC8TV+or 1NOrik+LswuL7UBQbzfcNWGZrLh4lShWxMa4WH+UkoyBhU24cDgoHnhcMBUgunWIcWZ0sK0WKoAg KgpIoYtJQvMwxudqoLNBOmiJxVps7nvsLODKbBuw2/lEcQvB4QSF0sehLQQio0VgyccAOwTlKMBV 5wCLKxD8kTzq31RCrFjIQKWSPg02TJcrDgiiVPOwRkB0uk+BkYUJp2Xrl4ydDqH2o213GRdxI5Ve 1VlS+i6ngysdWMl5qSS9isFAFdMnlcKUGxXCBHJCblT1PFdsQ8N9HxehXi8NdAdD1zYYACJ4o/Ld FGT3wyyc+KnK0VHXTfiBnh8mdVW2wMbFQFDfyCSQgUQfYGdKeRRsRiiCE0O1rpOji+uIy7KCgx5G CEQFDAIrV4ilsZByXlXeFeJyENFpBRCW7NbbMKBRn8VpCwki+LhbU9QhQoPSx69Y05vX2S0VS3fQ sish5RJVg4MoXekSobK9jYKGGHkZUYeBuTPNAQMREsVLm5y+oH5joDCb3IIS1A2y+0Xgs1NQ1NeK KFsHdLd9GDA49MsD/7fffrUC4DnOHx0sXij+WrC5eBgDhSORrLkrbD9K0a04rCM479udYqbV/sCa EvK6opkDXUVqpd1LpTrrjKhE2sQpiWGksiAGYfNr1MjyOFCjUOerusRsVYalt4OZ6XFFC+IjpUS3 gt2lKmM92HsXK2vtUZSragOd0Tl2DqwpDx0jaxyWrHrhdi3nqlaXMe1SrSW+uUIQ935cbVD9oZfZ Lov6rsoEiuoohLjwRFdHVhXhOW4TFZBLWb5h5KFzwsGk4aALq5Zxw4FpDUPzSZhzHLXrq0CCNbpF DlT0ZkDHflSipGmvdG4lFLLXRTHo21jydGk070PNHLORLodOmvjYusH7XCeGRqcrJKMS4KjoP1Nk j8plhw6YRykOFntCYLdQxRjM+MAm6mq3v8dr6GNaBUYpFIbBhKlbAfANS8M6O7oUWGneDbsavKiy rphjMuiiIxxHhohyoqrywdpYDGDaz6PKj2FRYAvzpLN8RwexxK+D0IHnC3AKV/Jd+CNBtGSSQbeL /iBfe1vjAsRifdJYe0YRlNLwbmYMDsZxUqlQwdusilHdnMh18lPEDpIqCWDLdWCwDkGOt4095P2X 2nmWGqVEpbysyTsQvSBEoWJGEGVtY0uFb8YFJaA72UdJZIiiGj0iD8//BXd2dNE4ariL9FodVntg rZLs835CCtG8rJmhNVyYbHB3SEyi8qFd9myi5ktngkJiQnydtNemj0yHclu8FB4tmhRKPkuduZeD hKCctT1RJphGDAtJQqGuOwSxeFAscQtlwzhg6EoJjlg14eu+hEdU2sn7maAU7wTlGmeGf3kyA4yf CjxnvoyhNXbaozXQa0LC5tbqomK+OjJ4dG0wXtHRDyUBLuMDQiEsM4phNggUfJGePxopJcJzAqQ/ xg2L0w/leAVbvDcKKvJquS0XJcEdUAte9fG1n9AHKAUsXkkgTIXLNENRTjoILNxVwbeFyCB3pywd uBrWeApdOlh9Dk0wBwIw9gFh7DdCUQgVqkZcEuLY3WLmXfkwAa6bqP+H3LFrsJnergQFV0FIZMqV ntjJqFPtfdUtnaehfuXgF5VEn/scLYIA0thKIQL9apllUIo32Ai+cFBoHozEUemgyWDqoKCmQwz5 nPEBMNDSvMfFUBEGNxRRlQy6B94yWox9sesfLSfaow3MQVHaqBFDNAxjadVXOeRBFLfNvPNjkpYz 6D6jrVsmMSwzB0Ytz4MdrYkm9xxCFnirNFA0tirputrGxyY76BXgbUo2jzgwYaK0PMBCJ5MHomGt ybUSMlPnZikrEtpMXzO9HFziglojF2TIbLzJJI9kN3r8I3QZ0IIaIEPjbXjggmfdUVAOZ+QU3m0M z6idjYa1I1aekyUhDKuKDM4+8BCiM0ALgh2iE0KtX9um9poIGO5HZmuVq6QrW84T9cbn2sqqOoou 8KYqp6g3kwCv8YwzF+Cx8pkQQhv2c3tESo5GEcAw3ANE6GQFdK7JgBsE7lTsVDnfY04QhSBvKBxm EEU5Ipa2ZameJ2KFlQADJhJEVxScgPEZmiEmKGsYYdaF11CksbELiC0lwpdGLsX0VRxADxUpOuDt UMF2leWIcVfFMEgetDFFgHGt6MjQAHEYERbdd6rttrIEtxRUzFWJbaUe8icIo3uYQ+oDPsT/FWAA JHTTHWNZCIwAAAAASUVORK5CYII= ------_=_NextPart_001_01CA1B37.E9011F13-- From gnn at neville-neil.com Wed Aug 12 13:57:16 2009 From: gnn at neville-neil.com (George Neville-Neil) Date: Wed Aug 12 13:57:38 2009 Subject: RFC: ARP Statistics Message-ID: <533A2900-CDAC-4BFB-952B-45FB18E19B7E@neville-neil.com> Howdy, Here is a small patch that updates the kernel and the netstat(1) program to print out protocol statistics for ARP. I'd be interested in any feedback people have on this. Sample output: netstat -s -p arp arp: 469 ARP requests sent 2117 ARP replies received 0 total packets dropped due to no ARP entry 469 ARP entrys timed out 0 Duplicate IPs seen Best, George Index: usr.bin/netstat/inet.c =================================================================== --- usr.bin/netstat/inet.c (revision 196095) +++ usr.bin/netstat/inet.c (working copy) @@ -49,6 +49,7 @@ #include #include +#include #include #include #include @@ -871,6 +872,44 @@ #undef p1a } +/* + * Dump ARP statistics structure. + */ +void +arp_stats(u_long off, const char *name, int af1 __unused, int proto __unused) +{ + struct arpstat arpstat, zerostat; + size_t len = sizeof(arpstat); + + if (live) { + if (zflag) + memset(&zerostat, 0, len); + if (sysctlbyname("net.link.ether.arp.stats", &arpstat, &len, + zflag ? &zerostat : NULL, zflag ? len : 0) < 0) { + warn("sysctl: net.link.ether.arp.stats"); + return; + } + } else + kread(off, &arpstat, len); + + printf("%s:\n", name); + +#define p(f, m) if (arpstat.f || sflag <= 1) \ + printf(m, arpstat.f, plural(arpstat.f)) +#define p1a(f, m) if (arpstat.f || sflag <= 1) \ + printf(m, arpstat.f) + + p(arp_requests, "\t%lu ARP request%s sent\n"); + p(arp_replies, "\t%lu ARP replie%s received\n"); + p(arp_dropped, "\t%lu total packet%s dropped due to no ARP entry\n"); + p(arp_timeout, "\t%lu ARP entry%s timed out\n"); + p(arp_dupips, "\t%lu Duplicate IP%s seen\n"); +#undef p +#undef p1a +} + + + static const char *icmpnames[ICMP_MAXTYPE + 1] = { "echo reply", /* RFC 792 */ "#1", Index: usr.bin/netstat/main.c =================================================================== --- usr.bin/netstat/main.c (revision 196095) +++ usr.bin/netstat/main.c (working copy) @@ -184,6 +184,8 @@ { .n_name = "_sctpstat" }, #define N_MFCTABLESIZE 54 { .n_name = "_mfctablesize" }, +#define N_ARPSTAT 55 + { .n_name = "_arpstat" }, { .n_name = NULL }, }; @@ -232,6 +234,8 @@ carp_stats, NULL, "carp", 1, 0 }, { -1, N_PFSYNCSTAT, 1, NULL, pfsync_stats, NULL, "pfsync", 1, 0 }, + { -1, N_ARPSTAT, 1, NULL, + arp_stats, NULL, "arp", 1, 0 }, { -1, -1, 0, NULL, NULL, NULL, NULL, 0, 0 } }; Index: usr.bin/netstat/netstat.h =================================================================== --- usr.bin/netstat/netstat.h (revision 196095) +++ usr.bin/netstat/netstat.h (working copy) @@ -75,6 +75,7 @@ void sctp_protopr(u_long, const char *, int, int); void sctp_stats(u_long, const char *, int, int); #endif +void arp_stats(u_long, const char *, int, int); void ip_stats(u_long, const char *, int, int); void icmp_stats(u_long, const char *, int, int); void igmp_stats(u_long, const char *, int, int); Index: sys/netinet/if_ether.c =================================================================== --- sys/netinet/if_ether.c (revision 196095) +++ sys/netinet/if_ether.c (working copy) @@ -80,6 +80,7 @@ SYSCTL_DECL(_net_link_ether); SYSCTL_NODE(_net_link_ether, PF_INET, inet, CTLFLAG_RW, 0, ""); +SYSCTL_NODE(_net_link_ether, PF_ARP, arp, CTLFLAG_RW, 0, ""); VNET_DEFINE(int, useloopback) = 1; /* use loopback interface for * local traffic */ @@ -108,6 +109,11 @@ &VNET_NAME(arp_proxyall), 0, "Enable proxy ARP for all suitable requests"); +struct arpstat arpstat; /* ARP statistics, see if_arp.h */ +SYSCTL_STRUCT(_net_link_ether_arp, OID_AUTO, stats, CTLFLAG_RW, + &arpstat, arpstat, + "ARP statistics (struct arpstat, net/if_arp.h)"); + static void arp_init(void); void arprequest(struct ifnet *, struct in_addr *, struct in_addr *, u_char *); @@ -127,6 +133,7 @@ #ifdef AF_INET void arp_ifscrub(struct ifnet *ifp, uint32_t addr); + /* * called by in_ifscrub to remove entry from the table when * the interface goes away @@ -165,12 +172,13 @@ ifp = lle->lle_tbl->llt_ifp; IF_AFDATA_LOCK(ifp); LLE_WLOCK(lle); - if (((lle->la_flags & LLE_DELETED) - || (time_second >= lle->la_expire)) - && (!callout_pending(&lle->la_timer) && - callout_active(&lle->la_timer))) + if (((lle->la_flags & LLE_DELETED) || + (time_second >= lle->la_expire)) && + (!callout_pending(&lle->la_timer) && + callout_active(&lle->la_timer))) { (void) llentry_free(lle); - else { + arpstat.arp_timeout++; + } else { /* * Still valid, just drop our reference */ @@ -238,6 +246,7 @@ sa.sa_len = 2; m->m_flags |= M_BCAST; (*ifp->if_output)(ifp, m, &sa, NULL); + arpstat.arp_requests++; } /* @@ -339,8 +348,10 @@ * latest one. */ if (m != NULL) { - if (la->la_hold != NULL) + if (la->la_hold != NULL) { m_freem(la->la_hold); + arpstat.arp_dropped++; + } la->la_hold = m; if (renew == 0 && (flags & LLE_EXCLUSIVE)) { flags &= ~LLE_EXCLUSIVE; @@ -413,6 +424,7 @@ ar = mtod(m, struct arphdr *); } + arpstat.arp_replies++; switch (ntohs(ar->ar_pro)) { #ifdef INET case ETHERTYPE_IP: @@ -603,6 +615,7 @@ ifp->if_addrlen, (u_char *)ar_sha(ah), ":", inet_ntoa(isaddr), ifp->if_xname); itaddr = myaddr; + arpstat.arp_dupips++; goto reply; } if (ifp->if_flags & IFF_STATICARP) @@ -821,7 +834,7 @@ static void arp_init(void) { - + bzero(&arpstat, sizeof(arpstat)); netisr_register(&arp_nh); } SYSINIT(arp, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, arp_init, 0); Index: sys/net/if_arp.h =================================================================== --- sys/net/if_arp.h (revision 196095) +++ sys/net/if_arp.h (working copy) @@ -108,6 +108,16 @@ #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) #define AC2IFP(ac) ((ac)->ac_ifp) -#endif +#endif /* _KERNEL */ +struct arpstat { + /* Normal things that happen */ + u_long arp_requests; /* # of ARP requests sent by this host */ + u_long arp_replies; /* # of ARP replies received by this host */ + /* Abnormal event and error counting */ + u_long arp_dropped; /* # of packets dropped while waiting for a reply */ + u_long arp_timeout; /* # of times an entry is removed due to timeout */ + u_long arp_dupips; /* # of duplicate IPs detected. */ +}; + #endif /* !_NET_IF_ARP_H_ */ From pyunyh at gmail.com Wed Aug 12 21:36:29 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Aug 12 21:36:40 2009 Subject: nfe taskq performance issues In-Reply-To: References: Message-ID: <20090812213521.GG55129@michelle.cdnetworks.com> On Thu, Jul 23, 2009 at 08:58:07AM -0700, Peter Steele wrote: > We've been hitting serious nfe taskq performance issues during stress > tests and in doing some research on the problem we came across this old > email: > > > > From: Ivan Voras > Date: April 28, 2009 3:53:14 AM PDT > To: freebsd-threads@freebsd.org > Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org > Subject: Re: FreeBSD 7.1 taskq em performance > > > > I have been hitting some barrier with FreeBSD 7.1 network performance. > I > > have written an application which contains two kernel threads that > takes > > mbufs directly from a network interface and forwards to another > network > > interface. This idea is to simulate different network environment. > > > > I have been using FreeBSD 6.4 amd64 and tested with an Ixia box > > (specialised hardware firing very high packet rate). The PC was a > Core2 2.6 > > GHz with dual ports Intel PCIE Gigabit network card. It can manage up > to 1.2 > > million pps. > > > > I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz > and > > PCIE Gigabit network card. The performance can only achieve up to 600k > pps. > > I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is > not in > > FreeBSD 6.4. > > > > In our case we are running FreeBSD 7.0, but we are seeing our boxes > experience serious thread starvation issues as the nfe0 cpu percentage > climbs steadily while cpu idle time drops at times to 0 percent. This > email thread mentioned a patch for the em driver here: > > > > http://people.yandex-team.ru/~wawa/ > > > > > Does anyone know if this patch will work with the nfe driver? > That's for em(4). AFAIK all nfe(4) controllers lacks intelligent interrupts moderation so driver should be prepared to handle excessive interrupt loads. I'm not sure whether NVIDIA ethernet controllers really lacks efficient interrupt mitigation mechanism but it seems Linux also faces the same hardware problem. As you might know there is no publicly available data sheet for NVIDIA controllers so setting it right looks very hard to me. From linimon at FreeBSD.org Wed Aug 12 21:37:31 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Aug 12 21:37:42 2009 Subject: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Message-ID: <200908122137.n7CLbUPw020259@freefall.freebsd.org> Old Synopsis: NET_RT_DUMP not working in FreeBSD 8 New Synopsis: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 12 21:36:18 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137700 From qing.li at bluecoat.com Wed Aug 12 21:59:40 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Wed Aug 12 21:59:46 2009 Subject: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 In-Reply-To: <200908122137.n7CLbUPw020259@freefall.freebsd.org> References: <200908122137.n7CLbUPw020259@freefall.freebsd.org> Message-ID: Hi, What's not working ? The code reported in the bug is identical to the code in /usr.sbin/netstat/route.c, function "ntreestuff()". Please take a look at this code. "netstat -r" works in FreeBSD 8. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of linimon@freebsd.org > Sent: Wednesday, August 12, 2009 2:38 PM > To: linimon@freebsd.org; freebsd-bugs@freebsd.org; freebsd- > net@freebsd.org > Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD > 8 > > Old Synopsis: NET_RT_DUMP not working in FreeBSD 8 > New Synopsis: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Aug 12 21:36:18 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=137700 > _______________________________________________ > 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 bzeeb-lists at lists.zabbadoz.net Wed Aug 12 22:30:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Aug 12 22:30:14 2009 Subject: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Message-ID: <200908122230.n7CMU7Gt056618@freefall.freebsd.org> The following reply was made to PR bin/137700; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, lab@gta.com Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Date: Wed, 12 Aug 2009 22:24:14 +0000 (UTC) On Wed, 12 Aug 2009, Li, Qing wrote: > Hi, > > What's not working ? > > The code reported in the bug is identical to the code in > /usr.sbin/netstat/route.c, function "ntreestuff()". > Please take a look at this code. > > "netstat -r" works in FreeBSD 8. uses kvm still. If the sysctl doesn't work, then that's probably my fault; assign the PR to bz and I'll look. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From bzeeb-lists at lists.zabbadoz.net Wed Aug 12 22:35:28 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Aug 12 22:35:35 2009 Subject: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 In-Reply-To: References: <200908122137.n7CLbUPw020259@freefall.freebsd.org> Message-ID: <20090812222214.S93661@maildrop.int.zabbadoz.net> On Wed, 12 Aug 2009, Li, Qing wrote: > Hi, > > What's not working ? > > The code reported in the bug is identical to the code in > /usr.sbin/netstat/route.c, function "ntreestuff()". > Please take a look at this code. > > "netstat -r" works in FreeBSD 8. uses kvm still. If the sysctl doesn't work, then that's probably my fault; assign the PR to bz and I'll look. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From bz at FreeBSD.org Wed Aug 12 23:12:17 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Wed Aug 12 23:12:23 2009 Subject: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Message-ID: <200908122312.n7CNCGPX093404@freefall.freebsd.org> Synopsis: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Wed Aug 12 23:11:55 UTC 2009 Responsible-Changed-Why: My bug. my fix. http://www.freebsd.org/cgi/query-pr.cgi?pr=137700 From bz at FreeBSD.org Wed Aug 12 23:30:28 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Wed Aug 12 23:30:39 2009 Subject: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 In-Reply-To: <20090812222214.S93661@maildrop.int.zabbadoz.net> References: <200908122137.n7CLbUPw020259@freefall.freebsd.org> <20090812222214.S93661@maildrop.int.zabbadoz.net> Message-ID: <20090812231244.U93661@maildrop.int.zabbadoz.net> On Wed, 12 Aug 2009, Bjoern A. Zeeb wrote: Here's the fix (untested): http://people.freebsd.org/~bz/20090812-04-rtsock-rt_dump-bugfix-pr137700.diff Shame on me:( /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From mav at FreeBSD.org Thu Aug 13 10:22:48 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Aug 13 10:22:55 2009 Subject: RFC: server side support for libradius Message-ID: <4A83DB62.9090303@FreeBSD.org> Hi. I have made a patch, extending libradius functionality by adding simple embedded RADIUS server support to it. It doesn't change any of existing client functionality and reuses much of it's code. Only four new functions were added with respect to the new server operation flow: rad_server_open(), rad_receive_request(), rad_create_response() and rad_send_response(). First consumer of this functionality is going to become forthcoming mpd5.4 release (now in CVS). It will include embedded RADIUS server, to support long awaited RADIUS Dynamic Authorization Extensions (RFC 3576), such as Change-of-Authorization (CoA) and Disconnect-Request (DR/PoD). Patch against HEAD (it should apply clean to previous versions): http://people.freebsd.org/~mav/libradius.server.20090813.patch If there will be no objections, I am going to commit it to the HEAD and merge down as soon as tree will be unfrozen. This work was sponsored by JSC "Ufanet", http://ufanet.ru/. -- Alexander Motin From delphij at delphij.net Thu Aug 13 10:46:18 2009 From: delphij at delphij.net (Xin LI) Date: Thu Aug 13 10:46:24 2009 Subject: RFC: interface description Message-ID: <4A83EEA8.5080202@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, While playing with some OpenBSD installation I found that they have an interesting feature - adding description to a NIC. This is useful for system administrators to "tag" the interface, also, the ladvd program has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP peer like: em0: flags=8843 metric 0 mtu 1500 ether 00:11:22:33:44:55 description: connected to myrouter.home (CDP) [...] The attached patch ported the feature to FreeBSD. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqD7qgACgkQi+vbBBjt66CF+QCeO6INwh3S1T/LvhIUTjZ/Ix4H zQkAniftv+SQ+irEcnItGHTbLH0HyUez =cEsJ -----END PGP SIGNATURE----- -------------- next part -------------- Index: sbin/ifconfig/ifconfig.8 =================================================================== --- sbin/ifconfig/ifconfig.8 (revision 196163) +++ sbin/ifconfig/ifconfig.8 (working copy) @@ -28,7 +28,7 @@ .\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94 .\" $FreeBSD$ .\" -.Dd July 8, 2009 +.Dd September 14, 2009 .Dt IFCONFIG 8 .Os .Sh NAME @@ -258,6 +258,12 @@ Disable permanently promiscuous mode. Another name for the .Fl alias parameter. +.It Cm description Ar value +Specify a description of the interface. +This can be used to label interfaces in situations where they may +otherwise be difficult to distinguish. +.It Cm -description +Clear the interface description. .It Cm down Mark an interface .Dq down . @@ -2443,6 +2449,10 @@ Configure the interface to use 100baseTX, full duplex Ethernet media options: .Dl # ifconfig xl0 media 100baseTX mediaopt full-duplex .Pp +Label the em0 interface as an uplink: +.Pp +.Dl # ifconfig em0 description \&"Uplink to Gigabit Switch 2\&" +.Pp Create the software network interface .Li gif1 : .Dl # ifconfig gif1 create Index: sbin/ifconfig/ifconfig.c =================================================================== --- sbin/ifconfig/ifconfig.c (revision 196163) +++ sbin/ifconfig/ifconfig.c (working copy) @@ -83,6 +83,7 @@ static const char rcsid[] = struct ifreq ifr; char name[IFNAMSIZ]; +char descr[IFDESCRSIZE]; int setaddr; int setmask; int doalias; @@ -822,6 +823,36 @@ setifname(const char *val, int dummy __unused, int free(newname); } +/* ARGSUSED */ +static void +setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp) +{ + char *newdescr; + + newdescr = strdup(val); + if (newdescr == NULL) { + warn("no memory to set ifdescr"); + return; + } + ifr.ifr_data = newdescr; + if (ioctl(s, SIOCSIFDESCR, (caddr_t)&ifr) < 0) { + warn("ioctl (set descr)"); + free(newdescr); + return; + } + strlcpy(descr, newdescr, sizeof(descr)); + free(newdescr); +} + +/* ARGSUSED */ +static void +unsetifdescr(const char *val, int value, int s, const struct afswtch *afp) +{ + + setifdescr("", 0, s, 0); +} + #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ @@ -866,6 +897,11 @@ status(const struct afswtch *afp, const struct soc printf(" mtu %d", ifr.ifr_mtu); putchar('\n'); + ifr.ifr_data = (caddr_t)&descr; + if (ioctl(s, SIOCGIFDESCR, &ifr) == 0 && + strlen(ifr.ifr_data) > 0) + printf("\tdescription: %s\n", ifr.ifr_data); + if (ioctl(s, SIOCGIFCAP, (caddr_t)&ifr) == 0) { if (ifr.ifr_curcap != 0) { printb("\toptions", ifr.ifr_curcap, IFCAPBITS); @@ -1035,6 +1071,10 @@ static struct cmd basic_cmds[] = { DEF_CMD("-arp", IFF_NOARP, setifflags), DEF_CMD("debug", IFF_DEBUG, setifflags), DEF_CMD("-debug", -IFF_DEBUG, setifflags), + DEF_CMD_ARG("description", setifdescr), + DEF_CMD_ARG("descr", setifdescr), + DEF_CMD("-description", 0, unsetifdescr), + DEF_CMD("-descr", 0, unsetifdescr), DEF_CMD("promisc", IFF_PPROMISC, setifflags), DEF_CMD("-promisc", -IFF_PPROMISC, setifflags), DEF_CMD("add", IFF_UP, notealias), Index: share/man/man4/netintro.4 =================================================================== --- share/man/man4/netintro.4 (revision 196163) +++ share/man/man4/netintro.4 (working copy) @@ -32,7 +32,7 @@ .\" @(#)netintro.4 8.2 (Berkeley) 11/30/93 .\" $FreeBSD$ .\" -.Dd June 18, 2004 +.Dd September 15, 2009 .Dt NETINTRO 4 .Os .Sh NAME @@ -277,6 +277,15 @@ and fields of the .Vt ifreq structure, respectively. +.It Dv SIOCGIFDESCR Fa "struct ifreq *" +Get the interface description, returned in the +.Va ifru_data +field. +.It Dv SIOCSIFDESCR Fa "struct ifreq *" +Set the interface description to the value of the +.Va ifru_data +field, limited to the size of +.Dv IFDESCRSIZE . .It Dv SIOCSIFFLAGS Set interface flags field. If the interface is marked down, Index: sys/kern/kern_jail.c =================================================================== --- sys/kern/kern_jail.c (revision 196163) +++ sys/kern/kern_jail.c (working copy) @@ -3437,6 +3437,7 @@ prison_priv_check(struct ucred *cred, int priv) case PRIV_NET_SETIFMETRIC: case PRIV_NET_SETIFPHYS: case PRIV_NET_SETIFMAC: + case PRIV_NET_SETIFDESCR: case PRIV_NET_ADDMULTI: case PRIV_NET_DELMULTI: case PRIV_NET_HWIOCTL: Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 196163) +++ sys/net/if.c (working copy) @@ -1927,6 +1927,7 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d int new_flags, temp_flags; size_t namelen, onamelen; char new_name[IFNAMSIZ]; + char ifdescrbuf[IFDESCRSIZE]; struct ifaddr *ifa; struct sockaddr_dl *sdl; @@ -1965,6 +1966,25 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d ifr->ifr_phys = ifp->if_physical; break; + case SIOCGIFDESCR: + bzero(ifdescrbuf, sizeof(ifdescrbuf)); + strlcpy(ifdescrbuf, ifp->if_description, IFDESCRSIZE); + error = copyout(ifdescrbuf, ifr->ifr_data, IFDESCRSIZE); + break; + + case SIOCSIFDESCR: + error = priv_check(td, PRIV_NET_SETIFDESCR); + if (error) + return (error); + error = copyinstr(ifr->ifr_data, ifdescrbuf, + IFDESCRSIZE, NULL); + if (error == 0) { + bzero(ifp->if_description, IFDESCRSIZE); + strlcpy(ifp->if_description, ifdescrbuf, IFDESCRSIZE); + getmicrotime(&ifp->if_lastchange); + } + break; + case SIOCSIFFLAGS: error = priv_check(td, PRIV_NET_SETIFFLAGS); if (error) Index: sys/net/if.h =================================================================== --- sys/net/if.h (revision 196163) +++ sys/net/if.h (working copy) @@ -60,6 +60,10 @@ struct ifnet; #define IFNAMSIZ IF_NAMESIZE #define IF_MAXUNIT 0x7fff /* historical value */ #endif + +/* Length of interface description, including terminating '\0'. */ +#define IFDESCRSIZE 64 + #if __BSD_VISIBLE /* Index: sys/net/if_var.h =================================================================== --- sys/net/if_var.h (revision 196163) +++ sys/net/if_var.h (working copy) @@ -197,6 +197,7 @@ struct ifnet { void *if_pf_kif; void *if_lagg; /* lagg glue */ u_char if_alloctype; /* if_type at time of allocation */ + char if_description[IFDESCRSIZE]; /* interface description */ /* * Spare fields are added so that we can modify sensitive data Index: sys/sys/priv.h =================================================================== --- sys/sys/priv.h (revision 196163) +++ sys/sys/priv.h (working copy) @@ -335,6 +335,7 @@ #define PRIV_NET_LAGG 415 /* Administer lagg interface. */ #define PRIV_NET_GIF 416 /* Administer gif interface. */ #define PRIV_NET_SETIFVNET 417 /* Move interface to vnet. */ +#define PRIV_NET_SETIFDESCR 418 /* Set interface description. */ /* * 802.11-related privileges. From sthaug at nethelp.no Thu Aug 13 11:34:26 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Thu Aug 13 11:34:33 2009 Subject: RFC: interface description In-Reply-To: <4A83EEA8.5080202@delphij.net> References: <4A83EEA8.5080202@delphij.net> Message-ID: <20090813.133424.41729466.sthaug@nethelp.no> > While playing with some OpenBSD installation I found that they have an > interesting feature - adding description to a NIC. This is useful for > system administrators to "tag" the interface, also, the ladvd program > has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP > peer like: Yes please! This is an "obvious" feature to those of us who are router geeks, and I've been wishing for this to show up in FreeBSD for years. Now if I could have "sticky" static routes also I would be even happier (as in: Next hop disappears -> route disappears. Next hop available again -> route shows up in routing table again). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From barney_cordoba at yahoo.com Thu Aug 13 11:56:34 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Aug 13 11:56:45 2009 Subject: nfe taskq performance issues In-Reply-To: <20090812213521.GG55129@michelle.cdnetworks.com> Message-ID: <430428.63263.qm@web63902.mail.re1.yahoo.com> --- On Wed, 8/12/09, Pyun YongHyeon wrote: > From: Pyun YongHyeon > Subject: Re: nfe taskq performance issues > To: "Peter Steele" > Cc: freebsd-net@freebsd.org > Date: Wednesday, August 12, 2009, 5:35 PM > On Thu, Jul 23, 2009 at 08:58:07AM > -0700, Peter Steele wrote: > > We've been hitting serious nfe taskq performance > issues during stress > > tests and in doing some research on the problem we > came across this old > > email: > > > >? > > > > From: Ivan Voras > > Date: April 28, 2009 3:53:14 AM PDT > > To: freebsd-threads@freebsd.org > > Cc: freebsd-net@freebsd.org, > freebsd-performance@freebsd.org > > Subject: Re: FreeBSD 7.1 taskq em performance > > > > > > I have been hitting some barrier with FreeBSD 7.1 > network performance. > > I > > > have written an application which contains two > kernel threads that > > takes > > > mbufs directly from a network interface and > forwards to another > > network > > > interface. This idea is to simulate different > network environment. > > > > > > I have been using FreeBSD 6.4 amd64 and tested > with an Ixia box > > > (specialised hardware firing very high packet > rate). The PC was a > > Core2 2.6 > > > GHz with dual ports Intel PCIE Gigabit network > card. It can manage up > > to 1.2 > > > million pps. > > > > > > I have a higher spec PC with FreeBSD 7.1 amd64 > and Quadcore 2.3 GHz > > and > > > PCIE Gigabit network card. The performance can > only achieve up to 600k > > pps. > > > I notice the 'taskq em0' and 'taskq em1' is solid > 100% CPU but it is > > not in > > > FreeBSD 6.4. > > > >? > > > > In our case we are running FreeBSD 7.0, but we are > seeing our boxes > > experience serious thread starvation issues as the > nfe0 cpu percentage > > climbs steadily while cpu idle time drops at times to > 0 percent. This > > email thread mentioned a patch for the em driver > here: > > > >? > > > > http://people.yandex-team.ru/~wawa/ > > > > > > >? > > > > Does anyone know if this patch will work with the nfe > driver? > > > > That's for em(4). > > AFAIK all nfe(4) controllers lacks intelligent interrupts > moderation so driver should be prepared to handle > excessive > interrupt loads. I'm not sure whether NVIDIA ethernet > controllers > really lacks efficient interrupt mitigation mechanism but > it > seems Linux also faces the same hardware problem. > As you might know there is no publicly available data sheet > for > NVIDIA controllers so setting it right looks very hard to > me. > Try removing the INTR_MPSAFE flag from the bus_setup_intr() call. The entire point of using filters is to reduce lock contention. It might not solve the problem but its clearly an unnecessary potential bottleneck. Barney From barney_cordoba at yahoo.com Thu Aug 13 12:37:26 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Aug 13 12:37:32 2009 Subject: nfe taskq performance issues In-Reply-To: <430428.63263.qm@web63902.mail.re1.yahoo.com> Message-ID: <978222.18685.qm@web63904.mail.re1.yahoo.com> --- On Thu, 8/13/09, Barney Cordoba wrote: > From: Barney Cordoba > Subject: Re: nfe taskq performance issues > To: "Peter Steele" , pyunyh@gmail.com > Cc: freebsd-net@freebsd.org > Date: Thursday, August 13, 2009, 7:56 AM > > > --- On Wed, 8/12/09, Pyun YongHyeon > wrote: > > > From: Pyun YongHyeon > > Subject: Re: nfe taskq performance issues > > To: "Peter Steele" > > Cc: freebsd-net@freebsd.org > > Date: Wednesday, August 12, 2009, 5:35 PM > > On Thu, Jul 23, 2009 at 08:58:07AM > > -0700, Peter Steele wrote: > > > We've been hitting serious nfe taskq performance > > issues during stress > > > tests and in doing some research on the problem > we > > came across this old > > > email: > > > > > >? > > > > > > From: Ivan Voras > > > Date: April 28, 2009 3:53:14 AM PDT > > > To: freebsd-threads@freebsd.org > > > Cc: freebsd-net@freebsd.org, > > freebsd-performance@freebsd.org > > > Subject: Re: FreeBSD 7.1 taskq em performance > > > > > > > > I have been hitting some barrier with > FreeBSD 7.1 > > network performance. > > > I > > > > have written an application which contains > two > > kernel threads that > > > takes > > > > mbufs directly from a network interface and > > forwards to another > > > network > > > > interface. This idea is to simulate > different > > network environment. > > > > > > > > I have been using FreeBSD 6.4 amd64 and > tested > > with an Ixia box > > > > (specialised hardware firing very high > packet > > rate). The PC was a > > > Core2 2.6 > > > > GHz with dual ports Intel PCIE Gigabit > network > > card. It can manage up > > > to 1.2 > > > > million pps. > > > > > > > > I have a higher spec PC with FreeBSD 7.1 > amd64 > > and Quadcore 2.3 GHz > > > and > > > > PCIE Gigabit network card. The performance > can > > only achieve up to 600k > > > pps. > > > > I notice the 'taskq em0' and 'taskq em1' is > solid > > 100% CPU but it is > > > not in > > > > FreeBSD 6.4. > > > > > >? > > > > > > In our case we are running FreeBSD 7.0, but we > are > > seeing our boxes > > > experience serious thread starvation issues as > the > > nfe0 cpu percentage > > > climbs steadily while cpu idle time drops at > times to > > 0 percent. This > > > email thread mentioned a patch for the em driver > > here: > > > > > >? > > > > > > http://people.yandex-team.ru/~wawa/ > > > > > > > > > > >? > > > > > > Does anyone know if this patch will work with the > nfe > > driver? > > > > > > > That's for em(4). > > > > AFAIK all nfe(4) controllers lacks intelligent > interrupts > > moderation so driver should be prepared to handle > > excessive > > interrupt loads. I'm not sure whether NVIDIA ethernet > > controllers > > really lacks efficient interrupt mitigation mechanism > but > > it > > seems Linux also faces the same hardware problem. > > As you might know there is no publicly available data > sheet > > for > > NVIDIA controllers so setting it right looks very hard > to > > me. > > > > Try removing the INTR_MPSAFE flag from the bus_setup_intr() > call. > The entire point of using filters is to reduce lock > contention. > It might not solve the problem but its clearly an > unnecessary > potential bottleneck. > > Barney I'm curious as to the statistics on your system. Your quad core adapter may actually be hurting the performance. What is the cpu usage distribution shown by top -SH when you are loaded, and how many interrupts/second are you getting per nic? It looks like the default moderation is set to 8000 ints/sec, which is probably ok for 1 interrupt per NIC. Its not clear whether multiple msix interrupts are allocated. Spreading interrupts isn't always a good thing as it increases lock contention so much as to be counterproductive, unless you have properly written mutex management code; which nfe doesn't. Barney From bu7cher at yandex.ru Thu Aug 13 13:13:34 2009 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Thu Aug 13 13:14:06 2009 Subject: RFC: interface description In-Reply-To: <4A83EEA8.5080202@delphij.net> References: <4A83EEA8.5080202@delphij.net> Message-ID: <4A840DA1.600@yandex.ru> Xin LI wrote: > While playing with some OpenBSD installation I found that they have an > interesting feature - adding description to a NIC. This is useful for > system administrators to "tag" the interface, also, the ladvd program > has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP Something similar was rejected at least two times :) http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 -- WBR, Andrey V. Elsukov From lists.br at gmail.com Thu Aug 13 14:15:07 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Thu Aug 13 14:24:49 2009 Subject: RFC: interface description References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> Message-ID: > Xin LI wrote: >> While playing with some OpenBSD installation I found that they have an >> interesting feature - adding description to a NIC. This is useful for >> system administrators to "tag" the interface, also, the ladvd program >> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP > > Something similar was rejected at least two times :) > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 > That was a long time ago... The Xin Li patch is a quite complete (manual pages updated as well) and only suffer from the 64 byte limit on interface description (and the 64 more bytes on ifnet), wich IMHO, should be easy to fix. Thank you Xin Li for bringing this =) Luiz From bzeeb-lists at lists.zabbadoz.net Thu Aug 13 16:05:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Aug 13 16:05:13 2009 Subject: NAT-T patch for 7-STABLE Message-ID: <20090813154703.Y93661@maildrop.int.zabbadoz.net> Hi, I just MFCed the UDP Control Block, which is a prerequisite for merging the NAT-T patch from HEAD (8) to 7-STABLE: http://svn.freebsd.org/viewvc/base?view=revision&revision=196192 I also merged back the NAT-T changes from FreeBSD 8/HEAD. This will allow us to provide the same API for tools for FreeBSD 7 (with patch) and stock FreeBSD 8.x and 9 (HEAD). Before anyone is going to ask: no the NAT-T is not comittable to FreeBSD 7-STABLE, so anyone on 7 will have to live with a patch. In case you use tools that rely on the right version of a patch (like ipsec-tools), I'd expect things to take a few days to get solved, so do not expect that things will mysteriously just work. Considering 8 is in BETA and I assume the ports tree will be frozen soon as well if it is not yet, it might even take a few days longer. This is mostly for the people doing the work, integrating things, changing software to have something to work with. Things have been bascially tested with a slightly modified to compile ipsec-tools CVS HEAD checkout. Last but not least - you can find the patch here: http://people.freebsd.org/~bz/20090813-01-mfc-r194062-natt.diff /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From ady at freebsd.ady.ro Thu Aug 13 16:35:09 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Thu Aug 13 16:35:18 2009 Subject: RFC: ARP Statistics In-Reply-To: <533A2900-CDAC-4BFB-952B-45FB18E19B7E@neville-neil.com> References: <533A2900-CDAC-4BFB-952B-45FB18E19B7E@neville-neil.com> Message-ID: <78cb3d3f0908130903v6b16d819qa27b9f5263676479@mail.gmail.com> Hi, Perhaps it would be useful to add a "ARP flip-flop events" field, counting the "arp: is on but got reply from on " events. PS: minor nit/correction: use "ARP cache entries timed out" instead of "ARP entrys timed out" Regards, Adrian Penisoara EnterpriseBSD On Wed, Aug 12, 2009 at 3:43 PM, George Neville-Neil wrote: > Howdy, > > Here is a small patch that updates the kernel and the netstat(1) program to > print out protocol > statistics for ARP. I'd be interested in any feedback people have on this. > > Sample output: > > netstat -s -p arp > arp: > 469 ARP requests sent > 2117 ARP replies received > 0 total packets dropped due to no ARP entry > 469 ARP entrys timed out > 0 Duplicate IPs seen > > > Best, > George > > > > Index: usr.bin/netstat/inet.c > =================================================================== > --- usr.bin/netstat/inet.c (revision 196095) > +++ usr.bin/netstat/inet.c (working copy) > @@ -49,6 +49,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -871,6 +872,44 @@ > #undef p1a > } > > +/* > + * Dump ARP statistics structure. > + */ > +void > +arp_stats(u_long off, const char *name, int af1 __unused, int proto > __unused) > +{ > + struct arpstat arpstat, zerostat; > + size_t len = sizeof(arpstat); > + > + if (live) { > + if (zflag) > + memset(&zerostat, 0, len); > + if (sysctlbyname("net.link.ether.arp.stats", &arpstat, > &len, > + zflag ? &zerostat : NULL, zflag ? len : 0) < 0) { > + warn("sysctl: net.link.ether.arp.stats"); > + return; > + } > + } else > + kread(off, &arpstat, len); > + > + printf("%s:\n", name); > + > +#define p(f, m) if (arpstat.f || sflag <= 1) \ > + printf(m, arpstat.f, plural(arpstat.f)) > +#define p1a(f, m) if (arpstat.f || sflag <= 1) \ > + printf(m, arpstat.f) > + > + p(arp_requests, "\t%lu ARP request%s sent\n"); > + p(arp_replies, "\t%lu ARP replie%s received\n"); > + p(arp_dropped, "\t%lu total packet%s dropped due to no ARP > entry\n"); > + p(arp_timeout, "\t%lu ARP entry%s timed out\n"); > + p(arp_dupips, "\t%lu Duplicate IP%s seen\n"); > +#undef p > +#undef p1a > +} > + > + > + > static const char *icmpnames[ICMP_MAXTYPE + 1] = { > "echo reply", /* RFC 792 */ > "#1", > Index: usr.bin/netstat/main.c > =================================================================== > --- usr.bin/netstat/main.c (revision 196095) > +++ usr.bin/netstat/main.c (working copy) > @@ -184,6 +184,8 @@ > { .n_name = "_sctpstat" }, > #define N_MFCTABLESIZE 54 > { .n_name = "_mfctablesize" }, > +#define N_ARPSTAT 55 > + { .n_name = "_arpstat" }, > { .n_name = NULL }, > }; > > @@ -232,6 +234,8 @@ > carp_stats, NULL, "carp", 1, 0 }, > { -1, N_PFSYNCSTAT, 1, NULL, > pfsync_stats, NULL, "pfsync", 1, 0 }, > + { -1, N_ARPSTAT, 1, NULL, > + arp_stats, NULL, "arp", 1, 0 }, > { -1, -1, 0, NULL, > NULL, NULL, NULL, 0, 0 } > }; > Index: usr.bin/netstat/netstat.h > =================================================================== > --- usr.bin/netstat/netstat.h (revision 196095) > +++ usr.bin/netstat/netstat.h (working copy) > @@ -75,6 +75,7 @@ > void sctp_protopr(u_long, const char *, int, int); > void sctp_stats(u_long, const char *, int, int); > #endif > +void arp_stats(u_long, const char *, int, int); > void ip_stats(u_long, const char *, int, int); > void icmp_stats(u_long, const char *, int, int); > void igmp_stats(u_long, const char *, int, int); > Index: sys/netinet/if_ether.c > =================================================================== > --- sys/netinet/if_ether.c (revision 196095) > +++ sys/netinet/if_ether.c (working copy) > @@ -80,6 +80,7 @@ > > SYSCTL_DECL(_net_link_ether); > SYSCTL_NODE(_net_link_ether, PF_INET, inet, CTLFLAG_RW, 0, ""); > +SYSCTL_NODE(_net_link_ether, PF_ARP, arp, CTLFLAG_RW, 0, ""); > > VNET_DEFINE(int, useloopback) = 1; /* use loopback interface for > * local traffic */ > @@ -108,6 +109,11 @@ > &VNET_NAME(arp_proxyall), 0, > "Enable proxy ARP for all suitable requests"); > > +struct arpstat arpstat; /* ARP statistics, see if_arp.h */ > +SYSCTL_STRUCT(_net_link_ether_arp, OID_AUTO, stats, CTLFLAG_RW, > + &arpstat, arpstat, > + "ARP statistics (struct arpstat, net/if_arp.h)"); > + > static void arp_init(void); > void arprequest(struct ifnet *, > struct in_addr *, struct in_addr *, u_char *); > @@ -127,6 +133,7 @@ > #ifdef AF_INET > void arp_ifscrub(struct ifnet *ifp, uint32_t addr); > > + > /* > * called by in_ifscrub to remove entry from the table when > * the interface goes away > @@ -165,12 +172,13 @@ > ifp = lle->lle_tbl->llt_ifp; > IF_AFDATA_LOCK(ifp); > LLE_WLOCK(lle); > - if (((lle->la_flags & LLE_DELETED) > - || (time_second >= lle->la_expire)) > - && (!callout_pending(&lle->la_timer) && > - callout_active(&lle->la_timer))) > + if (((lle->la_flags & LLE_DELETED) || > + (time_second >= lle->la_expire)) && > + (!callout_pending(&lle->la_timer) && > + callout_active(&lle->la_timer))) { > (void) llentry_free(lle); > - else { > + arpstat.arp_timeout++; > + } else { > /* > * Still valid, just drop our reference > */ > @@ -238,6 +246,7 @@ > sa.sa_len = 2; > m->m_flags |= M_BCAST; > (*ifp->if_output)(ifp, m, &sa, NULL); > + arpstat.arp_requests++; > } > > /* > @@ -339,8 +348,10 @@ > * latest one. > */ > if (m != NULL) { > - if (la->la_hold != NULL) > + if (la->la_hold != NULL) { > m_freem(la->la_hold); > + arpstat.arp_dropped++; > + } > la->la_hold = m; > if (renew == 0 && (flags & LLE_EXCLUSIVE)) { > flags &= ~LLE_EXCLUSIVE; > @@ -413,6 +424,7 @@ > ar = mtod(m, struct arphdr *); > } > > + arpstat.arp_replies++; > switch (ntohs(ar->ar_pro)) { > #ifdef INET > case ETHERTYPE_IP: > @@ -603,6 +615,7 @@ > ifp->if_addrlen, (u_char *)ar_sha(ah), ":", > inet_ntoa(isaddr), ifp->if_xname); > itaddr = myaddr; > + arpstat.arp_dupips++; > goto reply; > } > if (ifp->if_flags & IFF_STATICARP) > @@ -821,7 +834,7 @@ > static void > arp_init(void) > { > - > + bzero(&arpstat, sizeof(arpstat)); > netisr_register(&arp_nh); > } > SYSINIT(arp, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, arp_init, 0); > Index: sys/net/if_arp.h > =================================================================== > --- sys/net/if_arp.h (revision 196095) > +++ sys/net/if_arp.h (working copy) > @@ -108,6 +108,16 @@ > #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) > #define AC2IFP(ac) ((ac)->ac_ifp) > > -#endif > +#endif /* _KERNEL */ > > +struct arpstat { > + /* Normal things that happen */ > + u_long arp_requests; /* # of ARP requests sent by this host */ > + u_long arp_replies; /* # of ARP replies received by this host */ > + /* Abnormal event and error counting */ > + u_long arp_dropped; /* # of packets dropped while waiting for a > reply */ > + u_long arp_timeout; /* # of times an entry is removed due to > timeout */ > + u_long arp_dupips; /* # of duplicate IPs detected. */ > +}; > + > #endif /* !_NET_IF_ARP_H_ */ > > _______________________________________________ > 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 Thu Aug 13 17:40:04 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 13 17:40:14 2009 Subject: RFC: interface description In-Reply-To: <4A840DA1.600@yandex.ru> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> Message-ID: <4A844FF2.9000307@elischer.org> Andrey V. Elsukov wrote: > Xin LI wrote: >> While playing with some OpenBSD installation I found that they have an >> interesting feature - adding description to a NIC. This is useful for >> system administrators to "tag" the interface, also, the ladvd program >> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP > > Something similar was rejected at least two times :) not rejected.. suffered from lack of enthusiasm maybe. > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 > From bzeeb-lists at lists.zabbadoz.net Thu Aug 13 18:35:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Aug 13 18:35:14 2009 Subject: RFC: interface description In-Reply-To: <4A844FF2.9000307@elischer.org> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> Message-ID: <20090813182918.S93661@maildrop.int.zabbadoz.net> On Thu, 13 Aug 2009, Julian Elischer wrote: > Andrey V. Elsukov wrote: >> Xin LI wrote: >>> While playing with some OpenBSD installation I found that they have an >>> interesting feature - adding description to a NIC. This is useful for >>> system administrators to "tag" the interface, also, the ladvd program >>> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP >> >> Something similar was rejected at least two times :) >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 > > not rejected.. > > suffered from lack of enthusiasm maybe. My point has always been - if I have to add/do an ioctl I can always also use a library call that will read it from a .txt, .xml, .db file or whatever and I don't have to go to the kernel, handle all the string length problems there, ... especially as the kernel cannot do anything with that string. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From sthaug at nethelp.no Thu Aug 13 19:20:49 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Thu Aug 13 19:21:02 2009 Subject: RFC: interface description In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> References: <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> Message-ID: <20090813.212046.78768090.sthaug@nethelp.no> > My point has always been - if I have to add/do an ioctl I can always also > use a library call that will read it from a .txt, .xml, .db file > or whatever and I don't have to go to the kernel, handle all the > string length problems there, ... especially as the kernel cannot do > anything with that string. Personally, I couldn't care less if an interface description is stored in the kernel or in a file. I *do* care about being able to set and show the description via ifconfig. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From delphij at delphij.net Thu Aug 13 19:36:09 2009 From: delphij at delphij.net (Xin LI) Date: Thu Aug 13 19:36:16 2009 Subject: RFC: interface description In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> Message-ID: <4A846AD3.3080301@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bjoern A. Zeeb wrote: > On Thu, 13 Aug 2009, Julian Elischer wrote: > >> Andrey V. Elsukov wrote: >>> Xin LI wrote: >>>> While playing with some OpenBSD installation I found that they have an >>>> interesting feature - adding description to a NIC. This is useful for >>>> system administrators to "tag" the interface, also, the ladvd program >>>> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP >>> >>> Something similar was rejected at least two times :) >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 >> >> not rejected.. >> >> suffered from lack of enthusiasm maybe. > > My point has always been - if I have to add/do an ioctl I can always also > use a library call that will read it from a .txt, .xml, .db file > or whatever and I don't have to go to the kernel, handle all the > string length problems there, ... especially as the kernel cannot do > anything with that string. I have also received some private e-mail regarding this, and I think that would be more sensible (better flexibility, and of course, a better chance that we can MFC it since it won't change kernel ABI). The only question I have would be, that is it possible to uniquely identify a NIC without assistance from kernel? For instance, one can change an interface from being called "em0" to "eth0" and from "bge0" to "em0". It's easy to track this information through ifconfig(8) with a callback, clean up the file upon restart, but we can not prevent other programs from calling IOCSIFNAME on the interface. Any idea for this? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqEatIACgkQi+vbBBjt66Ah7gCgsv2O9FpF+fAbIPJqkICWkC+I HmYAoK4GmPynk4qh2FL2CnJY12MOBzEB =MG3y -----END PGP SIGNATURE----- From z3tbl4 at gmail.com Thu Aug 13 23:00:15 2009 From: z3tbl4 at gmail.com (Z3tbl4 []) Date: Thu Aug 13 23:00:21 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200908132300.n7DN0F9L037186@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: "Z3tbl4 []" To: bug-followup@FreeBSD.org, sergei.cherveni@gmail.com Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Fri, 14 Aug 2009 02:28:54 +0400 SGVsbG8gd29ybGQhIElzIGl0IHBvc3NpYmxlIHRvIHBhdGNoIG5nX2lmYWNlLmMgYW5kIG5nX2lm YWNlLmggb24KRnJlZUJTRCA2LjQtUkVMRUFTRSBzb21laG93PwpUaGFuayB5b3UuCiMjIyMjIyMj IyMjIyMjIyMjIyMjIyMK99PFzSDQ0snXxdQsINDP08/XxdTVytTFIN7UzyDExczB1Ngg1yDUwcvP yiDTydTVwcPJyS4uLgruwSDG0sUgKFA0IDNHSHopIDYuNC1yZWxlYXNlIMXT1NggbXBkNSwg0cTS zyDTz8LSwc7PINMKY3B1ICAgICAgICAgICAgIEk2ODZfQ1BVCm9wdGlvbnMgICAgICAgICBTTVAK b3B0aW9ucyAgICAgICAgIElQRklSRVdBTEwKb3B0aW9ucyAgICAgICAgIElQRElWRVJUCm9wdGlv bnMgICAgICAgICBEVU1NWU5FVApvcHRpb25zICAgICAgICAgTkVUR1JBUEgKb3B0aW9ucyAgICAg ICAgIE5FVEdSQVBIX1BQUApvcHRpb25zICAgICAgICAgTkVUR1JBUEhfUFBUUEdSRQoK1yDQ0s/J 2tfPzNjO2cUgzc/Nxc7U2SDawdfJ08HF1CDOxdTH0sHGLCDQ0sPF09MgInN3aTE6IG5ldCIgz9TW ydLBxdQK18XT2CDQ0s/DxdPTz9IsINfTxSDTxdTF19nFIMvB0tTZINDF0sXT1MHA1CDP1NfF3sHU 2Cwgy8/O08/M2ArSwcLP1MHF1Cwgzc/Wzs8g0sXC1dTO1dTY09EuCvPJzNjOzyDQz8fVx8zJ1ywg zsHbo8wsIN7UzyDc1MEgz9vJwsvBINfP2s7Jy8HF1CDJ2i3awSDUz8fPLCDe1M8gbXBkCtrBw8nL zMnXwcXUIMvBy8/KLdTPINPF1MXXz8og0MHLxdQgKN7UzyDX0NLJzsPJ0MUg08/HzMHT1cXU09Eg 0wrOwcLMwMTFzsnRzckpIMLBx9LF0M/S1CAia2Vybi8xMzI5ODQiCmh0dHA6Ly9saXN0cy5mcmVl YnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1idWdzLzIwMDktTWFyY2gvMC4uLiAuCu7B26PMINDB 1N4gxMzRIC9zeXMvbmV0Z3JhcGgvbmdfaWZhY2UuYywgbmdfaWZhY2UuaCwgzs8gwsXEwSDXINTP zSwK3tTPIM/OIM7FINPPwsnSwcXU09Eg0M/EIDYuNCAo18nEyc3PIMTM0SDG0sDIIDcgySDX2dvF KS4K5dPMySDL1M8g2s7BxdQgy8HLIMnT0NLB18nU2CDc1M/UIG5nX2lmYWNlLmMg0M/EIDYuNCDC 1cTVIMLF2s3F0s7PCsLMwcfPxMHSxc4sINPQwdPJws8uCg== From sfourman at gmail.com Fri Aug 14 00:05:48 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Fri Aug 14 00:05:54 2009 Subject: LACP support and if_tap interface In-Reply-To: References: Message-ID: <11167f520908131644w60627074g968d64061849ed22@mail.gmail.com> On Thu, Aug 6, 2009 at 11:51 PM, serg vasilyev wrote: > Now i'm able to emulate a media and status on if_tap interface... > > tap0: flags=8802 metric 0 mtu 1500 > ? ? ? ?ether 00:bd:49:f7:a6:00 > ? ? ? ?media: Ethernet 100baseTX > ? ? ? ?status: active > > BUT i suspect that there must be some another flag or capability of > if_tap to work with LACP... > can somebody tell me what flags exactly responsible for LACP functionality ? > > > 2009/8/6, serg vasilyev : >> Hi everyone. >> Can anyone modify if_tap interface to achieve LACP needs (probably add >> a virtual media i suspect)? >> I want to create an Ethernet tunnel with aggregation via openvpn but >> if_tap interface cannot give right internal capabilities for lagg and >> LACP to work properly Did anyone ever get this to work? I want to do LACP over ssh tunnels aka tap0 tap1 Sam Fourman Jr. From bu7cher at yandex.ru Fri Aug 14 06:05:16 2009 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri Aug 14 06:05:23 2009 Subject: RFC: interface description In-Reply-To: <4A846AD3.3080301@delphij.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> Message-ID: <4A84FE96.1070506@yandex.ru> Xin LI wrote: > The only question I have would be, that is it possible to uniquely > identify a NIC without assistance from kernel? For instance, one can > change an interface from being called "em0" to "eth0" and from "bge0" to > "em0". It's easy to track this information through ifconfig(8) with a > callback, clean up the file upon restart, but we can not prevent other > programs from calling IOCSIFNAME on the interface. Any idea for this? What about using interface index as a key(see if_nameindex(3))? -- WBR, Andrey V. Elsukov From bzeeb-lists at lists.zabbadoz.net Fri Aug 14 08:00:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Aug 14 08:00:15 2009 Subject: RFC: interface description In-Reply-To: <4A84FE96.1070506@yandex.ru> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> <4A84FE96.1070506@yandex.ru> Message-ID: <20090814071511.U93661@maildrop.int.zabbadoz.net> On Fri, 14 Aug 2009, Andrey V. Elsukov wrote: Hi, > Xin LI wrote: >> The only question I have would be, that is it possible to uniquely >> identify a NIC without assistance from kernel? For instance, one can >> change an interface from being called "em0" to "eth0" and from "bge0" to >> "em0". It's easy to track this information through ifconfig(8) with a >> callback, clean up the file upon restart, but we can not prevent other >> programs from calling IOCSIFNAME on the interface. Any idea for this? > > What about using interface index as a key(see if_nameindex(3))? So here comes the usual catch 22 on a classic PC system: you can change everything. Using RFC 2553 Section 4 is probably the best indeed but has drawbacks as well. If you match by xname, renaming the interface will break things. If you match by dname+unit, unit can still change between boots (see further on). If you match by MAC address the MAC address can be changed by the user. If you match by (PCI/..) slot, cards can be moved. If you match by card serial number, *oops* most of those don't have that in the consumer or even server world so that's not an option. Because of the above we don't have any metadata that would allow us to have persistent ifIndexes between boots. Once you add portable interfaces (pcmcia, usb, pc card, ..) to the game even your ifIndex upon boot may vary depending on if a card is plugged in or not or if you added another one, possibly using the same driver changing the unit number if unlucky (see above). Now add cloned interfaces from gif, tun, .. to wlan and you'll understand the big (problem|picture). Now let us look at this from a different view - what can venders do to avoid all this or how can they handle things: They might have ways to uniquely identify each interface so an ifIndex could possibly always be the same after the interface was first put into a device (interface serial number for example). They usually do not allow renaming of interface names. They usually do not have physical interfaces coming and going very often. They do have "cloned-a-like" interfaces as well so they have to handle them somehow. I have seldomly seen descriptions on those if they come and go. They possibly treat static "tunnel" interfaces, etc. more statically having a well defined bringup order. The cards lose their description if moved to a different slot or rather as the interface goes away usually and even if plugged into a different slot would lose the description but maybe not the ifIndex. What does that mean for us? For "dynamic" interfaces storing things with the kernel would for sure be easier as if you remove the interface the description is gone. If not storing in the kernel we get interface insertion and removal events already to userspace/devd imho we could use. The moment you add the description it doesn't matter what the interface is, as you can name it always some way. If you take the classic BSD scheme and will seed the "storage" upon boot from scratch from rc.conf or other places you will have a consitent ifIndex for all hard wired physical interfaces (non-hotpluggable). [Unless you move hardware that should even be the same if we don't change bus scanning orders, etc.] For all the cloned stuff things are harder, as we to my knowledge even recycle ifIndexes to not have huge gaps in the array (which is a real pain), so there are kernel limitations as well in the way we store/lookup things that also had come up during the vnet merges and that people are aware of. Bsnmp should have to handle parts of this all already and is for sure one of the first consumers so talking to harti and syrinx or looking at that code might also be a good thing todo. My biggest worry comes with the cloned interfaces like tuns or similar ones if they come and go often; if an ifIndex is recycled and even if the interface name is the same afterwards there should be no old description left, so "purging" entries on interface deletion and possibly asserting that on interface creation would be a good idea. JustMy2ctAndEndOfBrainDumpInTheMorningBeforeTheFirstCupOfCoffe /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From louie at transsys.com Fri Aug 14 15:05:54 2009 From: louie at transsys.com (Louis Mamakos) Date: Fri Aug 14 15:06:02 2009 Subject: RFC: interface description In-Reply-To: <20090814071511.U93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> <4A84FE96.1070506@yandex.ru> <20090814071511.U93661@maildrop.int.zabbadoz.net> Message-ID: On Aug 14, 2009, at 3:58 AM, Bjoern A. Zeeb wrote: > On Fri, 14 Aug 2009, Andrey V. Elsukov wrote: > > Hi, > >> Xin LI wrote: >>> The only question I have would be, that is it possible to uniquely >>> identify a NIC without assistance from kernel? For instance, one >>> can >>> change an interface from being called "em0" to "eth0" and from >>> "bge0" to >>> "em0". It's easy to track this information through ifconfig(8) >>> with a >>> callback, clean up the file upon restart, but we can not prevent >>> other >>> programs from calling IOCSIFNAME on the interface. Any idea for >>> this? >> >> What about using interface index as a key(see if_nameindex(3))? > > So here comes the usual catch 22 on a classic PC system: > you can change everything. > > Using RFC 2553 Section 4 is probably the best indeed but has drawbacks > as well. > > > If you match by xname, renaming the interface will break things. > If you match by dname+unit, unit can still change between boots (see > further on). > If you match by MAC address the MAC address can be changed by the > user. > If you match by (PCI/..) slot, cards can be moved. > If you match by card serial number, *oops* most of those don't have > that in the consumer or even server world so that's not an option. > Because of the above we don't have any metadata that would allow us to > have persistent ifIndexes between boots. > Once you add portable interfaces (pcmcia, usb, pc card, ..) to the > game > even your ifIndex upon boot may vary depending on if a card is > plugged in or not or if you added another one, possibly using the > same driver changing the unit number if unlucky (see above). > Now add cloned interfaces from gif, tun, .. to wlan and you'll > understand the big (problem|picture). > > > Now let us look at this from a different view - what can venders do to > avoid all this or how can they handle things: > > They might have ways to uniquely identify each interface so an ifIndex > could possibly always be the same after the interface was first > put into a device (interface serial number for example). > They usually do not allow renaming of interface names. > They usually do not have physical interfaces coming and going very > often. > They do have "cloned-a-like" interfaces as well so they have to handle > them somehow. I have seldomly seen descriptions on those if they > come and go. They possibly treat static "tunnel" interfaces, etc. > more statically having a well defined bringup order. > The cards lose their description if moved to a different slot or > rather as the interface goes away usually and even if plugged into > a different slot would lose the description but maybe not the > ifIndex. > > > What does that mean for us? > > For "dynamic" interfaces storing things with the kernel would for sure > be easier as if you remove the interface the description is gone. > If not storing in the kernel we get interface insertion and removal > events already to userspace/devd imho we could use. > The moment you add the description it doesn't matter what the > interface is, as you can name it always some way. > If you take the classic BSD scheme and will seed the "storage" upon > boot from scratch from rc.conf or other places you will have a > consitent ifIndex for all hard wired physical interfaces > (non-hotpluggable). > [Unless you move hardware that should even be the same if we don't > change bus scanning orders, etc.] > For all the cloned stuff things are harder, as we to my knowledge even > recycle ifIndexes to not have huge gaps in the array (which is a > real pain), so there are kernel limitations as well in the way > we store/lookup things that also had come up during the vnet > merges and that people are aware of. > Bsnmp should have to handle parts of this all already and is for sure > one of the first consumers so talking to harti and syrinx or > looking at that code might also be a good thing todo. > > > My biggest worry comes with the cloned interfaces like tuns or similar > ones if they come and go often; if an ifIndex is recycled and even if > the interface name is the same afterwards there should be no old > description left, so "purging" entries on interface deletion and > possibly asserting that on interface creation would be a good idea. > > > JustMy2ctAndEndOfBrainDumpInTheMorningBeforeTheFirstCupOfCoffe > > /bz > Interface names (bge0, fxp1, etc.) name ports on the local host/router. The use of "interface descriptions" is almost always an attempt to name or describe what's connected on the other side of the network interface. This is what the various "discovery" protocols, like CDP[1] and LLDP[2] try to solve; to dynamically discover WTF this port is plugged into. The problem with ifIndex stability is somewhat related, but you could imagine choosing some physical identifier (like the manufactured MAC address) as the name. The ifIndex in the general case doesn't account for the user deciding to externally swap the ethernet cables between a pair of ports. Louis Mamakos [1] http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol [2] http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol From qing.li at bluecoat.com Fri Aug 14 17:51:46 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Aug 14 17:51:52 2009 Subject: RFC: interface description In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru><4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> Message-ID: > > My point has always been - if I have to add/do an ioctl I can always > also use a library call that will read it from a .txt, .xml, .db file > or whatever and I don't have to go to the kernel, handle all the > string length problems there, ... especially as the kernel cannot do > anything with that string. > The interface description feature is a useful feature. Quite a few products out there actually put a label on the physical box so it's reasonable to have the ability to label the ports in the kernel. There are quite a few embedded systems and not-so-standalone boxes out there that are derivatives of FreeBSD. These systems might not have the luxury of a file system. And getting coredumps from the field with such information embedded in the ifnet{} just makes debugging field issues a little bit easier. > > So here comes the usual catch 22 on a classic PC system: > you can change everything. > > Using RFC 2553 Section 4 is probably the best indeed but has > drawbacks as well. > Seems rather off topic ... -- Qing From brooks at freebsd.org Fri Aug 14 20:05:28 2009 From: brooks at freebsd.org (Brooks Davis) Date: Fri Aug 14 20:05:34 2009 Subject: RFC: interface description In-Reply-To: References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> Message-ID: <20090814193303.GA21941@lor.one-eyed-alien.net> On Fri, Aug 14, 2009 at 10:49:24AM -0700, Li, Qing wrote: > > > > My point has always been - if I have to add/do an ioctl I can always > > also use a library call that will read it from a .txt, .xml, .db file > > or whatever and I don't have to go to the kernel, handle all the > > string length problems there, ... especially as the kernel cannot do > > anything with that string. > > The interface description feature is a useful feature. Quite a few > products out there actually put a label on the physical box so it's > reasonable to have the ability to label the ports in the kernel. > > There are quite a few embedded systems and not-so-standalone boxes > out there that are derivatives of FreeBSD. These systems might not > have the luxury of a file system. And getting coredumps from the > field with such information embedded in the ifnet{} just makes > debugging field issues a little bit easier. I think this is a decently compelling argument for in-kernel descriptions. They do solve some synchronization issues and one pointer is probably an acceptable price to pay given all the edge cases related to keeping a file in sync if you went the totally user land route. I general, I don't think we should try too hard to solve every problem here. Adding a pointer to ifnet, a quick get/set ioctl, ifconfig support, and support for ifdesc_ or similar variables in rc.conf is probably as much as makes sense to do. This is mostly a feature for appliance builders. If I were working on adding the ability to slim down ifnet to the base system, I'd certainly make this an optional feature, but there are much fatter targets at the moment. -- Brooks -------------- 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/20090814/bee442b1/attachment.pgp From linimon at FreeBSD.org Fri Aug 14 20:21:44 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Aug 14 20:21:51 2009 Subject: kern/137775: [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many Message-ID: <200908142021.n7EKLiQ0063600@freefall.freebsd.org> Old Synopsis: [patch] Add XMIT_FAILOVER to ng_one2many New Synopsis: [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 14 20:20:55 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137775 From delphij at delphij.net Sat Aug 15 00:32:38 2009 From: delphij at delphij.net (Xin LI) Date: Sat Aug 15 00:32:47 2009 Subject: [Take 2] Re: RFC: interface description In-Reply-To: <20090814193303.GA21941@lor.one-eyed-alien.net> References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> Message-ID: <4A8601CE.5030205@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, guys, Here is a patch that implements the functionality in userland (as setifdescription/getifdescription functions in libutil); with this I think we can also provide an option that some kernel feature (like Qing Li said it might be useful for embedded systems, but of course the kernel feature would require more careful design) being used without modifying programs. This version uses if_dname plus if_dunit as distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store the information. In order to obtain if_dname and if_duint I had to create a new ioctl, as we don't seem to expose these two fields in an KBI-stable manner in the past. I have not took a look at bsnmp yet but I'll take a look at it to see if we have some better ways to distinguish the interface name. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqGAc0ACgkQi+vbBBjt66D82QCeMV3G+2FepN5asaxvAwpc0qKS 1poAoIhQ719JdYPE7sq+lseTtszr++o0 =ph72 -----END PGP SIGNATURE----- -------------- next part -------------- Index: sbin/ifconfig/ifconfig.c =================================================================== --- sbin/ifconfig/ifconfig.c (revision 196234) +++ sbin/ifconfig/ifconfig.c (working copy) @@ -63,6 +63,7 @@ static const char rcsid[] = #include #include +#include #include #include #include @@ -822,6 +823,24 @@ setifname(const char *val, int dummy __unused, int free(newname); } +/* ARGSUSED */ +static void +setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp __unused) +{ + + setifdescription(s, &ifr, val); +} + +/* ARGSUSED */ +static void +unsetifdescr(const char *val __unused, int dummy __unused, int s, + const struct afswtch *afp __unused) +{ + + setifdescription(s, &ifr, NULL); +} + #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ @@ -843,6 +862,7 @@ status(const struct afswtch *afp, const struct soc struct ifaddrs *ift; int allfamilies, s; struct ifstat ifs; + char *description = NULL; if (afp == NULL) { allfamilies = 1; @@ -866,6 +886,11 @@ status(const struct afswtch *afp, const struct soc printf(" mtu %d", ifr.ifr_mtu); putchar('\n'); + if (getifdescription(s, &ifr, &description) == 0 && description != NULL) + printf("\tdescription: %s\n", description); + free(description); + description = NULL; + if (ioctl(s, SIOCGIFCAP, (caddr_t)&ifr) == 0) { if (ifr.ifr_curcap != 0) { printb("\toptions", ifr.ifr_curcap, IFCAPBITS); @@ -1035,6 +1060,10 @@ static struct cmd basic_cmds[] = { DEF_CMD("-arp", IFF_NOARP, setifflags), DEF_CMD("debug", IFF_DEBUG, setifflags), DEF_CMD("-debug", -IFF_DEBUG, setifflags), + DEF_CMD_ARG("description", setifdescr), + DEF_CMD_ARG("descr", setifdescr), + DEF_CMD("-description", 0, unsetifdescr), + DEF_CMD("-descr", 0, unsetifdescr), DEF_CMD("promisc", IFF_PPROMISC, setifflags), DEF_CMD("-promisc", -IFF_PPROMISC, setifflags), DEF_CMD("add", IFF_UP, notealias), Index: sbin/ifconfig/Makefile =================================================================== --- sbin/ifconfig/Makefile (revision 196234) +++ sbin/ifconfig/Makefile (working copy) @@ -27,8 +27,8 @@ SRCS+= ifgre.c # GRE keys etc SRCS+= ifgif.c # GIF reversed header workaround SRCS+= ifieee80211.c regdomain.c # SIOC[GS]IEEE80211 support -DPADD+= ${LIBBSDXML} ${LIBSBUF} ${LIBJAIL} -LDADD+= -lbsdxml -ljail -lsbuf +DPADD+= ${LIBBSDXML} ${LIBSBUF} ${LIBJAIL} ${LIBUTIL} +LDADD+= -lbsdxml -ljail -lsbuf -lutil SRCS+= ifcarp.c # SIOC[GS]VH support SRCS+= ifgroup.c # ... Index: lib/libutil/Makefile =================================================================== --- lib/libutil/Makefile (revision 196234) +++ lib/libutil/Makefile (working copy) @@ -10,11 +10,12 @@ SHLIB_MAJOR= 8 SRCS= _secure_path.c auth.c expand_number.c flopen.c fparseln.c gr_util.c \ hexdump.c humanize_number.c kinfo_getfile.c kinfo_getvmmap.c kld.c \ + if_description.c \ login.c login_auth.c login_cap.c \ login_class.c login_crypt.c login_ok.c login_times.c login_tty.c \ logout.c logwtmp.c pidfile.c property.c pty.c pw_util.c realhostname.c \ stub.c trimdomain.c uucplock.c -INCS= libutil.h login_cap.h +INCS= if_description.h libutil.h login_cap.h WARNS?= 6 @@ -31,7 +32,7 @@ MAN+= kld.3 login.3 login_auth.3 login_tty.3 logou _secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \ realhostname_sa.3 trimdomain.3 fparseln.3 humanize_number.3 \ pidfile.3 flopen.3 expand_number.3 hexdump.3 \ - kinfo_getfile.3 kinfo_getvmmap.3 + kinfo_getfile.3 kinfo_getvmmap.3 if_description.3 MAN+= login.conf.5 auth.conf.5 MLINKS+= kld.3 kld_isloaded.3 kld.3 kld_load.3 MLINKS+= property.3 properties_read.3 property.3 properties_free.3 @@ -59,5 +60,6 @@ MLINKS+=pidfile.3 pidfile_open.3 \ pidfile.3 pidfile_write.3 \ pidfile.3 pidfile_close.3 \ pidfile.3 pidfile_remove.3 +MLINKS+= if_description.3 setifdescription.3 if_description.3 getifdescription.3 .include Index: lib/libutil/if_description.3 =================================================================== --- lib/libutil/if_description.3 (revision 0) +++ lib/libutil/if_description.3 (revision 0) @@ -0,0 +1,90 @@ +.\"- +.\" Copyright (c) 2009 Xin LI +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd September 15, 2009 +.Os +.Dt IFSETDESCRIPTION 3 +.Sh NAME +.Nm ifsetdescription , +.Nm ifgetdescription +.Nd ifnet description utility functions +.Sh LIBRARY +.Lb libutil +.Sh SYNOPSIS +.In if_description.h +.Ft int +.Fn setifdescription "int s" "struct ifreq *ifr" "const char *val" +.Ft int +.Fn getifdescription "int s" "struct ifreq *ifr" "char **val" +.Sh DESCRIPTION +These functions manipulates auxiliary interface description facility +from userland. +.Pp +The +.Fn setifdescription +function store the description +.Fa val +on the socket +.Fa s +referencing the interface and a struct ifreq pointer +.Fa ifr +that is already filled in with appropriate request information. +If +.Fa val +is NULL or is a pointer to empty string, +the interface description is removed. +.Pp +The +.Fn getifdescription +function reads and fills the description information into +.Fa *val +from the socket +.Fa s +with a struct ifreq pointer +.Fa ifr +that is already filled in with appropriate request information. +The previous +.Fa *val +will be freed and reallocated if it is not NULL. +.Sh RETURN VALUES +.Rv -std +.Sh SEE ALSO +.Xr netintro 4 , +.Sh HISTORY +The +.Fn ifsetdescription +and +.Fn ifgetdescrition +functions first appeared in +.Fx 9.0 . +.Sh AUTHORS +The +.Fn ifsetdescription +and +.Fn ifgetdescription +functions and this manual page were written by +.An Xin LI Aq delphij@FreeBSD.org . Property changes on: lib/libutil/if_description.3 ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: lib/libutil/if_description.c =================================================================== --- lib/libutil/if_description.c (revision 0) +++ lib/libutil/if_description.c (revision 0) @@ -0,0 +1,107 @@ +/*- + * Copyright (c) 2009 Xin LI + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +int +setifdescription(int s, struct ifreq *ifr, const char *val) +{ + DB *res; + DBT key, entry; + char dname[IFNAMSIZ]; + + bzero(dname, sizeof(dname)); + ifr->ifr_data = (caddr_t)dname; + + errno = ioctl(s, SIOCGIFDNAME, ifr); + if (errno == 0) { + res = dbopen(_PATH_IFDESCR_DB, + O_RDWR|O_CREAT|O_EXLOCK, + S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, + DB_HASH, NULL); + if (res != NULL) { + key.data = dname; + key.size = strlen(dname); + + if (val == NULL || strlen(val) == 0) { + (res->del)(res, &key, 0); + } else { + entry.data = __DECONST(void *, val); + entry.size = strlen(val) + 1; + (res->put)(res, &key, &entry, 0); + } + (res->close)(res); + return 0; + } + } + + return -1; +} + +int +getifdescription(int s, struct ifreq *ifr, char **val) +{ + DB *res; + DBT key, entry; + char dname[IFNAMSIZ]; + + bzero(dname, sizeof(dname)); + ifr->ifr_data = (caddr_t)dname; + + free(*val); + *val = NULL; + + errno = ioctl(s, SIOCGIFDNAME, ifr); + if (errno == 0) { + res = dbopen(_PATH_IFDESCR_DB, + O_RDONLY|O_SHLOCK, 0, DB_HASH, NULL); + if (res != NULL) { + key.data = dname; + key.size = strlen(dname); + + if ((res->get)(res, &key, &entry, 0) == 0) { + *val = malloc(entry.size); + strlcpy(*val, entry.data, entry.size); + } + (res->close)(res); + } + } + return 0; +} + Property changes on: lib/libutil/if_description.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: lib/libutil/if_description.h =================================================================== --- lib/libutil/if_description.h (revision 0) +++ lib/libutil/if_description.h (revision 0) @@ -0,0 +1,37 @@ +/*- + * Copyright (c) 2009 Xin LI + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _IF_DESCRIPTION_H_ +#define _IF_DESCRIPTION_H_ + +#define _PATH_IFDESCR_DB "/etc/ifdescr.db" + +int setifdescription(int s, struct ifreq *ifr, const char *val); +int getifdescription(int s, struct ifreq *ifr, char **val); + +#endif /* _IF_DESCRIPTION_H_ */ Property changes on: lib/libutil/if_description.h ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 196234) +++ sys/net/if.c (working copy) @@ -1927,6 +1927,7 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d int new_flags, temp_flags; size_t namelen, onamelen; char new_name[IFNAMSIZ]; + char dname[IFNAMSIZ]; struct ifaddr *ifa; struct sockaddr_dl *sdl; @@ -1965,6 +1966,18 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d ifr->ifr_phys = ifp->if_physical; break; + case SIOCGIFDNAME: + bzero(dname, sizeof(dname)); + if (ifp->if_dunit != IF_DUNIT_NONE) + snprintf(dname, IFNAMSIZ, "%s%d", ifp->if_dname, + ifp->if_dunit); + else + strlcpy(dname, ifp->if_dname, sizeof(dname)); + error = copyout(dname, ifr->ifr_data, sizeof(dname)); + if (error) + return (error); + break; + case SIOCSIFFLAGS: error = priv_check(td, PRIV_NET_SETIFFLAGS); if (error) Index: sys/sys/sockio.h =================================================================== --- sys/sys/sockio.h (revision 196234) +++ sys/sys/sockio.h (working copy) @@ -82,6 +82,7 @@ #define SIOCGIFMAC _IOWR('i', 38, struct ifreq) /* get IF MAC label */ #define SIOCSIFMAC _IOW('i', 39, struct ifreq) /* set IF MAC label */ #define SIOCSIFNAME _IOW('i', 40, struct ifreq) /* set IF name */ +#define SIOCGIFDNAME _IOWR('i', 41, struct ifreq) /* get IF dname */ #define SIOCADDMULTI _IOW('i', 49, struct ifreq) /* add m'cast addr */ #define SIOCDELMULTI _IOW('i', 50, struct ifreq) /* del m'cast addr */ From weongyo.jeong at gmail.com Sat Aug 15 00:45:34 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sat Aug 15 00:45:42 2009 Subject: 8. Current and Intel 5100 AGN wifi In-Reply-To: References: Message-ID: <20090815004549.GA70621@weongyo.local> On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: > folks, > > Can anyone please shet any lights on this. are iwn & iwnfw going to > support 5100 agn wifi? > I've updated mine to 8. Current with iwn & iwnfw and still not going > anywhere with the card. AFAIK no one working on it. regards, Weongyo Jeong From alireza.torabi at gmail.com Sat Aug 15 00:50:59 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Sat Aug 15 00:51:05 2009 Subject: 8. Current and Intel 5100 AGN wifi In-Reply-To: <20090815004549.GA70621@weongyo.local> References: <20090815004549.GA70621@weongyo.local> Message-ID: thanks so i gathered by the lack of response i must say... On 8/15/09, Weongyo Jeong wrote: > On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: >> folks, >> >> Can anyone please shet any lights on this. are iwn & iwnfw going to >> support 5100 agn wifi? >> I've updated mine to 8. Current with iwn & iwnfw and still not going >> anywhere with the card. > > AFAIK no one working on it. > > regards, > Weongyo Jeong > > From sfourman at gmail.com Sat Aug 15 03:10:41 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Sat Aug 15 03:10:47 2009 Subject: 8. Current and Intel 5100 AGN wifi In-Reply-To: <20090815004549.GA70621@weongyo.local> References: <20090815004549.GA70621@weongyo.local> Message-ID: <11167f520908142010g278e0cd7q3acaf989b75ac69a@mail.gmail.com> On Fri, Aug 14, 2009 at 7:45 PM, Weongyo Jeong wrote: > On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: >> folks, >> >> Can anyone please shet any lights on this. are iwn & iwnfw ?going to >> support 5100 agn wifi? >> I've updated mine to 8. Current with iwn & iwnfw and still not going >> anywhere with the card. > > AFAIK no one working on it. > > regards, > Weongyo Jeong I have a spare 5100 agn to donate if someone want to work on a driver Sam Fourman Jr. From brucec at FreeBSD.org Sat Aug 15 12:10:12 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Sat Aug 15 12:10:18 2009 Subject: kern/137795: [sctp] panic: mtx_lock() of destroyed mutex Message-ID: <200908151210.n7FCABDq027124@freefall.freebsd.org> Synopsis: [sctp] panic: mtx_lock() of destroyed mutex Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Sat Aug 15 12:09:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137795 From andre at freebsd.org Sat Aug 15 15:01:24 2009 From: andre at freebsd.org (Andre Oppermann) Date: Sat Aug 15 15:01:31 2009 Subject: [Take 2] Re: RFC: interface description In-Reply-To: <4A8601CE.5030205@delphij.net> References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> <4A8601CE.5030205@delphij.net> Message-ID: <4A86C782.5030808@freebsd.org> Xin LI wrote: > Hi, guys, > > Here is a patch that implements the functionality in userland (as > setifdescription/getifdescription functions in libutil); with this I > think we can also provide an option that some kernel feature (like Qing > Li said it might be useful for embedded systems, but of course the > kernel feature would require more careful design) being used without > modifying programs. This version uses if_dname plus if_dunit as > distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store > the information. I don't like this approach. Adding unconditional dependencies to libutil and libbsdxml unnecessarily complicates and bloats up ifconfig, which is a very central utility that resides on every rescue and minimal boot disk. Additionally the DB stored description can easily go out of sync when interface disappear and reappear. On top of that it complicates porting of routing daemons (Quagga suite, OpenBGPD/OSPFD). Having it only for ifconfig but nowhere else is not entirely pointless but seriously reduces its usefulness. IMHO interface description is a very useful feature and it should be stored in the kernel attached to struct ifnet. However it probably should only be a pointer to malloc'ed memory. It is only infrequently accessed and never in a critical code path. A slight disadvantage is either a separate IOCTL to retrieve the description or a little hack to copy it into struct ifnet just when it is retrieved by userspace from the kernel. [Which reminds me that somewhen we need something more flexible than the current routing socket.] -- Andre From julian at elischer.org Sat Aug 15 17:39:14 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Aug 15 17:39:22 2009 Subject: [Take 2] Re: RFC: interface description In-Reply-To: <4A86C782.5030808@freebsd.org> References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> <4A8601CE.5030205@delphij.net> <4A86C782.5030808@freebsd.org> Message-ID: <4A86F2BE.4050203@elischer.org> Andre Oppermann wrote: > Xin LI wrote: >> Hi, guys, >> >> Here is a patch that implements the functionality in userland (as >> setifdescription/getifdescription functions in libutil); with this I >> think we can also provide an option that some kernel feature (like Qing >> Li said it might be useful for embedded systems, but of course the >> kernel feature would require more careful design) being used without >> modifying programs. This version uses if_dname plus if_dunit as >> distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store >> the information. > > I don't like this approach. Adding unconditional dependencies to libutil > and libbsdxml unnecessarily complicates and bloats up ifconfig, which is > a very central utility that resides on every rescue and minimal boot disk. > > Additionally the DB stored description can easily go out of sync when > interface disappear and reappear. On top of that it complicates porting > of routing daemons (Quagga suite, OpenBGPD/OSPFD). Having it only for > ifconfig but nowhere else is not entirely pointless but seriously reduces > its usefulness. > > IMHO interface description is a very useful feature and it should be stored > in the kernel attached to struct ifnet. However it probably should only be > a pointer to malloc'ed memory. It is only infrequently accessed and never > in a critical code path. A slight disadvantage is either a separate IOCTL > to retrieve the description or a little hack to copy it into struct ifnet > just when it is retrieved by userspace from the kernel. [Which reminds me > that somewhen we need something more flexible than the current routing > socket.] > From my perspective, putting it in a separate db outside the kernel kind of defeats the purpose. I thought the first patches had the right idea. though for me the current ability to rename an interface is good enough. I mean is you can cal your interface "Sydney0" or "Melbourne2" that is really enough.. From sthaug at nethelp.no Sat Aug 15 19:40:25 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Sat Aug 15 19:40:31 2009 Subject: [Take 2] Re: RFC: interface description In-Reply-To: <4A86F2BE.4050203@elischer.org> References: <4A8601CE.5030205@delphij.net> <4A86C782.5030808@freebsd.org> <4A86F2BE.4050203@elischer.org> Message-ID: <20090815.214022.41662662.sthaug@nethelp.no> > From my perspective, putting it in a separate db outside the kernel > kind of defeats the purpose. I thought the first patches had the > right idea. though for me the current ability to rename an interface > is good enough. I mean is you can cal your interface "Sydney0" or > "Melbourne2" that is really enough.. Having read the discussion, I agree that the description should be in the kernel. However, being a router geek the ability to rename an interface to "Sydney0" or "Melbourne2" is not at all enough. For the routers & switches I work with we really want a description of at least 50 characters - and it's important to be able to include space. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From randy at psg.com Sun Aug 16 01:29:10 2009 From: randy at psg.com (Randy Bush) Date: Sun Aug 16 02:03:53 2009 Subject: [Take 2] Re: RFC: interface description In-Reply-To: <20090815.214022.41662662.sthaug@nethelp.no> References: <4A8601CE.5030205@delphij.net> <4A86C782.5030808@freebsd.org> <4A86F2BE.4050203@elischer.org> <20090815.214022.41662662.sthaug@nethelp.no> Message-ID: >> From my perspective, putting it in a separate db outside the kernel >> kind of defeats the purpose. I thought the first patches had the >> right idea. though for me the current ability to rename an interface >> is good enough. I mean is you can cal your interface "Sydney0" or >> "Melbourne2" that is really enough.. > Having read the discussion, I agree that the description should be > in the kernel. However, being a router geek the ability to rename > an interface to "Sydney0" or "Melbourne2" is not at all enough. For > the routers & switches I work with we really want a description of > at least 50 characters - and it's important to be able to include > space. also a router geek. but for the sake of simplicity, i am quite willing to s/\ /_/ or whatever. randy From linimon at FreeBSD.org Sun Aug 16 16:02:27 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Aug 16 16:02:34 2009 Subject: bin/137841: [patch] wpa_supplicant(8) cannot verify SHA256 signed certificates Message-ID: <200908161602.n7GG2RWG052469@freefall.freebsd.org> Old Synopsis: wpa_supplicant cannot verify SHA256 signed certificates New Synopsis: [patch] wpa_supplicant(8) cannot verify SHA256 signed certificates Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 16 16:01:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137841 From bugmaster at FreeBSD.org Mon Aug 17 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:09:13 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200908171106.n7HB6xXn075880@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/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/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 bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/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 o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [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 [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal 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 bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] 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/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 323 problems total. From tuexen at freebsd.org Mon Aug 17 16:10:05 2009 From: tuexen at freebsd.org (Michael Tuexen) Date: Mon Aug 17 16:10:10 2009 Subject: kern/137795: [sctp] [panic] mtx_lock() of destroyed mutex Message-ID: <200908171610.n7HGA4l1014266@freefall.freebsd.org> The following reply was made to PR kern/137795; it has been noted by GNATS. From: Michael Tuexen To: bug-followup@FreeBSD.org, bruce@cran.org.uk Cc: Subject: Re: kern/137795: [sctp] [panic] mtx_lock() of destroyed mutex Date: Mon, 17 Aug 2009 18:07:45 +0200 Hi Bruce, is there running a (discard) server at 192.168.1.80, port 2345? Best regards Michael From remko at FreeBSD.org Mon Aug 17 19:26:48 2009 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Aug 17 19:27:00 2009 Subject: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 Message-ID: <200908171926.n7HJQmSI067262@freefall.freebsd.org> Synopsis: [rum] panic in rum(4) driver on 8.0-BETA2 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Aug 17 19:26:38 UTC 2009 Responsible-Changed-Why: Reassin to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=137776 From tuexen at fh-muenster.de Mon Aug 17 19:50:03 2009 From: tuexen at fh-muenster.de (Michael Tuexen) Date: Mon Aug 17 19:50:10 2009 Subject: kern/137795: [sctp] [panic] mtx_lock() of destroyed mutex Message-ID: <200908171950.n7HJo2EB083359@freefall.freebsd.org> The following reply was made to PR kern/137795; it has been noted by GNATS. From: Michael Tuexen To: bug-followup@FreeBSD.org, bruce@cran.org.uk Cc: Subject: Re: kern/137795: [sctp] [panic] mtx_lock() of destroyed mutex Date: Mon, 17 Aug 2009 21:40:33 +0200 Hi Bruce, OK, with a server available it runs fine, but I can reproduce a crash when there is no server available. I'll have a look into the problem. Thanks for reporting the issue. Best regards Michael From emaste at FreeBSD.org Mon Aug 17 20:17:23 2009 From: emaste at FreeBSD.org (emaste@FreeBSD.org) Date: Mon Aug 17 20:17:29 2009 Subject: kern/122794: [lagg] Kernel panic after brings lagg(8) up if NICs are not bringed up before Message-ID: <200908172017.n7HKHMoG005834@freefall.freebsd.org> Synopsis: [lagg] Kernel panic after brings lagg(8) up if NICs are not bringed up before State-Changed-From-To: patched->closed State-Changed-By: emaste State-Changed-When: Mon Aug 17 20:16:50 UTC 2009 State-Changed-Why: I see that thompsa has MFC'd this to 7 & 6. http://www.freebsd.org/cgi/query-pr.cgi?pr=122794 From emaste at freebsd.org Mon Aug 17 20:40:12 2009 From: emaste at freebsd.org (Ed Maste) Date: Mon Aug 17 20:40:19 2009 Subject: kern/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode Message-ID: <200908172040.n7HKeCO3027846@freefall.freebsd.org> The following reply was made to PR kern/122780; it has been noted by GNATS. From: Ed Maste To: bug-followup@FreeBSD.org, paul@gtcomm.net Cc: Subject: Re: kern/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode Date: Mon, 17 Aug 2009 16:14:13 -0400 Can you retest on recent 7.x or HEAD? I think there have been BPF changes to address this issue. -Ed From linimon at FreeBSD.org Mon Aug 17 22:28:33 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 17 22:28:39 2009 Subject: kern/137881: [netgraph] [panic] ng_pppoe fatal trap 12 Message-ID: <200908172228.n7HMSXHt010499@freefall.freebsd.org> Old Synopsis: [netgraph] ng_pppoe fatal trap 12 New Synopsis: [netgraph] [panic] ng_pppoe fatal trap 12 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 17 22:27:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137881 From manishv at lineratesystems.com Mon Aug 17 22:47:22 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Mon Aug 17 22:47:28 2009 Subject: Dropped vs. missed packets in the ixgbe driver Message-ID: <5bc218350908171524m5a46c3dbm3e6af625c51370d0@mail.gmail.com> I've been doing some performance testing on freebsd 7.2 and noticed that the ixgbe driver does not report missed packets as dropped when queried via netstat -id (the ixgbe driver in the 8.0 beta has a similar issue). A missed packet is a packet that was correctly received by the NIC but because it was out of descriptors and internal memory, the packet had to be dropped by the NIC itself -- a hardware register counts such events. Instead the driver only reports drops that are due to the driver itself, i.e., the NIC DMAed the packet to memory but the driver had to drop something because it was out of mbufs. Is the miss count reported elsewhere (besides via a kernel printf from the driver)? At the end of the email I give a stats dump from the driver and from netstat, note the number of packets dropped is 0 as reported by netstat but the Missed field in the dmesg output shows many missed packets. >From my perspective, it is disconcerting to see performance degradation on the link, along with TCP ack retransmits, packet reordering, etc. (on a point-to-point link with no switch in between) but then see no drops reported by netstat because the driver didn't drop the packet, the NIC did. The fix should be straight-forward and I'll gladly make a patch assuming that it is indeed a bug and not a conscious design choice. Here is the relevant netstat output Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop ix0 1500 00:30:48:94:60:ec 0 0 1 0 0 0 ix0 1500 192.168.105.0 192.168.105.2 0 - 0 - - - ix1 1500 00:30:48:94:60:ed 11M 0 6.1M 0 0 0 ix1 1500 192.168.5.0 192.168.5.2 10M - 6.1M - - - And here is the dmesg output after doing a sysctl dev.ix.1.stats=1 ix1: Std Mbuf Failed = 0 ix1: Missed Packets = 413872 ix1: Receive length errors = 0 ix1: Crc errors = 0 ix1: Driver dropped packets = 0 ix1: watchdog timeouts = 0 ix1: XON Rcvd = 616428212235 ix1: XON Xmtd = 0 ix1: XOFF Rcvd = 616428212235 ix1: XOFF Xmtd = 0 ix1: Total Packets Rcvd = 12424533 ix1: Good Packets Rcvd = 12010661 ix1: Good Packets Xmtd = 6419128 ix1: TSO Transmissions = 0 Manish -- Manish Vachharajani manishv@lineratesystems.com From glen.j.barber at gmail.com Tue Aug 18 02:51:20 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Tue Aug 18 02:51:26 2009 Subject: 8. Current and Intel 5100 AGN wifi In-Reply-To: <11167f520908142010g278e0cd7q3acaf989b75ac69a@mail.gmail.com> References: <20090815004549.GA70621@weongyo.local> <11167f520908142010g278e0cd7q3acaf989b75ac69a@mail.gmail.com> Message-ID: <4ad871310908171951n6295ef18x3ce2d790969ca162@mail.gmail.com> On Fri, Aug 14, 2009 at 11:10 PM, Sam Fourman Jr. wrote: > On Fri, Aug 14, 2009 at 7:45 PM, Weongyo Jeong wrote: >> On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: >>> folks, >>> >>> Can anyone please shet any lights on this. are iwn & iwnfw ?going to >>> support 5100 agn wifi? >>> I've updated mine to 8. Current with iwn & iwnfw and still not going >>> anywhere with the card. >> >> AFAIK no one working on it. >> >> regards, >> Weongyo Jeong > > I have a spare 5100 agn to donate if someone want to work on a driver > Hi, I don't have a spare card to donate unfortunately, but I'm willing (and hopefully able) to test patches on 8-STABLE. -- Glen Barber From dfilter at FreeBSD.ORG Tue Aug 18 20:00:14 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Aug 18 20:00:21 2009 Subject: kern/137795: commit references a PR Message-ID: <200908182000.n7IK04wi049425@freefall.freebsd.org> The following reply was made to PR kern/137795; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/137795: commit references a PR Date: Tue, 18 Aug 2009 19:59:03 +0000 (UTC) Author: tuexen Date: Tue Aug 18 19:58:49 2009 New Revision: 196364 URL: http://svn.freebsd.org/changeset/base/196364 Log: Fix a crash when using one-to-one stlye socket in non-blocking mode and there is no listening server. PR: 137795 Approved by: re, rrs (mentor) MFC after:immediately. Modified: head/sys/netinet/sctp_output.c Modified: head/sys/netinet/sctp_output.c ============================================================================== --- head/sys/netinet/sctp_output.c Tue Aug 18 16:23:09 2009 (r196363) +++ head/sys/netinet/sctp_output.c Tue Aug 18 19:58:49 2009 (r196364) @@ -12464,7 +12464,8 @@ sctp_lower_sosend(struct socket *so, error = ENOTCONN; goto out_unlocked; } - hold_tcblock = 0; + SCTP_TCB_LOCK(stcb); + hold_tcblock = 1; SCTP_INP_RUNLOCK(inp); if (addr) { /* Must locate the net structure if addr given */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Tue Aug 18 20:10:02 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Aug 18 20:12:55 2009 Subject: kern/137795: commit references a PR Message-ID: <200908182010.n7IKA2mf056358@freefall.freebsd.org> The following reply was made to PR kern/137795; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/137795: commit references a PR Date: Tue, 18 Aug 2009 20:06:16 +0000 (UTC) Author: tuexen Date: Tue Aug 18 20:06:00 2009 New Revision: 196365 URL: http://svn.freebsd.org/changeset/base/196365 Log: Fix a panic when using one-to-one style sockets in non-blocking mode and there is no listening server. PR: 137795 Approved by: re, rrs (mentor) Modified: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) stable/8/sys/netinet/sctp_output.c Modified: stable/8/sys/netinet/sctp_output.c ============================================================================== --- stable/8/sys/netinet/sctp_output.c Tue Aug 18 19:58:49 2009 (r196364) +++ stable/8/sys/netinet/sctp_output.c Tue Aug 18 20:06:00 2009 (r196365) @@ -12464,7 +12464,8 @@ sctp_lower_sosend(struct socket *so, error = ENOTCONN; goto out_unlocked; } - hold_tcblock = 0; + SCTP_TCB_LOCK(stcb); + hold_tcblock = 1; SCTP_INP_RUNLOCK(inp); if (addr) { /* Must locate the net structure if addr given */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From alireza.torabi at gmail.com Tue Aug 18 20:54:37 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Tue Aug 18 20:54:42 2009 Subject: 8. Current and Intel 5100 AGN wifi In-Reply-To: <4ad871310908171951n6295ef18x3ce2d790969ca162@mail.gmail.com> References: <20090815004549.GA70621@weongyo.local> <11167f520908142010g278e0cd7q3acaf989b75ac69a@mail.gmail.com> <4ad871310908171951n6295ef18x3ce2d790969ca162@mail.gmail.com> Message-ID: So will I On 18/08/2009, Glen Barber wrote: > On Fri, Aug 14, 2009 at 11:10 PM, Sam Fourman Jr. wrote: >> On Fri, Aug 14, 2009 at 7:45 PM, Weongyo Jeong >> wrote: >>> On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: >>>> folks, >>>> >>>> Can anyone please shet any lights on this. are iwn & iwnfw ?going to >>>> support 5100 agn wifi? >>>> I've updated mine to 8. Current with iwn & iwnfw and still not going >>>> anywhere with the card. >>> >>> AFAIK no one working on it. >>> >>> regards, >>> Weongyo Jeong >> >> I have a spare 5100 agn to donate if someone want to work on a driver >> > > Hi, > > I don't have a spare card to donate unfortunately, but I'm willing > (and hopefully able) to test patches on 8-STABLE. > > > -- > Glen Barber > _______________________________________________ > 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" > -- Sent from my mobile device From delphij at delphij.net Tue Aug 18 21:05:25 2009 From: delphij at delphij.net (Xin LI) Date: Tue Aug 18 21:05:33 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <2a41acea0908060905n69edf1dfkbf993d9f8a4edf37@mail.gmail.com> References: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> <692150.91493.qm@web63906.mail.re1.yahoo.com> <2a41acea0908060905n69edf1dfkbf993d9f8a4edf37@mail.gmail.com> Message-ID: <4A8B1729.8070503@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Jack, I have looked into the code history and found that sys/dev/em/if_em.c,v 1.119 has introduced the arp_ifinit() call in order to fix the problem that if_em won't send ARP when IP address is changed. I think we can further improve it as attached, say, only do it when IFF_NOARP is not set. This should have no effect for usual configuration but fix the problem when NOARP is the desired behavior. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqLFykACgkQi+vbBBjt66CMFQCeOkESwsgDAbqe5PCtiMulaU1E lIAAoIm0LDJ6qHuR8jyo7dXFi/9iYA22 =9E54 -----END PGP SIGNATURE----- -------------- next part -------------- Index: if_igb.c =================================================================== --- if_igb.c (revision 196363) +++ if_igb.c (working copy) @@ -952,7 +952,8 @@ igb_ioctl(struct ifnet *ifp, u_long command, caddr igb_init_locked(adapter); IGB_CORE_UNLOCK(adapter); } - arp_ifinit(ifp, ifa); + if (!(ifp->if_flags & IFF_NOARP)) + arp_ifinit(ifp, ifa); } else #endif error = ether_ioctl(ifp, command, data); Index: if_em.c =================================================================== --- if_em.c (revision 196363) +++ if_em.c (working copy) @@ -1204,7 +1204,8 @@ em_ioctl(struct ifnet *ifp, u_long command, caddr_ em_init_locked(adapter); EM_CORE_UNLOCK(adapter); } - arp_ifinit(ifp, ifa); + if (!(ifp->if_flags & IFF_NOARP)) + arp_ifinit(ifp, ifa); } else #endif error = ether_ioctl(ifp, command, data); From jfvogel at gmail.com Tue Aug 18 21:34:12 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Aug 18 21:34:19 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <4A8B1729.8070503@delphij.net> References: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> <692150.91493.qm@web63906.mail.re1.yahoo.com> <2a41acea0908060905n69edf1dfkbf993d9f8a4edf37@mail.gmail.com> <4A8B1729.8070503@delphij.net> Message-ID: <2a41acea0908181434l7a8119ffxbe03a5d312947757@mail.gmail.com> Yes, this would work, although talking to Sam about this, he said the whole reason for this hack in the driver was some other brokenness in the if code, and he said he was going to fix that, just not before 8 RELEASE. So, I would rather fix it upstream as it where, and then take this hack out of the code altogether instead of refining the hack :) Just my .02 Jack On Tue, Aug 18, 2009 at 2:03 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Jack, > > I have looked into the code history and found that sys/dev/em/if_em.c,v > 1.119 has introduced the arp_ifinit() call in order to fix the problem > that if_em won't send ARP when IP address is changed. > > I think we can further improve it as attached, say, only do it when > IFF_NOARP is not set. This should have no effect for usual > configuration but fix the problem when NOARP is the desired behavior. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (FreeBSD) > > iEYEARECAAYFAkqLFykACgkQi+vbBBjt66CMFQCeOkESwsgDAbqe5PCtiMulaU1E > lIAAoIm0LDJ6qHuR8jyo7dXFi/9iYA22 > =9E54 > -----END PGP SIGNATURE----- > > Index: if_igb.c > =================================================================== > --- if_igb.c (revision 196363) > +++ if_igb.c (working copy) > @@ -952,7 +952,8 @@ igb_ioctl(struct ifnet *ifp, u_long command, caddr > igb_init_locked(adapter); > IGB_CORE_UNLOCK(adapter); > } > - arp_ifinit(ifp, ifa); > + if (!(ifp->if_flags & IFF_NOARP)) > + arp_ifinit(ifp, ifa); > } else > #endif > error = ether_ioctl(ifp, command, data); > Index: if_em.c > =================================================================== > --- if_em.c (revision 196363) > +++ if_em.c (working copy) > @@ -1204,7 +1204,8 @@ em_ioctl(struct ifnet *ifp, u_long command, caddr_ > em_init_locked(adapter); > EM_CORE_UNLOCK(adapter); > } > - arp_ifinit(ifp, ifa); > + if (!(ifp->if_flags & IFF_NOARP)) > + arp_ifinit(ifp, ifa); > } else > #endif > error = ether_ioctl(ifp, command, data); > > From pyunyh at gmail.com Tue Aug 18 21:49:58 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Aug 18 21:50:04 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <4A8B1729.8070503@delphij.net> References: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> <692150.91493.qm@web63906.mail.re1.yahoo.com> <2a41acea0908060905n69edf1dfkbf993d9f8a4edf37@mail.gmail.com> <4A8B1729.8070503@delphij.net> Message-ID: <20090818214914.GC15025@michelle.cdnetworks.com> On Tue, Aug 18, 2009 at 02:03:37PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Jack, > > I have looked into the code history and found that sys/dev/em/if_em.c,v > 1.119 has introduced the arp_ifinit() call in order to fix the problem > that if_em won't send ARP when IP address is changed. > > I think we can further improve it as attached, say, only do it when > IFF_NOARP is not set. This should have no effect for usual > configuration but fix the problem when NOARP is the desired behavior. > That change was introduced by me. I guess the root cause of the problem was long initialization time of hardware which in turn resulted in unbearable boot time when multiple-alias addresses are assigned to em(4). I don't remember details,though. Since we're in the release cycle, the change you suggested would be quick fix for 8.0. I think em(4)/igb(4) should remove SIOCSIFADDR handling in driver which is layering violation. From jfvogel at gmail.com Tue Aug 18 22:03:27 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Aug 18 22:03:35 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <20090818214914.GC15025@michelle.cdnetworks.com> References: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com> <692150.91493.qm@web63906.mail.re1.yahoo.com> <2a41acea0908060905n69edf1dfkbf993d9f8a4edf37@mail.gmail.com> <4A8B1729.8070503@delphij.net> <20090818214914.GC15025@michelle.cdnetworks.com> Message-ID: <2a41acea0908181503jbb5b335q870e0d2eecbfce05@mail.gmail.com> Yes, I knew it was all your fault :) I was asking about this last week on IRC, without this code in place it will always end up doing a re-init, it should not but if it didn't then another driver broke according to Sam, think it was re. Should have the root cause fixed, but I'm ok with this temporary enhanced hack for now. Jack On Tue, Aug 18, 2009 at 2:49 PM, Pyun YongHyeon wrote: > On Tue, Aug 18, 2009 at 02:03:37PM -0700, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, Jack, > > > > I have looked into the code history and found that sys/dev/em/if_em.c,v > > 1.119 has introduced the arp_ifinit() call in order to fix the problem > > that if_em won't send ARP when IP address is changed. > > > > I think we can further improve it as attached, say, only do it when > > IFF_NOARP is not set. This should have no effect for usual > > configuration but fix the problem when NOARP is the desired behavior. > > > > That change was introduced by me. I guess the root cause of the > problem was long initialization time of hardware which in turn > resulted in unbearable boot time when multiple-alias addresses are > assigned to em(4). I don't remember details,though. > > Since we're in the release cycle, the change you suggested would be > quick fix for 8.0. I think em(4)/igb(4) should remove SIOCSIFADDR > handling in driver which is layering violation. > From barney_cordoba at yahoo.com Tue Aug 18 22:16:07 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Tue Aug 18 22:16:14 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908171524m5a46c3dbm3e6af625c51370d0@mail.gmail.com> Message-ID: <373149.52091.qm@web63907.mail.re1.yahoo.com> --- On Mon, 8/17/09, Manish Vachharajani wrote: > From: Manish Vachharajani > Subject: Dropped vs. missed packets in the ixgbe driver > To: freebsd-net@freebsd.org > Date: Monday, August 17, 2009, 6:24 PM > I've been doing some performance > testing on freebsd 7.2 and noticed > that the ixgbe driver does not report missed packets as > dropped when > queried via netstat -id (the ixgbe driver in the 8.0? > beta has a > similar issue).? A missed packet is a packet that was > correctly > received by the NIC but because it was out of descriptors > and internal > memory, the packet had to be dropped by the NIC itself -- a > hardware > register counts such events.? Instead the driver only > reports drops > that are due to the driver itself, i.e., the NIC DMAed the > packet to > memory but the driver had to drop something because it was > out of > mbufs.? Is the miss count reported elsewhere (besides > via a kernel > printf from the driver)?? At the end of the email I > give a stats dump > from the driver and from netstat, note the number of > packets dropped > is 0 as reported by netstat but the Missed field in the > dmesg output > shows many missed packets. > > >From my perspective, it is disconcerting to see > performance > degradation on the link, along with TCP ack retransmits, > packet > reordering, etc. (on a point-to-point link with no switch > in between) > but then see no drops reported by netstat because the > driver didn't > drop the packet, the NIC did.? The fix should be > straight-forward and > I'll gladly make a patch assuming that it is indeed a bug > and not a > conscious design choice. > > Here is the relevant netstat output > > Name? ? Mtu Network? ? > ???Address? ? ? ? ? > ? ? Ipkts Ierrs? ? Opkts > Oerrs? Coll Drop > ix0? ? 1500 ? ? ? > 00:30:48:94:60:ec? ? ? ? 0? > ???0? ? ? ? 1 > 0? ???0? ? 0 > ix0? ? 1500 192.168.105.0 192.168.105.2? > ? ? ? ? ? 0? > ???-? ? ? ? 0 > -? ???-? ? - > ix1? ? 1500 ? ? ? > 00:30:48:94:60:ed? ? ? 11M? > ???0? ???6.1M > 0? ???0? ? 0 > ix1? ? 1500 > 192.168.5.0???192.168.5.2? ? ? > ? ? ? 10M? ???-? > ???6.1M > -? ???-? ? - > > And here is the dmesg output after doing a sysctl > dev.ix.1.stats=1 > > ix1: Std Mbuf Failed = 0 > ix1: Missed Packets = 413872 > ix1: Receive length errors = 0 > ix1: Crc errors = 0 > ix1: Driver dropped packets = 0 > ix1: watchdog timeouts = 0 > ix1: XON Rcvd = 616428212235 > ix1: XON Xmtd = 0 > ix1: XOFF Rcvd = 616428212235 > ix1: XOFF Xmtd = 0 > ix1: Total Packets Rcvd = 12424533 > ix1: Good Packets Rcvd = 12010661 > ix1: Good Packets Xmtd = 6419128 > ix1: TSO Transmissions = 0 > > Manish the debug sysctl show more interesting info. Don't get too excited about doing performance testing with that driver. Its not designed to be any higher in performance than any of the other intel drivers. Barney From barney_cordoba at yahoo.com Tue Aug 18 22:32:29 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Tue Aug 18 22:32:40 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <20090818214914.GC15025@michelle.cdnetworks.com> Message-ID: <527700.21341.qm@web63902.mail.re1.yahoo.com> --- On Tue, 8/18/09, Pyun YongHyeon wrote: > From: Pyun YongHyeon > Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] > To: "Xin LI" > Cc: "Barney Cordoba" , "David Christensen" , "d@delphij..net" , "freebsd-net@freebsd.org" , "Jack Vogel" , "Jack F Vogel" , yongari@freebsd.org, "Julian Elischer" > Date: Tuesday, August 18, 2009, 5:49 PM > On Tue, Aug 18, 2009 at 02:03:37PM > -0700, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, Jack, > > > > I have looked into the code history and found that > sys/dev/em/if_em.c,v > > 1.119 has introduced the arp_ifinit() call in order to > fix the problem > > that if_em won't send ARP when IP address is changed. > > > > I think we can further improve it as attached, say, > only do it when > > IFF_NOARP is not set.? This should have no effect > for usual > > configuration but fix the problem when NOARP is the > desired behavior. > > > > That change was introduced by me. I guess the root cause of > the > problem was long initialization time of hardware which in > turn > resulted in unbearable boot time when multiple-alias > addresses are > assigned to em(4). I don't remember details,though. > > Since we're in the release cycle, the change you suggested > would be > quick fix for 8.0. I think em(4)/igb(4) should remove > SIOCSIFADDR > handling in driver which is layering violation. There are 2 kinds of programmers; those who do things "correctly', and those that do things that work. 99.99999% of the people will be using ARPs, so don't be silly and break the driver to solve a case that almost no-one cares about please. Barney From manishv at lineratesystems.com Tue Aug 18 22:35:08 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Tue Aug 18 22:35:15 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <373149.52091.qm@web63907.mail.re1.yahoo.com> References: <5bc218350908171524m5a46c3dbm3e6af625c51370d0@mail.gmail.com> <373149.52091.qm@web63907.mail.re1.yahoo.com> Message-ID: <5bc218350908181535o7c5275dfn2f6647454cfac804@mail.gmail.com> Indeed the debugging info is also interesting. However, I'd like to get some data from netstat when the driver drops frames. When looking at the bge driver source, it appears that all input drops at the NIC are reported as input errors. It appears that the intel drivers (e1000, ixgb, and ixgbe) don't report that number outside of the debug and stats printfs at all, and this seems broken. What I want to know is if I have just missed where these are reported. So, in a nutshell, the question is: should these drivers be reporting miss events as input errors in the ifnet struct as the bge driver does, or as drops in the ifnet struct, was there some conscious decision not to report miss events anywhere outside the debug and stats info, or am I just being silly and not seeing where the numbers are reported? Also, don't worry on the performance front, we are also looking at the driver in FreeBSD 8.0 :) which supports RSS to help performance scaling, though we have some interesting data there that I'll post about once I confirm that the numbers are indeed correct and not a tuning or setup problem. Manish > --- On Mon, 8/17/09, Manish Vachharajani wrote: > >> From: Manish Vachharajani >> Subject: Dropped vs. missed packets in the ixgbe driver >> To: freebsd-net@freebsd.org >> Date: Monday, August 17, 2009, 6:24 PM >> I've been doing some performance >> testing on freebsd 7.2 and noticed >> that the ixgbe driver does not report missed packets as >> dropped when >> queried via netstat -id (the ixgbe driver in the 8.0 >> beta has a >> similar issue).? A missed packet is a packet that was >> correctly >> received by the NIC but because it was out of descriptors >> and internal >> memory, the packet had to be dropped by the NIC itself -- a >> hardware >> register counts such events.? Instead the driver only >> reports drops >> that are due to the driver itself, i.e., the NIC DMAed the >> packet to >> memory but the driver had to drop something because it was >> out of >> mbufs.? Is the miss count reported elsewhere (besides >> via a kernel >> printf from the driver)?? At the end of the email I >> give a stats dump >> from the driver and from netstat, note the number of >> packets dropped >> is 0 as reported by netstat but the Missed field in the >> dmesg output >> shows many missed packets. >> >> >From my perspective, it is disconcerting to see >> performance >> degradation on the link, along with TCP ack retransmits, >> packet >> reordering, etc. (on a point-to-point link with no switch >> in between) >> but then see no drops reported by netstat because the >> driver didn't >> drop the packet, the NIC did.? The fix should be >> straight-forward and >> I'll gladly make a patch assuming that it is indeed a bug >> and not a >> conscious design choice. >> >> Here is the relevant netstat output >> >> Name? ? Mtu Network >> ???Address >> ? ? Ipkts Ierrs? ? Opkts >> Oerrs? Coll Drop >> ix0? ? 1500 >> 00:30:48:94:60:ec? ? ? ? 0 >> ???0? ? ? ? 1 >> ?0? ???0? ? 0 >> ix0? ? 1500 192.168.105.0 192.168.105.2 >> ? ? ? ? ? 0 >> ???-? ? ? ? 0 >> ?-? ???-? ? - >> ix1? ? 1500 >> 00:30:48:94:60:ed? ? ? 11M >> ???0? ???6.1M >> ?0? ???0? ? 0 >> ix1? ? 1500 >> 192.168.5.0???192.168.5.2 >> ? ? ? 10M? ???- >> ???6.1M >> ?-? ???-? ? - >> >> And here is the dmesg output after doing a sysctl >> dev.ix.1.stats=1 >> >> ix1: Std Mbuf Failed = 0 >> ix1: Missed Packets = 413872 >> ix1: Receive length errors = 0 >> ix1: Crc errors = 0 >> ix1: Driver dropped packets = 0 >> ix1: watchdog timeouts = 0 >> ix1: XON Rcvd = 616428212235 >> ix1: XON Xmtd = 0 >> ix1: XOFF Rcvd = 616428212235 >> ix1: XOFF Xmtd = 0 >> ix1: Total Packets Rcvd = 12424533 >> ix1: Good Packets Rcvd = 12010661 >> ix1: Good Packets Xmtd = 6419128 >> ix1: TSO Transmissions = 0 >> >> Manish > > the debug sysctl show more interesting info. Don't get too excited > about doing performance testing with that driver. Its not designed > to be any higher in performance than any of the other intel drivers. > > Barney > > > > -- Manish Vachharajani Founder LineRate Systems manishv@lineratesystems.com (609)635-9531 M From delphij at delphij.net Tue Aug 18 22:51:20 2009 From: delphij at delphij.net (Xin LI) Date: Tue Aug 18 22:51:27 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <527700.21341.qm@web63902.mail.re1.yahoo.com> References: <527700.21341.qm@web63902.mail.re1.yahoo.com> Message-ID: <4A8B3011.6070104@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barney Cordoba wrote: > > --- On Tue, 8/18/09, Pyun YongHyeon wrote: > >> From: Pyun YongHyeon >> Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] >> To: "Xin LI" >> Cc: "Barney Cordoba" , "David Christensen" , "d@delphij..net" , "freebsd-net@freebsd.org" , "Jack Vogel" , "Jack F Vogel" , yongari@freebsd.org, "Julian Elischer" >> Date: Tuesday, August 18, 2009, 5:49 PM >> On Tue, Aug 18, 2009 at 02:03:37PM >> -0700, Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi, Jack, >>> >>> I have looked into the code history and found that >> sys/dev/em/if_em.c,v >>> 1.119 has introduced the arp_ifinit() call in order to >> fix the problem >>> that if_em won't send ARP when IP address is changed. >>> >>> I think we can further improve it as attached, say, >> only do it when >>> IFF_NOARP is not set. This should have no effect >> for usual >>> configuration but fix the problem when NOARP is the >> desired behavior. >> That change was introduced by me. I guess the root cause of >> the >> problem was long initialization time of hardware which in >> turn >> resulted in unbearable boot time when multiple-alias >> addresses are >> assigned to em(4). I don't remember details,though. >> >> Since we're in the release cycle, the change you suggested >> would be >> quick fix for 8.0. I think em(4)/igb(4) should remove >> SIOCSIFADDR >> handling in driver which is layering violation. > > There are 2 kinds of programmers; those who do things "correctly', > and those that do things that work. > > 99.99999% of the people will be using ARPs, so don't be silly and > break the driver to solve a case that almost no-one cares about please. I see no reason how you have reached the "99.99999%" conclusion. My employer for instance, has several millions of dollars worth of hardware purchase every year, and, we do care about DSR, or NOARP being working or not. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqLMBEACgkQi+vbBBjt66DtJACcCuMIEljhYtKT/B9xP18HYzLD gMwAmwQpJiVSzFJzgXoNggWdRF/kj2Qs =ROT8 -----END PGP SIGNATURE----- From julian at elischer.org Tue Aug 18 22:55:46 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 18 22:55:53 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <4A8B3011.6070104@delphij.net> References: <527700.21341.qm@web63902.mail.re1.yahoo.com> <4A8B3011.6070104@delphij.net> Message-ID: <4A8B316F.3030408@elischer.org> Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Barney Cordoba wrote: >> --- On Tue, 8/18/09, Pyun YongHyeon wrote: >> >>> From: Pyun YongHyeon >>> Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] >>> To: "Xin LI" >>> Cc: "Barney Cordoba" , "David Christensen" , "d@delphij..net" , "freebsd-net@freebsd.org" , "Jack Vogel" , "Jack F Vogel" , yongari@freebsd.org, "Julian Elischer" >>> Date: Tuesday, August 18, 2009, 5:49 PM >>> On Tue, Aug 18, 2009 at 02:03:37PM >>> -0700, Xin LI wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi, Jack, >>>> >>>> I have looked into the code history and found that >>> sys/dev/em/if_em.c,v >>>> 1.119 has introduced the arp_ifinit() call in order to >>> fix the problem >>>> that if_em won't send ARP when IP address is changed. >>>> >>>> I think we can further improve it as attached, say, >>> only do it when >>>> IFF_NOARP is not set. This should have no effect >>> for usual >>>> configuration but fix the problem when NOARP is the >>> desired behavior. >>> That change was introduced by me. I guess the root cause of >>> the >>> problem was long initialization time of hardware which in >>> turn >>> resulted in unbearable boot time when multiple-alias >>> addresses are >>> assigned to em(4). I don't remember details,though. >>> >>> Since we're in the release cycle, the change you suggested >>> would be >>> quick fix for 8.0. I think em(4)/igb(4) should remove >>> SIOCSIFADDR >>> handling in driver which is layering violation. >> There are 2 kinds of programmers; those who do things "correctly', >> and those that do things that work. >> >> 99.99999% of the people will be using ARPs, so don't be silly and >> break the driver to solve a case that almost no-one cares about please. > Cisco.Ironport runs 50% (2 out of 4) of their em interfaces in noarp mode. please keep noarp working! > I see no reason how you have reached the "99.99999%" conclusion. My > employer for instance, has several millions of dollars worth of hardware > purchase every year, and, we do care about DSR, or NOARP being working > or not. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (FreeBSD) > > iEYEARECAAYFAkqLMBEACgkQi+vbBBjt66DtJACcCuMIEljhYtKT/B9xP18HYzLD > gMwAmwQpJiVSzFJzgXoNggWdRF/kj2Qs > =ROT8 > -----END PGP SIGNATURE----- > _______________________________________________ > 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 sfourman at gmail.com Wed Aug 19 02:55:24 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Aug 19 02:56:28 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com> Message-ID: <11167f520908181955x3cc90a26k3ca37fd45cfaabf3@mail.gmail.com> On Mon, Jul 13, 2009 at 12:25 PM, Mark Atkinson wrote: > Jack Vogel wrote: >> In case you hadn't seen it, the code that fixes this is now checked into >> the tip, so the latest em driver should work for you. > > I upgraded the machine in question this morning and it appears to be > working, thanks! Jack Would you be able to commit this patch to em(4) I have several machines that do not work on FreeBSD 8 BETA2 With the 82543 em(4) based card. I copied the same approach you took on e1000_82542.c Thank you Sam Fourman Jr. pciconf -v -l |grep -A4 -e "^em" em0@pci0:14:13:0: class=0x020000 card=0x10038086 chip=0x10018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC Gigabit Ethernet Adapter (Fiber)' class = network subclass = ethernet I tested this patch and it works on today's source tree **** e1000_82543.c Wed Nov 26 17:57:23 2008 --- /root/e1000_82543.c Tue Aug 18 21:23:00 2009 *************** *** 75,80 **** --- 75,81 ---- u16 count); static bool e1000_tbi_compatibility_enabled_82543(struct e1000_hw *hw); static void e1000_set_tbi_sbp_82543(struct e1000_hw *hw, bool state); + static s32 e1000_read_mac_addr_82543(struct e1000_hw *hw); /** * e1000_init_phy_params_82543 - Init PHY func ptrs. *************** *** 246,251 **** --- 247,254 ---- mac->ops.clear_vfta = e1000_clear_vfta_generic; /* setting MTA */ mac->ops.mta_set = e1000_mta_set_82543; + /* read mac address */ + mac->ops.read_mac_addr = e1000_read_mac_addr_82543; /* turn on/off LED */ mac->ops.led_on = e1000_led_on_82543; mac->ops.led_off = e1000_led_off_82543; *************** *** 1600,1602 **** --- 1603,1638 ---- E1000_READ_REG(hw, E1000_TSCTC); E1000_READ_REG(hw, E1000_TSCTFC); } + + /** + * e1000_read_mac_addr_82543 - Read device MAC address + * @hw: pointer to the HW structure + * Same approach was taken for the 82542 + * + * Reads the device MAC address from the EEPROM and stores the value. + **/ + static s32 e1000_read_mac_addr_82543(struct e1000_hw *hw) + { + s32 ret_val = E1000_SUCCESS; + u16 offset, nvm_data, i; + + DEBUGFUNC("e1000_read_mac_addr"); + + for (i = 0; i < ETH_ADDR_LEN; i += 2) { From jfvogel at gmail.com Wed Aug 19 06:06:41 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 19 06:06:47 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <11167f520908181955x3cc90a26k3ca37fd45cfaabf3@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com> <11167f520908181955x3cc90a26k3ca37fd45cfaabf3@mail.gmail.com> Message-ID: <2a41acea0908182306h740194bcw4de78b6093998e88@mail.gmail.com> Hmmm, that's odd, I had the validation group do a thorough test of older adapters, and that one did not seem to have a problem, let me see if we can repro the issue tomorrow, but, in principle I have no problem doing this. Jack On Tue, Aug 18, 2009 at 7:55 PM, Sam Fourman Jr. wrote: > On Mon, Jul 13, 2009 at 12:25 PM, Mark Atkinson wrote: > > Jack Vogel wrote: > >> In case you hadn't seen it, the code that fixes this is now checked into > >> the tip, so the latest em driver should work for you. > > > > I upgraded the machine in question this morning and it appears to be > > working, thanks! > > > Jack > > Would you be able to commit this patch to em(4) I have several > machines that do not work on FreeBSD 8 BETA2 > With the 82543 em(4) based card. I copied the same approach you took > on e1000_82542.c > > Thank you > > Sam Fourman Jr. > > > pciconf -v -l |grep -A4 -e "^em" > > em0@pci0:14:13:0: class=0x020000 card=0x10038086 chip=0x10018086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82543GC Gigabit Ethernet Adapter (Fiber)' > class = network > subclass = ethernet > > > > I tested this patch and it works on today's source tree > > > **** e1000_82543.c Wed Nov 26 17:57:23 2008 > --- /root/e1000_82543.c Tue Aug 18 21:23:00 2009 > *************** > *** 75,80 **** > --- 75,81 ---- > u16 count); > static bool e1000_tbi_compatibility_enabled_82543(struct e1000_hw *hw); > static void e1000_set_tbi_sbp_82543(struct e1000_hw *hw, bool state); > + static s32 e1000_read_mac_addr_82543(struct e1000_hw *hw); > > /** > * e1000_init_phy_params_82543 - Init PHY func ptrs. > *************** > *** 246,251 **** > --- 247,254 ---- > mac->ops.clear_vfta = e1000_clear_vfta_generic; > /* setting MTA */ > mac->ops.mta_set = e1000_mta_set_82543; > + /* read mac address */ > + mac->ops.read_mac_addr = e1000_read_mac_addr_82543; > /* turn on/off LED */ > mac->ops.led_on = e1000_led_on_82543; > mac->ops.led_off = e1000_led_off_82543; > *************** > *** 1600,1602 **** > --- 1603,1638 ---- > E1000_READ_REG(hw, E1000_TSCTC); > E1000_READ_REG(hw, E1000_TSCTFC); > } > + > + /** > + * e1000_read_mac_addr_82543 - Read device MAC address > + * @hw: pointer to the HW structure > + * Same approach was taken for the 82542 > + * > + * Reads the device MAC address from the EEPROM and stores the value. > + **/ > + static s32 e1000_read_mac_addr_82543(struct e1000_hw *hw) > + { > + s32 ret_val = E1000_SUCCESS; > + u16 offset, nvm_data, i; > + > + DEBUGFUNC("e1000_read_mac_addr"); > + > + for (i = 0; i < ETH_ADDR_LEN; i += 2) { > _______________________________________________ > 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 sfourman at gmail.com Wed Aug 19 06:58:04 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Aug 19 06:58:10 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <2a41acea0908182306h740194bcw4de78b6093998e88@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com> <11167f520908181955x3cc90a26k3ca37fd45cfaabf3@mail.gmail.com> <2a41acea0908182306h740194bcw4de78b6093998e88@mail.gmail.com> Message-ID: <11167f520908182358hc7a176as962788b505b87148@mail.gmail.com> On Wed, Aug 19, 2009 at 1:06 AM, Jack Vogel wrote: > Hmmm, that's odd, I had the validation group do a thorough test > of older adapters, and that one did not seem to have a problem, > let me see if we can repro the issue tomorrow, but, in principle I > have no problem doing this. > > Jack I can provide root ssh access to these with a serial console and public IP's if you need I have over 100 of these (old dell P3 2450's with whatever em(4) fibre nic dell shipped) sitting on the shelf collecting dust. Just send me a heads up and I will have someone set one up for you right away. Sam Fourman Jr. Fourman Networks From brde at optusnet.com.au Wed Aug 19 09:24:53 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Aug 19 09:25:00 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908181535o7c5275dfn2f6647454cfac804@mail.gmail.com> References: <5bc218350908171524m5a46c3dbm3e6af625c51370d0@mail.gmail.com> <373149.52091.qm@web63907.mail.re1.yahoo.com> <5bc218350908181535o7c5275dfn2f6647454cfac804@mail.gmail.com> Message-ID: <20090819183756.Y35058@delplex.bde.org> On Tue, 18 Aug 2009, Manish Vachharajani wrote: > So, in a nutshell, the question is: should these drivers be reporting > miss events as input errors in the ifnet struct as the bge driver > does, or as drops in the ifnet struct, was there some conscious > decision not to report miss events anywhere outside the debug and > stats info, or am I just being silly and not seeing where the numbers > are reported? Certainly they should be no worse than bge in this area. Even bge has problems for the 5705_PLUS versions. PLUS really means MINUS; 5705- hardware is dumbed down so the IFIN_DROPS register is almost unusable, but since the hardware is so bad drops are more likely than with better hardware. The unusablility involves the register being only 8 (?) bits wide and being reset on every read, so you have to read it often to ensure that it doesn't wrap, but reading it (or any PCI register) is very inefficient so the the read that is done often enough to work (in bge_rxeof()) is only done if the "notyet" non-option is configured. Resetting on every read of this and most or all other statistic registers on 5705- hardware also completely breaks most or all bge statistics in the bge statistics sysctl, due to the way sysctl(3) is implemented: sysctl(3) always calls the sysctl syscall twice and uses the results of the second call; both calls do a read at the lowest level, so with registers that are reset on every read, the first call resets the registers and the second call usually reads zero. No history is kept in the sysctl, so the sysctl also clobbers the statistics that are maintained at the non-sysctl level (only collisions and ifin drops for 5705-). The non-sysctl level understands the reset and does keep history, but this is defeated if the sysctl is used. There may also still be a generic problem with intrq drops. The default ip intrq length (sysctl net.inet.ip.intr_queue_maxlen) was too small by default (32 IIRC). Now it is larger by default (256), but 256 is still small if you have multiple NICs with rx ring sizes of hundreds or thousands. Direct dispatch reduces this problem. Further, if an intrq drop actually occurs, then it is only reported in generic ip statistics (net.inet.ip.intr_queue_drops); there is no sign of it in ierrors and no way to determine which interface it happened on. I use 1024 to ensure no drops with a single bge NIC. There is still a related design problem for intrq drops: packets that will be dropped should not even be passed to upper layers, to avoid unnecessary extra load on already-overloaded systems. There is related inefficiency of IFF_MONITOR mode: checking for this should be the very first thing in ether_input(), or at least before asking for cache misses by looking at packet headers, but the check is after mounds of code and at least 1 likely cache miss (for initializing etype unecessarily early). Intrq drops would be efficient if they occurred near the start of ether_input() too, but they occur up much further up the stack than the check for monitor mode. Bruce From alexpalias-bsdnet at yahoo.com Wed Aug 19 12:52:27 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Wed Aug 19 12:52:34 2009 Subject: em driver input errors In-Reply-To: <001401ca1f4d$e96a2170$1e010a0a@in72.ru> Message-ID: <24727.68667.qm@web56404.mail.re3.yahoo.com> Greetings. --- On Mon, 8/17/09, ??????? ???????? wrote: > From: ??????? ???????? > Subject: RE: em driver input errors > To: alexpalias-bsdnet@yahoo.com > Cc: freebsd-net@freebsd.org > Date: Monday, August 17, 2009, 6:17 PM > > > >/boot/loader.conf: > >hw.em.rxd=4096 > >hw.em.txd=4096 > why you are using this > values? try default (without > this lines in loader.conf) As said in my original email, I was getting way more errors with the defaults. ? > > Witout the above we > were seeing way more > errors, now they are reduced, but still come in bursts of > over 1000 errors on > em0. > >Still seeing errros, > after some searching the > mailing lists we also added: > ># the four lines below > are repeated for em1, > em2, > em3 > >dev.em.0.rx_int_delay=0 > >dev.em.0.rx_abs_int_delay=0 > >dev.em.0.tx_int_delay=0 > >dev.em.0.tx_abs_int_delay=0 > try to increase > rx_int_delay to 600 and > rx_abs_int_delay to 1000, tx_*_delay without changes -> > by default > (100?) Thanks for the suggestion. From a "clean" box: dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 I reset all the values (errors still appearing), then tried your suggestion (rx_int_delay=600, rx_abs_int_delay=1000). This has reduced the number of interrupts for em0 (from about 7200/sec to around 6500/sec). After some time, I started getting errors again. But that has made me try this also: dev.em.0.tx_int_delay=600 dev.em.0.tx_abs_int_delay=1000 Meaning using your suggested values for tx too. Now em0 is seeing about 1800 interrupts/second, which is way better, but after some time I saw errors again... From the output of "netstat -nI em0 -w 5": input (em0) output packets errs bytes packets errs bytes colls 87267 0 50372599 106931 0 81598993 0 86496 0 50990332 105467 0 80064657 0 81726 3056 49876613 99080 0 73273640 0 90425 0 59172531 105299 0 77110096 0 120292 0 70369292 109597 0 78626248 0 ... a few minutes pass with zero errors ... 89646 0 56951878 111240 0 86493393 0 86031 0 53549721 108695 0 83592747 0 77760 3054 48505562 96912 0 73185576 0 87508 0 56116394 106094 0 79130608 0 89031 0 56490982 103039 0 77398567 0 What's interesting is that I'm seeing errors in a 80k packets/5 sec (so around 16k packets/s) zone, but no errors at 120k packets/5sec (24kpps). Currently, I've set the delay to 600 and abs_delay to 1000 on all interfaces (em0, em1, em2, em3), thus reducing the number of interrupts. I'm currently seeing (in systat -vmstat 2): Around 1800 irqs/s for em0, 1800 for em1, 1800 for em2, under 10/s for em3 Around 2000 irqs/s for cpu0:time, 2000 more for cpu1:time, 2000 for cpu2:time and 2000 for cpu3:time. Interrupts total (as reported by systat): around 13500/second. I would estimate the old IRQ load at around 30000-35000/second, which doesn't seem too much to me, for a dual xeon machine. ? > >kern.ipc.nmbclusters=655360 > no need. see netstat > -m Thanks, but as I said, I did try almost *EVERYTHING* I could without rebooting. Including this. Speaking of which, I did compile the kernel with "options DEVICE_POLLING", but enabling polling only made the errors appear more often, and in greater numbers. > P.S. change copper cable, > turn off the flow-control > (if is on) There are 4 em interfaces on this machine, with new cat6 cables. 2 more em interfaces on another machine that was seeing the same errors (the old router), on different cables. And 2 more em interfaces on another machine that's in production, also with new cables. The input errors (as debugged by sysctl dev.em.0.stats=1 -> read dmesg) are only 2 because of CRC errors, as opposed to around 2.500.000 from other causes. I tend to feel the cable isn't the problem. Flow control is off, I just checked. I forgot about that one, thanks for reminding me. Thank you for your help Alex From jfvogel at gmail.com Wed Aug 19 16:07:30 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 19 16:07:36 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <11167f520908182358hc7a176as962788b505b87148@mail.gmail.com> References: <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com> <11167f520908181955x3cc90a26k3ca37fd45cfaabf3@mail.gmail.com> <2a41acea0908182306h740194bcw4de78b6093998e88@mail.gmail.com> <11167f520908182358hc7a176as962788b505b87148@mail.gmail.com> Message-ID: <2a41acea0908190907g366fd2bft3a65c8565e3d859@mail.gmail.com> That should not be necessary. I will have someone look into this today. Jack On Tue, Aug 18, 2009 at 11:58 PM, Sam Fourman Jr. wrote: > On Wed, Aug 19, 2009 at 1:06 AM, Jack Vogel wrote: > > Hmmm, that's odd, I had the validation group do a thorough test > > of older adapters, and that one did not seem to have a problem, > > let me see if we can repro the issue tomorrow, but, in principle I > > have no problem doing this. > > > > Jack > > I can provide root ssh access to these with a serial console and > public IP's if you need > I have over 100 of these (old dell P3 2450's with whatever em(4) fibre > nic dell shipped) sitting on the shelf collecting dust. > > Just send me a heads up and I will have someone set one up for you right > away. > > Sam Fourman Jr. > Fourman Networks > From gigabyte.tmn at gmail.com Wed Aug 19 16:27:03 2009 From: gigabyte.tmn at gmail.com (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsg==?=) Date: Wed Aug 19 16:34:47 2009 Subject: em driver input errors References: <24727.68667.qm@web56404.mail.re3.yahoo.com> Message-ID: <000e01ca20e9$e19caa10$1e010a0a@in72.ru> Hello Alex. What sheduler are you using? ULE or 4BSD Have you NIC IRQ sharing with other hardware? What HZ value? 1000? >Thanks for the suggestion. >From a "clean" box: >dev.em.0.rx_int_delay: 0 >dev.em.0.tx_int_delay: 66 >dev.em.0.rx_abs_int_delay: 66 >dev.em.0.tx_abs_int_delay: 66 >I reset all the values (errors still appearing), then tried your suggestion >(rx_int_delay=600, rx_abs_int_delay=1000). This has reduced the number of > >interrupts for em0 (from about 7200/sec to around 6500/sec). After some >time, I started getting errors again. mmm, try the maximum value 67108, what hapens... > But that has made me try this also: >dev.em.0.tx_int_delay=600 >dev.em.0.tx_abs_int_delay=1000 I think it's a bad idea, but don't know because: >Meaning using your suggested values for tx too. Now em0 is seeing about >1800 interrupts/second, which is way better, but after some time I saw >errors >again... >From the output of "netstat -nI em0 -w 5": maybe mistake, did you meen "netstat -w5 em0" ? I have PPPoE concenrator based on S3000AHV motherboard with Core2Quad 6600 and four (to load all cores in CPU) Intel PCI-E x1 and PCI-E x4 NIC's My load: bras1 [/usr/home/dm]# netstat -w5 em0 input (Total) output packets errs bytes packets errs bytes colls 943831 0 803741196 932221 0 766771487 0 ^C bras1 [/usr/home/dm]# netstat -w1 -Iem0 input (em0) output packets errs bytes packets errs bytes colls 24067 0 20593033 17152 0 17361755 0 ^C bras1 [/usr/home/dm]# netstat -w1 -Ilagg0 input (lagg0) output packets errs bytes packets errs bytes colls 47085 0 38454150 46708 0 38128482 0 44888 0 36087138 44714 0 35985529 0 49607 0 40467232 49326 0 40227456 0 ^C bras1 [/usr/home/dm]# netstat -w5 -Ilagg0 input (lagg0) output packets errs bytes packets errs bytes colls 230260 0 187650240 228911 0 186485136 0 238023 0 194650670 236648 0 193471650 0 218424 0 175576014 216860 0 174282762 0 ^C The lagg0 interface includes em0, em1, em2, em3 for lacp protocol, and comunicates with cisco 2960G switch. vmstat -i says: interrupt total rate irq4: sio0 95234 0 irq19: atapci1 8430157 1 cpu0: timer 1275549106 258 irq256: em0 2329917460 472 irq257: em1 645070135 130 irq258: em2 3527395550 715 irq259: em3 3923746474 795 cpu1: timer 1275548822 258 cpu3: timer 1275548798 258 cpu2: timer 1275548865 258 Total 15536850601 3149 And i have't any problems. I think i select the good hardware. > input (em0) output > packets errs bytes packets errs bytes colls > 87267 0 50372599 106931 0 81598993 0 > 86496 0 50990332 105467 0 80064657 0 > 81726 3056 49876613 99080 0 73273640 0 > 90425 0 59172531 105299 0 77110096 0 > 120292 0 70369292 109597 0 78626248 0 >... a few minutes pass with zero errors ... > 89646 0 56951878 111240 0 86493393 0 > 86031 0 53549721 108695 0 83592747 0 > 77760 3054 48505562 96912 0 73185576 0 > 87508 0 56116394 106094 0 79130608 0 > 89031 0 56490982 103039 0 77398567 0 >What's interesting is that I'm seeing errors in a 80k packets/5 sec (so >around 16k packets/s) zone, but no errors at 120k packets/5sec (24kpps). Yes, it's not normaly. >Interrupts total (as reported by systat): around 13500/second. I would >estimate the old IRQ load at around 30000-35000/second, which doesn't seem >too >much to me, for a dual xeon machine. I think it depends by motherbord, what full hardware specification are you using? with chips names >Speaking of which, I did compile the kernel with "options DEVICE_POLLING", >but enabling polling only made the errors appear more often, and in greater > >numbers. I don't use polling on FBSD 7.x, it's usable on FBSD older versions > - 1 x dual-port gigabit interface, PCI-X Maybe I have this card. And it works unstable, i don't remember what happens, but i seen by tcpdump "truncated IP, missing XX bytes" Good luck. From spawk at acm.poly.edu Wed Aug 19 17:52:26 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Wed Aug 19 17:52:53 2009 Subject: kmem_map too small panics with Soekris/Atheros access point Message-ID: <4A8C3557.20002@acm.poly.edu> Ahoy. I've got two Soekris Net5501s with Atheros 5212 cards in them, acting as access points. They are both running 7.2-RELEASE and at times each one has up to 30 machines associated with it. Relevant information about them can be found at "http://acm.poly.edu/~spawk/ap/". After a few days, they panic with: panic: kmem_malloc(32768): kmem_map too small: 86142976 total allocated Indeed, vm.kmem_size on each of them is 86228992. I had nowhere to write a core dump to, but the root issue seems to be that all kernel memory was exhausted, which sounds like a memory leak somewhere. Is that a known problem with that release and hardware configuration? -Boris From barney_cordoba at yahoo.com Wed Aug 19 18:14:34 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Wed Aug 19 18:14:41 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <4A8B316F.3030408@elischer.org> Message-ID: <121870.41829.qm@web63905.mail.re1.yahoo.com> --- On Tue, 8/18/09, Julian Elischer wrote: > From: Julian Elischer > Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] > To: d@delphij.net > Cc: pyunyh@gmail.com, "Barney Cordoba" , "David Christensen" , "freebsd-net@freebsd.org" , "Jack Vogel" , "Jack F Vogel" , yongari@freebsd.org > Date: Tuesday, August 18, 2009, 6:55 PM > Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Barney Cordoba wrote: > >> --- On Tue, 8/18/09, Pyun YongHyeon > wrote: > >> > >>> From: Pyun YongHyeon > >>> Subject: Re: [PATCH] Fix for e1000 (em/igb) > NOARP issue [Was Re: em(4): sending ARP regardless of NOARP > flag] > >>> To: "Xin LI" > >>> Cc: "Barney Cordoba" , > "David Christensen" , > "d@delphij..net" > , > "freebsd-net@freebsd.org" > , > "Jack Vogel" , > "Jack F Vogel" , > yongari@freebsd.org, > "Julian Elischer" > >>> Date: Tuesday, August 18, 2009, 5:49 PM > >>> On Tue, Aug 18, 2009 at 02:03:37PM > >>> -0700, Xin LI wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> Hi, Jack, > >>>> > >>>> I have looked into the code history and > found that > >>> sys/dev/em/if_em.c,v > >>>> 1.119 has introduced the arp_ifinit() call > in order to > >>> fix the problem > >>>> that if_em won't send ARP when IP address > is changed. > >>>> > >>>> I think we can further improve it as > attached, say, > >>> only do it when > >>>> IFF_NOARP is not set.? This should > have no effect > >>> for usual > >>>> configuration but fix the problem when > NOARP is the > >>> desired behavior. > >>> That change was introduced by me. I guess the > root cause of > >>> the > >>> problem was long initialization time of > hardware which in > >>> turn > >>> resulted in unbearable boot time when > multiple-alias > >>> addresses are > >>> assigned to em(4). I don't remember > details,though. > >>> > >>> Since we're in the release cycle, the change > you suggested > >>> would be > >>> quick fix for 8.0. I think em(4)/igb(4) should > remove > >>> SIOCSIFADDR > >>> handling in driver which is layering > violation. > >> There are 2 kinds of programmers; those who do > things "correctly', > >> and those that do things that work. > >> > >> 99.99999% of the people will be using ARPs, so > don't be silly and > >> break the driver to solve a case that almost > no-one cares about please. > > > > Cisco.Ironport? runs 50% (2 out of 4) of their em > interfaces in noarp > mode. Ah, are they running Jack's drivers unmodified? Seems unlikely. NOARP does work. Does your network catch on fire if the interface sends an ARP out? Does equipment start failing like dominos? My point was don't make ARPs not work (the reason the "hack" is in there is to make something work better) to preserve some fantasy of "layering" that went out with the 8-track player. The check for the NOARP flag is a better solution until the subsystem works the way its supposed to work. Barney From jfvogel at gmail.com Wed Aug 19 18:43:00 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 19 18:43:06 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <2a41acea0908190907g366fd2bft3a65c8565e3d859@mail.gmail.com> References: <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com> <11167f520908181955x3cc90a26k3ca37fd45cfaabf3@mail.gmail.com> <2a41acea0908182306h740194bcw4de78b6093998e88@mail.gmail.com> <11167f520908182358hc7a176as962788b505b87148@mail.gmail.com> <2a41acea0908190907g366fd2bft3a65c8565e3d859@mail.gmail.com> Message-ID: <2a41acea0908191142k453b4211n15aea5904e1b21a0@mail.gmail.com> We've repro'd this, it wasnt caught before because he only tested copper. I will get the change submitted. Jack On Wed, Aug 19, 2009 at 9:07 AM, Jack Vogel wrote: > That should not be necessary. I will have someone look into this today. > > Jack > > > > On Tue, Aug 18, 2009 at 11:58 PM, Sam Fourman Jr. wrote: > >> On Wed, Aug 19, 2009 at 1:06 AM, Jack Vogel wrote: >> > Hmmm, that's odd, I had the validation group do a thorough test >> > of older adapters, and that one did not seem to have a problem, >> > let me see if we can repro the issue tomorrow, but, in principle I >> > have no problem doing this. >> > >> > Jack >> >> I can provide root ssh access to these with a serial console and >> public IP's if you need >> I have over 100 of these (old dell P3 2450's with whatever em(4) fibre >> nic dell shipped) sitting on the shelf collecting dust. >> >> Just send me a heads up and I will have someone set one up for you right >> away. >> >> Sam Fourman Jr. >> Fourman Networks >> > > From barney_cordoba at yahoo.com Wed Aug 19 18:43:06 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Wed Aug 19 18:43:14 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908181535o7c5275dfn2f6647454cfac804@mail.gmail.com> Message-ID: <822688.18516.qm@web63903.mail.re1.yahoo.com> --- On Tue, 8/18/09, Manish Vachharajani wrote: > From: Manish Vachharajani > Subject: Re: Dropped vs. missed packets in the ixgbe driver > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Tuesday, August 18, 2009, 6:35 PM > Indeed the debugging info is also > interesting.? However, I'd like to > get some data from netstat when the driver drops > frames.? When looking > at the bge driver source, it appears that all input drops > at the NIC > are reported as input errors.? It appears that the > intel drivers > (e1000, ixgb, and ixgbe) don't report that number outside > of the debug > and stats printfs at all, and this seems broken.? What > I want to know > is if I have just missed where these are reported. > > So, in a nutshell, the question is:? should these > drivers be reporting > miss events as input errors in the ifnet struct as the bge > driver > does, or as drops in the ifnet struct, was there some > conscious > decision not to report miss events anywhere outside the > debug and > stats info, or am I just being silly and not seeing where > the numbers > are reported? > > Also, don't worry on the performance front, we are also > looking at the > driver in FreeBSD 8.0 :) which supports RSS to help > performance > scaling,? though we have some interesting data there > that I'll post > about once I confirm that the numbers are indeed correct > and not a > tuning or setup problem. > > Manish > > > --- On Mon, 8/17/09, Manish Vachharajani > wrote: > > > >> From: Manish Vachharajani > >> Subject: Dropped vs. missed packets in the ixgbe > driver > >> To: freebsd-net@freebsd.org > >> Date: Monday, August 17, 2009, 6:24 PM > >> I've been doing some performance > >> testing on freebsd 7.2 and noticed > >> that the ixgbe driver does not report missed > packets as > >> dropped when > >> queried via netstat -id (the ixgbe driver in the > 8.0 > >> beta has a > >> similar issue).? A missed packet is a packet that > was > >> correctly > >> received by the NIC but because it was out of > descriptors > >> and internal > >> memory, the packet had to be dropped by the NIC > itself -- a > >> hardware > >> register counts such events.? Instead the driver > only > >> reports drops > >> that are due to the driver itself, i.e., the NIC > DMAed the > >> packet to > >> memory but the driver had to drop something > because it was > >> out of > >> mbufs.? Is the miss count reported elsewhere > (besides > >> via a kernel > >> printf from the driver)?? At the end of the email > I > >> give a stats dump > >> from the driver and from netstat, note the number > of > >> packets dropped > >> is 0 as reported by netstat but the Missed field > in the > >> dmesg output > >> shows many missed packets. > >> > >> >From my perspective, it is disconcerting to > see > >> performance > >> degradation on the link, along with TCP ack > retransmits, > >> packet > >> reordering, etc. (on a point-to-point link with no > switch > >> in between) > >> but then see no drops reported by netstat because > the > >> driver didn't > >> drop the packet, the NIC did.? The fix should be > >> straight-forward and > >> I'll gladly make a patch assuming that it is > indeed a bug > >> and not a > >> conscious design choice. > >> > >> Here is the relevant netstat output > >> > >> Name? ? Mtu Network > >> ???Address > >> ? ? Ipkts Ierrs? ? Opkts > >> Oerrs? Coll Drop > >> ix0? ? 1500 > >> 00:30:48:94:60:ec? ? ? ? 0 > >> ???0? ? ? ? 1 > >> ?0? ???0? ? 0 > >> ix0? ? 1500 192.168.105.0 192.168.105.2 > >> ? ? ? ? ? 0 > >> ???-? ? ? ? 0 > >> ?-? ???-? ? - if you look in ixgbe_update_stats_counters at the bottom: ifp->if_ierrors = missed_rx + adapter->stats.crcerrs + adapter->stats.rlec; the errors are added in. BC > >> 00:30:48:94:60:ed? ? ? 11M > >> ???0? ???6.1M > >> ?0? ???0? ? 0 > >> ix1? ? 1500 > >> 192.168.5.0???192.168.5.2 > >> ? ? ? 10M? ???- > >> ???6.1M > >> ?-? ???-? ? - > >> > >> And here is the dmesg output after doing a sysctl > >> dev.ix.1.stats=1 > >> > >> ix1: Std Mbuf Failed = 0 > >> ix1: Missed Packets = 413872 > >> ix1: Receive length errors = 0 > >> ix1: Crc errors = 0 > >> ix1: Driver dropped packets = 0 > >> ix1: watchdog timeouts = 0 > >> ix1: XON Rcvd = 616428212235 > >> ix1: XON Xmtd = 0 > >> ix1: XOFF Rcvd = 616428212235 > >> ix1: XOFF Xmtd = 0 > >> ix1: Total Packets Rcvd = 12424533 > >> ix1: Good Packets Rcvd = 12010661 > >> ix1: Good Packets Xmtd = 6419128 > >> ix1: TSO Transmissions = 0 > >> > >> Manish > > > > the debug sysctl show more interesting info. Don't get > too excited > > about doing performance testing with that driver. Its > not designed > > to be any higher in performance than any of the other > intel drivers. > > > > Barney > > > > > > > > > > > > -- > Manish Vachharajani > Founder > LineRate Systems > manishv@lineratesystems.com > (609)635-9531 M > _______________________________________________ > 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 manishv at lineratesystems.com Wed Aug 19 18:46:06 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Wed Aug 19 18:46:13 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <822688.18516.qm@web63903.mail.re1.yahoo.com> References: <5bc218350908181535o7c5275dfn2f6647454cfac804@mail.gmail.com> <822688.18516.qm@web63903.mail.re1.yahoo.com> Message-ID: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> Agreed, the errors are reported but missed packets are not. The question is, is the correct fix to just add stats.mpc[0] to if_ierrors in that line or to add it to if_iqdrops. The fix is easy once we agree on what the correct behavior is. Manish > Barney wrote: > > if you look in ixgbe_update_stats_counters at the bottom: > > ? ? ? ?ifp->if_ierrors = missed_rx + adapter->stats.crcerrs + > ? ? ? ? ? ? ? ?adapter->stats.rlec; > > the errors are added in. > > BC -- Manish Vachharajani Founder LineRate Systems manishv@lineratesystems.com (609)635-9531 M From julian at elischer.org Wed Aug 19 19:34:07 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Aug 19 19:34:20 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <121870.41829.qm@web63905.mail.re1.yahoo.com> References: <121870.41829.qm@web63905.mail.re1.yahoo.com> Message-ID: <4A8C53AD.1040102@elischer.org> Barney Cordoba wrote: > > --- On Tue, 8/18/09, Julian Elischer wrote: > >> From: Julian Elischer >> Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] >> To: d@delphij.net >> Cc: pyunyh@gmail.com, "Barney Cordoba" , "David Christensen" , "freebsd-net@freebsd.org" , "Jack Vogel" , "Jack F Vogel" , yongari@freebsd.org >> Date: Tuesday, August 18, 2009, 6:55 PM >> Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Barney Cordoba wrote: >>>> --- On Tue, 8/18/09, Pyun YongHyeon >> wrote: >>>>> From: Pyun YongHyeon >>>>> Subject: Re: [PATCH] Fix for e1000 (em/igb) >> NOARP issue [Was Re: em(4): sending ARP regardless of NOARP >> flag] >>>>> To: "Xin LI" >>>>> Cc: "Barney Cordoba" , >> "David Christensen" , >> "d@delphij..net" >> , >> "freebsd-net@freebsd.org" >> , >> "Jack Vogel" , >> "Jack F Vogel" , >> yongari@freebsd.org, >> "Julian Elischer" >>>>> Date: Tuesday, August 18, 2009, 5:49 PM >>>>> On Tue, Aug 18, 2009 at 02:03:37PM >>>>> -0700, Xin LI wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Hi, Jack, >>>>>> >>>>>> I have looked into the code history and >> found that >>>>> sys/dev/em/if_em.c,v >>>>>> 1.119 has introduced the arp_ifinit() call >> in order to >>>>> fix the problem >>>>>> that if_em won't send ARP when IP address >> is changed. >>>>>> I think we can further improve it as >> attached, say, >>>>> only do it when >>>>>> IFF_NOARP is not set. This should >> have no effect >>>>> for usual >>>>>> configuration but fix the problem when >> NOARP is the >>>>> desired behavior. >>>>> That change was introduced by me. I guess the >> root cause of >>>>> the >>>>> problem was long initialization time of >> hardware which in >>>>> turn >>>>> resulted in unbearable boot time when >> multiple-alias >>>>> addresses are >>>>> assigned to em(4). I don't remember >> details,though. >>>>> Since we're in the release cycle, the change >> you suggested >>>>> would be >>>>> quick fix for 8.0. I think em(4)/igb(4) should >> remove >>>>> SIOCSIFADDR >>>>> handling in driver which is layering >> violation. >>>> There are 2 kinds of programmers; those who do >> things "correctly', >>>> and those that do things that work. >>>> >>>> 99.99999% of the people will be using ARPs, so >> don't be silly and >>>> break the driver to solve a case that almost >> no-one cares about please. >> Cisco.Ironport runs 50% (2 out of 4) of their em >> interfaces in noarp >> mode. > > > Ah, are they running Jack's drivers unmodified? Seems unlikely. well they will be when they go to 8. They stay a revision or two back for stability reasons of course. why wouldn't they? > > NOARP does work. Does your network catch on fire if the interface sends > an ARP out? Does equipment start failing like dominos? well if your network sniffer started responding to arps, how would you feel? > > My point was don't make ARPs not work (the reason the "hack" is in > there is to make something work better) to preserve some fantasy of > "layering" that went out with the 8-track player. The check for > the NOARP flag is a better solution until the subsystem works the > way its supposed to work. > > Barney > > > From alexpalias-bsdnet at yahoo.com Wed Aug 19 21:45:10 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Wed Aug 19 21:45:16 2009 Subject: em driver input errors In-Reply-To: <4A8C15B7.5090404@sepehrs.com> Message-ID: <959379.51225.qm@web56407.mail.re3.yahoo.com> --- On Wed, 8/19/09, H.Fazaeli wrote: > From: H.Fazaeli > Subject: Re: em driver input errors > To: alexpalias-bsdnet@yahoo.com > Cc: freebsd-net@freebsd.org > Date: Wednesday, August 19, 2009, 6:09 PM > Have you tries fixed speed/duplex? Hello. Flow control is already disabled in the switch, and now I have configured fixed speed and duplex both on the switch and the network card. # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:xx:xx:xx:xx:xx media: Ethernet 1000baseTX status: active I will let you know if this fixes the problem; however, I seem to remember that speed/duplex problems usually result in lots of collisions and CRC errors, but I get very little of those (no collisions in fact): # netstat -nI em0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:xx:xx:xx:xx:xx 10448059238 2746221 12382379424 0 0 Also: r# sysctl dev.em.0.stats=1 ; dmesg | tail -21 dev.em.0.stats: -1 -> -1 em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 2746217 em0: Receive No Buffers = 4996579 em0: Receive Length Errors = 0 em0: Receive errors = 2 em0: Crc errors = 2 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 1134 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 10443504721 em0: Good Packets Xmtd = 12377389802 em0: TSO Contexts Xmtd = 0 em0: TSO Contexts Failed = 0 This seems to suggest that the number of errors seen in ifconfig is linked to the "missed packets" statistic that's produced by the sysctl. Note that there are only 2 CRC errors and 2 other errors; I can't see anything that corresponds to the "Receive no buffers" figure; are those packets dropped by the NIC itself? Alex From alexpalias-bsdnet at yahoo.com Wed Aug 19 21:49:55 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Wed Aug 19 21:50:01 2009 Subject: em driver input errors In-Reply-To: <959379.51225.qm@web56407.mail.re3.yahoo.com> Message-ID: <107062.54569.qm@web56406.mail.re3.yahoo.com> --- On Thu, 8/20/09, alexpalias-bsdnet@yahoo.com wrote: > From: alexpalias-bsdnet@yahoo.com > Subject: Re: em driver input errors > To: "H.Fazaeli" > Cc: freebsd-net@freebsd.org > Date: Thursday, August 20, 2009, 12:45 AM > > I will let you know if this fixes the problem; however, I > seem to remember that speed/duplex problems usually result > in lots of collisions and CRC errors, but I get very little > of those (no collisions in fact): Nope; still seeing errors (a burst of 2500 errors in 10 seconds recently). Thank you for the suggestion though Alex From fazaeli at sepehrs.com Wed Aug 19 22:35:07 2009 From: fazaeli at sepehrs.com (H.Fazaeli) Date: Wed Aug 19 22:35:14 2009 Subject: em driver input errors In-Reply-To: <11420.28890.qm@web56404.mail.re3.yahoo.com> References: <11420.28890.qm@web56404.mail.re3.yahoo.com> Message-ID: <4A8C15B7.5090404@sepehrs.com> Have you tries fixed speed/duplex? alexpalias-bsdnet@yahoo.com wrote: > Good day > > I'm running a FreeBSD 7.2 router and I am seeing a lot of input errors on one of the em interfaces (em0), coupled with (at approximately the same times) much fewer errors on em1 and em2. Monitoring is done with SNMP from another machine, and the CPU load as reported via SNMP is mostly below 30%, with a couple of spikes up to 35%. > > Software description: > > - FreeBSD 7.2-RELEASE-p2, amd64 > - bsnmpd with modules: hostres and (from ports) snmp_ucd > - quagga 0.99.12 (running only zebra and bgpd) > - netgraph (ng_ether and ng_netflow) > > Hardware description: > > - Dell machine, dual Xeon 3.20 GHz, 4 GB RAM > - 2 x built-in gigabit interfaces (em0, em1) > - 1 x dual-port gigabit interface, PCI-X (em2, em3) [see pciconf near the end] > > > The machine receives the global routing table ("netstat -nr | wc -l" gives 289115 currently). > > All of the em interfaces are just configured "up", with various vlan interfaces on them. Note that I use "kpps" to mean "thousands of packets per second", sorry if that's the wrong shorthand. > > - em0 sees a traffic of 10...22 kpps in, and 15...35 kpps out. In bits, it's 30...120Mbits/s in, and 100...210Mbits/s out. Vlans configured are vlan100 and vlan200, and most of the traffic is on vlan100 (vlan200 sees 4kpps in / 0.5kpps out maximum, with the average at about one third of this). em0 is the external interface, and its traffic corresponds to the sum of traffic through em1 and em2 > > - em1 has 5 vlans, and sees about 22kpps in / 11kpps out (maximum) > > - em2 has a single VLAN, and sees about 4...13kpps both in and out (almost equal in/out during most of the day) > > - em3 is a backup interface, with 2 VLANS, and is the only one which has seen no errors. > > Only the vlans on em0 are analyzed by ng_netflow, and the errors I'm seeing have started appearing days before netgraph was even loaded in the kernel. > > Tuning done: > > /boot/loader.conf: > hw.em.rxd=4096 > hw.em.txd=4096 > > Witout the above we were seeing way more errors, now they are reduced, but still come in bursts of over 1000 errors on em0. > > /etc/sysctl.conf: > net.inet.ip.fastforwarding=1 > dev.em.0.rx_processing_limit=300 > dev.em.1.rx_processing_limit=300 > dev.em.2.rx_processing_limit=300 > dev.em.3.rx_processing_limit=300 > > Still seeing errros, after some searching the mailing lists we also added: > > # the four lines below are repeated for em1, em2, em3 > dev.em.0.rx_int_delay=0 > dev.em.0.rx_abs_int_delay=0 > dev.em.0.tx_int_delay=0 > dev.em.0.tx_abs_int_delay=0 > > Still getting errors, so I also added: > > net.inet.ip.intr_queue_maxlen=4096 > net.route.netisr_maxqlen=1024 > > and > > kern.ipc.nmbclusters=655360 > > > Also tried with rx_processing_limit set to -1 on all em interfaces, still getting errors. > > Looking at the shape of the error and packet graphs, there seems to be a correlation between the number of packets per second on em0 and the height of the error "spikes" on the error graph. These spikes are spread throughout the day, with spaces (zones with no errors) of various lengths (10 minutes ... 2 hours spaces within the last 24 hours), but sometimes there are errors even in the lowest kpps times of the day. > > em0 and em1 error times are correlated, with all errors on the graph for em0 having a smaller corresponding error spike on em1 at the same time, and sometimes an error spike on em2. > > The old router was seeing about the same traffic, and had em0, em1, re0 and re1 network cards, and was only seeing errors on the em cards. It was running 7.2-PRERELEASE/i386 > > > Any suggestions would be greatly appreciated. Please note that this is a live router, and I can't reboot it (unless absolutely necessary). Tuning that can be applied without rebooting will be tried first. > > Here are some more details: > > Trimmed output of netstat -ni (sorry if there are line breaks): > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > em0 1500 00:14:22:xx:xx:xx 19744458839 15494721 24284439443 0 0 > em1 1500 00:14:22:xx:xx:xx 12832245469 123181 10105031790 0 0 > em2 1500 00:04:23:xx:xx:xx 12082552403 10964 10339416865 0 0 > em3 1500 00:04:23:xx:xx:xx 79912337 0 48178737 0 0 > > Relevant part of pciconf -vl: > > em0@pci0:6:7:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > em1@pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > em2@pci0:9:4:0: class=0x020000 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > em3@pci0:9:4:1: class=0x020000 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > > Kernel messages after sysctl dev.em.0.stats=1: > (note that I've removed the lines which only showed zeros in the second and third outputs) > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 15435312 > em0: Receive No Buffers = 16446113 > em0: Receive Length Errors = 0 > em0: Receive errors = 1 > em0: Crc errors = 2 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 96826 > em0: watchdog timeouts = 0 > em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 19002068797 > em0: Good Packets Xmtd = 23168462599 > em0: TSO Contexts Xmtd = 0 > em0: TSO Contexts Failed = 0 > > [later] > em0: Excessive collisions = 0 > em0: Missed Packets = 15459111 > em0: Receive No Buffers = 16447082 > em0: Receive errors = 1 > em0: Crc errors = 2 > em0: RX overruns = 96835 > em0: Good Packets Rcvd = 19165047284 > em0: Good Packets Xmtd = 23386976960 > > [later] > em0: Excessive collisions = 0 > em0: Missed Packets = 15470583 > em0: Receive No Buffers = 16447686 > em0: Receive errors = 1 > em0: Crc errors = 2 > em0: RX overruns = 96840 > em0: Good Packets Rcvd = 19255466068 > em0: Good Packets Xmtd = 23519004546 > > > Thank you for your time. > > _______________________________________________ > 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 From rpsfa at rit.edu Thu Aug 20 03:10:03 2009 From: rpsfa at rit.edu (Ryan Steinmetz) Date: Thu Aug 20 03:10:10 2009 Subject: kern/109733: [bge] bge link state issues [regression] Message-ID: <200908200310.n7K3A2wC028356@freefall.freebsd.org> The following reply was made to PR kern/109733; it has been noted by GNATS. From: Ryan Steinmetz To: bug-followup@FreeBSD.org, donbrearley@hibbing.edu Cc: Subject: Re: kern/109733: [bge] bge link state issues [regression] Date: Wed, 19 Aug 2009 23:03:16 -0400 This issue appears to still exist in 7.2-RELEASE. The 3c996-sx doesn't function properly, nor does the remote side ever go into a link-up state. -r -- Ryan Steinmetz Lead Security/Systems Administrator Infrastructure Engineering Rochester Institute of Technology 585.475.5663 PGP: EF36 D45A 5CA9 28B1 A550 18CD A43C D111 7AD7 FAF2 From stef-list at memberwebs.com Thu Aug 20 04:46:15 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Thu Aug 20 04:46:21 2009 Subject: ath0: ath_rx_proc: no mbuf! Message-ID: <20090820042016.C8F913039754@mx.npubs.com> I'm having a problem on an old FreeBSD 6.0 box, that's a wireless router, been running steadily for years. A short while ago (perhaps due to a change in traffic), every few hours, the wireless interface becomes unresponsive, and I started seeing thousands of lines like this in: ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! Has anyone seen this problem? An mbuf leak? Or perhaps fixed something like it in a later version of FreeBSD? Would upgrading the FreeBSD version fix this? It's in a really remote location, high on a tower, and tough to upgrade :( netstat -m shows: # netstat -m 104/19096/19200 mbufs in use (current/cache/total) 101/2971/3072/3072 mbuf clusters in use (current/cache/total/max) 0/3/1024 sfbufs in use (current/peak/max) 228K/10716K/10944K bytes allocated to network (current/cache/total) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines The mbufs are in fact all used up. I allocate more via kern.ipc.nmbclusters, and see the same behavior. 6.0-RELEASE-p5 FreeBSD 6.0-RELEASE-p5 #6: Thu May 18 18:02:20 UTC 2006 Thanks in advance, Stef From lev at serebryakov.spb.ru Thu Aug 20 05:28:34 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Thu Aug 20 05:28:40 2009 Subject: ath0: ath_rx_proc: no mbuf! In-Reply-To: <20090820042016.C8F913039754@mx.npubs.com> References: <20090820042016.C8F913039754@mx.npubs.com> Message-ID: <1038963609.20090820091230@serebryakov.spb.ru> Hello, Stef. You wrote 20 ??????? 2009 ?., 08:20:17: > I'm having a problem on an old FreeBSD 6.0 box, that's a wireless > router, been running steadily for years. > A short while ago (perhaps due to a change in traffic), every few hours, > the wireless interface becomes unresponsive, and I started seeing > thousands of lines like this in: > ath0: ath_rx_proc: no mbuf! > The mbufs are in fact all used up. I allocate more via > kern.ipc.nmbclusters, and see the same behavior. Same problem here on 7.2-STABLE, but incresaing kern.ipc.nmbclusters to 65536 helps. It seems, that when traffic is reauuly huge, system with ath need a lot of mbufs. At night, when traffic is almost zero, netstat -m shows a lot of free mbufs and clusters, so it seems, that there is no mbuf leaks. -- // Black Lion AKA Lev Serebryakov From delphij at delphij.net Thu Aug 20 07:41:12 2009 From: delphij at delphij.net (Xin LI) Date: Thu Aug 20 07:41:21 2009 Subject: (just for fun) port of OpenBSD pf's sloppy mode Message-ID: <4A8CFDAF.1000309@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Since there is effort undergoing to port a newer pf version to FreeBSD, I think this work would not be useful for inclusion in -CURRENT. However, I'd like to share it here as someone may find it useful before the new pf code hits the tree. The patch can also be downloaded from my website: http://www.delphij.net/pf-sloppy.diff About this patch: When pf(4) is operating in a manner that not all packet would went through it, specifically, when being used in a DSR ("Direct Server Return") network, the strict TCP state tracking would prevent some packets from being able to pass through. This can exhibit as, when you upload files, the connection would stall at ~60KB (may differ if you have special TCP setting), or stalled connections. With this change, pf.conf would support a new syntax, i.e. "(sloppy)" as state flag, e.g.: pass in quick on em0 route-to { (em1 $server1), (em1 $server2) } round-robin proto tcp from any to $ext_ip port 80 keep state (sloppy) When enabled, the "sloppy" TCP FSM would be activated, which loosens the state check. When using this option, the backend server has to use its own mechanism to prevent ICMP teardown attack and/or insertion attacks, so please use caution and limit the use in cases where pf(4) won't see some packets in the connection. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqM/a8ACgkQi+vbBBjt66BRSACfQaOY3gHdEhjhGO5bz1zYhdud NFMAmgLaVnzbBdA4ofj5helYkDtdqTds =N0nJ -----END PGP SIGNATURE----- -------------- next part -------------- Index: sys/contrib/pf/net/if_pfsync.c =================================================================== --- sys/contrib/pf/net/if_pfsync.c (revision 196398) +++ sys/contrib/pf/net/if_pfsync.c (working copy) @@ -465,7 +465,7 @@ pfsync_insert_net_state(struct pfsync_state *sp, u st->direction = sp->direction; st->log = sp->log; st->timeout = sp->timeout; - st->allow_opts = sp->allow_opts; + st->state_flags = sp->state_flags; bcopy(sp->id, &st->id, sizeof(st->id)); st->creatorid = sp->creatorid; @@ -1578,7 +1578,7 @@ pfsync_pack_state(u_int8_t action, struct pf_state sp->proto = st->proto; sp->direction = st->direction; sp->log = st->log; - sp->allow_opts = st->allow_opts; + sp->state_flags = st->state_flags; sp->timeout = st->timeout; if (flags & PFSYNC_FLAG_STALE) Index: sys/contrib/pf/net/pfvar.h =================================================================== --- sys/contrib/pf/net/pfvar.h (revision 196398) +++ sys/contrib/pf/net/pfvar.h (working copy) @@ -700,6 +700,7 @@ struct pf_rule { /* rule flags again */ #define PFRULE_IFBOUND 0x00010000 /* if-bound */ +#define PFRULE_STATESLOPPY 0x00020000 /* sloppy state tracking */ #define PFSTATE_HIWAT 10000 /* default state table size */ #define PFSTATE_ADAPT_START 6000 /* default adaptive timeout start */ @@ -800,7 +801,9 @@ struct pf_state { u_int8_t pad; #endif u_int8_t log; - u_int8_t allow_opts; + u_int8_t state_flags; +#define PFSTATE_ALLOWOPTS 0x01 +#define PFSTATE_SLOPPY 0x02 u_int8_t timeout; u_int8_t sync_flags; #define PFSTATE_NOSYNC 0x01 Index: sys/contrib/pf/net/if_pfsync.h =================================================================== --- sys/contrib/pf/net/if_pfsync.h (revision 196398) +++ sys/contrib/pf/net/if_pfsync.h (working copy) @@ -80,7 +80,7 @@ struct pfsync_state { u_int8_t proto; u_int8_t direction; u_int8_t log; - u_int8_t allow_opts; + u_int8_t state_flags; u_int8_t timeout; u_int8_t sync_flags; u_int8_t updates; Index: sys/contrib/pf/net/pf.c =================================================================== --- sys/contrib/pf/net/pf.c (revision 196398) +++ sys/contrib/pf/net/pf.c (working copy) @@ -253,6 +253,13 @@ int pf_test_fragment(struct pf_rule **, int, struct pfi_kif *, struct mbuf *, void *, struct pf_pdesc *, struct pf_rule **, struct pf_ruleset **); +int pf_tcp_track_full(struct pf_state_peer *, + struct pf_state_peer *, struct pf_state **, + struct pfi_kif *, struct mbuf *, int, + struct pf_pdesc *, u_short *, int *); +int pf_tcp_track_sloppy(struct pf_state_peer *, + struct pf_state_peer *, struct pf_state **, + struct pf_pdesc *, u_short *); int pf_test_state_tcp(struct pf_state **, int, struct pfi_kif *, struct mbuf *, int, void *, struct pf_pdesc *, u_short *); @@ -3528,7 +3535,10 @@ cleanup: s->nat_rule.ptr = nr; s->anchor.ptr = a; STATE_INC_COUNTERS(s); - s->allow_opts = r->allow_opts; + if (r->allow_opts) + s->state_flags |= PFSTATE_ALLOWOPTS; + if (r->rule_flag & PFRULE_STATESLOPPY) + s->state_flags |= PFSTATE_SLOPPY; s->log = r->log & PF_LOG_ALL; if (nr != NULL) s->log |= nr->log & PF_LOG_ALL; @@ -3925,7 +3935,10 @@ cleanup: s->nat_rule.ptr = nr; s->anchor.ptr = a; STATE_INC_COUNTERS(s); - s->allow_opts = r->allow_opts; + if (r->allow_opts) + s->state_flags |= PFSTATE_ALLOWOPTS; + if (r->rule_flag & PFRULE_STATESLOPPY) + s->state_flags |= PFSTATE_SLOPPY; s->log = r->log & PF_LOG_ALL; if (nr != NULL) s->log |= nr->log & PF_LOG_ALL; @@ -4238,7 +4251,10 @@ cleanup: s->nat_rule.ptr = nr; s->anchor.ptr = a; STATE_INC_COUNTERS(s); - s->allow_opts = r->allow_opts; + if (r->allow_opts) + s->state_flags |= PFSTATE_ALLOWOPTS; + if (r->rule_flag & PFRULE_STATESLOPPY) + s->state_flags |= PFSTATE_SLOPPY; s->log = r->log & PF_LOG_ALL; if (nr != NULL) s->log |= nr->log & PF_LOG_ALL; @@ -4525,7 +4541,10 @@ cleanup: s->nat_rule.ptr = nr; s->anchor.ptr = a; STATE_INC_COUNTERS(s); - s->allow_opts = r->allow_opts; + if (r->allow_opts) + s->state_flags |= PFSTATE_ALLOWOPTS; + if (r->rule_flag & PFRULE_STATESLOPPY) + s->state_flags |= PFSTATE_SLOPPY; s->log = r->log & PF_LOG_ALL; if (nr != NULL) s->log |= nr->log & PF_LOG_ALL; @@ -4666,166 +4685,16 @@ pf_test_fragment(struct pf_rule **rm, int directio } int -pf_test_state_tcp(struct pf_state **state, int direction, struct pfi_kif *kif, - struct mbuf *m, int off, void *h, struct pf_pdesc *pd, - u_short *reason) +pf_tcp_track_full(struct pf_state_peer *src, struct pf_state_peer *dst, + struct pf_state **state, struct pfi_kif *kif, struct mbuf *m, int off, + struct pf_pdesc *pd, u_short *reason, int *copyback) { - struct pf_state_cmp key; - struct tcphdr *th = pd->hdr.tcp; - u_int16_t win = ntohs(th->th_win); - u_int32_t ack, end, seq, orig_seq; - u_int8_t sws, dws; - int ackskew; - int copyback = 0; - struct pf_state_peer *src, *dst; + struct tcphdr *th = pd->hdr.tcp; + u_int16_t win = ntohs(th->th_win); + u_int32_t ack, end, seq, orig_seq; + u_int8_t sws, dws; + int ackskew; - key.af = pd->af; - key.proto = IPPROTO_TCP; - if (direction == PF_IN) { - PF_ACPY(&key.ext.addr, pd->src, key.af); - PF_ACPY(&key.gwy.addr, pd->dst, key.af); - key.ext.port = th->th_sport; - key.gwy.port = th->th_dport; - } else { - PF_ACPY(&key.lan.addr, pd->src, key.af); - PF_ACPY(&key.ext.addr, pd->dst, key.af); - key.lan.port = th->th_sport; - key.ext.port = th->th_dport; - } - - STATE_LOOKUP(); - - if (direction == (*state)->direction) { - src = &(*state)->src; - dst = &(*state)->dst; - } else { - src = &(*state)->dst; - dst = &(*state)->src; - } - - if ((*state)->src.state == PF_TCPS_PROXY_SRC) { - if (direction != (*state)->direction) { - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_SYNPROXY_DROP); - } - if (th->th_flags & TH_SYN) { - if (ntohl(th->th_seq) != (*state)->src.seqlo) { - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_DROP); - } -#ifdef __FreeBSD__ - pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, pd->dst, -#else - pf_send_tcp((*state)->rule.ptr, pd->af, pd->dst, -#endif - pd->src, th->th_dport, th->th_sport, - (*state)->src.seqhi, ntohl(th->th_seq) + 1, - TH_SYN|TH_ACK, 0, (*state)->src.mss, 0, 1, - 0, NULL, NULL); - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_SYNPROXY_DROP); - } else if (!(th->th_flags & TH_ACK) || - (ntohl(th->th_ack) != (*state)->src.seqhi + 1) || - (ntohl(th->th_seq) != (*state)->src.seqlo + 1)) { - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_DROP); - } else if ((*state)->src_node != NULL && - pf_src_connlimit(state)) { - REASON_SET(reason, PFRES_SRCLIMIT); - return (PF_DROP); - } else - (*state)->src.state = PF_TCPS_PROXY_DST; - } - if ((*state)->src.state == PF_TCPS_PROXY_DST) { - struct pf_state_host *src, *dst; - - if (direction == PF_OUT) { - src = &(*state)->gwy; - dst = &(*state)->ext; - } else { - src = &(*state)->ext; - dst = &(*state)->lan; - } - if (direction == (*state)->direction) { - if (((th->th_flags & (TH_SYN|TH_ACK)) != TH_ACK) || - (ntohl(th->th_ack) != (*state)->src.seqhi + 1) || - (ntohl(th->th_seq) != (*state)->src.seqlo + 1)) { - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_DROP); - } - (*state)->src.max_win = MAX(ntohs(th->th_win), 1); - if ((*state)->dst.seqhi == 1) - (*state)->dst.seqhi = htonl(arc4random()); -#ifdef __FreeBSD__ - pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, - &src->addr, -#else - pf_send_tcp((*state)->rule.ptr, pd->af, &src->addr, -#endif - &dst->addr, src->port, dst->port, - (*state)->dst.seqhi, 0, TH_SYN, 0, - (*state)->src.mss, 0, 0, (*state)->tag, NULL, NULL); - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_SYNPROXY_DROP); - } else if (((th->th_flags & (TH_SYN|TH_ACK)) != - (TH_SYN|TH_ACK)) || - (ntohl(th->th_ack) != (*state)->dst.seqhi + 1)) { - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_DROP); - } else { - (*state)->dst.max_win = MAX(ntohs(th->th_win), 1); - (*state)->dst.seqlo = ntohl(th->th_seq); -#ifdef __FreeBSD__ - pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, pd->dst, -#else - pf_send_tcp((*state)->rule.ptr, pd->af, pd->dst, -#endif - pd->src, th->th_dport, th->th_sport, - ntohl(th->th_ack), ntohl(th->th_seq) + 1, - TH_ACK, (*state)->src.max_win, 0, 0, 0, - (*state)->tag, NULL, NULL); -#ifdef __FreeBSD__ - pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, - &src->addr, -#else - pf_send_tcp((*state)->rule.ptr, pd->af, &src->addr, -#endif - &dst->addr, src->port, dst->port, - (*state)->src.seqhi + 1, (*state)->src.seqlo + 1, - TH_ACK, (*state)->dst.max_win, 0, 0, 1, - 0, NULL, NULL); - (*state)->src.seqdiff = (*state)->dst.seqhi - - (*state)->src.seqlo; - (*state)->dst.seqdiff = (*state)->src.seqhi - - (*state)->dst.seqlo; - (*state)->src.seqhi = (*state)->src.seqlo + - (*state)->dst.max_win; - (*state)->dst.seqhi = (*state)->dst.seqlo + - (*state)->src.max_win; - (*state)->src.wscale = (*state)->dst.wscale = 0; - (*state)->src.state = (*state)->dst.state = - TCPS_ESTABLISHED; - REASON_SET(reason, PFRES_SYNPROXY); - return (PF_SYNPROXY_DROP); - } - } - - if (((th->th_flags & (TH_SYN|TH_ACK)) == TH_SYN) && - dst->state >= TCPS_FIN_WAIT_2 && - src->state >= TCPS_FIN_WAIT_2) { - if (pf_status.debug >= PF_DEBUG_MISC) { - printf("pf: state reuse "); - pf_print_state(*state); - pf_print_flags(th->th_flags); - printf("\n"); - } - /* XXX make sure it's the same direction ?? */ - (*state)->src.state = (*state)->dst.state = TCPS_CLOSED; - pf_unlink_state(*state); - *state = NULL; - return (PF_DROP); - } - if (src->wscale && dst->wscale && !(th->th_flags & TH_SYN)) { sws = src->wscale & PF_WSCALE_MASK; dws = dst->wscale & PF_WSCALE_MASK; @@ -4863,7 +4732,7 @@ int pf_change_a(&th->th_seq, &th->th_sum, htonl(seq + src->seqdiff), 0); pf_change_a(&th->th_ack, &th->th_sum, htonl(ack), 0); - copyback = 1; + *copyback = 1; } else { ack = ntohl(th->th_ack); } @@ -4915,7 +4784,7 @@ int pf_change_a(&th->th_seq, &th->th_sum, htonl(seq + src->seqdiff), 0); pf_change_a(&th->th_ack, &th->th_sum, htonl(ack), 0); - copyback = 1; + *copyback = 1; } end = seq + pd->p_len; if (th->th_flags & TH_SYN) @@ -4961,7 +4830,7 @@ int */ if (dst->seqdiff && (th->th_off << 2) > sizeof(struct tcphdr)) { if (pf_modulate_sack(m, off, pd, th, dst)) - copyback = 1; + *copyback = 1; } @@ -4980,7 +4849,7 @@ int if (dst->scrub || src->scrub) { if (pf_normalize_tcp_stateful(m, off, pd, reason, th, - *state, src, dst, ©back)) + *state, src, dst, copyback)) return (PF_DROP); } @@ -5082,7 +4951,7 @@ int if (dst->scrub || src->scrub) { if (pf_normalize_tcp_stateful(m, off, pd, reason, th, - *state, src, dst, ©back)) + *state, src, dst, copyback)) return (PF_DROP); } @@ -5128,6 +4997,7 @@ int src->seqhi = 1; src->max_win = 1; } else if (pf_status.debug >= PF_DEBUG_MISC) { +#if 0 printf("pf: BAD state: "); pf_print_state(*state); pf_print_flags(th->th_flags); @@ -5140,8 +5010,8 @@ int #else (*state)->packets[0], (*state)->packets[1], #endif - direction == PF_IN ? "in" : "out", - direction == (*state)->direction ? "fwd" : "rev"); + pd->dir == PF_IN ? "in" : "out", + pd->dir == (*state)->direction ? "fwd" : "rev"); printf("pf: State failure on: %c %c %c %c | %c %c\n", SEQ_GEQ(src->seqhi, end) ? ' ' : '1', SEQ_GEQ(seq, src->seqlo - (dst->max_win << dws)) ? @@ -5150,13 +5020,255 @@ int (ackskew <= (MAXACKWINDOW << sws)) ? ' ' : '4', SEQ_GEQ(src->seqhi + MAXACKWINDOW, end) ?' ' :'5', SEQ_GEQ(seq, src->seqlo - MAXACKWINDOW) ?' ' :'6'); +#endif } REASON_SET(reason, PFRES_BADSTATE); return (PF_DROP); } /* Any packets which have gotten here are to be passed */ + return (PF_PASS); +} +int +pf_tcp_track_sloppy(struct pf_state_peer *src, struct pf_state_peer *dst, + struct pf_state **state, struct pf_pdesc *pd, u_short *reason) +{ + struct tcphdr *th = pd->hdr.tcp; + + if (th->th_flags & TH_SYN) + if (src->state < TCPS_SYN_SENT) + src->state = TCPS_SYN_SENT; + if (th->th_flags & TH_FIN) + if (src->state < TCPS_CLOSING) + src->state = TCPS_CLOSING; + if (th->th_flags & TH_ACK) { + if (dst->state == TCPS_SYN_SENT) { + dst->state = TCPS_ESTABLISHED; + if (src->state == TCPS_ESTABLISHED && + (*state)->src_node != NULL && + pf_src_connlimit(state)) { + REASON_SET(reason, PFRES_SRCLIMIT); + return (PF_DROP); + } + } else if (dst->state == TCPS_CLOSING) { + dst->state = TCPS_FIN_WAIT_2; + } else if (src->state == TCPS_SYN_SENT && + dst->state < TCPS_SYN_SENT) { + /* + * Handle a special sloppy case where we only see one + * half of the connection. If there is a ACK after + * the initial SYN without ever seeing a packet from + * the destination, set the connection to established. + */ + dst->state = src->state = TCPS_ESTABLISHED; + if ((*state)->src_node != NULL && + pf_src_connlimit(state)) { + REASON_SET(reason, PFRES_SRCLIMIT); + return (PF_DROP); + } + } else if (src->state == TCPS_CLOSING && + dst->state == TCPS_ESTABLISHED && + dst->seqlo == 0) { + /* + * Handle the closing of half connections where we + * don't see the full bidirectional FIN/ACK+ACK + * handshake. + */ + dst->state = TCPS_CLOSING; + } + } + if (th->th_flags & TH_RST) + src->state = dst->state = TCPS_TIME_WAIT; + + /* update expire time */ + (*state)->expire = time_second; + if (src->state >= TCPS_FIN_WAIT_2 && + dst->state >= TCPS_FIN_WAIT_2) + (*state)->timeout = PFTM_TCP_CLOSED; + else if (src->state >= TCPS_CLOSING && + dst->state >= TCPS_CLOSING) + (*state)->timeout = PFTM_TCP_FIN_WAIT; + else if (src->state < TCPS_ESTABLISHED || + dst->state < TCPS_ESTABLISHED) + (*state)->timeout = PFTM_TCP_OPENING; + else if (src->state >= TCPS_CLOSING || + dst->state >= TCPS_CLOSING) + (*state)->timeout = PFTM_TCP_CLOSING; + else + (*state)->timeout = PFTM_TCP_ESTABLISHED; + + return (PF_PASS); +} + + +/* XXXXX */ +int +pf_test_state_tcp(struct pf_state **state, int direction, struct pfi_kif *kif, + struct mbuf *m, int off, void *h, struct pf_pdesc *pd, + u_short *reason) +{ + struct pf_state_cmp key; + struct tcphdr *th = pd->hdr.tcp; + int copyback = 0; + struct pf_state_peer *src, *dst; + + key.af = pd->af; + key.proto = IPPROTO_TCP; + if (direction == PF_IN) { + PF_ACPY(&key.ext.addr, pd->src, key.af); + PF_ACPY(&key.gwy.addr, pd->dst, key.af); + key.ext.port = th->th_sport; + key.gwy.port = th->th_dport; + } else { + PF_ACPY(&key.lan.addr, pd->src, key.af); + PF_ACPY(&key.ext.addr, pd->dst, key.af); + key.lan.port = th->th_sport; + key.ext.port = th->th_dport; + } + + STATE_LOOKUP(); + + if (direction == (*state)->direction) { + src = &(*state)->src; + dst = &(*state)->dst; + } else { + src = &(*state)->dst; + dst = &(*state)->src; + } + + if ((*state)->src.state == PF_TCPS_PROXY_SRC) { + if (direction != (*state)->direction) { + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_SYNPROXY_DROP); + } + if (th->th_flags & TH_SYN) { + if (ntohl(th->th_seq) != (*state)->src.seqlo) { + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_DROP); + } +#ifdef __FreeBSD__ + pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, pd->dst, +#else + pf_send_tcp((*state)->rule.ptr, pd->af, pd->dst, +#endif + pd->src, th->th_dport, th->th_sport, + (*state)->src.seqhi, ntohl(th->th_seq) + 1, + TH_SYN|TH_ACK, 0, (*state)->src.mss, 0, 1, + 0, NULL, NULL); + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_SYNPROXY_DROP); + } else if (!(th->th_flags & TH_ACK) || + (ntohl(th->th_ack) != (*state)->src.seqhi + 1) || + (ntohl(th->th_seq) != (*state)->src.seqlo + 1)) { + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_DROP); + } else if ((*state)->src_node != NULL && + pf_src_connlimit(state)) { + REASON_SET(reason, PFRES_SRCLIMIT); + return (PF_DROP); + } else + (*state)->src.state = PF_TCPS_PROXY_DST; + } + if ((*state)->src.state == PF_TCPS_PROXY_DST) { + struct pf_state_host *src, *dst; + + if (direction == PF_OUT) { + src = &(*state)->gwy; + dst = &(*state)->ext; + } else { + src = &(*state)->ext; + dst = &(*state)->lan; + } + if (direction == (*state)->direction) { + if (((th->th_flags & (TH_SYN|TH_ACK)) != TH_ACK) || + (ntohl(th->th_ack) != (*state)->src.seqhi + 1) || + (ntohl(th->th_seq) != (*state)->src.seqlo + 1)) { + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_DROP); + } + (*state)->src.max_win = MAX(ntohs(th->th_win), 1); + if ((*state)->dst.seqhi == 1) + (*state)->dst.seqhi = htonl(arc4random()); +#ifdef __FreeBSD__ + pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, + &src->addr, +#else + pf_send_tcp((*state)->rule.ptr, pd->af, &src->addr, +#endif + &dst->addr, src->port, dst->port, + (*state)->dst.seqhi, 0, TH_SYN, 0, + (*state)->src.mss, 0, 0, (*state)->tag, NULL, NULL); + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_SYNPROXY_DROP); + } else if (((th->th_flags & (TH_SYN|TH_ACK)) != + (TH_SYN|TH_ACK)) || + (ntohl(th->th_ack) != (*state)->dst.seqhi + 1)) { + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_DROP); + } else { + (*state)->dst.max_win = MAX(ntohs(th->th_win), 1); + (*state)->dst.seqlo = ntohl(th->th_seq); +#ifdef __FreeBSD__ + pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, pd->dst, +#else + pf_send_tcp((*state)->rule.ptr, pd->af, pd->dst, +#endif + pd->src, th->th_dport, th->th_sport, + ntohl(th->th_ack), ntohl(th->th_seq) + 1, + TH_ACK, (*state)->src.max_win, 0, 0, 0, + (*state)->tag, NULL, NULL); +#ifdef __FreeBSD__ + pf_send_tcp(NULL, (*state)->rule.ptr, pd->af, + &src->addr, +#else + pf_send_tcp((*state)->rule.ptr, pd->af, &src->addr, +#endif + &dst->addr, src->port, dst->port, + (*state)->src.seqhi + 1, (*state)->src.seqlo + 1, + TH_ACK, (*state)->dst.max_win, 0, 0, 1, + 0, NULL, NULL); + (*state)->src.seqdiff = (*state)->dst.seqhi - + (*state)->src.seqlo; + (*state)->dst.seqdiff = (*state)->src.seqhi - + (*state)->dst.seqlo; + (*state)->src.seqhi = (*state)->src.seqlo + + (*state)->dst.max_win; + (*state)->dst.seqhi = (*state)->dst.seqlo + + (*state)->src.max_win; + (*state)->src.wscale = (*state)->dst.wscale = 0; + (*state)->src.state = (*state)->dst.state = + TCPS_ESTABLISHED; + REASON_SET(reason, PFRES_SYNPROXY); + return (PF_SYNPROXY_DROP); + } + } + + if (((th->th_flags & (TH_SYN|TH_ACK)) == TH_SYN) && + dst->state >= TCPS_FIN_WAIT_2 && + src->state >= TCPS_FIN_WAIT_2) { + if (pf_status.debug >= PF_DEBUG_MISC) { + printf("pf: state reuse "); + pf_print_state(*state); + pf_print_flags(th->th_flags); + printf("\n"); + } + /* XXX make sure it's the same direction ?? */ + (*state)->src.state = (*state)->dst.state = TCPS_CLOSED; + pf_unlink_state(*state); + *state = NULL; + return (PF_DROP); + } + + if ((*state)->state_flags & PFSTATE_SLOPPY) { + if (pf_tcp_track_sloppy(src, dst, state, pd, reason) == PF_DROP) + return (PF_DROP); + } else { + if (pf_tcp_track_full(src, dst, state, kif, m, off, pd, reason, + ©back) == PF_DROP) + return (PF_DROP); + } + /* translate source/destination address, if necessary */ if (STATE_TRANSLATE(*state)) { if (direction == PF_OUT) @@ -5533,8 +5645,9 @@ pf_test_state_icmp(struct pf_state **state, int di copyback = 1; } - if (!SEQ_GEQ(src->seqhi, seq) || - !SEQ_GEQ(seq, src->seqlo - (dst->max_win << dws))) { + if (!((*state)->state_flags & PFSTATE_SLOPPY) && + (!SEQ_GEQ(src->seqhi, seq) || + !SEQ_GEQ(seq, src->seqlo - (dst->max_win << dws)))) { if (pf_status.debug >= PF_DEBUG_MISC) { printf("pf: BAD ICMP %d:%d ", icmptype, pd->hdr.icmp->icmp_code); @@ -7052,7 +7165,7 @@ pf_test(int dir, struct ifnet *ifp, struct mbuf ** done: if (action == PF_PASS && h->ip_hl > 5 && - !((s && s->allow_opts) || r->allow_opts)) { + !((s && s->state_flags & PFSTATE_ALLOWOPTS) || r->allow_opts)) { action = PF_DROP; REASON_SET(&reason, PFRES_IPOPTIONS); log = 1; @@ -7513,7 +7626,7 @@ pf_test6(int dir, struct ifnet *ifp, struct mbuf * done: /* handle dangerous IPv6 extension headers. */ if (action == PF_PASS && rh_cnt && - !((s && s->allow_opts) || r->allow_opts)) { + !((s && s->state_flags & PFSTATE_ALLOWOPTS) || r->allow_opts)) { action = PF_DROP; REASON_SET(&reason, PFRES_IPOPTIONS); log = 1; Index: contrib/pf/pfctl/parse.y =================================================================== --- contrib/pf/pfctl/parse.y (revision 196387) +++ contrib/pf/pfctl/parse.y (working copy) @@ -128,7 +128,7 @@ enum { PF_STATE_OPT_MAX, PF_STATE_OPT_NOSYNC, PF_S PF_STATE_OPT_MAX_SRC_STATES, PF_STATE_OPT_MAX_SRC_CONN, PF_STATE_OPT_MAX_SRC_CONN_RATE, PF_STATE_OPT_MAX_SRC_NODES, PF_STATE_OPT_OVERLOAD, PF_STATE_OPT_STATELOCK, - PF_STATE_OPT_TIMEOUT }; + PF_STATE_OPT_TIMEOUT, PF_STATE_OPT_SLOPPY }; enum { PF_SRCTRACK_NONE, PF_SRCTRACK, PF_SRCTRACK_GLOBAL, PF_SRCTRACK_RULE }; @@ -423,7 +423,7 @@ typedef struct { %token QUEUE PRIORITY QLIMIT RTABLE %token LOAD RULESET_OPTIMIZATION %token STICKYADDRESS MAXSRCSTATES MAXSRCNODES SOURCETRACK GLOBAL RULE -%token MAXSRCCONN MAXSRCCONNRATE OVERLOAD FLUSH +%token MAXSRCCONN MAXSRCCONNRATE OVERLOAD FLUSH SLOPPY %token TAGGED TAG IFBOUND FLOATING STATEPOLICY ROUTE %token STRING %token PORTBINARY @@ -1891,6 +1891,14 @@ pfrule : action dir logquick interface route af p statelock = 1; r.rule_flag |= o->data.statelock; break; + case PF_STATE_OPT_SLOPPY: + if (r.rule_flag & PFRULE_STATESLOPPY) { + yyerror("state sloppy option: " + "multiple definitions"); + YYERROR; + } + r.rule_flag |= PFRULE_STATESLOPPY; + break; case PF_STATE_OPT_TIMEOUT: if (o->data.timeout.number == PFTM_ADAPTIVE_START || @@ -3216,6 +3224,14 @@ state_opt_item : MAXIMUM number { $$->next = NULL; $$->tail = $$; } + | SLOPPY { + $$ = calloc(1, sizeof(struct node_state_opt)); + if ($$ == NULL) + err(1, "state_opt_item: calloc"); + $$->type = PF_STATE_OPT_SLOPPY; + $$->next = NULL; + $$->tail = $$; + } | STRING number { int i; @@ -4101,6 +4117,13 @@ filter_consistent(struct pf_rule *r, int anchor_ca yyerror("keep state on block rules doesn't make sense"); problems++; } + if (r->rule_flag & PFRULE_STATESLOPPY && + (r->keep_state == PF_STATE_MODULATE || + r->keep_state == PF_STATE_SYNPROXY)) { + yyerror("sloppy state matching cannot be used with " + "synproxy state or modulate state"); + problems++; + } return (-problems); } @@ -4969,6 +4992,7 @@ lookup(char *s) { "scrub", SCRUB}, { "set", SET}, { "skip", SKIP}, + { "sloppy", SLOPPY}, { "source-hash", SOURCEHASH}, { "source-track", SOURCETRACK}, { "state", STATE}, Index: contrib/pf/pfctl/pf_print_state.c =================================================================== --- contrib/pf/pfctl/pf_print_state.c (revision 196387) +++ contrib/pf/pfctl/pf_print_state.c (working copy) @@ -294,6 +294,8 @@ print_state(struct pf_state *s, int opts) printf(", anchor %u", s->anchor.nr); if (s->rule.nr != -1) printf(", rule %u", s->rule.nr); + if (s->state_flags & PFSTATE_SLOPPY) + printf(", sloppy"); if (s->src_node != NULL) printf(", source-track"); if (s->nat_src_node != NULL) Index: contrib/pf/pfctl/pfctl_parser.c =================================================================== --- contrib/pf/pfctl/pfctl_parser.c (revision 196387) +++ contrib/pf/pfctl/pfctl_parser.c (working copy) @@ -873,6 +873,8 @@ print_rule(struct pf_rule *r, const char *anchor_c opts = 1; if (r->rule_flag & PFRULE_IFBOUND) opts = 1; + if (r->rule_flag & PFRULE_STATESLOPPY) + opts = 1; for (i = 0; !opts && i < PFTM_MAX; ++i) if (r->timeout[i]) opts = 1; @@ -939,6 +941,12 @@ print_rule(struct pf_rule *r, const char *anchor_c printf("if-bound"); opts = 0; } + if (r->rule_flag & PFRULE_STATESLOPPY) { + if (!opts) + printf(", "); + printf("sloppy"); + opts = 0; + } for (i = 0; i < PFTM_MAX; ++i) if (r->timeout[i]) { int j; From max at love2party.net Thu Aug 20 09:08:41 2009 From: max at love2party.net (Max Laier) Date: Thu Aug 20 09:08:48 2009 Subject: (just for fun) port of OpenBSD pf's sloppy mode In-Reply-To: <4A8CFDAF.1000309@delphij.net> References: <4A8CFDAF.1000309@delphij.net> Message-ID: <200908201108.39177.max@love2party.net> Nice Work! Thanks a lot! On Thursday 20 August 2009 09:39:27 Xin LI wrote: > Since there is effort undergoing to port a newer pf version to FreeBSD, > I think this work would not be useful for inclusion in -CURRENT. > However, I'd like to share it here as someone may find it useful before > the new pf code hits the tree. The patch can also be downloaded from my I disagree about the usefulness of this. As your patch doesn't affect ABI this could make it into 8.1 (which the all new pf won't). With SVN it is also much simpler to manage the vendor branch differences, now. > website: > > http://www.delphij.net/pf-sloppy.diff freebsd-pf@ test and provide feedback - I know people have asked about this in the past. > About this patch: > > When pf(4) is operating in a manner that not all packet would went > through it, specifically, when being used in a DSR ("Direct Server > Return") network, the strict TCP state tracking would prevent some > packets from being able to pass through. This can exhibit as, when you > upload files, the connection would stall at ~60KB (may differ if you > have special TCP setting), or stalled connections. > > With this change, pf.conf would support a new syntax, i.e. "(sloppy)" as > state flag, e.g.: > > pass in quick on em0 route-to { (em1 $server1), (em1 $server2) } > round-robin proto tcp from any to $ext_ip port 80 keep state (sloppy) > > When enabled, the "sloppy" TCP FSM would be activated, which loosens the > state check. When using this option, the backend server has to use its > own mechanism to prevent ICMP teardown attack and/or insertion attacks, > so please use caution and limit the use in cases where pf(4) won't see > some packets in the connection. -- /"\ 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 alexpalias-bsdnet at yahoo.com Thu Aug 20 09:42:41 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Thu Aug 20 09:42:47 2009 Subject: em driver input errors In-Reply-To: <4A8D15C9.6020002@sepehrs.com> Message-ID: <206677.64959.qm@web56407.mail.re3.yahoo.com> --- On Thu, 8/20/09, H.Fazaeli wrote: > From: H.Fazaeli > Subject: Re: em driver input errors > To: alexpalias-bsdnet@yahoo.com > Cc: freebsd-net@freebsd.org > Date: Thursday, August 20, 2009, 12:22 PM > > > can you provide sysctl dev.em.0.debug=1 output? em0: Adapter hardware address = 0xfffffffe80230320 em0: CTRL = 0x40f00241 RCTL = 0x8002 em0: Packet buffer = Tx=16k Rx=48k em0: Flow control watermarks high = 47104 low = 45604 em0: tx_int_delay = 0, tx_abs_int_delay = 0 em0: rx_int_delay = 0, rx_abs_int_delay = 0 em0: fifo workaround = 0, fifo_reset_count = 0 em0: hw tdh = 259, hw tdt = 259 em0: hw rdh = 603, hw rdt = 602 em0: Num Tx descriptors avail = 4095 em0: Tx Descriptors not avail1 = 0 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 em0: Driver tx dma failure in encap = 0 > There are posts that show the following workarounds have > fixed problems similar to yours on other interface types: > > - disable tso (ifconfig em0 -tso) There's no TSO flag active currently, but I did try it... I guess it's a no-op. Also, the machine is a router, meaning most of the packets are just being forwarded. As far as I understand, TSO is concerned with TCP connections with one local endpoint. Anyway, I did this (after looking in the README for the new intel driver): sysctl net.inet.tcp.tso=0 > - disable msi/msix (hw.em.enable_msi=0 in > /boot/loader.conf. There are also hw.pci.enable_msix and > hw.pci.enable_msi but I don't know their exact > effect). This, and the next one (new driver), will be much harder to try in a production environment... I'll try to find some test machines to torture. > You may also try upgrading to the latest intel em driver > (6.9.12). > http://downloadcenter.intel.com/Filter_Results.aspx?strOSs=52&strTypes=all&ProductID=1067&OSFullName=FreeBSD*&lang=eng > Thanks Alex From alexpalias-bsdnet at yahoo.com Thu Aug 20 10:07:55 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Thu Aug 20 10:08:04 2009 Subject: em driver input errors In-Reply-To: <000e01ca20e9$e19caa10$1e010a0a@in72.ru> Message-ID: <550146.64358.qm@web56404.mail.re3.yahoo.com> Hello. --- On Wed, 8/19/09, ??????? ???????? wrote: > From: ??????? ???????? > Subject: Re: em driver input errors > To: alexpalias-bsdnet@yahoo.com > Cc: freebsd-net@freebsd.org > Date: Wednesday, August 19, 2009, 7:27 PM > Hello Alex. > > What sheduler are you using? ULE or 4BSD > Have you NIC IRQ sharing with other hardware? > What HZ value? 1000? SCHED_ULE, HZ=1000: host# sysctl kern.sched.name kern.hz kern.sched.name: ULE kern.hz: 1000 host# > > Thanks for the suggestion. > > From a "clean" box: > > dev.em.0.rx_int_delay: 0 > > dev.em.0.tx_int_delay: 66 > > dev.em.0.rx_abs_int_delay: 66 > > dev.em.0.tx_abs_int_delay: 66 > > I reset all the values (errors still appearing), then > tried your suggestion (rx_int_delay=600, > rx_abs_int_delay=1000).? This has reduced the number of > >interrupts for em0 (from about 7200/sec to around > 6500/sec).? After some time, I started getting errors > again. > mmm, try the maximum value 67108, what hapens... I will try this today when there's enough traffic to see errors. > > But that has made me try this also: > > dev.em.0.tx_int_delay=600 > > dev.em.0.tx_abs_int_delay=1000 > I think it's a bad idea, but don't know because: > > Meaning using your suggested values for tx too.? > Now em0 is seeing about 1800 interrupts/second, which is way > better, but after some time I saw errors >again... > > > From the output of "netstat -nI em0 -w 5": > maybe mistake, did you meen "netstat -w5 em0" ? Nope, exactly as in my mail, "netstat -nI em0 -w 5". It does take 5 seconds to produce meaningful output. > I have PPPoE concenrator based on S3000AHV motherboard with > Core2Quad 6600 and four (to load all cores in CPU) Intel > PCI-E x1 and PCI-E x4 NIC's > My load: Pretty impressive figures. And "netstat -ni" shows 0 errors on all cards? > And i have't any problems. I think i select the good > hardware. > > > Interrupts total (as reported by systat):? around > 13500/second.? I would estimate the old IRQ load at > around 30000-35000/second, which doesn't seem too >much > to me, for a dual xeon machine. > I think it depends by motherbord, what full hardware > specification are you using? with chips names The machine is a Dell PowerEdge 2850. According to its specs, the chipset is Intel E7520. Two 64-bit Xeon processors at 3.20GHz, 4 GB RAM. > > Speaking of which, I did compile the kernel with > "options DEVICE_POLLING", but enabling polling only made the > errors appear more often, and in greater >numbers. > I don't use polling on FBSD 7.x, it's usable on FBSD older > versions I tried as many possibilities as I could. > > - 1 x dual-port gigabit interface, PCI-X > Maybe I have this card. And it works unstable, i don't > remember what happens, but i seen by tcpdump "truncated IP, > missing XX bytes" Currently most errors are on the motherboard-embedded em0 interface. Second is embedded em1. Last are em2 and em3 which are on the dual-port card (em2 under 170k errors as opposed to 2.6M for em0, and em3 0 errors) > Good luck. Thanks! From gigabyte.tmn at gmail.com Thu Aug 20 11:58:28 2009 From: gigabyte.tmn at gmail.com (Dmitriy Zamuraev) Date: Thu Aug 20 11:58:35 2009 Subject: em driver input errors References: <550146.64358.qm@web56404.mail.re3.yahoo.com> Message-ID: <010901ca218d$878276a0$1e010a0a@in72.ru> Hello Alex, > SCHED_ULE, HZ=1000: I use this too >> > From the output of "netstat -nI em0 -w 5": >> maybe mistake, did you meen "netstat -w5 em0" ? > Nope, exactly as in my mail, "netstat -nI em0 -w 5". It does take 5 > seconds to produce meaningful output. hmm, just comments: -n Show network addresses and ports as numbers. -l Shows listen sockets -nl with -w is wrong parameters. > I have PPPoE concenrator based on S3000AHV motherboard with > Core2Quad 6600 and four (to load all cores in CPU) Intel > PCI-E x1 and PCI-E x4 NIC's > My load: > ... > Pretty impressive figures. And "netstat -ni" shows 0 errors on all cards? Not exactly zero, but for uptime 155 days it seems to be ok. bras1 [/usr/home/dm]# netstat -i|grep em em0 1500 00:15:17:71:f8:52 2457503820 20175 2096211799 0 0 em1 1500 00:15:17:71:f8:52 1084492221 11188 909418060 0 0 em2 1500 00:15:17:71:f8:52 4212941427 29566 3500442287 0 0 em3 1500 00:15:17:71:f8:52 2143321197 0 1878792786 0 0 This counters was made by UDP flood, when dummynet can't process all packets and swi:net loads one core up to 100%. Yes, the dummynet on this machine, its bad idea but it's working stable. (After this incident the switches now control the flood attack) NOTE: the MAC is equal because i use if_lagg(4) for this interfaces for load all cores in CPU >> I think it depends by motherbord, what full hardware specification are >> you using? with chips names > The machine is a Dell PowerEdge 2850. According to its specs, the chipset > is Intel E7520. > Two 64-bit Xeon processors at 3.20GHz, 4 GB RAM. For you bandwidth this server must work fine. Check the UDP/ICMP or other flood on em0 when errors appear. What kind of device at the end of em0 copper cable? If this a manageable switch, and supports tools - try to investigate what happens when errors appear. From alexpalias-bsdnet at yahoo.com Thu Aug 20 12:34:39 2009 From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com) Date: Thu Aug 20 12:34:45 2009 Subject: em driver input errors In-Reply-To: <010901ca218d$878276a0$1e010a0a@in72.ru> Message-ID: <487959.75728.qm@web56402.mail.re3.yahoo.com> --- On Thu, 8/20/09, Dmitriy Zamuraev wrote: > From: Dmitriy Zamuraev > Subject: Re: em driver input errors > To: alexpalias-bsdnet@yahoo.com > Cc: freebsd-net@freebsd.org > Date: Thursday, August 20, 2009, 2:58 PM > Hello Alex, > > > SCHED_ULE, HZ=1000: > I use this too > > > And "netstat -ni" > shows 0 errors on all cards? > Not exactly zero, but for uptime 155 days it seems to be > ok. > bras1 [/usr/home/dm]# netstat -i|grep em > em0? ? 1500 ? ? ?00:15:17:71:f8:52 2457503820 20175 2096211799 0??0 > em1? ? 1500 ? ? ?00:15:17:71:f8:52 1084492221 11188 909418060????0 0 > em2? ? 1500 ? ? ?00:15:17:71:f8:52 4212941427 29566 3500442287 0????0 > em3? ? 1500 ? ? ?00:15:17:71:f8:52 2143321197? ???0 1878792786 0? ???0 Definitely way better than my numbers. Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 blah1 11166666892 2776856 13194560132 0 0 em1 1500 blah2 7420822703 462462 6185054971 0 0 em2 1500 blah3 6070962640 167193 5341606634 0 0 em3 1500 blah4 15183452 0 17424318 0 0 # uptime 3:29PM up 8 days, 11:19, 2 users, load averages: 0.69, 0.78, 0.83 > This counters was made by UDP flood, when dummynet can't > process all packets and > swi:net loads one core up to 100%. Yes, the dummynet on > this machine, its bad idea but it's > working stable. (After this incident the switches now > control the flood attack) > NOTE: the MAC is equal because i use if_lagg(4) for this > interfaces for load all cores in CPU Interesting. But I'm seeing this during normal traffic. I can't remember if it was this machine, or the older machine (also with em driver) when I did get a flood of over 90.000 packets/second, and the error rate jumped to around 50.000/second... > >> I think it depends by motherbord, what full > hardware specification are you using? with chips names > > The machine is a Dell PowerEdge 2850.? According > to its specs, the chipset is Intel E7520. > > Two 64-bit Xeon processors at 3.20GHz, 4 GB RAM. > For you bandwidth this server must work fine. > Check the UDP/ICMP or other flood on em0 when errors > appear. > What kind of device at the end of em0 copper cable? > If this a manageable switch, and supports tools - try to > investigate what happens when errors appear. It's a ZyXEL managed switch, unfortunately SNMP support doesn't seem to work very well on it. But even before I added this switch (when there was a Cisco Catalyst 3560 at the end of the cable) I was seeing the error bursts. But I will try and see if I detect anything on the switch end. Thanks Alex From sepron at gmail.com Thu Aug 20 12:39:40 2009 From: sepron at gmail.com (Sergey Pronin) Date: Thu Aug 20 12:39:46 2009 Subject: em driver input errors Message-ID: Try to set sysctl net.isr.direct=1 swi:net will not use 100% of your CPU. From barney_cordoba at yahoo.com Thu Aug 20 12:49:39 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Aug 20 12:49:46 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> Message-ID: <435336.24858.qm@web63908.mail.re1.yahoo.com> --- On Wed, 8/19/09, Manish Vachharajani wrote: > From: Manish Vachharajani > Subject: Re: Dropped vs. missed packets in the ixgbe driver > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Wednesday, August 19, 2009, 2:46 PM > Agreed, the errors are reported but > missed packets are not.? The > question is, is the correct fix to just add stats.mpc[0] to > if_ierrors > in that line or to add it to if_iqdrops.? The fix is > easy once we > agree on what the correct behavior is. > > Manish > > > Barney wrote: > > > > if you look in ixgbe_update_stats_counters at the > bottom: > > > > ? ? ? ?ifp->if_ierrors = missed_rx + > adapter->stats.crcerrs + > > ? ? ? ? ? ? ? ?adapter->stats.rlec; > > > > the errors are added in. > > > > BC Huh? missed_rx are the missed packets. So they are counted. BC From barney_cordoba at yahoo.com Thu Aug 20 13:09:52 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Aug 20 13:09:58 2009 Subject: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] In-Reply-To: <4A8C53AD.1040102@elischer.org> Message-ID: <233049.86158.qm@web63904.mail.re1.yahoo.com> --- On Wed, 8/19/09, Julian Elischer wrote: > From: Julian Elischer > Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP issue [Was Re: em(4): sending ARP regardless of NOARP flag] > To: "Barney Cordoba" > Cc: d@delphij.net, pyunyh@gmail.com, "David Christensen" , "freebsd-net@freebsd.org" , "Jack Vogel" , "Jack F Vogel" , yongari@freebsd.org > Date: Wednesday, August 19, 2009, 3:34 PM > Barney Cordoba wrote: > > > > --- On Tue, 8/18/09, Julian Elischer > wrote: > > > >> From: Julian Elischer > >> Subject: Re: [PATCH] Fix for e1000 (em/igb) NOARP > issue [Was Re: em(4): sending ARP regardless of NOARP flag] > >> To: d@delphij.net > >> Cc: pyunyh@gmail.com, > "Barney Cordoba" , > "David Christensen" , > "freebsd-net@freebsd.org" > , > "Jack Vogel" , > "Jack F Vogel" , > yongari@freebsd.org > >> Date: Tuesday, August 18, 2009, 6:55 PM > >> Xin LI wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> Barney Cordoba wrote: > >>>> --- On Tue, 8/18/09, Pyun YongHyeon > >> wrote: > >>>>> From: Pyun YongHyeon > >>>>> Subject: Re: [PATCH] Fix for e1000 > (em/igb) > >> NOARP issue [Was Re: em(4): sending ARP regardless > of NOARP > >> flag] > >>>>> To: "Xin LI" > >>>>> Cc: "Barney Cordoba" , > >> "David Christensen" , > >> "d@delphij..net" > >> , > >> "freebsd-net@freebsd.org" > >> , > >> "Jack Vogel" , > >> "Jack F Vogel" , > >> yongari@freebsd.org, > >> "Julian Elischer" > >>>>> Date: Tuesday, August 18, 2009, 5:49 > PM > >>>>> On Tue, Aug 18, 2009 at 02:03:37PM > >>>>> -0700, Xin LI wrote: > >>>>>> -----BEGIN PGP SIGNED > MESSAGE----- > >>>>>> Hash: SHA1 > >>>>>> > >>>>>> Hi, Jack, > >>>>>> > >>>>>> I have looked into the code > history and > >> found that > >>>>> sys/dev/em/if_em.c,v > >>>>>> 1.119 has introduced the > arp_ifinit() call > >> in order to > >>>>> fix the problem > >>>>>> that if_em won't send ARP when IP > address > >> is changed. > >>>>>> I think we can further improve it > as > >> attached, say, > >>>>> only do it when > >>>>>> IFF_NOARP is not set.? This > should > >> have no effect > >>>>> for usual > >>>>>> configuration but fix the problem > when > >> NOARP is the > >>>>> desired behavior. > >>>>> That change was introduced by me. I > guess the > >> root cause of > >>>>> the > >>>>> problem was long initialization time > of > >> hardware which in > >>>>> turn > >>>>> resulted in unbearable boot time when > >> multiple-alias > >>>>> addresses are > >>>>> assigned to em(4). I don't remember > >> details,though. > >>>>> Since we're in the release cycle, the > change > >> you suggested > >>>>> would be > >>>>> quick fix for 8.0. I think > em(4)/igb(4) should > >> remove > >>>>> SIOCSIFADDR > >>>>> handling in driver which is layering > >> violation. > >>>> There are 2 kinds of programmers; those > who do > >> things "correctly', > >>>> and those that do things that work. > >>>> 99.99999% of the people will be using > ARPs, so > >> don't be silly and > >>>> break the driver to solve a case that > almost > >> no-one cares about please. > >> Cisco.Ironport? runs 50% (2 out of 4) of > their em > >> interfaces in noarp mode. > > > > > > Ah, are they running Jack's drivers unmodified? Seems > unlikely. > > well they will be when they go to 8. > They stay a revision or two back for stability reasons of > course. > why wouldn't they? Because the generic drivers generally suck rocks? And from all of the complaints, it certainly doesn't seem that they are stable. > > > > > > NOARP does work. Does your network catch on fire if > the interface sends > > an ARP out? Does equipment start failing like dominos? > > > well if your network sniffer started responding to arps, > how would you feel? The problem here is that an ARP is sent on address initialization. So what does that have to do with responding to ARPs? Do you usually give a network sniffer an IP address on the monitor port? You seem to be arguing the case that NOARP isn't completely useless, which has no relevance to this discussion. Of course my solution would be to simply comment out the arp init code, because trying to convince 34 bearded gurus of the correct way to do it is way too much work. :) BC > > > > My point was don't make ARPs not work (the reason the > "hack" is in > > there is to make something work better) to preserve > some fantasy of > > "layering" that went out with the 8-track player. The > check for the NOARP flag is a better solution until the > subsystem works the way its supposed to work. > > > > Barney > > > > > >? ? ??? > > From julian at elischer.org Thu Aug 20 16:17:04 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 20 16:17:11 2009 Subject: pf and vimage In-Reply-To: <200908201108.39177.max@love2party.net> References: <4A8CFDAF.1000309@delphij.net> <200908201108.39177.max@love2party.net> Message-ID: <4A8D76FE.7040302@elischer.org> there were some people looking at adding vnet support to pf. Since we discussed it last, the rules of the game have significantly changed for the better. With the addition of some new facilitiesin FreeBSD, the work needed to virtualize a module has significantly decreased. The following doc gives the new rules.. -------------- next part -------------- August 17 2009 Julian Elischer =================== Vimage: what is it? =================== Vimage is a framework in the BSD kernel which allows a co-operating module to operate on multiple independent instances of its state so that it can participate in a virtual machine / virtual environment scenario. It refers to a part of the Jail infrastructure in FreeBSD. For historical reasons "Virtual network stack enabled jails"(1) are also known as "vimage enabled jails"(2) or "vnet enabled jails"(3). The currently correct term is the latter, which is a contraction of the first. In the future other parts of the system may be virtualized using the same technology and the term to cover all such components would be VIMAGE enhanced modules. The implementation approach taken by the vimage framework is a redefinition of selected global state variables to evaluate to constructs that allow for the virtualized state to be stored and resolved in appropriate instances of 'jail' specific container storage regions. The code operating on virtualized state has to conform to a set of rules described further below. Among other things in order to allow for all the changes to be conditionally compilable. i.e. permitting the virtualized code to fall back to operation on global state. The rest of this document will discuss NETWORK virtualization though the concepts may be true in the future for other parts of the system. The most visible change throughout the existing code is typically replacement of direct references to global variables with macros; foo_bar thus becomes V_foo_bar. V_foo_bar macros will resolve back to the foo_bar global in default kernel builds, and alternatively to the logical equivalent of some_base_pointer->_foo_bar for "options VIMAGE" kernel configs. Prepending of "V_" prefixes to variable references helps in visual discrimination between global and virtualized state. It is also possible to use an alternative syntax, of VNET(foo_bar) to achieve the same thing. The developers felt that V_foo_bar was less visually distracting while still providing enough clues to the reader that the variable is virtualized. In fact the V_foo_bar macro is locally defined near the definition of foo_bar to be an alias for VNET(foo_bar) so the two are not only equivalent, they are the same. The framework also extends the sysctl infrastructure to support access to virtualized state through introduction of the SYSCTL_VNET family of macros; those also automatically fall back to their standard SYSCTL counterparts in default kernel builds. Transparent libkvm(3) lookups are provided to virtualized variables which permits userland binaries such as netstat to operate unmodified on "options VIMAGE" kernels, though this may have some security implications. Vnets are associated with jails. In 8.0, every process is associated with a jail, usually the default (null) jail, and jails currently hang off of a processes ucred. This relationship defines a process's administrative affinity to a vnet and thus indirectly to all of its state. All network interfaces and sockets hold pointers back to their associated vnets. This relationship is obviously entirely independent from proc->ucred->jail bindings. Hence, when a process opens a socket, the socket will get bound to a vnet instance hanging off of proc->ucred->jail->vnet, but once such a socket->vnet binding gets established, it cannot be changed for the entire socket lifetime. The mapping of a from a thread to a vnet should always be done via the TD_TO_VNET macro as the path may change in the future as we get more experience with using the system. Certain classes of network interfaces (Ethernet in particular) can be reassigned from one vnet to another at any time. By definition all vnets are independent and can communicate only if they are explicitly provided with communication paths. Currently mainly netgraph is used to establish inter-vnet datapaths, though other paths are being explored such as the 'epair' back-to-back virtual interface pair, in which the different sides may exist in different jails. In network traffic processing the vnet affinity is defined either by the inbound interface or by the socket / pcb -> vnet binding. However, there are many functions in the network stack that cannot implicitly fetch the vnet context from their standard arguments. Instead of explicitly extending argument lists of such functions with a struct vnet *, the concept of a "current vnet", a per-thread variable was introduced, which can be fetched efficiently via the curvnet macro. The correct network context has to be set on entry to the network stack (socket operations, packet reception, or timer-driven functions) and cleared on exit. This must be done via provided CURVNET_SET() / CURVNET_RESTORE() family of macros, which allow for "stacking" of curvnet context setting and provide additional debugging info in INVARIANTS kernel configs. In most cases however a developer writing virtualized code will not have to set / restore the curvnet context unless the code would include timer-driven events, given that those are inherently vnet-contextless on entry. The current rule is that when not in networking code, the result of the 'curvnet' macro will return NULL and evaluating a V_xxx (or VNET(xxx)) macro will result in an kernel page-fault error. While this is not strictly necessary, it aids in debugging and assurance of program correctness. Note this does NOT mean that TD_TO_VNET(curthread) is invalid. A thread is always associated with a vnet, but just the efficient "curvnet" access method is disabled along with the ability to resolve virtualized symbols. Converting / virtualizing existing code ======================================= There are several steps need in virtualisation. 1/ Decide whether the module needs to be virtualised. If the module is a driver for specific hardware, it makes sense that there be only one instance of the driver as there is only one piece of physical hardware. There are changes in the networking code to allow physical (or virtual) interfaces to be moved between vnets. This generally requires NO changes to the network drivers of the classes covered (e.g. ethernet). Currently if your module is does not have any networking facet, the answer is "no" by default. 2/ If the module is to be virtualised, decide which attributes of the module should be virtualised. For example, It may make sense that there be a single central pool of "struct foo" and a single uma zone for them to come from, with a single lock guarding it. It might also make sense if the "foo_debug" sysctl controls all the instances at once, while on the other hand, the "foo_mode" sysctl might make better sense if it were controllable on a virtual system by virtual system basis. 3/ Work out what global variables and structures are to be virtualised to achieve the behaviour required for part #2. 4/ Work out for all the code paths through the module, how the thread entering the module can divine which virtual environment it is on. Some examples: * Since interfaces are all assigned to one vnet or another, an incoming packet has a pointer to the receive interface, which in turn has a pointer back to the vnet. Often "curvnet" will already have been set by the time your code is called anyhow. * Similarly, on any request from outside the kernel, (direct or indirect) the current thread has a way to get to the current virtual environment instance via TD_TO_VNET(curthread). For existing sockets the vnet context must be used via so->so_vnet since the thread's vnet might change after socket creation. * Timer initiated actions usually have a (void *) argument which points to some private structure for the module. It should be possible to add a pointer to the appropriate module instance into whatever structure that points to. * Sometimes an action (timer trigerred or trigerred by module load or unload simply has to check all the vimage or module instances. There are macro (pairs) for this which will iterate through all the VNET or instances. (see sample code below). This covers most of the cases, however in some cases it may still be required for the module to stash away the virtual environment instance somewhere, and make associated changes in the code. 5/ Decide which parts of the initialization and teardown are per jail and which parts are global, and separate out the code accordingly. Global initialization is done using the SYSINIT facility. Per jail initialization is done using VNET_SYSINIT(). Per jail teardown is doen using VNET_SYSUNINIT(). Global teardown is done using SYSUNIT(). In addition, the modevent handler is called with various event types before any of these are called. The modevent handler may veto load or teardown. On Shutdown, only the modevent handler is called so it may have to simulate the calling of the other handlers if clean shutdown is a requirement of your module. (see sample code below). Don't forget to unregister event handlers, and destroy locks and condition variables. 6/ Add the code described below to the files that make up the module. Details: (VNET implementation details) Firstly the file must be included. Depending on what code you use you may find you also need one or more of: , and . These requirements may change slightly as the ABI settles. Having decided which variables need to be virtualized, the definition of thosvariables needs to be modified to use the VNET_DEFINE() macro. For example: static int foo = 3; struct bar thebar = { 1,2,3 }; would become: static VNET_DEFINE(int, foo) = 3; VNET_DEFINE(struct bar, thebar) = { 1,2,3 }; extern int foo; in an include file might become: VNET_DECLARE(int foo); Normal rules regarding 'static/extern' apply. The initial values that you give in this way will be stored and used as the initial values for EACH NEW INSTANCE of these variables as new jails/vnets are created. As mentioned above, accesses to virtualized symbols are achieved via macros, which generally are of the same name as the original symbol but with a "V_" prepended, thus the head of the interface list, called 'ifnet' is replaced whereever used with "V_ifnet". We do this, by adding the following lines after the definitions above: #define V_foo VNET(foo) #define V_thebar VNET(thebar) --- side-note --- In SCTP, because the code is shared with other OS's they are replaced with a macro MODULE_GLOBAL(modulename, symbol). (this may simplify in light of recent changes). -------------- In addition, should any of your values need to be changed or viewed via sysctl, the following SYSCTL definitions would be needed: SYSCTL_VNET_PROC(_net_inet, OID_AUTO, thebar, CTLTYPE_?? | CTLFLAG_RW | CTLFLAG_SECURE3, &VNET_NAME(thebar), 0, thebar, "?", "the bar is open"); {[XXX] robert fix this is possible ^^^} SYSCTL_VNET_INT(_net_inet, OID_AUTO, foo, CTLFLAG_RW, &VNET_NAME(foo), 0, "size of foo"); In the current version of vimage, when VIMAGE is not compiled into the kernel, the macros evaluate to a direct reference to the one and only symbol/variable, so that there is no speed penalty for those not using vnets. When VIMAGE is compiled in, the macro will evaluate to an access to an offset into a data structure that is accessed on a per-vet basis. The vnet used for this is always curvnet. For this reason an attempt to access such a variable while curvnet is not valid, will result in an exception. To ensure that curvnet has a valid value when needed one needs to add the following code on all entry code paths into the networking code: int my_func(int arg) { CURVNET_SET(TD_TO_VNET(curthread)); do_my_network_stuff(arg); CURVNET_RESTORE(); return (0); } The initial value is usually something like "TD_TO_VNET(curthread) which in turn is a macro that derives the vnet affinity from the current thread. It could also be (m->m_ifp->if_vnet) if we were receiving an mbuf, or so->so_vnet if we had a socket involved. Usually, when a packet enters the system it is carried through the processing path via a single thread, and that thread will set its virtual environment reference to that indicated by the packet on picking up that new packet. This means that in the normal inbound processing path as well as the outgoing process path the current thread can be used to indicate the current virtual environment and curvet will always be valid once most user supplied code is reached. In timer events, it is sometimes necessary to add an "outer loop" to iterate through all the possible vnets if there is just one timer for all instances. When a new loadable module is virtualised the module definitions and intializers need to be examined. The following example illustrates what is needed in the case that you are not loading a new protocol, or domain. (for that see later) ============= sample skeleton code ========== /* init on boot or module load */ static int mymod_init(void) { return (error); } /**************** * Stuff that must be initialized for every instance * (including the first of course). */ static int mymod_vnet_init(const void *unused) { return (0); } /********************** * Called for the removal of the last instance only on module unload. */ static void mymod_uninit(void) { } /*********************** * Called for the removal of each instance. */ static int mymod_vnet_uninit(const void *unused) { return (0) } mymod_modevent(module_t mod, int type, void *unused) { int err = 0; switch (type) { case MOD_LOAD: /* check that loading is ok */ break; case MOD_UNLOAD: /* check that unloading is ok */ break; case MOD_QUIESCE: /* warning: try stop processing */ /* maybe sleep 1 mSec or something to let threads get out */ break; case MOD_SHUTDOWN: /* * this is called once but you may want to shut down * things in each jail, or something global. * In that case it's up to us to simulate the SYSUNINIT() * or the VNET_SYSUNINIT() */ { VNET_ITERATOR_DECL(vnet_iter); VNET_LIST_RLOCK(); VNET_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); mymod_vnet_uninit(NULL); CURVNET_RESTORE(); } VNET_LIST_RUNLOCK(); } /* you may need to shutdown something global. */ mymod_uninit(); break; default: err = EOPNOTSUPP; break; } return err; } static moduledata_t mymodmod = { "mymod", mymod_modevent, 0 }; /* define execution order using constants from /sys/sys/kernel.h */ #define MYMOD_MAJOR_ORDER SI_SUB_PROTO_BEGIN /* for example */ #define MYMOD_MODULE_ORDER (SI_ORDER_ANY + 64) /* not fussy */ #define MYMOD_SYSINIT_ORDER (MYMOD_MODULE_ORDER + 1) /* a bit later */ #define MYMOD_VNET_ORDER (MYMOD_MODULE_ORDER + 2) /* later still */ DECLARE_MODULE(mymod, mymodmod, MYMOD_MAJOR_ORDER, MYMOD_MODULE_ORDER); MODULE_DEPEND(mymod, ipfw, 2, 2, 2); /* depend on ipfw version (exactly) 2 */ MODULE_VERSION(mymod, 1); SYSINIT(mymod_init, MYMOD_MAJOR_ORDER, MYMOD_SYSINIT_ORDER, mymod_init, NULL); SYSUNINIT(mymod_uninit, MYMOD_MAJOR_ORDER, MYMOD_SYSINIT_ORDER, mymod_uninit, NULL); VNET_SYSINIT(mymod_vnet_init, MYMOD_MAJOR_ORDER, MYMOD_VNET_ORDER, mymod_vnet_init, NULL); VNET_SYSUNINIT(mymod_vnet_uninit, MYMOD_MAJOR_ORDER, MYMOD_VNET_ORDER, mymod_vnet_uninit, NULL); ========== end sample code ======= On BOOT, the order of evaluation will be: In a NON-VIMAGE kernel where the module is compiled: MODEVENT, SYSINIT and VNET_SYSINIT both runm with order defined by their order declarations. {good foot shooting material if you get it wrong!} In a VIMAGE kernel where the module is compiled in: MODEVNET, SYSINIT and VNET_SYSINIT all run with order defined by their order declarations. AND in addition, the VNET_SYSINIT is repeated once for every existing or new jail/vnet. On loading a vnet enabled kernel module after boot: MODEVENT("event = load"); SYSINIT() VNET_SYSINIT() for every existing jail AND in addition, VNET_SYSINIT being called for each new jail created. On unloading of module: MODEVENT("event = MOD_QUIESCE") MODEVENT("event = MOD_UNLOAD") VNET_SYSUNINIT called for every jail/vnet SYSUNINIT On system shutdown: MODEVENT(shutdown) NOTICE that while the order of the SYSINIT and VNET_SYSINIT is reversed from that of SYSUNINIT and VNET_SYSUNINIT, MODEVENTS do not follow this rule and thus it is dangerous to initialise and uninitialise things which are order dependent using MODEVENTs. Or, put another way, Since MODEVENT is called first during module load, it would, by the assumption that everything is reversed, be easy to assume that MODEVENT is called AFTER the SYSINITS during unload. This is in fact not the case. (and I have the scars to prove it). It might be make some sense if the "QUIESCE" was called before the SYSINIT/SYSUNINIT and the UNLOAD called after.. with a millisecond sleep between them, but this is not the case either. Since initial values are copied into the virtualized variables on each new instantiatin, it is quite possible to have modules for which some of the above methods are not needed, and they may be left out. (but not the modevent). Sometimes there is a need to iterate through the vnets. See the modevent shutdown handler (above) for an example of how to do this. Don't forget the locks. In the case where you are loading a new protocol, or domain (protocol family) there are some "shortcuts" that are in place to allow you to maintain a bit more source compatibility with older revisions of FreeBSD. It must be added that the sample code above works just fine for protocols, however protcols also have an aditional initialization vector which is via the prtocol structure, which has a pr_init() entry. When a protocol is registered using pf_proto_register(), the pr_init() for the protocol is called once for every existing vnet. in addition, it will be called for each new vnet. The pr_destroy() method will be called as well on vnet teardown. The pf_proto_register() funcion can be called either from a modevent handler of from the SYSINIT() if you have one, and the pf_proto_unregister() called from the SYSUNINIT or the unload modevent handler. If you are adding a whole new protocol domain, (protocol family) then you should add the VNET_DOMAIN_SET(domainname) (e,g, inet, inet6) macro. These use VNET_SYSINIT internally to indirectly call the dom_init() and pr_init() functions for each vnet, (and the equivalent for teardown.) In this case one needs to be absolutely sure that both your domain and protocol initializers can be called multiple times, once for each vnet. One can still add SYSINITs for once only initialization, or use the modevent handler. I prefer to do as much explicitly in the SYSINITS and VNET_SYSINITS as then you have no surprises. finally: The command to make a new jail with a new vnet: jail -c host.hostname=test path=/ vnet command=/bin/tcsh jail -c host.hostname=test path=/ children.max=4 vnet command=/bin/tcsh (children.max allows hierarchical jail creation). Note that the command must come last. From manishv at lineratesystems.com Thu Aug 20 16:53:59 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Thu Aug 20 16:54:06 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <435336.24858.qm@web63908.mail.re1.yahoo.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> Message-ID: <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> Oh whoops, sorry didn't see that. So the plot thickens. Why don't these errors show up in the netstat output I forwarded originally? Ierrs was 0 but the dmesg output clearly shows missed packets. Any thoughts on what is going on? Looking at the code, missed_rx should certainly get counted in the ierrors field as you said. Is the Ierrs in the netstat output some other counter? If so, how do I get the if_ierrors variable from the command line? Manish On Thu, Aug 20, 2009 at 6:49 AM, Barney Cordoba wrote: > > > --- On Wed, 8/19/09, Manish Vachharajani wrote: > >> From: Manish Vachharajani >> Subject: Re: Dropped vs. missed packets in the ixgbe driver >> To: "Barney Cordoba" >> Cc: freebsd-net@freebsd.org >> Date: Wednesday, August 19, 2009, 2:46 PM >> Agreed, the errors are reported but >> missed packets are not.? The >> question is, is the correct fix to just add stats.mpc[0] to >> if_ierrors >> in that line or to add it to if_iqdrops.? The fix is >> easy once we >> agree on what the correct behavior is. >> >> Manish >> >> > Barney wrote: >> > >> > if you look in ixgbe_update_stats_counters at the >> bottom: >> > >> > ? ? ? ?ifp->if_ierrors = missed_rx + >> adapter->stats.crcerrs + >> > ? ? ? ? ? ? ? ?adapter->stats.rlec; >> > >> > the errors are added in. >> > >> > BC > > Huh? missed_rx are the missed packets. So they are counted. > > BC > > > > > -- Manish Vachharajani Founder LineRate Systems manishv@lineratesystems.com (609)635-9531 M From jfvogel at gmail.com Thu Aug 20 17:08:10 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Aug 20 17:08:17 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> Message-ID: <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> I've been looking at the code due to another problem of bogus flow control numbers, and there are some changes needed, things that should be 82599 vs 82598 and were not seperated properly. Will be forthcoming. Not sure if it has any relevance to this, but its possible. Jack On Thu, Aug 20, 2009 at 9:53 AM, Manish Vachharajani < manishv@lineratesystems.com> wrote: > Oh whoops, sorry didn't see that. So the plot thickens. Why don't > these errors show up in the netstat output I forwarded originally? > Ierrs was 0 but the dmesg output clearly shows missed packets. Any > thoughts on what is going on? Looking at the code, missed_rx should > certainly get counted in the ierrors field as you said. > > Is the Ierrs in the netstat output some other counter? If so, how do > I get the if_ierrors variable from the command line? > > Manish > > On Thu, Aug 20, 2009 at 6:49 AM, Barney Cordoba > wrote: > > > > > > --- On Wed, 8/19/09, Manish Vachharajani > wrote: > > > >> From: Manish Vachharajani > >> Subject: Re: Dropped vs. missed packets in the ixgbe driver > >> To: "Barney Cordoba" > >> Cc: freebsd-net@freebsd.org > >> Date: Wednesday, August 19, 2009, 2:46 PM > >> Agreed, the errors are reported but > >> missed packets are not. The > >> question is, is the correct fix to just add stats.mpc[0] to > >> if_ierrors > >> in that line or to add it to if_iqdrops. The fix is > >> easy once we > >> agree on what the correct behavior is. > >> > >> Manish > >> > >> > Barney wrote: > >> > > >> > if you look in ixgbe_update_stats_counters at the > >> bottom: > >> > > >> > ifp->if_ierrors = missed_rx + > >> adapter->stats.crcerrs + > >> > adapter->stats.rlec; > >> > > >> > the errors are added in. > >> > > >> > BC > > > > Huh? missed_rx are the missed packets. So they are counted. > > > > BC > > > > > > > > > > > > > > -- > Manish Vachharajani > Founder > LineRate Systems > manishv@lineratesystems.com > (609)635-9531 M > _______________________________________________ > 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 manishv at lineratesystems.com Thu Aug 20 17:23:16 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Thu Aug 20 17:23:22 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> Message-ID: <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> I noticed the bogus XON, XOFF numbers. I'm glad to see it will be fixed so I can cross it off my todo list. :) I don't think the issue is related though, but you never know. Barney pointed out that missed_rx in the ixgbe_update_stats_counters function accumulates the missed packet registers into the missed_rx field. At the end of the function, these are summed into ifp->if_ierrors which should be reported under Ierrs by netstat -idh. However that count is zero as reported via netstat. The stats printfs activated via sysctl dev.ix.#.stats=1 prints stats.mpc[0]. This number is large (around 400k on the machine I've been using to find the problem). If you look at the code, missed_rx and mpc[i] are updated with the same variables. Given that missed_rx is unsigned, I don't understand how the number fails to make it into ifp->if_ierrors, but I have yet to dive into debugging this seriously. Initially, I thought the fix was simple since I didn't see the missed_rx getting added to ierrors. But now, I am not sure where the problem is. Hopefully, it will be more obvious to you than it is to me. I'm sure it is something simple that I am missing. Manish On Thu, Aug 20, 2009 at 11:08 AM, Jack Vogel wrote: > I've been looking at the code due to another problem of bogus flow control > numbers, and there are some changes needed, things that should be 82599 vs > 82598 and were not seperated properly. Will be forthcoming. Not sure if it > has any relevance to this, but its possible. > > Jack > > > On Thu, Aug 20, 2009 at 9:53 AM, Manish Vachharajani > wrote: >> >> Oh whoops, sorry didn't see that. ?So the plot thickens. ?Why don't >> these errors show up in the netstat output I forwarded originally? >> Ierrs was 0 but the dmesg output clearly shows missed packets. ?Any >> thoughts on what is going on? ?Looking at the code, missed_rx should >> certainly get counted in the ierrors field as you said. >> >> Is the Ierrs in the netstat output some other counter? ?If so, how do >> I get the if_ierrors variable from the command line? >> >> Manish >> >> On Thu, Aug 20, 2009 at 6:49 AM, Barney Cordoba >> wrote: >> > >> > >> > --- On Wed, 8/19/09, Manish Vachharajani >> > wrote: >> > >> >> From: Manish Vachharajani >> >> Subject: Re: Dropped vs. missed packets in the ixgbe driver >> >> To: "Barney Cordoba" >> >> Cc: freebsd-net@freebsd.org >> >> Date: Wednesday, August 19, 2009, 2:46 PM >> >> Agreed, the errors are reported but >> >> missed packets are not.? The >> >> question is, is the correct fix to just add stats.mpc[0] to >> >> if_ierrors >> >> in that line or to add it to if_iqdrops.? The fix is >> >> easy once we >> >> agree on what the correct behavior is. >> >> >> >> Manish >> >> >> >> > Barney wrote: >> >> > >> >> > if you look in ixgbe_update_stats_counters at the >> >> bottom: >> >> > >> >> > ? ? ? ?ifp->if_ierrors = missed_rx + >> >> adapter->stats.crcerrs + >> >> > ? ? ? ? ? ? ? ?adapter->stats.rlec; >> >> > >> >> > the errors are added in. >> >> > >> >> > BC >> > >> > Huh? missed_rx are the missed packets. So they are counted. >> > >> > BC >> > >> > >> > >> > >> > >> >> >> >> -- >> Manish Vachharajani >> _______________________________________________ >> 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" > > -- Manish Vachharajani From manishv at lineratesystems.com Thu Aug 20 17:32:30 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Thu Aug 20 17:32:38 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> Message-ID: <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> My co-founder, John, just pointed out the problem. The MPC register on ixgbe is clear on read. stats.mpc[i] correctly accumulates the misses, but missed_rx gets set to 0 on any interval where there are no misses and subsequently, if_errors gets set to 0 (assuming no crcerrs or rlecs.) I believe the correct fix is in the patch below: diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c index f1fa728..9cbaec6 100644 --- a/fbsd/ixgbe-1.7.4/ixgbe.c +++ b/fbsd/ixgbe-1.7.4/ixgbe.c @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) { struct ifnet *ifp = adapter->ifp;; struct ixgbe_hw *hw = &adapter->hw; - u32 missed_rx = 0, bprc, lxon, lxoff, total; + u32 missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); missed_rx += mp; adapter->stats.mpc[i] += mp; + missed_rx_cum += adapter->stats.mpc[i]; adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); } (Note that it may not apply since I've pulled the driver out into a separate directory structure) We need the missed_rx_cum that is the total number of rx misses seen because missed_rx is decremented from gprc to work around a hardware issue and so needs to be the misses seen on this call to the function. Manish On Thu, Aug 20, 2009 at 11:23 AM, Manish Vachharajani wrote: > I noticed the bogus XON, XOFF numbers. ?I'm glad to see it will be > fixed so I can cross it off my todo list. ?:) ?I don't think the issue > is related though, but you never know. > > Barney pointed out that missed_rx in the ixgbe_update_stats_counters > function accumulates the missed packet registers into the missed_rx > field. ?At the end of the function, these are summed into > ifp->if_ierrors which should be reported under Ierrs by netstat -idh. > However that count is zero as reported via netstat. ?The stats printfs > activated via sysctl dev.ix.#.stats=1 prints stats.mpc[0]. ?This > number is large (around 400k on the machine I've been using to find > the problem). ?If you look at the code, missed_rx and mpc[i] are > updated with the same variables. ?Given that missed_rx is unsigned, I > don't understand how the number fails to make it into ifp->if_ierrors, > but I have yet to dive into debugging this seriously. > > Initially, I thought the fix was simple since I didn't see the > missed_rx getting added to ierrors. ?But now, I am not sure where the > problem is. ?Hopefully, it will be more obvious to you than it is to > me. ?I'm sure it is something simple that I am missing. > > Manish > > On Thu, Aug 20, 2009 at 11:08 AM, Jack Vogel wrote: >> I've been looking at the code due to another problem of bogus flow control >> numbers, and there are some changes needed, things that should be 82599 vs >> 82598 and were not seperated properly. Will be forthcoming. Not sure if it >> has any relevance to this, but its possible. >> >> Jack >> >> >> On Thu, Aug 20, 2009 at 9:53 AM, Manish Vachharajani >> wrote: >>> >>> Oh whoops, sorry didn't see that. ?So the plot thickens. ?Why don't >>> these errors show up in the netstat output I forwarded originally? >>> Ierrs was 0 but the dmesg output clearly shows missed packets. ?Any >>> thoughts on what is going on? ?Looking at the code, missed_rx should >>> certainly get counted in the ierrors field as you said. >>> >>> Is the Ierrs in the netstat output some other counter? ?If so, how do >>> I get the if_ierrors variable from the command line? >>> >>> Manish >>> >>> On Thu, Aug 20, 2009 at 6:49 AM, Barney Cordoba >>> wrote: >>> > >>> > >>> > --- On Wed, 8/19/09, Manish Vachharajani >>> > wrote: >>> > >>> >> From: Manish Vachharajani >>> >> Subject: Re: Dropped vs. missed packets in the ixgbe driver >>> >> To: "Barney Cordoba" >>> >> Cc: freebsd-net@freebsd.org >>> >> Date: Wednesday, August 19, 2009, 2:46 PM >>> >> Agreed, the errors are reported but >>> >> missed packets are not.? The >>> >> question is, is the correct fix to just add stats.mpc[0] to >>> >> if_ierrors >>> >> in that line or to add it to if_iqdrops.? The fix is >>> >> easy once we >>> >> agree on what the correct behavior is. >>> >> >>> >> Manish >>> >> >>> >> > Barney wrote: >>> >> > >>> >> > if you look in ixgbe_update_stats_counters at the >>> >> bottom: >>> >> > >>> >> > ? ? ? ?ifp->if_ierrors = missed_rx + >>> >> adapter->stats.crcerrs + >>> >> > ? ? ? ? ? ? ? ?adapter->stats.rlec; >>> >> > >>> >> > the errors are added in. >>> >> > >>> >> > BC >>> > >>> > Huh? missed_rx are the missed packets. So they are counted. >>> > >>> > BC >>> > >>> > >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Manish Vachharajani > >>> _______________________________________________ >>> 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" >> >> > > -- > Manish Vachharajani > From manishv at lineratesystems.com Thu Aug 20 17:34:13 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Thu Aug 20 17:34:21 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> Message-ID: <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> Whoops, the correct fix is below. Forgot to use missed_rx_cum when summing: diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c index f1fa728..262d64d 100644 --- a/fbsd/ixgbe-1.7.4/ixgbe.c +++ b/fbsd/ixgbe-1.7.4/ixgbe.c @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) { struct ifnet *ifp = adapter->ifp;; struct ixgbe_hw *hw = &adapter->hw; - u32 missed_rx = 0, bprc, lxon, lxoff, total; + u32 missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); missed_rx += mp; adapter->stats.mpc[i] += mp; + missed_rx_cum += adapter->stats.mpc[i]; adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); } @@ -4370,7 +4371,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) ifp->if_collisions = 0; /* Rx Errors */ - ifp->if_ierrors = missed_rx + adapter->stats.crcerrs + + ifp->if_ierrors = missed_rx_cum + adapter->stats.crcerrs + adapter->stats.rlec; } On Thu, Aug 20, 2009 at 11:32 AM, Manish Vachharajani wrote: > My co-founder, John, just pointed out the problem. > > The MPC register on ixgbe is clear on read. ?stats.mpc[i] correctly > accumulates the misses, but missed_rx gets set to 0 on any interval > where there are no misses and subsequently, if_errors gets set to 0 > (assuming no crcerrs or rlecs.) ?I believe the correct fix is in the > patch below: > > diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c > index f1fa728..9cbaec6 100644 > --- a/fbsd/ixgbe-1.7.4/ixgbe.c > +++ b/fbsd/ixgbe-1.7.4/ixgbe.c > @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) > ?{ > ? ? ? ?struct ifnet ? *ifp = adapter->ifp;; > ? ? ? ?struct ixgbe_hw *hw = &adapter->hw; > - ? ? ? u32 ?missed_rx = 0, bprc, lxon, lxoff, total; > + ? ? ? u32 ?missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; > > ? ? ? ?adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); > > @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) > ? ? ? ? ? ? ? ?mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); > ? ? ? ? ? ? ? ?missed_rx += mp; > ? ? ? ? ? ? ? ?adapter->stats.mpc[i] += mp; > + ? ? ? ? ? ? ? missed_rx_cum += adapter->stats.mpc[i]; > ? ? ? ? ? ? ? ?adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); > ? ? ? ?} > > (Note that it may not apply since I've pulled the driver out into a > separate directory structure) > > We need the missed_rx_cum that is the total number of rx misses seen > because missed_rx is decremented from gprc to work around a hardware > issue and so needs to be the misses seen on this call to the function. > > Manish > > > On Thu, Aug 20, 2009 at 11:23 AM, Manish > Vachharajani wrote: >> I noticed the bogus XON, XOFF numbers. ?I'm glad to see it will be >> fixed so I can cross it off my todo list. ?:) ?I don't think the issue >> is related though, but you never know. >> >> Barney pointed out that missed_rx in the ixgbe_update_stats_counters >> function accumulates the missed packet registers into the missed_rx >> field. ?At the end of the function, these are summed into >> ifp->if_ierrors which should be reported under Ierrs by netstat -idh. >> However that count is zero as reported via netstat. ?The stats printfs >> activated via sysctl dev.ix.#.stats=1 prints stats.mpc[0]. ?This >> number is large (around 400k on the machine I've been using to find >> the problem). ?If you look at the code, missed_rx and mpc[i] are >> updated with the same variables. ?Given that missed_rx is unsigned, I >> don't understand how the number fails to make it into ifp->if_ierrors, >> but I have yet to dive into debugging this seriously. >> >> Initially, I thought the fix was simple since I didn't see the >> missed_rx getting added to ierrors. ?But now, I am not sure where the >> problem is. ?Hopefully, it will be more obvious to you than it is to >> me. ?I'm sure it is something simple that I am missing. >> >> Manish >> >> On Thu, Aug 20, 2009 at 11:08 AM, Jack Vogel wrote: >>> I've been looking at the code due to another problem of bogus flow control >>> numbers, and there are some changes needed, things that should be 82599 vs >>> 82598 and were not seperated properly. Will be forthcoming. Not sure if it >>> has any relevance to this, but its possible. >>> >>> Jack >>> >>> >>> On Thu, Aug 20, 2009 at 9:53 AM, Manish Vachharajani >>> wrote: >>>> >>>> Oh whoops, sorry didn't see that. ?So the plot thickens. ?Why don't >>>> these errors show up in the netstat output I forwarded originally? >>>> Ierrs was 0 but the dmesg output clearly shows missed packets. ?Any >>>> thoughts on what is going on? ?Looking at the code, missed_rx should >>>> certainly get counted in the ierrors field as you said. >>>> >>>> Is the Ierrs in the netstat output some other counter? ?If so, how do >>>> I get the if_ierrors variable from the command line? >>>> >>>> Manish >>>> >>>> On Thu, Aug 20, 2009 at 6:49 AM, Barney Cordoba >>>> wrote: >>>> > >>>> > >>>> > --- On Wed, 8/19/09, Manish Vachharajani >>>> > wrote: >>>> > >>>> >> From: Manish Vachharajani >>>> >> Subject: Re: Dropped vs. missed packets in the ixgbe driver >>>> >> To: "Barney Cordoba" >>>> >> Cc: freebsd-net@freebsd.org >>>> >> Date: Wednesday, August 19, 2009, 2:46 PM >>>> >> Agreed, the errors are reported but >>>> >> missed packets are not.? The >>>> >> question is, is the correct fix to just add stats.mpc[0] to >>>> >> if_ierrors >>>> >> in that line or to add it to if_iqdrops.? The fix is >>>> >> easy once we >>>> >> agree on what the correct behavior is. >>>> >> >>>> >> Manish >>>> >> >>>> >> > Barney wrote: >>>> >> > >>>> >> > if you look in ixgbe_update_stats_counters at the >>>> >> bottom: >>>> >> > >>>> >> > ? ? ? ?ifp->if_ierrors = missed_rx + >>>> >> adapter->stats.crcerrs + >>>> >> > ? ? ? ? ? ? ? ?adapter->stats.rlec; >>>> >> > >>>> >> > the errors are added in. >>>> >> > >>>> >> > BC >>>> > >>>> > Huh? missed_rx are the missed packets. So they are counted. >>>> > >>>> > BC >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Manish Vachharajani >> >>>> _______________________________________________ >>>> 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" >>> >>> >> >> -- >> Manish Vachharajani >> > -- Manish Vachharajani Founder LineRate Systems manishv@lineratesystems.com (609)635-9531 M From jfvogel at gmail.com Thu Aug 20 17:37:24 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Aug 20 17:37:30 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> Message-ID: <2a41acea0908201037n10505b04le924f29efd5398a7@mail.gmail.com> Thanks Manish, I will keep this diff around and work it into my final changes in the code, you confirmed this solved the problem you were seeing I assume? Cheers, Jack On Thu, Aug 20, 2009 at 10:34 AM, Manish Vachharajani < manishv@lineratesystems.com> wrote: > Whoops, the correct fix is below. Forgot to use missed_rx_cum when > summing: > > diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c > index f1fa728..262d64d 100644 > --- a/fbsd/ixgbe-1.7.4/ixgbe.c > +++ b/fbsd/ixgbe-1.7.4/ixgbe.c > @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) > { > struct ifnet *ifp = adapter->ifp;; > struct ixgbe_hw *hw = &adapter->hw; > - u32 missed_rx = 0, bprc, lxon, lxoff, total; > + u32 missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; > > adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); > > @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) > mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); > missed_rx += mp; > adapter->stats.mpc[i] += mp; > + missed_rx_cum += adapter->stats.mpc[i]; > adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); > } > > @@ -4370,7 +4371,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) > ifp->if_collisions = 0; > > /* Rx Errors */ > - ifp->if_ierrors = missed_rx + adapter->stats.crcerrs + > + ifp->if_ierrors = missed_rx_cum + adapter->stats.crcerrs + > adapter->stats.rlec; > } > > > > On Thu, Aug 20, 2009 at 11:32 AM, Manish > Vachharajani wrote: > > My co-founder, John, just pointed out the problem. > > > > The MPC register on ixgbe is clear on read. stats.mpc[i] correctly > > accumulates the misses, but missed_rx gets set to 0 on any interval > > where there are no misses and subsequently, if_errors gets set to 0 > > (assuming no crcerrs or rlecs.) I believe the correct fix is in the > > patch below: > > > > diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c > > index f1fa728..9cbaec6 100644 > > --- a/fbsd/ixgbe-1.7.4/ixgbe.c > > +++ b/fbsd/ixgbe-1.7.4/ixgbe.c > > @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter > *adapter) > > { > > struct ifnet *ifp = adapter->ifp;; > > struct ixgbe_hw *hw = &adapter->hw; > > - u32 missed_rx = 0, bprc, lxon, lxoff, total; > > + u32 missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; > > > > adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); > > > > @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter > *adapter) > > mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); > > missed_rx += mp; > > adapter->stats.mpc[i] += mp; > > + missed_rx_cum += adapter->stats.mpc[i]; > > adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, > IXGBE_RNBC(i)); > > } > > > > (Note that it may not apply since I've pulled the driver out into a > > separate directory structure) > > > > We need the missed_rx_cum that is the total number of rx misses seen > > because missed_rx is decremented from gprc to work around a hardware > > issue and so needs to be the misses seen on this call to the function. > > > > Manish > > > > > > On Thu, Aug 20, 2009 at 11:23 AM, Manish > > Vachharajani wrote: > >> I noticed the bogus XON, XOFF numbers. I'm glad to see it will be > >> fixed so I can cross it off my todo list. :) I don't think the issue > >> is related though, but you never know. > >> > >> Barney pointed out that missed_rx in the ixgbe_update_stats_counters > >> function accumulates the missed packet registers into the missed_rx > >> field. At the end of the function, these are summed into > >> ifp->if_ierrors which should be reported under Ierrs by netstat -idh. > >> However that count is zero as reported via netstat. The stats printfs > >> activated via sysctl dev.ix.#.stats=1 prints stats.mpc[0]. This > >> number is large (around 400k on the machine I've been using to find > >> the problem). If you look at the code, missed_rx and mpc[i] are > >> updated with the same variables. Given that missed_rx is unsigned, I > >> don't understand how the number fails to make it into ifp->if_ierrors, > >> but I have yet to dive into debugging this seriously. > >> > >> Initially, I thought the fix was simple since I didn't see the > >> missed_rx getting added to ierrors. But now, I am not sure where the > >> problem is. Hopefully, it will be more obvious to you than it is to > >> me. I'm sure it is something simple that I am missing. > >> > >> Manish > >> > >> On Thu, Aug 20, 2009 at 11:08 AM, Jack Vogel wrote: > >>> I've been looking at the code due to another problem of bogus flow > control > >>> numbers, and there are some changes needed, things that should be 82599 > vs > >>> 82598 and were not seperated properly. Will be forthcoming. Not sure if > it > >>> has any relevance to this, but its possible. > >>> > >>> Jack > >>> > >>> > >>> On Thu, Aug 20, 2009 at 9:53 AM, Manish Vachharajani > >>> wrote: > >>>> > >>>> Oh whoops, sorry didn't see that. So the plot thickens. Why don't > >>>> these errors show up in the netstat output I forwarded originally? > >>>> Ierrs was 0 but the dmesg output clearly shows missed packets. Any > >>>> thoughts on what is going on? Looking at the code, missed_rx should > >>>> certainly get counted in the ierrors field as you said. > >>>> > >>>> Is the Ierrs in the netstat output some other counter? If so, how do > >>>> I get the if_ierrors variable from the command line? > >>>> > >>>> Manish > >>>> > >>>> On Thu, Aug 20, 2009 at 6:49 AM, Barney Cordoba< > barney_cordoba@yahoo.com> > >>>> wrote: > >>>> > > >>>> > > >>>> > --- On Wed, 8/19/09, Manish Vachharajani < > manishv@lineratesystems.com> > >>>> > wrote: > >>>> > > >>>> >> From: Manish Vachharajani > >>>> >> Subject: Re: Dropped vs. missed packets in the ixgbe driver > >>>> >> To: "Barney Cordoba" > >>>> >> Cc: freebsd-net@freebsd.org > >>>> >> Date: Wednesday, August 19, 2009, 2:46 PM > >>>> >> Agreed, the errors are reported but > >>>> >> missed packets are not. The > >>>> >> question is, is the correct fix to just add stats.mpc[0] to > >>>> >> if_ierrors > >>>> >> in that line or to add it to if_iqdrops. The fix is > >>>> >> easy once we > >>>> >> agree on what the correct behavior is. > >>>> >> > >>>> >> Manish > >>>> >> > >>>> >> > Barney wrote: > >>>> >> > > >>>> >> > if you look in ixgbe_update_stats_counters at the > >>>> >> bottom: > >>>> >> > > >>>> >> > ifp->if_ierrors = missed_rx + > >>>> >> adapter->stats.crcerrs + > >>>> >> > adapter->stats.rlec; > >>>> >> > > >>>> >> > the errors are added in. > >>>> >> > > >>>> >> > BC > >>>> > > >>>> > Huh? missed_rx are the missed packets. So they are counted. > >>>> > > >>>> > BC > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Manish Vachharajani > >> > >>>> _______________________________________________ > >>>> 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 > " > >>> > >>> > >> > >> -- > >> Manish Vachharajani > >> > > > > > > -- > Manish Vachharajani > Founder > LineRate Systems > manishv@lineratesystems.com > (609)635-9531 M > From manishv at lineratesystems.com Thu Aug 20 17:39:01 2009 From: manishv at lineratesystems.com (Manish Vachharajani) Date: Thu Aug 20 17:39:08 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <2a41acea0908201037n10505b04le924f29efd5398a7@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> <2a41acea0908201037n10505b04le924f29efd5398a7@mail.gmail.com> Message-ID: <5bc218350908201039q574f92e3mabe73d01c35f662c@mail.gmail.com> Yes, in our latest tests, netstat correctly outputs the misses as Ierrs. Manish On Thu, Aug 20, 2009 at 11:37 AM, Jack Vogel wrote: > Thanks Manish, I will keep this diff around and work it into my final > changes in the > code, you confirmed this solved the problem you were seeing I assume? > > Cheers, > > Jack > > > On Thu, Aug 20, 2009 at 10:34 AM, Manish Vachharajani > wrote: >> >> Whoops, the correct fix is below. ?Forgot to use missed_rx_cum when >> summing: >> >> diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c >> index f1fa728..262d64d 100644 >> --- a/fbsd/ixgbe-1.7.4/ixgbe.c >> +++ b/fbsd/ixgbe-1.7.4/ixgbe.c >> @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) >> ?{ >> ? ? ? ?struct ifnet ? *ifp = adapter->ifp;; >> ? ? ? ?struct ixgbe_hw *hw = &adapter->hw; >> - ? ? ? u32 ?missed_rx = 0, bprc, lxon, lxoff, total; >> + ? ? ? u32 ?missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; >> >> ? ? ? ?adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); >> >> @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) >> ? ? ? ? ? ? ? ?mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); >> ? ? ? ? ? ? ? ?missed_rx += mp; >> ? ? ? ? ? ? ? ?adapter->stats.mpc[i] += mp; >> + ? ? ? ? ? ? ? missed_rx_cum += adapter->stats.mpc[i]; >> ? ? ? ? ? ? ? ?adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, >> IXGBE_RNBC(i)); >> ? ? ? ?} >> >> @@ -4370,7 +4371,7 @@ ixgbe_update_stats_counters(struct adapter *adapter) >> ? ? ? ?ifp->if_collisions = 0; >> >> ? ? ? ?/* Rx Errors */ >> - ? ? ? ifp->if_ierrors = missed_rx + adapter->stats.crcerrs + >> + ? ? ? ifp->if_ierrors = missed_rx_cum + adapter->stats.crcerrs + >> ? ? ? ? ? ? ? ?adapter->stats.rlec; >> ?} >> >> >> >> On Thu, Aug 20, 2009 at 11:32 AM, Manish >> Vachharajani wrote: >> > My co-founder, John, just pointed out the problem. >> > >> > The MPC register on ixgbe is clear on read. ?stats.mpc[i] correctly >> > accumulates the misses, but missed_rx gets set to 0 on any interval >> > where there are no misses and subsequently, if_errors gets set to 0 >> > (assuming no crcerrs or rlecs.) ?I believe the correct fix is in the >> > patch below: >> > >> > diff --git a/fbsd/ixgbe-1.7.4/ixgbe.c b/fbsd/ixgbe-1.7.4/ixgbe.c >> > index f1fa728..9cbaec6 100644 >> > --- a/fbsd/ixgbe-1.7.4/ixgbe.c >> > +++ b/fbsd/ixgbe-1.7.4/ixgbe.c >> > @@ -4294,7 +4294,7 @@ ixgbe_update_stats_counters(struct adapter >> > *adapter) >> > ?{ >> > ? ? ? ?struct ifnet ? *ifp = adapter->ifp;; >> > ? ? ? ?struct ixgbe_hw *hw = &adapter->hw; >> > - ? ? ? u32 ?missed_rx = 0, bprc, lxon, lxoff, total; >> > + ? ? ? u32 ?missed_rx = 0, missed_rx_cum = 0, bprc, lxon, lxoff, total; >> > >> > ? ? ? ?adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); >> > >> > @@ -4303,6 +4303,7 @@ ixgbe_update_stats_counters(struct adapter >> > *adapter) >> > ? ? ? ? ? ? ? ?mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); >> > ? ? ? ? ? ? ? ?missed_rx += mp; >> > ? ? ? ? ? ? ? ?adapter->stats.mpc[i] += mp; >> > + ? ? ? ? ? ? ? missed_rx_cum += adapter->stats.mpc[i]; >> > ? ? ? ? ? ? ? ?adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, >> > IXGBE_RNBC(i)); >> > ? ? ? ?} >> > >> > (Note that it may not apply since I've pulled the driver out into a >> > separate directory structure) >> > >> > We need the missed_rx_cum that is the total number of rx misses seen >> > because missed_rx is decremented from gprc to work around a hardware >> > issue and so needs to be the misses seen on this call to the function. >> > >> > Manish >> > >> > >> > On Thu, Aug 20, 2009 at 11:23 AM, Manish >> > Vachharajani wrote: >> >> I noticed the bogus XON, XOFF numbers. ?I'm glad to see it will be >> >> fixed so I can cross it off my todo list. ?:) ?I don't think the issue >> >> is related though, but you never know. >> >> >> >> Barney pointed out that missed_rx in the ixgbe_update_stats_counters >> >> function accumulates the missed packet registers into the missed_rx >> >> field. ?At the end of the function, these are summed into >> >> ifp->if_ierrors which should be reported under Ierrs by netstat -idh. >> >> However that count is zero as reported via netstat. ?The stats printfs >> >> activated via sysctl dev.ix.#.stats=1 prints stats.mpc[0]. ?This >> >> number is large (around 400k on the machine I've been using to find >> >> the problem). ?If you look at the code, missed_rx and mpc[i] are >> >> updated with the same variables. ?Given that missed_rx is unsigned, I >> >> don't understand how the number fails to make it into ifp->if_ierrors, >> >> but I have yet to dive into debugging this seriously. >> >> >> >> Initially, I thought the fix was simple since I didn't see the >> >> missed_rx getting added to ierrors. ?But now, I am not sure where the >> >> problem is. ?Hopefully, it will be more obvious to you than it is to >> >> me. ?I'm sure it is something simple that I am missing. >> >> >> >> Manish >> >> >> >> On Thu, Aug 20, 2009 at 11:08 AM, Jack Vogel wrote: >> >>> I've been looking at the code due to another problem of bogus flow >> >>> control >> >>> numbers, and there are some changes needed, things that should be >> >>> 82599 vs >> >>> 82598 and were not seperated properly. Will be forthcoming. Not sure >> >>> if it >> >>> has any relevance to this, but its possible. >> >>> >> >>> Jack >> >>> >> >>> >> >>> On Thu, Aug 20, 2009 at 9:53 AM, Manish Vachharajani >> >>> wrote: >> >>>> >> >>>> Oh whoops, sorry didn't see that. ?So the plot thickens. ?Why don't >> >>>> these errors show up in the netstat output I forwarded originally? >> >>>> Ierrs was 0 but the dmesg output clearly shows missed packets. ?Any >> >>>> thoughts on what is going on? ?Looking at the code, missed_rx should >> >>>> certainly get counted in the ierrors field as you said. >> >>>> >> >>>> Is the Ierrs in the netstat output some other counter? ?If so, how do >> >>>> I get the if_ierrors variable from the command line? >> >>>> >> >>>> Manish >> >>>> >> >>>> On Thu, Aug 20, 2009 at 6:49 AM, Barney >> >>>> Cordoba >> >>>> wrote: >> >>>> > >> >>>> > >> >>>> > --- On Wed, 8/19/09, Manish Vachharajani >> >>>> > >> >>>> > wrote: >> >>>> > >> >>>> >> From: Manish Vachharajani >> >>>> >> Subject: Re: Dropped vs. missed packets in the ixgbe driver >> >>>> >> To: "Barney Cordoba" >> >>>> >> Cc: freebsd-net@freebsd.org >> >>>> >> Date: Wednesday, August 19, 2009, 2:46 PM >> >>>> >> Agreed, the errors are reported but >> >>>> >> missed packets are not.? The >> >>>> >> question is, is the correct fix to just add stats.mpc[0] to >> >>>> >> if_ierrors >> >>>> >> in that line or to add it to if_iqdrops.? The fix is >> >>>> >> easy once we >> >>>> >> agree on what the correct behavior is. >> >>>> >> >> >>>> >> Manish >> >>>> >> >> >>>> >> > Barney wrote: >> >>>> >> > >> >>>> >> > if you look in ixgbe_update_stats_counters at the >> >>>> >> bottom: >> >>>> >> > >> >>>> >> > ? ? ? ?ifp->if_ierrors = missed_rx + >> >>>> >> adapter->stats.crcerrs + >> >>>> >> > ? ? ? ? ? ? ? ?adapter->stats.rlec; >> >>>> >> > >> >>>> >> > the errors are added in. >> >>>> >> > >> >>>> >> > BC >> >>>> > >> >>>> > Huh? missed_rx are the missed packets. So they are counted. >> >>>> > >> >>>> > BC >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Manish Vachharajani >> >> >> >>>> _______________________________________________ >> >>>> 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" >> >>> >> >>> >> >> >> >> -- >> >> Manish Vachharajani >> >> >> > >> >> >> >> -- >> Manish Vachharajani >> Founder >> LineRate Systems >> manishv@lineratesystems.com >> (609)635-9531 M > > -- Manish Vachharajani Founder LineRate Systems manishv@lineratesystems.com (609)635-9531 M From stef-list at memberwebs.com Fri Aug 21 00:10:17 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Fri Aug 21 00:10:23 2009 Subject: ath0: ath_rx_proc: no mbuf! References: <20090820042016.C8F913039754@mx.npubs.com> <1038963609.20090820091230@serebryakov.spb.ru> Message-ID: <20090821001014.B45D5303970C@mx.npubs.com> Lev Serebryakov wrote: > Hello, Stef. > >> ath0: ath_rx_proc: no mbuf! > >> The mbufs are in fact all used up. I allocate more via >> kern.ipc.nmbclusters, and see the same behavior. > Same problem here on 7.2-STABLE, but incresaing kern.ipc.nmbclusters > to 65536 helps. It seems, that when traffic is reauuly huge, system > with ath need a lot of mbufs. At night, when traffic is almost zero, > netstat -m shows a lot of free mbufs and clusters, so it seems, that > there is no mbuf leaks. Thanks for responding. I'll try tweaking some more. Sadly this is an 'embedded' style box that has 64 MB of RAM. According to tuning(7) Having 65536 mbuf clusters would use up 128 MB of RAM :( Cheers, Stef From jfvogel at gmail.com Fri Aug 21 00:21:36 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Aug 21 00:21:41 2009 Subject: Dropped vs. missed packets in the ixgbe driver In-Reply-To: <5bc218350908201039q574f92e3mabe73d01c35f662c@mail.gmail.com> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> <2a41acea0908201037n10505b04le924f29efd5398a7@mail.gmail.com> <5bc218350908201039q574f92e3mabe73d01c35f662c@mail.gmail.com> Message-ID: <2a41acea0908201721o33372c89q25e33b8cde8edf06@mail.gmail.com> Manish, This is a diff on my changes, note some differences: first, I don't know what vintage your code was, but you do NOT want to read RNBC(i) into stats.mpc. also that is an 82598-only thing. This means that missed_rx is going to accumulate just as it should, except it should be 64 bit. This diff also contains a fix to the flow control stats on 82598, there were differences between that and 82599 that somehow got stripped from my code along the way, this corrects that. Try these changes and let me know if it works for you. Jack Index: ixgbe.c =================================================================== --- ixgbe.c (revision 195857) +++ ixgbe.c (working copy) @@ -4456,7 +4456,8 @@ { struct ifnet *ifp = adapter->ifp;; struct ixgbe_hw *hw = &adapter->hw; - u32 missed_rx = 0, bprc, lxon, lxoff, total; + u32 bprc, lxon, lxoff, total; + u64 missed_rx = 0; adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); @@ -4465,16 +4466,31 @@ mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); missed_rx += mp; adapter->stats.mpc[i] += mp; - adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); + if (hw->mac.type == ixgbe_mac_82598EB) + adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); } /* Hardware workaround, gprc counts missed packets */ adapter->stats.gprc += IXGBE_READ_REG(hw, IXGBE_GPRC); adapter->stats.gprc -= missed_rx; - adapter->stats.gorc += IXGBE_READ_REG(hw, IXGBE_GORCH); - adapter->stats.gotc += IXGBE_READ_REG(hw, IXGBE_GOTCH); - adapter->stats.tor += IXGBE_READ_REG(hw, IXGBE_TORH); + if (hw->mac.type == ixgbe_mac_82599EB) { + adapter->stats.gorc += IXGBE_READ_REG(hw, IXGBE_GORCL); + IXGBE_READ_REG(hw, IXGBE_GORCH); /* clears register */ + adapter->stats.gotc += IXGBE_READ_REG(hw, IXGBE_GOTCL); + IXGBE_READ_REG(hw, IXGBE_GOTCH); /* clears register */ + adapter->stats.tor += IXGBE_READ_REG(hw, IXGBE_TORL); + IXGBE_READ_REG(hw, IXGBE_TORH); /* clears register */ + adapter->stats.lxonrxc += IXGBE_READ_REG(hw, IXGBE_LXONRXCNT); + adapter->stats.lxoffrxc += IXGBE_READ_REG(hw, IXGBE_LXOFFRXCNT); + } else { + adapter->stats.lxonrxc += IXGBE_READ_REG(hw, IXGBE_LXONRXC); + adapter->stats.lxoffrxc += IXGBE_READ_REG(hw, IXGBE_LXOFFRXC); + /* 82598 only has a counter in the high register */ + adapter->stats.gorc += IXGBE_READ_REG(hw, IXGBE_GORCH); + adapter->stats.gorc += IXGBE_READ_REG(hw, IXGBE_GOTCH); + adapter->stats.tor += IXGBE_READ_REG(hw, IXGBE_TORH); + } /* * Workaround: mprc hardware is incorrectly counting @@ -4494,9 +4510,6 @@ adapter->stats.prc1522 += IXGBE_READ_REG(hw, IXGBE_PRC1522); adapter->stats.rlec += IXGBE_READ_REG(hw, IXGBE_RLEC); - adapter->stats.lxonrxc += IXGBE_READ_REG(hw, IXGBE_LXONRXCNT); - adapter->stats.lxoffrxc += IXGBE_READ_REG(hw, IXGBE_LXOFFRXCNT); - lxon = IXGBE_READ_REG(hw, IXGBE_LXONTXC); adapter->stats.lxontxc += lxon; lxoff = IXGBE_READ_REG(hw, IXGBE_LXOFFTXC); From julian at elischer.org Fri Aug 21 12:16:32 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 21 12:16:39 2009 Subject: pf and vimage In-Reply-To: <1321ED43-81C5-4507-AFC0-4B2DEE71BB78@netasq.com> References: <4A8CFDAF.1000309@delphij.net> <200908201108.39177.max@love2party.net> <4A8D76FE.7040302@elischer.org> <1321ED43-81C5-4507-AFC0-4B2DEE71BB78@netasq.com> Message-ID: <4A8E901F.6080903@elischer.org> Fabien Thomas wrote: > Thanks very useful! > Do you have an "official" page to look for update. you can always find teh latest here: http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/vimage named "porting_to_vimage.txt" > What do you think of putting it on the FreeBSD Wiki? > > Fabien > I plan to write a man page some time. From fabien.thomas at netasq.com Fri Aug 21 12:42:04 2009 From: fabien.thomas at netasq.com (Fabien Thomas) Date: Fri Aug 21 12:42:11 2009 Subject: pf and vimage In-Reply-To: <4A8D76FE.7040302@elischer.org> References: <4A8CFDAF.1000309@delphij.net> <200908201108.39177.max@love2party.net> <4A8D76FE.7040302@elischer.org> Message-ID: <1321ED43-81C5-4507-AFC0-4B2DEE71BB78@netasq.com> Thanks very useful! Do you have an "official" page to look for update. What do you think of putting it on the FreeBSD Wiki? Fabien Le 20 ao?t 09 ? 18:17, Julian Elischer a ?crit : > there were some people looking at adding vnet support to pf. > Since we discussed it last, the rules of the game have > significantly changed for the better. With the addition > of some new facilitiesin FreeBSD, the work needed to virtualize > a module has significantly decreased. > > > The following doc gives the new rules.. > > > August 17 2009 > Julian Elischer > > =================== > Vimage: what is it? > =================== > > Vimage is a framework in the BSD kernel which allows a co-operating > module > to operate on multiple independent instances of its state so that it > can > participate in a virtual machine / virtual environment scenario. It > refers > to a part of the Jail infrastructure in FreeBSD. For historical > reasons > "Virtual network stack enabled jails"(1) are also known as "vimage > enabled > jails"(2) or "vnet enabled jails"(3). The currently correct term is > the > latter, which is a contraction of the first. In the future other > parts of > the system may be virtualized using the same technology and the term > to > cover all such components would be VIMAGE enhanced modules. > > The implementation approach taken by the vimage framework is a > redefinition > of selected global state variables to evaluate to constructs that > allow for > the virtualized state to be stored and resolved in appropriate > instances of > 'jail' specific container storage regions. The code operating on > virtualized > state has to conform to a set of rules described further below. > Among other > things in order to allow for all the changes to be conditionally > compilable. > i.e. permitting the virtualized code to fall back to operation on > global state. > > The rest of this document will discuss NETWORK virtualization > though the concepts may be true in the future for other parts of the > system. > > The most visible change throughout the existing code is typically > replacement > of direct references to global variables with macros; foo_bar thus > becomes > V_foo_bar. V_foo_bar macros will resolve back to the foo_bar global > in > default kernel builds, and alternatively to the logical equivalent of > some_base_pointer->_foo_bar for "options VIMAGE" kernel configs. > > Prepending of "V_" prefixes to variable references helps in > visual discrimination between global and virtualized state. > It is also possible to use an alternative syntax, of VNET(foo_bar) to > achieve the same thing. The developers felt that V_foo_bar was less > visually distracting while still providing enough clues to the reader > that the variable is virtualized. In fact the V_foo_bar macro is > locally defined near the definition of foo_bar to be an alias for > VNET(foo_bar) so the two are not only equivalent, they are the same. > > The framework also extends the sysctl infrastructure to support > access to > virtualized state through introduction of the SYSCTL_VNET family of > macros; > those also automatically fall back to their standard SYSCTL > counterparts > in default kernel builds. > > Transparent libkvm(3) lookups are provided to virtualized variables > which permits userland binaries such as netstat to operate unmodified > on "options VIMAGE" kernels, though this may have some security > implications. > > Vnets are associated with jails. In 8.0, every process is > associated with > a jail, usually the default (null) jail, and jails currently hang > off of > a processes ucred. This relationship defines a process's > administrative > affinity to a vnet and thus indirectly to all of its state. All > network > interfaces and sockets hold pointers back to their associated vnets. > This relationship is obviously entirely independent from proc->ucred- > >jail > bindings. Hence, when a process opens a socket, the socket will get > bound > to a vnet instance hanging off of proc->ucred->jail->vnet, but once > such a > socket->vnet binding gets established, it cannot be changed for the > entire > socket lifetime. > > The mapping of a from a thread to a vnet should always be done via the > TD_TO_VNET macro as the path may change in the future as we get more > experience with using the system. > > Certain classes of network interfaces (Ethernet in particular) can be > reassigned from one vnet to another at any time. By definition all > vnets > are independent and can communicate only if they are explicitly > provided with communication paths. Currently mainly netgraph is used > to > establish inter-vnet datapaths, though other paths are being explored > such as the 'epair' back-to-back virtual interface pair, in which > the different sides may exist in different jails. > > In network traffic processing the vnet affinity is defined either by > the > inbound interface or by the socket / pcb -> vnet binding. However, > there > are many functions in the network stack that cannot implicitly fetch > the vnet context from their standard arguments. Instead of explicitly > extending argument lists of such functions with a struct vnet *, > the concept of a "current vnet", a per-thread variable was introduced, > which can be fetched efficiently via the curvnet macro. The correct > network context has to be set on entry to the network stack (socket > operations, packet reception, or timer-driven functions) and cleared > on exit. > This must be done via provided CURVNET_SET() / CURVNET_RESTORE() > family of > macros, which allow for "stacking" of curvnet context setting and > provide > additional debugging info in INVARIANTS kernel configs. In most cases > however a developer writing virtualized code will not have to set / > restore the curvnet context unless the code would include timer-driven > events, given that those are inherently vnet-contextless on entry. > > The current rule is that when not in networking code, the result of > the 'curvnet' macro will return NULL and evaluating a V_xxx (or > VNET(xxx)) > macro will result in an kernel page-fault error. While this is not > strictly > necessary, it aids in debugging and assurance of program correctness. > Note this does NOT mean that TD_TO_VNET(curthread) is invalid. > A thread is always associated with a vnet, but just the efficient > "curvnet" access method is disabled along with the ability to resolve > virtualized symbols. > > > Converting / virtualizing existing code > ======================================= > > There are several steps need in virtualisation. > > 1/ Decide whether the module needs to be virtualised. > > If the module is a driver for specific hardware, it makes sense that > there be only one instance of the driver as there is only one > piece of > physical hardware. There are changes in the networking code to > allow > physical (or virtual) interfaces to be moved between vnets. This > generally requires NO changes to the network drivers of the classes > covered (e.g. ethernet). Currently if your module is does not have > any > networking facet, the answer is "no" by default. > > 2/ If the module is to be virtualised, decide which attributes of the > module should be virtualised. > > For example, It may make sense that there be a single central pool > of "struct foo" and a single uma zone for them to come from, with > a single > lock guarding it. It might also make sense if the "foo_debug" sysctl > controls all the instances at once, while on the other hand, the > "foo_mode" sysctl might make better sense if it were controllable > on a virtual system by virtual system basis. > > 3/ Work out what global variables and structures are to be > virtualised to > achieve the behaviour required for part #2. > > 4/ Work out for all the code paths through the module, how the > thread entering > the module can divine which virtual environment it is on. > > Some examples: > * Since interfaces are all assigned to one vnet or another, an > incoming > packet has a pointer to the receive interface, which in turn has a > pointer back to the vnet. Often "curvnet" will already have been > set > by the time your code is called anyhow. > * Similarly, on any request from outside the kernel, (direct or > indirect) > the current thread has a way to get to the current virtual > environment > instance via TD_TO_VNET(curthread). For existing sockets the vnet > context must be used via so->so_vnet since the thread's vnet might > change after socket creation. > * Timer initiated actions usually have a (void *) argument which > points to > some private structure for the module. It should be possible to > add > a pointer to the appropriate module instance into whatever > structure > that points to. > * Sometimes an action (timer trigerred or trigerred by module load > or > unload simply has to check all the vimage or module instances. > There are macro (pairs) for this which will iterate through all > the > VNET or instances. (see sample code below). > > This covers most of the cases, however in some cases it may still be > required for the module to stash away the virtual environment > instance > somewhere, and make associated changes in the code. > > 5/ Decide which parts of the initialization and teardown are per > jail and > which parts are global, and separate out the code accordingly. > Global initialization is done using the SYSINIT facility. > Per jail initialization is done using VNET_SYSINIT(). > Per jail teardown is doen using VNET_SYSUNINIT(). > Global teardown is done using SYSUNIT(). > In addition, the modevent handler is called with various event > types before > any of these are called. The modevent handler may veto load or > teardown. > On Shutdown, only the modevent handler is called so it may have to > simulate > the calling of the other handlers if clean shutdown is a requirement > of your module. (see sample code below). Don't forget to unregister > event handlers, and destroy locks and condition variables. > > 6/ Add the code described below to the files that make up the module. > > Details: (VNET implementation details) > > Firstly the file must be included. Depending on what > code you use you may find you also need one or more of: , > and . These requirements may change slightly > as the ABI settles. > > Having decided which variables need to be virtualized, the definition > of thosvariables needs to be modified to use the VNET_DEFINE() macro. > For example: > > static int foo = 3; > struct bar thebar = { 1,2,3 }; > > would become: > > static VNET_DEFINE(int, foo) = 3; > VNET_DEFINE(struct bar, thebar) = { 1,2,3 }; > > extern int foo; > in an include file might become: > VNET_DECLARE(int foo); > > Normal rules regarding 'static/extern' apply. The initial values > that you > give in this way will be stored and used as the initial values for > EACH NEW INSTANCE of these variables as new jails/vnets are created. > > As mentioned above, accesses to virtualized symbols are achieved via > macros, > which generally are of the same name as the original symbol but with > a "V_" > prepended, thus the head of the interface list, called 'ifnet' is > replaced > whereever used with "V_ifnet". We do this, by adding the following > lines after the definitions above: > > #define V_foo VNET(foo) > #define V_thebar VNET(thebar) > > --- side-note --- > In SCTP, because the code is shared with > other OS's they are replaced with a macro MODULE_GLOBAL(modulename, > symbol). > (this may simplify in light of recent changes). > -------------- > > In addition, should any of your values need to be changed or viewed > via sysctl, the following SYSCTL definitions would be needed: > > SYSCTL_VNET_PROC(_net_inet, OID_AUTO, thebar, > CTLTYPE_?? | CTLFLAG_RW | CTLFLAG_SECURE3, &VNET_NAME(thebar), 0, > thebar, "?", "the bar is open"); > {[XXX] robert fix this is possible ^^^} > SYSCTL_VNET_INT(_net_inet, OID_AUTO, foo, > CTLFLAG_RW, &VNET_NAME(foo), 0, "size of foo"); > > > In the current version of vimage, when VIMAGE is not compiled into > the kernel, the macros evaluate to a direct reference to the one and > only > symbol/variable, so that there is no speed penalty for those not > using vnets. > > When VIMAGE is compiled in, the macro will evaluate to an access to > an offset > into a data structure that is accessed on a per-vet basis. The vnet > used for this is always curvnet. For this reason an attempt to access > such a variable while curvnet is not valid, will result in an > exception. > > To ensure that curvnet has a valid value when needed one needs to > add the following code on all entry code paths into the networking > code: > int > my_func(int arg) > { > CURVNET_SET(TD_TO_VNET(curthread)); > do_my_network_stuff(arg); > CURVNET_RESTORE(); > return (0); > } > > The initial value is usually something like "TD_TO_VNET(curthread) > which in turn is a macro that derives the vnet affinity from the > current > thread. It could also be (m->m_ifp->if_vnet) if we were receiving > an mbuf, > or so->so_vnet if we had a socket involved. > > Usually, when a packet enters the system it is carried through the > processing > path via a single thread, and that thread will set its virtual > environment > reference to that indicated by the packet on picking up that new > packet. > This means that in the normal inbound processing path as well as the > outgoing process path the current thread can be used to indicate the > current virtual environment and curvet will always be valid once most > user supplied code is reached. In timer events, it is sometimes > necessary to add an "outer loop" to iterate through all the possible > vnets > if there is just one timer for all instances. > > When a new loadable module is virtualised the module definitions > and intializers need to be examined. The following example illustrates > what is needed in the case that you are not loading a new protocol, > or domain. > (for that see later) > > ============= sample skeleton code ========== > > /* init on boot or module load */ > static int > mymod_init(void) > { > return (error); > } > > /**************** > * Stuff that must be initialized for every instance > * (including the first of course). > */ > static int > mymod_vnet_init(const void *unused) > { > return (0); > } > > /********************** > * Called for the removal of the last instance only on module unload. > */ > static void > mymod_uninit(void) > { > } > > /*********************** > * Called for the removal of each instance. > */ > static int > mymod_vnet_uninit(const void *unused) > { > return (0) > } > > mymod_modevent(module_t mod, int type, void *unused) > { > int err = 0; > > switch (type) { > case MOD_LOAD: > /* check that loading is ok */ > break; > > case MOD_UNLOAD: > /* check that unloading is ok */ > break; > > case MOD_QUIESCE: > /* warning: try stop processing */ > /* maybe sleep 1 mSec or something to let threads get out */ > break; > > case MOD_SHUTDOWN: > /* > * this is called once but you may want to shut down > * things in each jail, or something global. > * In that case it's up to us to simulate the SYSUNINIT() > * or the VNET_SYSUNINIT() > */ > { > VNET_ITERATOR_DECL(vnet_iter); > VNET_LIST_RLOCK(); > VNET_FOREACH(vnet_iter) { > CURVNET_SET(vnet_iter); > mymod_vnet_uninit(NULL); > CURVNET_RESTORE(); > } > VNET_LIST_RUNLOCK(); > } > /* you may need to shutdown something global. */ > mymod_uninit(); > break; > > default: > err = EOPNOTSUPP; > break; > } > return err; > } > > static moduledata_t mymodmod = { > "mymod", > mymod_modevent, > 0 > }; > > /* define execution order using constants from /sys/sys/kernel.h */ > #define MYMOD_MAJOR_ORDER SI_SUB_PROTO_BEGIN /* for > example */ > #define MYMOD_MODULE_ORDER (SI_ORDER_ANY + 64) /* not > fussy */ > #define MYMOD_SYSINIT_ORDER (MYMOD_MODULE_ORDER + 1) /* a bit > later */ > #define MYMOD_VNET_ORDER (MYMOD_MODULE_ORDER + 2) /* later > still */ > > DECLARE_MODULE(mymod, mymodmod, MYMOD_MAJOR_ORDER, > MYMOD_MODULE_ORDER); > MODULE_DEPEND(mymod, ipfw, 2, 2, 2); /* depend on ipfw version > (exactly) 2 */ > MODULE_VERSION(mymod, 1); > > SYSINIT(mymod_init, MYMOD_MAJOR_ORDER, MYMOD_SYSINIT_ORDER, > mymod_init, NULL); > SYSUNINIT(mymod_uninit, MYMOD_MAJOR_ORDER, MYMOD_SYSINIT_ORDER, > mymod_uninit, NULL); > > VNET_SYSINIT(mymod_vnet_init, MYMOD_MAJOR_ORDER, MYMOD_VNET_ORDER, > mymod_vnet_init, NULL); > VNET_SYSUNINIT(mymod_vnet_uninit, MYMOD_MAJOR_ORDER, MYMOD_VNET_ORDER, > mymod_vnet_uninit, NULL); > > > ========== end sample code ======= > > On BOOT, the order of evaluation will be: > In a NON-VIMAGE kernel where the module is compiled: > MODEVENT, SYSINIT and VNET_SYSINIT both runm with order defined > by their > order declarations. {good foot shooting material if you get it > wrong!} > > In a VIMAGE kernel where the module is compiled in: > MODEVNET, SYSINIT and VNET_SYSINIT all run with order defined by > their > order declarations. AND in addition, the VNET_SYSINIT is > repeated once for every existing or new jail/vnet. > > On loading a vnet enabled kernel module after boot: > MODEVENT("event = load"); > SYSINIT() > VNET_SYSINIT() for every existing jail > AND in addition, VNET_SYSINIT being called for each new jail > created. > > On unloading of module: > MODEVENT("event = MOD_QUIESCE") > MODEVENT("event = MOD_UNLOAD") > VNET_SYSUNINIT called for every jail/vnet > SYSUNINIT > > On system shutdown: > MODEVENT(shutdown) > > NOTICE that while the order of the SYSINIT and VNET_SYSINIT is > reversed from > that of SYSUNINIT and VNET_SYSUNINIT, MODEVENTS do not follow > this rule and thus it is dangerous to initialise and uninitialise > things which are order dependent using MODEVENTs. > > Or, put another way, > Since MODEVENT is called first during module load, it would, by the > assumption that everything is reversed, be easy to assume that > MODEVENT > is called AFTER the SYSINITS during unload. This is in fact not > the case. (and I have the scars to prove it). > > It might be make some sense if the "QUIESCE" was called before the > SYSINIT/SYSUNINIT and the UNLOAD called after.. with a millisecond > sleep between them, but this is not the case either. > > Since initial values are copied into the virtualized variables > on each new instantiatin, it is quite possible to have modules for > which > some of the above methods are not needed, and they may be left out. > (but not the modevent). > > Sometimes there is a need to iterate through the vnets. > See the modevent shutdown handler (above) for an example of how to > do this. > Don't forget the locks. > > In the case where you are loading a new protocol, or domain > (protocol family) > there are some "shortcuts" that are in place to allow you to > maintain a bit > more source compatibility with older revisions of FreeBSD. It must be > added that the sample code above works just fine for protocols, > however > protcols also have an aditional initialization vector which is via the > prtocol structure, which has a pr_init() entry. > When a protocol is registered using pf_proto_register(), the pr_init() > for the protocol is called once for every existing vnet. in addition, > it will be called for each new vnet. The pr_destroy() method will be > called > as well on vnet teardown. The pf_proto_register() funcion can be > called > either from a modevent handler of from the SYSINIT() if you have > one, and > the pf_proto_unregister() called from the SYSUNINIT or the unload > modevent handler. > > If you are adding a whole new protocol domain, (protocol family) then > you should add the VNET_DOMAIN_SET(domainname) (e,g, inet, inet6) > macro. These use VNET_SYSINIT internally to indirectly call the > dom_init() and pr_init() functions for each vnet, (and the > equivalent for > teardown.) In this case one needs to be absolutely sure that both > your > domain and protocol initializers can be called multiple times, once > for > each vnet. One can still add SYSINITs for once only initialization, > or use the modevent handler. I prefer to do as much explicitly > in the SYSINITS and VNET_SYSINITS as then you have no surprises. > > finally: > The command to make a new jail with a new vnet: > jail -c host.hostname=test path=/ vnet command=/bin/tcsh > jail -c host.hostname=test path=/ children.max=4 vnet command=/bin/ > tcsh > (children.max allows hierarchical jail creation). > Note that the command must come last. > > > _______________________________________________ > 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 Aug 21 14:20:42 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Fri Aug 21 14:20:50 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link Message-ID: <20090821142039.GA40018@traktor.dnepro.net> Hello, Freebsd-net subscribers! This is on 7.2-Stable. I've got a D-Link DGE-560SX GigE fiber adapter. It's Marvell 88E8061 so I hoped it will work as msk(4). D-Link has changed PCI Id for the chip: none1@pci0:1:0:0: class=0x020000 card=0x4b021186 chip=0x4b021186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' device = 'DGE-560SX PCIe Gigabit Ethernet Adapter' class = network subclass = ethernet So I've patched the driver to recognize new IDs. --- /sys/dev/msk/if_mskreg.h.old 2009-08-14 17:04:09.000000000 +0300 +++ /sys/dev/msk/if_mskreg.h 2009-08-14 17:04:49.000000000 +0300 @@ -149,6 +149,7 @@ */ #define DEVICEID_DLINK_DGE550SX 0x4001 #define DEVICEID_DLINK_DGE560T 0x4b00 +#define DEVICEID_DLINK_DGE560SX 0x4b02 #define BIT_31 (1 << 31) #define BIT_30 (1 << 30) --- /sys/dev/msk/if_msk.c.old 2009-08-14 17:04:03.000000000 +0300 +++ /sys/dev/msk/if_msk.c 2009-08-14 17:12:48.000000000 +0300 @@ -224,7 +224,9 @@ { VENDORID_DLINK, DEVICEID_DLINK_DGE550SX, "D-Link 550SX Gigabit Ethernet" }, { VENDORID_DLINK, DEVICEID_DLINK_DGE560T, - "D-Link 560T Gigabit Ethernet" } + "D-Link 560T Gigabit Ethernet" }, + { VENDORID_DLINK, DEVICEID_DLINK_DGE560SX, + "D-Link 560SX Gigabit Ethernet" } }; static const char *model_name[] = { Then the driver recognizes the card: mskc0: port 0x4000-0x40ff mem 0xdc100000-0xdc103fff irq 16 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:21:91:52:4f:09 miibus1: on msk0 e1000phy0: PHY 0 on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [FILTER] Now I'm stuck because it doesn't see link. # ifconfig msk0 up # ifconfig -m msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a capabilities=11a ether 00:21:91:52:4f:09 media: Ethernet autoselect (100baseTX ) status: no carrier supported media: media autoselect media 1000baseTX mediaopt full-duplex media 1000baseTX media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none The adapter is definitely not broken, I've tested it on Win and there it works normally. Also on Win it has no speed/duplex settings, while msk driver allows to change media. I've also tried Marvell's binary if_myk driver, but it doesn't know about d-link. Can anyone propose something to get it working? -- Eugene Perevyazko From pyunyh at gmail.com Fri Aug 21 22:20:13 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Aug 21 22:20:20 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090821142039.GA40018@traktor.dnepro.net> References: <20090821142039.GA40018@traktor.dnepro.net> Message-ID: <20090821221932.GE1262@michelle.cdnetworks.com> On Fri, Aug 21, 2009 at 05:20:39PM +0300, Eugene Perevyazko wrote: > Hello, Freebsd-net subscribers! > > This is on 7.2-Stable. > I've got a D-Link DGE-560SX GigE fiber adapter. It's Marvell 88E8061 so > I hoped it will work as msk(4). > D-Link has changed PCI Id for the chip: > none1@pci0:1:0:0: class=0x020000 card=0x4b021186 chip=0x4b021186 rev=0x10 > hdr=0x00 > vendor = 'D-Link System Inc' > device = 'DGE-560SX PCIe Gigabit Ethernet Adapter' > class = network > subclass = ethernet > > > So I've patched the driver to recognize new IDs. > Your patch looks to me. [...] > Then the driver recognizes the card: > > mskc0: port 0x4000-0x40ff mem 0xdc100000-0xdc103fff irq 16 at device 0.0 on pci1 > msk0: on mskc0 > msk0: Ethernet address: 00:21:91:52:4f:09 > miibus1: on msk0 > e1000phy0: PHY 0 on miibus1 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This part is problem, you have finer media, so you should have just 1000baseSX. > mskc0: [FILTER] > > Now I'm stuck because it doesn't see link. > # ifconfig msk0 up > # ifconfig -m msk0 > msk0: flags=8843 metric 0 mtu 1500 > options=11a > capabilities=11a > ether 00:21:91:52:4f:09 > media: Ethernet autoselect (100baseTX ) > status: no carrier > supported media: > media autoselect > media 1000baseTX mediaopt full-duplex > media 1000baseTX > media 100baseTX mediaopt full-duplex > media 100baseTX > media 10baseT/UTP mediaopt full-duplex > media 10baseT/UTP > media none > > The adapter is definitely not broken, I've tested it on Win and there it works > normally. Also on Win it has no speed/duplex settings, while msk driver allows > to change media. > ATM there is no easy/clean way to pass driver specific data to mii layer in FreeBSD so e1000phy(4) incorrectly thinks it found copper PHY. Marvell PHYs seem to have no reliable way to know configured media type of PHY hardware unless parent driver(msk) gives hint to it. If you have just 1 NIC which uses e1000phy(4) on your system, modify e1000phy(4) to force it having fiber media by inserting the following line around line 114 in e1000phy.c. sc->mii_flags |= MIIF_HAVEFIBER; > I've also tried Marvell's binary if_myk driver, but it doesn't know about d-link. > > Can anyone propose something to get it working? > > -- > Eugene Perevyazko From linimon at FreeBSD.org Sun Aug 23 07:16:59 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Aug 23 07:17:11 2009 Subject: kern/134956: [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Server Adapter (82571), ifconfig reports "status: active" after cable unplugged Message-ID: <200908230716.n7N7GxFB072455@freefall.freebsd.org> Old Synopsis: FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Server Adapter (82571), ifconfig reports "status: active" after cable unplugged New Synopsis: [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Server Adapter (82571), ifconfig reports "status: active" after cable unplugged Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 23 07:16:27 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134956 From linimon at FreeBSD.org Mon Aug 24 04:09:59 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 24 04:10:05 2009 Subject: kern/138046: [tcp] tcp sockets stay in SYN_SENT even after receiving RST. never time out as well. Message-ID: <200908240409.n7O49wYY082711@freefall.freebsd.org> Old Synopsis: tcp sockets stay in SYN_SENT even after receiving RST. never time out as well. New Synopsis: [tcp] tcp sockets stay in SYN_SENT even after receiving RST. never time out as well. Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 24 04:08:39 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=138046 From wjw at digiware.nl Mon Aug 24 07:17:27 2009 From: wjw at digiware.nl (Willem Jan Withagen) Date: Mon Aug 24 07:17:34 2009 Subject: Strange src forwarding. Message-ID: <4A923E81.2020409@digiware.nl> I have the strange IPv6 forwarding messages in my security output. The link-local ip-nr is not lokal on this system, so is there another system in my network that does this ipv6. But I've not yet found a system with fc:ba as last bytes in my arp-table? Can anybody tell me why I get these messages in my log? --WjW rack1.digiware.nl kernel log messages: +++ /tmp/security.KCtiPXhd 2009-08-24 03:04:39.000000000 +0200 +cannot forward src fe80:1::213:2ff:fe2a:fcba, dst 2a01:138:a001:201::21, nxt 6, rcvif em0, outif em1 +cannot forward src fe80:1::213:2ff:fe2a:fcba, dst 2a01:138:a001:201::21, nxt 6, rcvif em0, outif em1 +cannot forward src fe80:1::213:2ff:fe2a:fcba, dst 2a01:138:a001:201::21, nxt 6, rcvif em0, outif em1 From linimon at FreeBSD.org Mon Aug 24 10:36:28 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 24 10:36:34 2009 Subject: kern/138130: [netinet] [patch] Resource leak in LibAliasRefreshModules() in file sys/netinet/libalias/alias.c Message-ID: <200908241036.n7OAaRfv017169@freefall.freebsd.org> Old Synopsis: Resource leak in LibAliasRefreshModules() in file sys/netinet/libalias/alias.c New Synopsis: [netinet] [patch] Resource leak in LibAliasRefreshModules() in file sys/netinet/libalias/alias.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 24 10:35:19 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138130 From bugmaster at FreeBSD.org Mon Aug 24 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:08:57 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200908241107.n7OB70Jn048667@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/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/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 bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/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 o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal 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 bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] 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/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 327 problems total. From linimon at FreeBSD.org Mon Aug 24 12:22:13 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 24 12:22:25 2009 Subject: kern/138135: [fxp] truncated-ip - 2 bytes missing! on fxp(4) Message-ID: <200908241222.n7OCMDDP033905@freefall.freebsd.org> Old Synopsis: truncated-ip - 2 bytes missing! on fxp(4) New Synopsis: [fxp] truncated-ip - 2 bytes missing! on fxp(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 24 12:21:54 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138135 From ndenev at gmail.com Mon Aug 24 14:57:49 2009 From: ndenev at gmail.com (Nikolay Denev) Date: Mon Aug 24 14:57:56 2009 Subject: 7.2 sends broken TCP retransmits while in half-closed state? Message-ID: <6C253DEA-0C34-4109-9D45-3DE1750DB1BE@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Today while I was diagnosing a FTP problem which turned out to be EPSV issue I found some very interesting things in the tcpdumps. From what I understand from the trace, after a few retransmits, the client side sends FIN/ACK to close the connection, and receives ACK. But while waiting for the remote side to send it's FIN/ACK to be ACK'ed, it continues to send the retransmits that it did before the first FIN/ACK, but they are now truncated. Here is the exported trace from Wireshark. I can also send it in tcpdump output format if someone prefers it. 10.10.0.10 is the client IP. 10.20.0.20 is the server IP. Look for the "Destination Unreachable" messages generated by the broken retransmits. Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 47, Ack: 248, Len: 0 No. Time Source Destination Protocol Info 23 11.930506 10.10.0.10 10.20.0.20 FTP Request: EPSV Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 47, Ack: 248, Len: 6 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 24 11.987691 10.20.0.20 10.10.0.10 FTP Response: 229 Entering Extended Passive Mode (|||59364|) Internet Protocol, Src: 10.20.0.20 (10.20.0.20), Dst: 10.10.0.10 (10.10.0.10) Transmission Control Protocol, Src Port: ftp (21), Dst Port: 65073 (65073), Seq: 248, Ack: 53, Len: 48 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 25 11.987770 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=2276550531 TSER=0 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 26 12.087485 10.10.0.10 10.20.0.20 TCP 65073 > ftp [ACK] Seq=53 Ack=296 Win=66608 Len=0 TSV=2276550631 TSER=3200765949 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 0 No. Time Source Destination Protocol Info 27 14.987564 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=2276553531 TSER=0 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 28 18.187647 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=2276556731 TSER=0 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 29 21.387724 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 30 24.587802 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 31 27.787885 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 32 33.988042 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 33 46.188343 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 34 70.388952 10.10.0.10 10.20.0.20 TCP 62552 > 59364 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 62552 (62552), Dst Port: 59364 (59364), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 35 86.989453 10.10.0.10 10.20.0.20 FTP Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 36 87.287370 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 37 87.683379 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 38 88.275395 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 39 89.259423 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 40 91.027467 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 41 92.859511 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 42 96.323600 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 43 103.051770 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 44 116.308102 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 45 142.620762 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: EPRT |1|10.10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 53, Ack: 296, Len: 31 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 46 146.991908 10.10.0.10 10.20.0.20 TCP 65073 > ftp [FIN, ACK] Seq=84 Ack=296 Win=66608 Len=0 TSV=2276685532 TSER=3200765949 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 84, Ack: 296, Len: 0 No. Time Source Destination Protocol Info 47 147.049585 10.20.0.20 10.10.0.10 TCP ftp > 65073 [ACK] Seq=296 Ack=65 Win=5792 Len=0 TSV=3200901032 TSER=2276550631 SLE=72 SRE=73 Internet Protocol, Src: 10.20.0.20 (10.20.0.20), Dst: 10.10.0.10 (10.10.0.10) Transmission Control Protocol, Src Port: ftp (21), Dst Port: 65073 (65073), Seq: 296, Ack: 65, Len: 0 No. Time Source Destination Protocol Info 48 211.050479 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: 10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 65, Ack: 296, Len: 19 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 49 211.118136 10.20.0.20 10.10.0.10 ICMP Destination unreachable (Host administratively prohibited) Internet Protocol, Src: 10.20.0.20 (10.20.0.20), Dst: 10.10.0.10 (10.10.0.10) Internet Control Message Protocol No. Time Source Destination Protocol Info 50 275.052084 10.10.0.10 10.20.0.20 FTP [TCP Retransmission] Request: 10.0.10|49610| Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 65, Ack: 296, Len: 19 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 51 275.105225 10.20.0.20 10.10.0.10 ICMP Destination unreachable (Host administratively prohibited) Internet Protocol, Src: 10.20.0.20 (10.20.0.20), Dst: 10.10.0.10 (10.10.0.10) Internet Control Message Protocol No. Time Source Destination Protocol Info 52 299.988028 10.20.0.20 10.10.0.10 FTP Response: 421 No Transfer Timeout (300 seconds): closing control connection. Internet Protocol, Src: 10.20.0.20 (10.20.0.20), Dst: 10.10.0.10 (10.10.0.10) Transmission Control Protocol, Src Port: ftp (21), Dst Port: 65073 (65073), Seq: 296, Ack: 65, Len: 68 File Transfer Protocol (FTP) No. Time Source Destination Protocol Info 53 299.988051 10.10.0.10 10.20.0.20 TCP 65073 > ftp [RST] Seq=65 Win=0 Len=0 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 65, Len: 0 No. Time Source Destination Protocol Info 54 299.988053 10.20.0.20 10.10.0.10 TCP ftp > 65073 [FIN, ACK] Seq=364 Ack=65 Win=5792 Len=0 TSV=3201053996 TSER=2276550631 SLE=72 SRE=73 Internet Protocol, Src: 10.20.0.20 (10.20.0.20), Dst: 10.10.0.10 (10.10.0.10) Transmission Control Protocol, Src Port: ftp (21), Dst Port: 65073 (65073), Seq: 364, Ack: 65, Len: 0 No. Time Source Destination Protocol Info 55 299.988060 10.10.0.10 10.20.0.20 TCP 65073 > ftp [RST] Seq=65 Win=0 Len=0 Internet Protocol, Src: 10.10.0.10 (10.10.0.10), Dst: 10.20.0.20 (10.20.0.20) Transmission Control Protocol, Src Port: 65073 (65073), Dst Port: ftp (21), Seq: 65, Len: 0 No. Time Source Destination Protocol Info 56 300.041497 10.20.0.20 10.10.0.10 ICMP Destination unreachable (Host administratively prohibited) - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkqSpVgACgkQHNAJ/fLbfrmTHwCfUcgiwrc1VsWB3Om627VDqTx9 bzwAoJrlsZCOqiZ99QWHoGkvSYpuDbmr =0VLB -----END PGP SIGNATURE----- From yongari at FreeBSD.org Mon Aug 24 18:22:33 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Mon Aug 24 18:22:39 2009 Subject: kern/138135: [fxp] truncated-ip - 2 bytes missing! on fxp(4) [regression] Message-ID: <200908241822.n7OIMWkc004089@freefall.freebsd.org> Synopsis: [fxp] truncated-ip - 2 bytes missing! on fxp(4) [regression] State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Aug 24 18:20:03 UTC 2009 State-Changed-Why: The pciconf(8) looks wrong to me. According to the chipid your fxp0 interface is "Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet" and fxp[1-7] is "Intel 82559ER Embedded 10/100 Ethernet". Since these controllers have no TSO/Tx checksum offload support I guess it could be related with other parts of kernel. By chance are you using some firewall in your box(pf/ipf/ipfw)? Also would you let me know the last known working release? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Aug 24 18:20:03 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=138135 From smith.graham23 at gmail.com Mon Aug 24 19:39:35 2009 From: smith.graham23 at gmail.com (Graham Smith) Date: Mon Aug 24 21:06:03 2009 Subject: native vlan Message-ID: Networking folks Nothing to do with freebsd per say, but can someone tell real life scenario requiring creation of native vlan (vlan 0) and why native vlan are most suitable for this scene ? TIA, From mksmith at adhost.com Mon Aug 24 21:26:29 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon Aug 24 21:26:35 2009 Subject: native vlan In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D52031606934019@ad-exh01.adhost.lan> Well, in Cisco speak, the native vlan is untagged and used for management. So, all your customer traffic comes in tagged with various VLAN's and your management stuff remains untagged and localized to the switching infrastructure. So, I guess you would do it if you wanted to speak spanning tree (802.1D) with switches and/or you wanted to put a management IP address on the same subnet as your switch management VLAN subnet. Regards, Mike > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Graham Smith > Sent: Monday, August 24, 2009 12:12 PM > To: freebsd-net@freebsd.org > Subject: native vlan > > Networking folks > > Nothing to do with freebsd per say, but can someone tell real life > scenario > requiring creation of native vlan (vlan 0) and why native vlan are > most > suitable for this scene ? > > TIA, > _______________________________________________ > 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 repcsike at gmail.com Mon Aug 24 21:34:58 2009 From: repcsike at gmail.com (=?ISO-8859-1?B?QmFs4XpzIE3hdOlmZnk=?=) Date: Mon Aug 24 21:35:05 2009 Subject: native vlan In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606934019@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031606934019@ad-exh01.adhost.lan> Message-ID: Hi, I would add, that if you have hosts, a hub or an unmanaged switch without vlan capability between two switches with vlans those devices will use the native vlan. And another thing: you have to make the native vlan the same on the switches or you will get native vlan error messages. In cisco the native vlan's number is 1 by the way not 0, as far as I know. Hope this helps! Regards, Repcsi. 2009/8/24 Michael K. Smith - Adhost > Well, in Cisco speak, the native vlan is untagged and used for > management. So, all your customer traffic comes in tagged with various > VLAN's and your management stuff remains untagged and localized to the > switching infrastructure. > > So, I guess you would do it if you wanted to speak spanning tree > (802.1D) with switches and/or you wanted to put a management IP address > on the same subnet as your switch management VLAN subnet. > > Regards, > > Mike > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > net@freebsd.org] On Behalf Of Graham Smith > > Sent: Monday, August 24, 2009 12:12 PM > > To: freebsd-net@freebsd.org > > Subject: native vlan > > > > Networking folks > > > > Nothing to do with freebsd per say, but can someone tell real life > > scenario > > requiring creation of native vlan (vlan 0) and why native vlan are > > most > > suitable for this scene ? > > > > TIA, > > _______________________________________________ > > 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 bms at incunabulum.net Mon Aug 24 22:05:04 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Aug 24 22:05:10 2009 Subject: native vlan In-Reply-To: References: Message-ID: <4A930E89.9070609@incunabulum.net> Graham Smith wrote: > Networking folks > > Nothing to do with freebsd per say, but can someone tell real life scenario > requiring creation of native vlan (vlan 0) and why native vlan are most > suitable for this scene ? Assuming you're referring to what's in the 802.1q header: it's what 802.1p puts in the VLAN tag of an 802.1p priority frame, and it isn't a VLAN. From john at dnepro.net Tue Aug 25 08:39:02 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Tue Aug 25 08:39:09 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090821221932.GE1262@michelle.cdnetworks.com> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> Message-ID: <20090825083857.GA22983@traktor.dnepro.net> Hello Pyun. I apologise for long delay, we had 3-day state holidays here. :) On Fri, Aug 21, 2009 at 03:19:32PM -0700, Pyun YongHyeon wrote: > On Fri, Aug 21, 2009 at 05:20:39PM +0300, Eugene Perevyazko wrote: [...] > > > Then the driver recognizes the card: > > > > mskc0: port 0x4000-0x40ff mem 0xdc100000-0xdc103fff irq 16 at device 0.0 on pci1 > > msk0: on mskc0 > > msk0: Ethernet address: 00:21:91:52:4f:09 > > miibus1: on msk0 > > e1000phy0: PHY 0 on miibus1 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This part is problem, you have finer media, so you should have just > 1000baseSX. [...] > > ATM there is no easy/clean way to pass driver specific data to mii > layer in FreeBSD so e1000phy(4) incorrectly thinks it found copper > PHY. Marvell PHYs seem to have no reliable way to know configured > media type of PHY hardware unless parent driver(msk) gives hint to > it. If you have just 1 NIC which uses e1000phy(4) on your system, > modify e1000phy(4) to force it having fiber media by inserting the > following line around line 114 in e1000phy.c. > > sc->mii_flags |= MIIF_HAVEFIBER; > I'm lucky enough that it's the only e1000phy NIC in the system, but I can't find the place you mean in e1000phy.c It's src/sys/dev/e1000/e1000_phy.c,v 1.1.2.2 and lines 112-115 are /** * e1000_null_lplu_state - No-op function, return 0 * @hw: pointer to the HW structure **/ I really doubt, there's any sense in patching this comment. Could you please give me a patch or precise instructions? -- Eugene Perevyazko From john at dnepro.net Tue Aug 25 11:46:55 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Tue Aug 25 11:47:02 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090825083857.GA22983@traktor.dnepro.net> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> Message-ID: <20090825114649.GA11642@traktor.dnepro.net> Hello Pyun. On Tue, Aug 25, 2009 at 11:38:57AM +0300, Eugene Perevyazko wrote: > [...] > > > > ATM there is no easy/clean way to pass driver specific data to mii > > layer in FreeBSD so e1000phy(4) incorrectly thinks it found copper > > PHY. Marvell PHYs seem to have no reliable way to know configured > > media type of PHY hardware unless parent driver(msk) gives hint to > > it. If you have just 1 NIC which uses e1000phy(4) on your system, > > modify e1000phy(4) to force it having fiber media by inserting the > > following line around line 114 in e1000phy.c. > > > > sc->mii_flags |= MIIF_HAVEFIBER; > > > I'm lucky enough that it's the only e1000phy NIC in the system, but I can't > find the place you mean in e1000phy.c > It's src/sys/dev/e1000/e1000_phy.c,v 1.1.2.2 and lines 112-115 are Sorry for being so blind as to look for MII code in intel's gigabit driver! :) It's sys/dev/mii/e1000phy.c of course. Line 114 still looks weird to me, so I'm trying this: --- e1000phy.c 2009-08-25 14:45:03.000000000 +0300 +++ e1000phy.c.old 2009-08-25 14:44:47.000000000 +0300 @@ -166,7 +166,6 @@ break; } - sc->mii_flags |= MIIF_HAVEFIBER; e1000phy_reset(sc); sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask; for src/sys/dev/mii/e1000phy.c,v 1.18.2.8 I'm rebuilding kernel now... -- Eugene Perevyazko From steve at ibctech.ca Tue Aug 25 12:23:58 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Aug 25 12:24:05 2009 Subject: native vlan In-Reply-To: References: <17838240D9A5544AAA5FF95F8D52031606934019@ad-exh01.adhost.lan> Message-ID: <4A93D7DB.3050500@ibctech.ca> Bal?zs M?t?ffy wrote: > Hi, > > I would add, that if you have hosts, a hub or an unmanaged switch without > vlan capability between two switches with vlans those devices will use the > native vlan. This isn't entirely accurate. Note that the VLAN tag is applied during the ingress into the switch. If I have a host (or switch etc) that is incapable of 802.1q that I want configured into a non-native VLAN (vlan 500 for example), then I would configure the port the host is connected to as a vlan 500 access port. The device connected to that port would then be part of vlan 500. > And another thing: you have to make the native vlan the same on > the switches or you will get native vlan error messages. In cisco the native > vlan's number is 1 by the way not 0, as far as I know. Yes, in Cisco-land, VLAN 1 is the default, native VLAN. Most people will disable vlan 1, and configure native to be an arbitrary number. Also, there are cases where the native vlan warnings are acceptable, such as when you need to bridge your network via layer-2 to an outside network that you don't control, and both parties are using separate native vlans. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090825/1cf1a621/smime.bin From john at dnepro.net Tue Aug 25 13:08:23 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Tue Aug 25 13:08:58 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090825114649.GA11642@traktor.dnepro.net> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> Message-ID: <20090825130821.GA41669@traktor.dnepro.net> Hello. On Tue, Aug 25, 2009 at 02:46:49PM +0300, Eugene Perevyazko wrote: > > > > > > ATM there is no easy/clean way to pass driver specific data to mii > > > layer in FreeBSD so e1000phy(4) incorrectly thinks it found copper > > > PHY. Marvell PHYs seem to have no reliable way to know configured > > > media type of PHY hardware unless parent driver(msk) gives hint to > > > it. If you have just 1 NIC which uses e1000phy(4) on your system, > > > modify e1000phy(4) to force it having fiber media by inserting the > > > following line around line 114 in e1000phy.c. > > > > > > sc->mii_flags |= MIIF_HAVEFIBER; [...] > --- e1000phy.c 2009-08-25 14:45:03.000000000 +0300 > +++ e1000phy.c.old 2009-08-25 14:44:47.000000000 +0300 > @@ -166,7 +166,6 @@ > break; > } > > - sc->mii_flags |= MIIF_HAVEFIBER; > e1000phy_reset(sc); > > sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask; > > for src/sys/dev/mii/e1000phy.c,v 1.18.2.8 I've rebooted with new kernel with following results: mskc0: port 0x4000-0x40ff mem 0xdc100000-0xdc103 fff irq 16 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:21:91:52:4f:09 miibus1: on msk0 e1000phy0: PHY 0 on miibus1 e1000phy0: 1000baseSX, 1000baseSX-FDX, auto mskc0: [FILTER] # ifconfig msk0 msk0: flags=8802 metric 0 mtu 1500 options=11a ether 00:21:91:52:4f:09 media: Ethernet autoselect # ifconfig msk0 up # ifconfig -m msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a capabilities=11a ether 00:21:91:52:4f:09 media: Ethernet autoselect (autoselect ) status: active supported media: media autoselect media 1000baseSX mediaopt full-duplex media 1000baseSX media none Switch and NIC see the link, but no packets pass through the interface. # ifconfig msk0 media 1000baseSX mediaopt full-duplex # ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a ether 00:21:91:52:4f:09 media: Ethernet 1000baseSX (autoselect ) status: active Again no packets are seen with tcpdump. Switch counters show no incoming packets from NIC if I set an ip and try to generate some traffic. Any ideas? -- Eugene Perevyazko From gnemmi at gmail.com Tue Aug 25 14:00:16 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Aug 25 14:00:27 2009 Subject: kern/136876: [bge] bge will not resume properly after suspend Message-ID: <200908251400.n7PE05mj025337@freefall.freebsd.org> The following reply was made to PR kern/136876; it has been noted by GNATS. From: Gonzalo Nemmi To: bug-followup@freebsd.org, adamk@voicenet.com Cc: Subject: Re: kern/136876: [bge] bge will not resume properly after suspend Date: Tue, 25 Aug 2009 10:51:13 -0300 bge0 problem is still present on BETA3 -- Blessings Gonzalo Nemmi From pyunyh at gmail.com Tue Aug 25 18:26:30 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Aug 25 18:26:37 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090825130821.GA41669@traktor.dnepro.net> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> Message-ID: <20090825182553.GD1282@michelle.cdnetworks.com> On Tue, Aug 25, 2009 at 04:08:21PM +0300, Eugene Perevyazko wrote: > Hello. > > On Tue, Aug 25, 2009 at 02:46:49PM +0300, Eugene Perevyazko wrote: > > > > > > > > ATM there is no easy/clean way to pass driver specific data to mii > > > > layer in FreeBSD so e1000phy(4) incorrectly thinks it found copper > > > > PHY. Marvell PHYs seem to have no reliable way to know configured > > > > media type of PHY hardware unless parent driver(msk) gives hint to > > > > it. If you have just 1 NIC which uses e1000phy(4) on your system, > > > > modify e1000phy(4) to force it having fiber media by inserting the > > > > following line around line 114 in e1000phy.c. > > > > > > > > sc->mii_flags |= MIIF_HAVEFIBER; > [...] > > --- e1000phy.c 2009-08-25 14:45:03.000000000 +0300 > > +++ e1000phy.c.old 2009-08-25 14:44:47.000000000 +0300 > > @@ -166,7 +166,6 @@ > > break; > > } > > > > - sc->mii_flags |= MIIF_HAVEFIBER; > > e1000phy_reset(sc); > > > > sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask; > > > > for src/sys/dev/mii/e1000phy.c,v 1.18.2.8 > > I've rebooted with new kernel with following results: > > mskc0: port 0x4000-0x40ff mem 0xdc100000-0xdc103 > fff irq 16 at device 0.0 on pci1 > msk0: on mskc0 > msk0: Ethernet address: 00:21:91:52:4f:09 > miibus1: on msk0 > e1000phy0: PHY 0 on miibus1 > e1000phy0: 1000baseSX, 1000baseSX-FDX, auto > mskc0: [FILTER] > > # ifconfig msk0 > msk0: flags=8802 metric 0 mtu 1500 > options=11a > ether 00:21:91:52:4f:09 > media: Ethernet autoselect > > # ifconfig msk0 up > # ifconfig -m msk0 > msk0: flags=8843 metric 0 mtu 1500 > options=11a > capabilities=11a > ether 00:21:91:52:4f:09 > media: Ethernet autoselect (autoselect ) > status: active > supported media: > media autoselect > media 1000baseSX mediaopt full-duplex > media 1000baseSX > media none > > Switch and NIC see the link, but no packets pass through the interface. > > # ifconfig msk0 media 1000baseSX mediaopt full-duplex > # ifconfig msk0 > msk0: flags=8843 metric 0 mtu 1500 > options=11a > ether 00:21:91:52:4f:09 > media: Ethernet 1000baseSX (autoselect ) > status: active > > Again no packets are seen with tcpdump. > Switch counters show no incoming packets from NIC if I set an ip and try to generate some traffic. > > Any ideas? Try attached patch and let me know how it goes on your box. You can see statistics counters maintained in driver with sysctl. "sysctl dev.msk.0.stats" will show some numbers if it can see packets on wire. -------------- next part -------------- A non-text attachment was scrubbed... Name: msk.DGE560.diff Type: text/x-diff Size: 1235 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090825/9241f72f/msk.DGE560.bin From dima_bsd at inbox.lv Tue Aug 25 20:33:20 2009 From: dima_bsd at inbox.lv (Dmitriy Demidov) Date: Tue Aug 25 20:33:27 2009 Subject: Broadcom BCM5761,BCM5784,BCM5785 drivers available for 8.0/7.2 Message-ID: <200908252233.10562.dima_bsd@inbox.lv> Hello. I'm "happy" user of Acer aspire 5536 notebook :) I met one problem with Broadcom BCM5784M network adapter using FreeBSD 8.0-BETA2 - there is no native support for my ethernet card. A good news that there is extra patches that adds support for this Broadcom, and that they works without any problems (at least for me... so far...). Can somebody please take a look on them here: http://forums.freebsd.org/showthread.php?t=6081 http://nccs.christian.net/bge_bcm5784_patch.htm and if they are OK, commit them into FreeBSD? Thanks! From john at dnepro.net Wed Aug 26 09:39:19 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Wed Aug 26 09:39:26 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090825182553.GD1282@michelle.cdnetworks.com> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> Message-ID: <20090826093916.GB10790@traktor.dnepro.net> On Tue, Aug 25, 2009 at 11:25:53AM -0700, Pyun YongHyeon wrote: > > Try attached patch and let me know how it goes on your box. > You can see statistics counters maintained in driver with sysctl. > "sysctl dev.msk.0.stats" will show some numbers if it can see > packets on wire. With attached patch NIC doesn't see link again. All counters in dev.msk.0.stats are 0s. mskc0: port 0x4000-0x40ff mem 0xdc100000-0xdc103fff irq 16 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:21:91:52:4f:09 miibus1: on msk0 e1000phy0: PHY 0 on miibus1 e1000phy0: 1000baseSX, 1000baseSX-FDX, auto mskc0: [FILTER] # ifconfig msk0 msk0: flags=8802 metric 0 mtu 1500 options=11a ether 00:21:91:52:4f:09 media: Ethernet autoselect # ifconfig msk0 up # ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a ether 00:21:91:52:4f:09 media: Ethernet autoselect (none) status: no carrier # ifconfig -m msk0 msk0: flags=8843 metric 0 mtu 1500 options=11a capabilities=11a ether 00:21:91:52:4f:09 media: Ethernet autoselect (none) status: no carrier supported media: media autoselect media 1000baseSX mediaopt full-duplex media 1000baseSX media none -- Eugene Perevyazko From john at dnepro.net Wed Aug 26 09:48:59 2009 From: john at dnepro.net (Eugene Perevyazko) Date: Wed Aug 26 09:49:05 2009 Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link In-Reply-To: <20090826093916.GB10790@traktor.dnepro.net> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> <20090826093916.GB10790@traktor.dnepro.net> Message-ID: <20090826094856.GC10790@traktor.dnepro.net> On Wed, Aug 26, 2009 at 12:39:16PM +0300, Eugene Perevyazko wrote: > On Tue, Aug 25, 2009 at 11:25:53AM -0700, Pyun YongHyeon wrote: > > > > Try attached patch and let me know how it goes on your box. > > You can see statistics counters maintained in driver with sysctl. > > "sysctl dev.msk.0.stats" will show some numbers if it can see > > packets on wire. > > With attached patch NIC doesn't see link again. > All counters in dev.msk.0.stats are 0s. > > # ifconfig msk0 > msk0: flags=8843 metric 0 mtu 1500 > options=11a > ether 00:21:91:52:4f:09 > media: Ethernet autoselect (none) > status: no carrier At the same time the link led on NIC is on, and switch shows that port is up. That's different from the unpatched system, where led was off and switch port was down. -- Eugene Perevyazko From freebsd-net at kouznetsov.com Wed Aug 26 14:40:31 2009 From: freebsd-net at kouznetsov.com (Alexey Kouznetsov) Date: Wed Aug 26 15:41:12 2009 Subject: Pipes and wrong IPs Message-ID: <4D0FE79CC65F4813906B3D7A932EC0A6@hcnstrela.ru> Hello! Time to time a see at FreeBSD router some troubles with pipes We have rooles: ... 20000 pipe tablearg ip from any to table(30) xmit em1 out 20000 pipe tablearg ip from table(31) to any recv em1 in ... no more rooles where we use pipe or queue in table 30 we have list of IPs, have to be shaped for incoming and in table 31 IPs we have to shape for outgoing. With parameters - the PIPE numbers Also we have lot of pipes: /sbin/ipfw pipe 122 config mask dst-ip 0xffffffff bw 32768Byte/s queue 32 gred 0.002/8/16/0.1 /sbin/ipfw pipe 1122 config mask src-ip 0xffffffff bw 32768Byte/s queue 32 gred 0.002/8/16/0.1 Each pair of pipes for their speeds so, for example if we want to shape IP 10.10.10.10 to 32 MB for both directipons we will have ipfw table 30 add 10.10.10.10 122 ipfw table 31 add 10.10.10.10 1122 And.. time to time I see at output for ipfw pipe XXX show wrong IPs, whch should not be at this pipe. Often I see IPs which should not be at any pape and which are not listen in 30/31 table at all Just for now: (after 1 hour after reboot and i'm 100% sure such IP was not in tables 30/31 for this 1 hour) $ sudo ipfw table 31 list | egrep 10.10.101.120 $ sudo ipfw table 30 list | egrep 10.10.101.120 $ sudo ipfw pipe list | egrep 10.10.101.120 12652 ip 0.0.0.0/0 10.10.101.120/0 8463 3827439 0 0 0 $ sudo ipfw pipe list | egrep 10.10.101.120 12652 ip 0.0.0.0/0 10.10.101.120/0 8478 3831640 0 0 0 So, traffic come to pipe (here, in example, this is pipe 101, but possible to be any pipe used in system). There no other calls for pipes in firewall rooles. Here are other tables used in firewall, where possible we have such IP, but other tables not checked here. And, if we checks speed from IP 10.10.101.120, we wioll see this is really shaped to speed of pipe 101, so this is not print error, this is actually shaped by this pipe. Some details about system: FreeBSD xxx.xxx.xxx 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed Aug 26 14:56:23 MSD 2009 root@xxx.xxx.xxx:/usr/obj/usr/src/sys/xxxxxxxxx amd64 System was rebuild today, CVSUPed yesterday.after I found this problem. First time I saw such problem 2 years (or about) ago on 7.0 amd64. but before I fixed it by reboot and problem come again not so often.... but now it come again and again. I never saw it at 6.x or 5.x. also, 2 years ago here was not tablearg at my firewall set. here was lot of rooles like .. 20000 pipe 122 ip from any to table(122) xmit em1 out 20000 pipe 1122 ip from table(122) to any recv em1 in 20000 pipe 123 ip from any to table(123) xmit em1 out 20000 pipe 1123 ip from table(123) to any recv em1 in .. Also, here are some small tuning of pipes: net.inet.ip.dummynet.hash_size=16384 net.inet.ip.dummynet.expire=0 ipfw and dumminet complied in the kernel. sudo ipfw l | wc -l ipfw: DEPRECATED: 'l' matched 'list' as a sub-string 69 Any ideas? sorry for my english. :< With best regards /Alexey From hrs at FreeBSD.org Wed Aug 26 17:29:30 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Wed Aug 26 17:29:37 2009 Subject: IPv6 regression on 8.x Message-ID: <20090827.022654.83897589.hrs@allbsd.org> Hi, I found there are serious regressions in IPv6 routing on 8.x (and 7.1R and later) after ARP/NDP changes in the last December. What I noticed are the following: 1) Scope violation in a simple global unicast address: # ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 # ping6 2001:db8:1::1 PING6(56=40+8+8 bytes) 2001:db8:1::1 --> 2001:db8:1::1 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.195 ms --> 2001:db8:1::1 has a routing entry with lo0, but ::1 should not be used in the reply packet. On 7.x, 2001:db8:1::1 is used as expected. 2) Issue of subnet-router anycast address with a global address on another I/F: box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 box-1# ifconfig em0 inet6 2001:db8:1:: prefixlen 64 anycast box-2# ifconfig re0 inet6 2001:db8:1::6 prefixlen 64 box-2# ping6 2001:db8:1:: PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1:: 16 bytes from 2001:db8:1::1, icmp_seq=0 hlim=64 time=0.439 ms ^C box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 -alias box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64 box-2# ping6 2001:db8:1:: PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1:: 16 bytes from fe80::213:a9ff:feff:63e6%re0, icmp_seq=0 hlim=64 time=0.405 ms ^C --> The em0 and re0 are on the same link with each other. In 7.x, replies are from 2001:db8:2::1, not fe80::/64. 3) Manually-configured subnet routes disapper on receiving RA: box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64 box-1# netstat -nrf inet6 | grep ^2001:db8 2001:db8:1::/64 link#1 U em0 2001:db8:1::1 link#5 UHS lo0 2001:db8:2::/64 link#6 U em1 2001:db8:2::1 link#5 UHS lo0 box-1# sysctl net.inet6.ip6.accept_rtadv=1 box-1# rtsol em0 box-1# netstat -nrf inet6 | grep ^2001:db8 2001:db8:1::1 link#5 UHS lo0 2001:db8:2::1 link#5 UHS lo0 --> This symptom occurs on 7.1R and later, including 8.x and 9-current, not 7.0R. Even by doing a manual configuration, the routes on the RA-receiving I/F can not be added. I am very concerned that these bugs would disappoint IPv6 users in production environments if we ship 8.0R without fixing them. -- Hiroki -------------- 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/20090826/3a809235/attachment.pgp From vanhu at FreeBSD.org Wed Aug 26 21:00:36 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Wed Aug 26 21:01:08 2009 Subject: NAT-T patch for 7-STABLE In-Reply-To: <20090813154703.Y93661@maildrop.int.zabbadoz.net> References: <20090813154703.Y93661@maildrop.int.zabbadoz.net> Message-ID: <20090826204500.GB9228@zeninc.net> On Thu, Aug 13, 2009 at 04:04:05PM +0000, Bjoern A. Zeeb wrote: > Hi, Hi. Sorry for the very late answer, but I wanted to work on the userland part as soon as I had your patch, then I had an unexpected failure in my internet access (still not completely resolved, hope you'll get this mail). > I just MFCed the UDP Control Block, which is a prerequisite for merging > the NAT-T patch from HEAD (8) to 7-STABLE: > http://svn.freebsd.org/viewvc/base?view=revision&revision=196192 > > I also merged back the NAT-T changes from FreeBSD 8/HEAD. This > will allow us to provide the same API for tools for FreeBSD 7 (with > patch) and stock FreeBSD 8.x and 9 (HEAD). Great ! With that, I could easilly start tests on kernel+userland. ipsec-tools HEAD is now expected to compile/work with that kernel API, and I have a running tunnel with FreeBSD7+patchset+ipsec-tools HEAD as the responder (with NAT-T used). More tests will come soon, but please all report any issue ! Latest ipsec-tools snapshot will also compile and work (actually, this is exactly the same as HEAD, except some typo fixes....) with that API. Yvan. From bzeeb-lists at lists.zabbadoz.net Wed Aug 26 21:30:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Aug 26 21:30:16 2009 Subject: NAT-T patch for 7-STABLE In-Reply-To: <20090826204500.GB9228@zeninc.net> References: <20090813154703.Y93661@maildrop.int.zabbadoz.net> <20090826204500.GB9228@zeninc.net> Message-ID: <20090826210423.H93661@maildrop.int.zabbadoz.net> On Wed, 26 Aug 2009, VANHULLEBUS Yvan wrote: Hi, > On Thu, Aug 13, 2009 at 04:04:05PM +0000, Bjoern A. Zeeb wrote: >> Hi, > > Hi. > Sorry for the very late answer, but I wanted to work on the userland > part as soon as I had your patch, then I had an unexpected failure in > my internet access (still not completely resolved, hope you'll get > this mail). > > >> I just MFCed the UDP Control Block, which is a prerequisite for merging >> the NAT-T patch from HEAD (8) to 7-STABLE: >> http://svn.freebsd.org/viewvc/base?view=revision&revision=196192 >> >> I also merged back the NAT-T changes from FreeBSD 8/HEAD. This >> will allow us to provide the same API for tools for FreeBSD 7 (with >> patch) and stock FreeBSD 8.x and 9 (HEAD). > > Great ! > > With that, I could easilly start tests on kernel+userland. Fantastic; I had hoped that. > ipsec-tools HEAD is now expected to compile/work with that kernel API, > and I have a running tunnel with FreeBSD7+patchset+ipsec-tools HEAD as > the responder (with NAT-T used). > > More tests will come soon, but please all report any issue ! > > > Latest ipsec-tools snapshot will also compile and work (actually, this > is exactly the same as HEAD, except some typo fixes....) with that API. Yes, I could remove my private patches to make ipsec-tools HEAD compile on FreeBSD 8/9 or 7+patch after the latest update two days ago. For anyone brave enough to track the bleeding edge of all worlds, I have put together an initial start of a collection of things... The following is not for you if you: (1) don't know how to apply a patch to the kernel, recompile your kernel or wonder what I am talking about. (2) if you don't know freebsd ports creation and compiling bascis. You'll need change the makefile, touch internals, run a cvs checkout, ... (3) don't know how to not shoot yourself in the foot ----- my text template that I should streamline put on the wiki;) ------ If you are on FreeBSD 6 or earlier, you can stop reading here. In case you are on 7-STABLE before r196192 either update to latest 7-STABLE or take the patch from SVN r196192 or http://people.freebsd.org/~bz/20090730-01-mfc-r192649-udpcb.diff (which should be the same modulo the naming of the spare in the struct field "notyetmfced" vs. u_pspare). In case you are on 7-STABLE or applied the previous patch) you'll need this patch on top for NAT-T: http://people.freebsd.org/~bz/20090813-01-mfc-r194062-natt.diff . In case you are on a recent FreeBSD 8 or FreeBSD 9, you need no patches for the kernel. To build an ipsec-tools-devel CVS HEAD checkout port: apply the patch from .. to your ports tree http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/138139 and give the instructions from this one and below a try: http://people.freebsd.org/~bz/20090824-ipsec-tools.tar.gz (basically the cvs checkout and the tarball creation; I guess it's lacking a make makesum at the end) It may give you something usable. I am not trying the snapshot regularly and the port isn't ready to be used as a automatic port as you have to do it all by hand incl. updating PORTVERSION, the cvs checkout, creating the tarball, make makesum and all that. But at least for me it compiles the CVS checkout directly, with the port options from below, on a 8.x/9.x system, without the needs for doing any autocrap stuff manually before creating the src tarball. You may change the port options of course, I just cannot test all combinations to see if they work. If doing this on 7.x make sure to have the kernel patch(es) mentioned above applied upfront and have the headers installed correctly before you start building the port. Successfully tested combination of options: WITH_DEBUG=true WITH_IPV6=true WITHOUT_ADMINPORT=true WITHOUT_STATS=true WITH_DPD=true WITH_NATT=true WITH_NATTF=true WITH_FRAG=true WITH_HYBRID=true WITHOUT_PAM=true WITHOUT_RADIUS=true WITHOUT_LDAP=true WITHOUT_GSSAPI=true WITHOUT_SAUNSPEC=true WITH_RC5=true WITH_IDEA=true WITHOUT_READLINE=true ------------------------------------------------------------------------ /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From qing.li at bluecoat.com Wed Aug 26 21:56:40 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Wed Aug 26 21:57:44 2009 Subject: IPv6 regression on 8.x In-Reply-To: <20090827.022654.83897589.hrs@allbsd.org> References: <20090827.022654.83897589.hrs@allbsd.org> Message-ID: Hi Hiroki, > > > 1) Scope violation in a simple global unicast address: > > 2) Issue of subnet-router anycast address with a global address on > another I/F: > > I have fixed the above regression issues last week, but due to traveling, I did not commit the fix until about 5 minutes ago. Please sync-up to "svn-r196569" and let me know how the patch works out for you. I have tested the patch myself using your examples and the patch produces the expected results. This patch also fixes another issue, and using your example, where packets received on em0 that are destined for either re0 or em1 cannot get any response packets. > > 3) Manually-configured subnet routes disapper on receiving RA: > > > --> This symptom occurs on 7.1R and later, including 8.x and > 9-current, not 7.0R. Even by doing a manual configuration, the > routes on the RA-receiving I/F can not be added. > The new L2/L3 rewrite only applies to 8.x and 9-current. Since this symptom occurs also on 7.1R, and this is the first I heard of it, I will investigate further and get back to you, soon. Thanks, -- Qing From vanhu at FreeBSD.org Thu Aug 27 11:34:38 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Thu Aug 27 11:34:45 2009 Subject: NAT-T patch for 7-STABLE In-Reply-To: <20090826210423.H93661@maildrop.int.zabbadoz.net> References: <20090813154703.Y93661@maildrop.int.zabbadoz.net> <20090826204500.GB9228@zeninc.net> <20090826210423.H93661@maildrop.int.zabbadoz.net> Message-ID: <20090827111626.GB11104@zeninc.net> On Wed, Aug 26, 2009 at 09:28:11PM +0000, Bjoern A. Zeeb wrote: [....] > For anyone brave enough to track the bleeding edge of all worlds, I > have put together an initial start of a collection of things... For those brave people: please report issues AND success setups, and give us precisions: initiator, responder, generate_policy or not, NAT-T used in the tunnel or not, tunnel or transport, FreeBSD7+patch or FreeBSD8 or FreeBSD9, etc.... Yvan. From qing.li at bluecoat.com Fri Aug 28 07:29:51 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Aug 28 08:13:05 2009 Subject: a few fixes for network problems In-Reply-To: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> Message-ID: Please apply the patch at http://people.freebsd.org/~qingli/patch-8-27-net.diff This patch fixes the following issue (some referenced in http://wiki.freebsd.org/8.0TODO) 1. RTM_CHANGE in net/rtsock.c can incorrectly set RTF_GATEWAY I went through the implementation for the various utilities (route, arp, ndp, ppp etc.) on how the routing commands and the associated parameters are packaged and issued. In addition, having reviewed the discussion thread that took place a couple of months on this subject, I decided the best way to address this category of problems is to fix the routing socket command handler in rtsock.c. So this patch should address the if_tun interface route issue, where the route entry for the tunnel end points has the "G" (gateway) flag bit set. Joe Marcus helped me verify the patch for ppp. I performed unit testing for the if_tun case as described in the recent bug report. I also performed the tests where I issued various "route" command, specifically, I issued "route change 192.168.1.2 192.168.1.1 -mtu 1400" on a tunnel route (192.168.1.2 is the remote end, and 192.168.1.1 is the local end of the tunnel), and the patch produces the expected result. 2. flowtable mishandles gateway (G) routes on POINT2POINT interfaces This problem was reported last Wednesday, which I responded to on the mailing list before my trip. The flow-table code should not try to cache L2/L3 info if the interface type is of IFF_POINTOPOINT or IFF_LOOPBACK type. The code can be optimized to reduce the number of calls to rtalloc(), but I will postpone those changes to post 8.0 release. Excessive message of "IPv4 address: \"%s\" is not on the network" was triggered by the above bug and should be fixed by this patch. Also, the panic seen in if_tun output function should also be fixed. 3. reproducible panic under load on BETA-3 ip_output() should not try to free a LLE entry from the route cache if that route cache was not initialized by the flow-table. ro_lle field in the LLE entry is valid only if it came from the flow-table. Please apply the patch and let me know if these issues have been Addressed. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Denis Ahrens > Sent: Wednesday, August 19, 2009 12:59 AM > To: freebsd-current@freebsd.org > Subject: network problems > > Hi > > After installing the latest CURRENT from today I see strange network > problems. > > The problems are similar to http://lists.freebsd.org/pipermail/freebsd- > current/2009-August/010287.html > > I see alot of this in the log: > > Aug 19 09:33:39 monolith kernel: IPv4 address: "213.191.89.1" is not > on the network > Aug 19 09:33:57 monolith last message repeated 22 times > Aug 19 09:36:07 monolith last message repeated 6 times > Aug 19 09:38:19 monolith last message repeated 15 times > > 213.191.89.1 is my ppp endpoint: > > tun0: flags=8051 metric 0 mtu 1492 > inet 85.178.62.185 --> 213.191.89.1 netmask 0xffffffff > Opened by PID 1351 > > When I try to ping the address the machine panics! > (something with sin_family and in_lltable_lookup) > http://denisy.dyndns.org/panic.jpg > > While restarting the ppp daemon I see this in the logs: > > Aug 19 09:33:33 monolith kernel: tun0: link state changed to UP > Aug 19 09:33:38 monolith ppp[1351]: tun0: Warning: 0.0.0.0: Change > route failed: errno: No such process > > I don't know if it is related at all. > > netstat -rn > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 213.191.89.1 UGS 0 12579 tun0 > 10.1.2.0/24 link#1 U 2 18778 re0 > 10.1.2.1 link#4 UHS 0 0 lo0 > 85.178.62.185 link#4 UHS 0 0 lo0 > 127.0.0.1 link#4 UH 0 87 lo0 > 213.191.89.1 link#5 UGHS 0 0 tun0 > > Denis > > _______________________________________________ > 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 qing.li at bluecoat.com Fri Aug 28 07:29:56 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Aug 28 08:13:54 2009 Subject: IPv6 regression on 8.x Message-ID: Hi, The problems you raised: > > 1) Scope violation in a simple global unicast address: > > 2) Issue of subnet-router anycast address with a global address on > another I/F: > The above two issues should be fixed by r196569. Please confirm. > > 3) Manually-configured subnet routes disapper on receiving RA: > I've found the problem and have a fix. I will do some more investigation. Please try the patch at http://people.freebsd.org/~qingli/patch-8-27-ipv6.diff I have done unit testing and RA no longer removes the statically configured prefixes. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Hiroki Sato > Sent: Wednesday, August 26, 2009 10:27 AM > To: net@freebsd.org; re@freebsd.org > Cc: qingli@freebsd.org > Subject: IPv6 regression on 8.x > > Hi, > > I found there are serious regressions in IPv6 routing on 8.x (and > 7.1R and later) after ARP/NDP changes in the last December. What I > noticed are the following: > > 1) Scope violation in a simple global unicast address: > > # ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 > # ping6 2001:db8:1::1 > PING6(56=40+8+8 bytes) 2001:db8:1::1 --> 2001:db8:1::1 > 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.195 ms > > --> 2001:db8:1::1 has a routing entry with lo0, but ::1 should not be > used in the reply packet. On 7.x, 2001:db8:1::1 is used as > expected. > > 2) Issue of subnet-router anycast address with a global address on > another I/F: > > box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 > box-1# ifconfig em0 inet6 2001:db8:1:: prefixlen 64 anycast > box-2# ifconfig re0 inet6 2001:db8:1::6 prefixlen 64 > box-2# ping6 2001:db8:1:: > PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1:: > 16 bytes from 2001:db8:1::1, icmp_seq=0 hlim=64 time=0.439 ms > ^C > box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 -alias > box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64 > box-2# ping6 2001:db8:1:: > PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1:: > 16 bytes from fe80::213:a9ff:feff:63e6%re0, icmp_seq=0 hlim=64 > time=0.405 ms > ^C > > --> The em0 and re0 are on the same link with each other. In 7.x, > replies are from 2001:db8:2::1, not fe80::/64. > > 3) Manually-configured subnet routes disapper on receiving RA: > > box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 > box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64 > box-1# netstat -nrf inet6 | grep ^2001:db8 > 2001:db8:1::/64 link#1 U > em0 > 2001:db8:1::1 link#5 UHS > lo0 > 2001:db8:2::/64 link#6 U > em1 > 2001:db8:2::1 link#5 UHS > lo0 > box-1# sysctl net.inet6.ip6.accept_rtadv=1 > box-1# rtsol em0 > box-1# netstat -nrf inet6 | grep ^2001:db8 > 2001:db8:1::1 link#5 UHS > lo0 > 2001:db8:2::1 link#5 UHS > lo0 > > --> This symptom occurs on 7.1R and later, including 8.x and > 9-current, not 7.0R. Even by doing a manual configuration, the > routes on the RA-receiving I/F can not be added. > > I am very concerned that these bugs would disappoint IPv6 users in > production environments if we ship 8.0R without fixing them. > > -- Hiroki From qing.li at bluecoat.com Fri Aug 28 07:33:15 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Aug 28 08:26:31 2009 Subject: a few fixes for network problems Message-ID: Please apply the patch at http://people.freebsd.org/~qingli/patch-8-27-net.diff This patch fixes the following issue (some referenced in http://wiki.freebsd.org/8.0TODO) 1. RTM_CHANGE in net/rtsock.c can incorrectly set RTF_GATEWAY I went through the implementation for the various utilities (route, arp, ndp, ppp etc.) on how the routing commands and the associated parameters are packaged and issued. In addition, having reviewed the discussion thread that took place a couple of months on this subject, I decided the best way to address this category of problems is to fix the routing socket command handler in rtsock.c. So this patch should address the if_tun interface route issue, where the route entry for the tunnel end points has the "G" (gateway) flag bit set. Joe Marcus helped me verify the patch for ppp. I performed unit testing for the if_tun case as described in the recent bug report. I also performed the tests where I issued various "route" command, specifically, I issued "route change 192.168.1.2 192.168.1.1 -mtu 1400" on a tunnel route (192.168.1.2 is the remote end, and 192.168.1.1 is the local end of the tunnel), and the patch produces the expected result. 2. flowtable mishandles gateway (G) routes on POINT2POINT interfaces This problem was reported last Wednesday, which I responded to on the mailing list before my trip. The flow-table code should not try to cache L2/L3 info if the interface type is of IFF_POINTOPOINT or IFF_LOOPBACK type. The code can be optimized to reduce the number of calls to rtalloc(), but I will postpone those changes to post 8.0 release. Excessive message of "IPv4 address: \"%s\" is not on the network" was triggered by the above bug and should be fixed by this patch. Also, the panic seen in if_tun output function should also be fixed. 3. reproducible panic under load on BETA-3 ip_output() should not try to free a LLE entry from the route cache if that route cache was not initialized by the flow-table. ro_lle field in the LLE entry is valid only if it came from the flow-table. Please apply the patch and let me know if these issues have been Addressed. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Denis Ahrens > Sent: Wednesday, August 19, 2009 12:59 AM > To: freebsd-current@freebsd.org > Subject: network problems > > Hi > > After installing the latest CURRENT from today I see strange network > problems. > > The problems are similar to http://lists.freebsd.org/pipermail/freebsd- > current/2009-August/010287.html > > I see alot of this in the log: > > Aug 19 09:33:39 monolith kernel: IPv4 address: "213.191.89.1" is not > on the network > Aug 19 09:33:57 monolith last message repeated 22 times > Aug 19 09:36:07 monolith last message repeated 6 times > Aug 19 09:38:19 monolith last message repeated 15 times > > 213.191.89.1 is my ppp endpoint: > > tun0: flags=8051 metric 0 mtu 1492 > inet 85.178.62.185 --> 213.191.89.1 netmask 0xffffffff > Opened by PID 1351 > > When I try to ping the address the machine panics! > (something with sin_family and in_lltable_lookup) > http://denisy.dyndns.org/panic.jpg > > While restarting the ppp daemon I see this in the logs: > > Aug 19 09:33:33 monolith kernel: tun0: link state changed to UP > Aug 19 09:33:38 monolith ppp[1351]: tun0: Warning: 0.0.0.0: Change > route failed: errno: No such process > > I don't know if it is related at all. > > netstat -rn > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 213.191.89.1 UGS 0 12579 tun0 > 10.1.2.0/24 link#1 U 2 18778 re0 > 10.1.2.1 link#4 UHS 0 0 lo0 > 85.178.62.185 link#4 UHS 0 0 lo0 > 127.0.0.1 link#4 UH 0 87 lo0 > 213.191.89.1 link#5 UGHS 0 0 tun0 > > Denis > > _______________________________________________ > 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 qing.li at bluecoat.com Fri Aug 28 07:34:08 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Aug 28 08:29:14 2009 Subject: IPv6 regression on 8.x In-Reply-To: <20090827.022654.83897589.hrs@allbsd.org> References: <20090827.022654.83897589.hrs@allbsd.org> Message-ID: Hi, The problems you raised: > > 1) Scope violation in a simple global unicast address: > > 2) Issue of subnet-router anycast address with a global address on > another I/F: > The above two issues should be fixed by r196569. Please confirm. > > 3) Manually-configured subnet routes disapper on receiving RA: > I've found the problem and have a fix. I will do some more investigation. Please try the patch at http://people.freebsd.org/~qingli/patch-8-27-ipv6.diff I have done unit testing and RA no longer removes the statically configured prefixes. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Hiroki Sato > Sent: Wednesday, August 26, 2009 10:27 AM > To: net@freebsd.org; re@freebsd.org > Cc: qingli@freebsd.org > Subject: IPv6 regression on 8.x > > Hi, > > I found there are serious regressions in IPv6 routing on 8.x (and > 7.1R and later) after ARP/NDP changes in the last December. What I > noticed are the following: > > 1) Scope violation in a simple global unicast address: > > # ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 > # ping6 2001:db8:1::1 > PING6(56=40+8+8 bytes) 2001:db8:1::1 --> 2001:db8:1::1 > 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.195 ms > > --> 2001:db8:1::1 has a routing entry with lo0, but ::1 should not be > used in the reply packet. On 7.x, 2001:db8:1::1 is used as > expected. > > 2) Issue of subnet-router anycast address with a global address on > another I/F: > > box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 > box-1# ifconfig em0 inet6 2001:db8:1:: prefixlen 64 anycast > box-2# ifconfig re0 inet6 2001:db8:1::6 prefixlen 64 > box-2# ping6 2001:db8:1:: > PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1:: > 16 bytes from 2001:db8:1::1, icmp_seq=0 hlim=64 time=0.439 ms > ^C > box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 -alias > box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64 > box-2# ping6 2001:db8:1:: > PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1:: > 16 bytes from fe80::213:a9ff:feff:63e6%re0, icmp_seq=0 hlim=64 > time=0.405 ms > ^C > > --> The em0 and re0 are on the same link with each other. In 7.x, > replies are from 2001:db8:2::1, not fe80::/64. > > 3) Manually-configured subnet routes disapper on receiving RA: > > box-1# ifconfig em0 inet6 2001:db8:1::1 prefixlen 64 > box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64 > box-1# netstat -nrf inet6 | grep ^2001:db8 > 2001:db8:1::/64 link#1 U > em0 > 2001:db8:1::1 link#5 UHS > lo0 > 2001:db8:2::/64 link#6 U > em1 > 2001:db8:2::1 link#5 UHS > lo0 > box-1# sysctl net.inet6.ip6.accept_rtadv=1 > box-1# rtsol em0 > box-1# netstat -nrf inet6 | grep ^2001:db8 > 2001:db8:1::1 link#5 UHS > lo0 > 2001:db8:2::1 link#5 UHS > lo0 > > --> This symptom occurs on 7.1R and later, including 8.x and > 9-current, not 7.0R. Even by doing a manual configuration, the > routes on the RA-receiving I/F can not be added. > > I am very concerned that these bugs would disappoint IPv6 users in > production environments if we ship 8.0R without fixing them. > > -- Hiroki From Michael.Tuexen at lurchi.franken.de Fri Aug 28 09:00:12 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Aug 28 09:00:18 2009 Subject: routing message problem Message-ID: Dear all, via a bug report from Preethi I figured out that there are no RTM_NEWADDR routing messages generated when an IP address is added to an interface and there is already an address in the same network configured. This is a problem for the SCTP stack. To reproduce the problem you can sudo ifconfig em0 192.168.1.1 sudo ifconfig em0 192.168.1.2 alias and use the attached problem. It will only show the first address being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 RELEASE. Any idea how to fix the problem? Best regards Michael From Michael.Tuexen at lurchi.franken.de Fri Aug 28 09:02:01 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Aug 28 09:02:09 2009 Subject: routing message problem In-Reply-To: References: Message-ID: <5467E669-F6F3-46E6-9978-111E42DAB328@lurchi.franken.de> ... I forgot to attach the program... -------------- next part -------------- A non-text attachment was scrubbed... Name: aw.c Type: application/octet-stream Size: 2125 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090828/1ec5a0af/aw.obj -------------- next part -------------- On Aug 28, 2009, at 11:00 AM, Michael T?xen wrote: > Dear all, > > via a bug report from Preethi I figured out that there are no > RTM_NEWADDR > routing messages generated when an IP address is added to an interface > and there is already an address in the same network configured. > This is a problem for the SCTP stack. > > To reproduce the problem you can > sudo ifconfig em0 192.168.1.1 > sudo ifconfig em0 192.168.1.2 alias > > and use the attached problem. It will only show the first address > being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 > RELEASE. > > Any idea how to fix the problem? > > Best regards > Michael > From linimon at FreeBSD.org Fri Aug 28 11:44:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Aug 28 11:44:40 2009 Subject: kern/138266: [panic] kernel panic when udp benchmark test used as regular user Message-ID: <200908281144.n7SBiSqi087119@freefall.freebsd.org> Old Synopsis: kernel panic when udp benchmark test used as regular user New Synopsis: [panic] kernel panic when udp benchmark test used as regular user Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 28 11:44:11 UTC 2009 Responsible-Changed-Why: Could be network-related? http://www.freebsd.org/cgi/query-pr.cgi?pr=138266 From ume at freebsd.org Fri Aug 28 15:58:40 2009 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Fri Aug 28 16:05:34 2009 Subject: IPv6 regression on 8.x In-Reply-To: References: Message-ID: Hi, >>>>> On Thu, 27 Aug 2009 21:20:42 -0700 >>>>> "Li, Qing" said: > 1) Scope violation in a simple global unicast address: > > 2) Issue of subnet-router anycast address with a global address on > another I/F: qing.li> The above two issues should be fixed by r196569. Please confirm. I confirmed that 1) is fixed on my RELENG_8 box with r196569 applied. I don't have an environment to test 2), though. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From dzakpunk at gmail.com Fri Aug 28 17:15:21 2009 From: dzakpunk at gmail.com (Rakhmadhany Primananda) Date: Fri Aug 28 17:15:29 2009 Subject: SIP Express Router and Mediaproxy Message-ID: <56f73d330908280954x777e6317ud8467e55ce05c034@mail.gmail.com> Hi,, I want to ask about SER and Mediaproxy. I'm using freebsd 6.2 and installing SER 0.9.6 with Mediaproxy 1.8. Could you help me,how to running Mediaproxy with SER in one machine? Thanks,, Dhany From qing.li at bluecoat.com Fri Aug 28 17:25:17 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Aug 28 17:25:24 2009 Subject: routing message problem In-Reply-To: References: Message-ID: > > Dear all, > > via a bug report from Preethi I figured out that there are no > RTM_NEWADDR > routing messages generated when an IP address is added to an interface > and there is already an address in the same network configured. > This is a problem for the SCTP stack. > > To reproduce the problem you can > sudo ifconfig em0 192.168.1.1 > sudo ifconfig em0 192.168.1.2 alias > > and use the attached problem. It will only show the first address > being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 > RELEASE. > > Any idea how to fix the problem? > Please try my patch (not the final version) at http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff I have tested it and seems to work as expected. You should get the notifications for both address insertion ("alias") and deletion ("-alias"). Let me know if it's to your satisfaction. I found a couple of other issues while looking over the code. 1. in_scrubprefix() is called unnecessarily in 2 locations 2. the loopback host route is not removed for an alias On a related note, in.c can use some code cleanup. I think I will do that post 8.0 release. Thanks, -- Qing From Michael.Tuexen at lurchi.franken.de Fri Aug 28 18:48:32 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Aug 28 18:48:38 2009 Subject: routing message problem In-Reply-To: References: Message-ID: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> Hi Qing, your patch fixes the issue. Will it find its way into 8.0? Will it find its way into 7.3? Best regards Michael On Aug 28, 2009, at 7:24 PM, Li, Qing wrote: >> >> Dear all, >> >> via a bug report from Preethi I figured out that there are no >> RTM_NEWADDR >> routing messages generated when an IP address is added to an >> interface >> and there is already an address in the same network configured. >> This is a problem for the SCTP stack. >> >> To reproduce the problem you can >> sudo ifconfig em0 192.168.1.1 >> sudo ifconfig em0 192.168.1.2 alias >> >> and use the attached problem. It will only show the first address >> being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 >> RELEASE. >> >> Any idea how to fix the problem? >> > > > Please try my patch (not the final version) at > > http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff > > > I have tested it and seems to work as expected. You should > get the notifications for both address insertion ("alias") > and deletion ("-alias"). > > Let me know if it's to your satisfaction. > > I found a couple of other issues while looking over the code. > > 1. in_scrubprefix() is called unnecessarily in 2 locations > 2. the loopback host route is not removed for an alias > > On a related note, in.c can use some code cleanup. I think > I will do that post 8.0 release. > > Thanks, > > -- Qing > > From linimon at FreeBSD.org Sat Aug 29 13:48:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Aug 29 13:48:11 2009 Subject: kern/138292: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 Message-ID: <200908291348.n7TDm33R003053@freefall.freebsd.org> Old Synopsis: "zyd0: device timeout" with ZyXEL G-202 New Synopsis: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Aug 29 13:45:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138292 From hrs at FreeBSD.org Sat Aug 29 17:44:52 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sat Aug 29 17:45:00 2009 Subject: IPv6 regression on 8.x In-Reply-To: References: Message-ID: <20090830.024420.174808572.hrs@allbsd.org> "Li, Qing" wrote in : qi> Hi, qi> qi> The problems you raised: qi> qi> > qi> > 1) Scope violation in a simple global unicast address: qi> > qi> > 2) Issue of subnet-router anycast address with a global address on qi> > another I/F: qi> > qi> qi> The above two issues should be fixed by r196569. Please confirm. qi> qi> > 3) Manually-configured subnet routes disapper on receiving RA: qi> > qi> qi> I've found the problem and have a fix. I will do some more qi> investigation. qi> Please try the patch at qi> qi> http://people.freebsd.org/~qingli/patch-8-27-ipv6.diff Thanks for the fixes! With the two patches 1) and 3) are gone, but 2) still remains. Is there something I can help to narrow down it? -- Hiroki -------------- 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/20090829/06df17cb/attachment.pgp From qing.li at bluecoat.com Sun Aug 30 02:14:28 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Aug 30 02:14:34 2009 Subject: routing message problem In-Reply-To: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> References: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> Message-ID: Hi Michael, > > your patch fixes the issue. > Will it find its way into 8.0? > Will it find its way into 7.3? > Yes, the patch will make its way into 8.0 Release and 7.3, too. Thanks, -- Qing > > On Aug 28, 2009, at 7:24 PM, Li, Qing wrote: > > >> > >> Dear all, > >> > >> via a bug report from Preethi I figured out that there are no > >> RTM_NEWADDR > >> routing messages generated when an IP address is added to an > >> interface > >> and there is already an address in the same network configured. > >> This is a problem for the SCTP stack. > >> > >> To reproduce the problem you can > >> sudo ifconfig em0 192.168.1.1 > >> sudo ifconfig em0 192.168.1.2 alias > >> > >> and use the attached problem. It will only show the first address > >> being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 > >> RELEASE. > >> > >> Any idea how to fix the problem? > >> > > > > > > Please try my patch (not the final version) at > > > > http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff > > > > > > I have tested it and seems to work as expected. You should > > get the notifications for both address insertion ("alias") > > and deletion ("-alias"). > > > > Let me know if it's to your satisfaction. > > > > I found a couple of other issues while looking over the code. > > > > 1. in_scrubprefix() is called unnecessarily in 2 locations > > 2. the loopback host route is not removed for an alias > > > > On a related note, in.c can use some code cleanup. I think > > I will do that post 8.0 release. > > > > Thanks, > > > > -- Qing > > > > From Michael.Tuexen at lurchi.franken.de Sun Aug 30 06:05:23 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Sun Aug 30 06:05:30 2009 Subject: routing message problem In-Reply-To: References: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> Message-ID: On Aug 30, 2009, at 4:08 AM, Li, Qing wrote: > Hi Michael, >> >> your patch fixes the issue. >> Will it find its way into 8.0? >> Will it find its way into 7.3? >> > > Yes, the patch will make its way into 8.0 Release and 7.3, too. Great! Thanks a lot. Best regards Michael > > Thanks, > > -- Qing > > >> >> On Aug 28, 2009, at 7:24 PM, Li, Qing wrote: >> >>>> >>>> Dear all, >>>> >>>> via a bug report from Preethi I figured out that there are no >>>> RTM_NEWADDR >>>> routing messages generated when an IP address is added to an >>>> interface >>>> and there is already an address in the same network configured. >>>> This is a problem for the SCTP stack. >>>> >>>> To reproduce the problem you can >>>> sudo ifconfig em0 192.168.1.1 >>>> sudo ifconfig em0 192.168.1.2 alias >>>> >>>> and use the attached problem. It will only show the first address >>>> being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 >>>> RELEASE. >>>> >>>> Any idea how to fix the problem? >>>> >>> >>> >>> Please try my patch (not the final version) at >>> >>> http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff >>> >>> >>> I have tested it and seems to work as expected. You should >>> get the notifications for both address insertion ("alias") >>> and deletion ("-alias"). >>> >>> Let me know if it's to your satisfaction. >>> >>> I found a couple of other issues while looking over the code. >>> >>> 1. in_scrubprefix() is called unnecessarily in 2 locations >>> 2. the loopback host route is not removed for an alias >>> >>> On a related note, in.c can use some code cleanup. I think >>> I will do that post 8.0 release. >>> >>> Thanks, >>> >>> -- Qing >>> >>> > > From linimon at FreeBSD.org Sun Aug 30 07:33:16 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Aug 30 07:33:23 2009 Subject: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Message-ID: <200908300733.n7U7XFnK014980@freefall.freebsd.org> Old Synopsis: FreeBSD 8.0-beta3 wpa_supplicant lost auth New Synopsis: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 30 07:32:41 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138331 From linimon at FreeBSD.org Sun Aug 30 09:22:55 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Aug 30 09:23:02 2009 Subject: kern/138332: [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BETA3 Message-ID: <200908300922.n7U9Mtsk035480@freefall.freebsd.org> Old Synopsis: ifconfig tun0 destroy causes LOR on 8.0-BETA3 New Synopsis: [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BETA3 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 30 09:22:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138332 From sam at errno.com Sun Aug 30 17:50:03 2009 From: sam at errno.com (Sam Leffler) Date: Sun Aug 30 17:50:10 2009 Subject: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Message-ID: <200908301750.n7UHo3Lg060702@freefall.freebsd.org> The following reply was made to PR bin/138331; it has been noted by GNATS. From: Sam Leffler To: bug-followup@FreeBSD.org, sshutdownow@gmail.com Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Date: Sun, 30 Aug 2009 10:28:47 -0700 You appear to say this problem does not entirely stop traffic from flowing. Please provide a debug wpa_supplicant log that shows a complete session (i.e. a log with -d and/or -dd). Why do you set eapol_version=1. Is this really needed? What is your AP make/model? Note also that country=RU is ignored on freebsd. Sam From sshutdownow at gmail.com Sun Aug 30 19:00:05 2009 From: sshutdownow at gmail.com (Igor Popov) Date: Sun Aug 30 19:00:13 2009 Subject: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Message-ID: <200908301900.n7UJ05Ap030533@freefall.freebsd.org> The following reply was made to PR bin/138331; it has been noted by GNATS. From: Igor Popov To: Sam Leffler Cc: bug-followup@freebsd.org Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Date: Sun, 30 Aug 2009 21:33:20 +0300 --0014852f5780d7c3810472602664 Content-Type: text/plain; charset=UTF-8 Hi, Sam. man (5) for wpa_supplicant.conf stands that it is default value, but when I commented out this parameter nothing has changed. I ping IP of Access Point: $ ping 192.168.12.1 PING 192.168.12.1 (192.168.12.1): 56 data bytes 64 bytes from 192.168.12.1: icmp_seq=0 ttl=128 time=6.450 ms 64 bytes from 192.168.12.1: icmp_seq=3 ttl=128 time=0.762 ms 64 bytes from 192.168.12.1: icmp_seq=25 ttl=128 time=0.743 ms 64 bytes from 192.168.12.1: icmp_seq=75 ttl=128 time=0.755 ms 64 bytes from 192.168.12.1: icmp_seq=79 ttl=128 time=0.959 ms 64 bytes from 192.168.12.1: icmp_seq=103 ttl=128 time=0.740 ms 64 bytes from 192.168.12.1: icmp_seq=162 ttl=128 time=5.322 ms 64 bytes from 192.168.12.1: icmp_seq=164 ttl=128 time=5.705 ms 64 bytes from 192.168.12.1: icmp_seq=165 ttl=128 time=22.138 ms 64 bytes from 192.168.12.1: icmp_seq=166 ttl=128 time=1.218 ms 64 bytes from 192.168.12.1: icmp_seq=167 ttl=128 time=26.788 ms 64 bytes from 192.168.12.1: icmp_seq=168 ttl=128 time=17.097 ms 64 bytes from 192.168.12.1: icmp_seq=169 ttl=128 time=3.628 ms 64 bytes from 192.168.12.1: icmp_seq=217 ttl=128 time=1.788 ms 64 bytes from 192.168.12.1: icmp_seq=218 ttl=128 time=3.626 ms 64 bytes from 192.168.12.1: icmp_seq=219 ttl=128 time=6.011 ms 64 bytes from 192.168.12.1: icmp_seq=220 ttl=128 time=2.699 ms 64 bytes from 192.168.12.1: icmp_seq=221 ttl=128 time=1.804 ms 64 bytes from 192.168.12.1: icmp_seq=222 ttl=128 time=3.044 ms 64 bytes from 192.168.12.1: icmp_seq=223 ttl=128 time=2.621 ms 64 bytes from 192.168.12.1: icmp_seq=224 ttl=128 time=2.852 ms 64 bytes from 192.168.12.1: icmp_seq=225 ttl=128 time=1.161 ms 64 bytes from 192.168.12.1: icmp_seq=226 ttl=128 time=4.579 ms 64 bytes from 192.168.12.1: icmp_seq=227 ttl=128 time=3.935 ms 64 bytes from 192.168.12.1: icmp_seq=228 ttl=128 time=4.390 ms 64 bytes from 192.168.12.1: icmp_seq=229 ttl=128 time=2.741 ms 64 bytes from 192.168.12.1: icmp_seq=230 ttl=128 time=3.711 ms 64 bytes from 192.168.12.1: icmp_seq=231 ttl=128 time=8.003 ms 64 bytes from 192.168.12.1: icmp_seq=232 ttl=128 time=6.082 ms 64 bytes from 192.168.12.1: icmp_seq=233 ttl=128 time=5.059 ms 64 bytes from 192.168.12.1: icmp_seq=234 ttl=128 time=2.456 ms 64 bytes from 192.168.12.1: icmp_seq=235 ttl=128 time=3.144 ms 64 bytes from 192.168.12.1: icmp_seq=236 ttl=128 time=1.202 ms 64 bytes from 192.168.12.1: icmp_seq=237 ttl=128 time=6.566 ms 64 bytes from 192.168.12.1: icmp_seq=238 ttl=128 time=13.830 ms 64 bytes from 192.168.12.1: icmp_seq=239 ttl=128 time=5.463 ms 64 bytes from 192.168.12.1: icmp_seq=240 ttl=128 time=1.272 ms ^C --- 192.168.12.1 ping statistics --- 241 packets transmitted, 37 packets received, 84.6% packet loss round-trip min/avg/max/stddev = 0.740/5.144/26.788/5.734 ms logs (during ping) that you are requested: # wpa_supplicant -Kdd -i wlan0 -Dbsd -c /etc/wpa_supplicant.conf Initializing interface 'wlan0' 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' ctrl_interface_group='wheel' eapol_version=1 ap_scan=1 fast_reauth=1 country='RU' Line: 10 - start of a new network block ssid - hexdump_ascii(len=8): 6d 69 63 72 6f 6e 65 74 micronet BSSID - hexdump(len=6): 00 17 9a f0 b6 82 scan_ssid=1 (0x1) key_mgmt: 0x2 proto: 0x1 pairwise: 0x8 group: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=31): 4e 64 47 6a 51 74 55 4d 24 75 74 62 6b 2e 49 37 NdGjQtUM$utbk.I7 44 73 6b 37 36 2e 2e 66 30 61 59 61 55 65 2e Dsk76..f0aYaUe. PSK (from passphrase) - hexdump(len=32): 19 7b 12 a0 c6 0b ca 92 12 2a a5 77 e6 76 c4 ef 3b bf 43 88 18 b4 9d f1 f6 16 bb ff ac d2 cf 74 Priority group 0 id=0 ssid='micronet' Initializing interface (2) 'wlan0' Own MAC address: 00:15:e9:a4:58:9b 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 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 100000 usec Added interface wlan0 State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=8): 6d 69 63 72 6f 6e 65 74 micronet Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (2 BSSes) Scan results: 2 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:17:9a:f0:b6:82 ssid='micronet' wpa_ie_len=22 rsn_ie_len=0 caps=0x11 selected based on WPA IE selected WPA AP 00:17:9a:f0:b6:82 ssid='micronet' Trying to associate with 00:17:9a:f0:b6:82 (SSID='micronet' freq=2462 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 WPA: using IEEE 802.11i/D3.0 WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2 proto 1 WPA: set AP WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: clearing AP RSN IE WPA: using GTK TKIP WPA: using PTK TKIP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'micronet' wpa ie len 24 pairwise 2 group 2 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec State: ASSOCIATING -> ASSOCIATED Associated to a new BSS: BSSID=00:17:9a:f0:b6:82 No keys have been configured - skip key clearing Associated with 00:17:9a:f0:b6:82 WPA: Association event - clear replay counter WPA: Clear old PTK Setting authentication timeout: 10 sec 0 usec Cancelling scan request RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 18 79 fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Setting authentication timeout: 10 sec 0 usec IEEE 802.1X RX: version=1 type=3 length=95 EAPOL-Key type=254 key_info 0x89 (ver=1 keyidx=0 rsvd=0 Pairwise Ack) key_length=32 key_data_length=0 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 79 key_nonce - hexdump(len=32): fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 WPA: RX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 18 79 fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 State: ASSOCIATED -> 4WAY_HANDSHAKE WPA: RX message 1 of 4-Way Handshake from 00:17:9a:f0:b6:82 (ver=1) WPA: Renewed SNonce - hexdump(len=32): e7 85 ca a4 c8 2b de 3b 24 c6 9b 9e 44 1f 34 53 b7 7c b0 08 27 6f 24 57 58 ec a9 74 d5 c1 ad 50 WPA: PTK derivation - A1=00:15:e9:a4:58:9b A2=00:17:9a:f0:b6:82 WPA: PMK - hexdump(len=32): 19 7b 12 a0 c6 0b ca 92 12 2a a5 77 e6 76 c4 ef 3b bf 43 88 18 b4 9d f1 f6 16 bb ff ac d2 cf 74 WPA: PTK - hexdump(len=64): b8 d1 4e 9a 79 d6 20 c7 8e 99 c1 aa 0e 3b 12 6f f4 f4 f1 d9 fd 63 44 9d 1e 07 96 96 f4 38 e2 eb c0 0d e0 70 cf 42 e4 97 eb ef 33 78 10 b3 d0 7b c4 8e 71 a4 74 c4 54 46 31 40 9e 9f e9 9a 17 f3 WPA: WPA IE for msg 2/4 - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: Sending EAPOL-Key 2/4 WPA: TX EAPOL-Key - hexdump(len=123): 01 03 00 77 fe 01 09 00 20 00 00 00 00 00 00 18 79 e7 85 ca a4 c8 2b de 3b 24 c6 9b 9e 44 1f 34 53 b7 7c b0 08 27 6f 24 57 58 ec a9 74 d5 c1 ad 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 35 c9 fa 43 a9 1a 7b e7 ba ae e8 b7 42 04 61 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=123): 01 03 00 77 fe 01 c9 00 20 00 00 00 00 00 00 18 7a fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 a9 2f 5f 06 7e c4 73 8c 0a db 12 18 83 b7 b8 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 IEEE 802.1X RX: version=1 type=3 length=119 EAPOL-Key type=254 key_info 0x1c9 (ver=1 keyidx=0 rsvd=0 Pairwise Install Ack MIC) key_length=32 key_data_length=24 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 7a key_nonce - hexdump(len=32): fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): c1 a9 2f 5f 06 7e c4 73 8c 0a db 12 18 83 b7 b8 WPA: RX EAPOL-Key - hexdump(len=123): 01 03 00 77 fe 01 c9 00 20 00 00 00 00 00 00 18 7a fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 a9 2f 5f 06 7e c4 73 8c 0a db 12 18 83 b7 b8 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE WPA: RX message 3 of 4-Way Handshake from 00:17:9a:f0:b6:82 (ver=1) WPA: IE KeyData - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: Sending EAPOL-Key 4/4 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 01 09 00 20 00 00 00 00 00 00 18 7a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d6 ed 39 9f d9 ba 67 3d 71 02 1d 5a 5c a3 51 cb 00 00 WPA: Installing PTK to the driver. WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=00:17:9a:f0:b6:82 key_idx=0 set_tx=1 seq_len=6 key_len=32 State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=131): 01 03 00 7f fe 03 b1 00 20 00 00 00 00 00 00 18 7c 73 86 0c ce 6c cb 57 bb b9 18 d9 5f 2c 0c 1d ee 89 b7 34 02 f5 0a 48 bd 45 1e df 05 68 42 d2 78 89 b7 34 02 00 00 00 00 00 00 00 00 00 00 00 02 89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b8 a4 8d 9d da 1d 7e 78 16 ed ad ed 08 86 e1 59 00 20 b6 f6 79 22 3c d5 ce 0b 9a d9 87 5a 19 11 8b 2f 89 29 a8 c5 e6 6f 2e 3e 26 8f 72 ef 32 68 98 c8 IEEE 802.1X RX: version=1 type=3 length=127 EAPOL-Key type=254 key_info 0x3b1 (ver=1 keyidx=3 rsvd=0 Group Ack MIC Secure) key_length=32 key_data_length=32 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 7c key_nonce - hexdump(len=32): 73 86 0c ce 6c cb 57 bb b9 18 d9 5f 2c 0c 1d ee 89 b7 34 02 f5 0a 48 bd 45 1e df 05 68 42 d2 78 key_iv - hexdump(len=16): 89 b7 34 02 00 00 00 00 00 00 00 00 00 00 00 02 key_rsc - hexdump(len=8): 89 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): b8 a4 8d 9d da 1d 7e 78 16 ed ad ed 08 86 e1 59 WPA: RX EAPOL-Key - hexdump(len=131): 01 03 00 7f fe 03 b1 00 20 00 00 00 00 00 00 18 7c 73 86 0c ce 6c cb 57 bb b9 18 d9 5f 2c 0c 1d ee 89 b7 34 02 f5 0a 48 bd 45 1e df 05 68 42 d2 78 89 b7 34 02 00 00 00 00 00 00 00 00 00 00 00 02 89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b8 a4 8d 9d da 1d 7e 78 16 ed ad ed 08 86 e1 59 00 20 b6 f6 79 22 3c d5 ce 0b 9a d9 87 5a 19 11 8b 2f 89 29 a8 c5 e6 6f 2e 3e 26 8f 72 ef 32 68 98 c8 WPA: RX message 1 of Group Key Handshake from 00:17:9a:f0:b6:82 (ver=1) State: GROUP_HANDSHAKE -> GROUP_HANDSHAKE WPA: Group Key - hexdump(len=32): 76 5a 29 1b c2 1b 83 f6 66 7b ab 11 69 df d0 d4 4a ab 6f b6 37 6a f2 c4 0c 8a 52 8b 17 86 8a 97 WPA: Installing GTK to the driver (keyidx=3 tx=0 len=32). WPA: RSC - hexdump(len=6): 89 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=3 set_tx=0 seq_len=6 key_len=32 WPA: Sending EAPOL-Key 2/2 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 03 31 00 20 00 00 00 00 00 00 18 7c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 35 38 6c a0 5b 7f 1a 13 d5 14 ef 88 9c 6f 0b 00 00 WPA: Key negotiation completed with 00:17:9a:f0:b6:82 [PTK=TKIP GTK=TKIP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:17:9a:f0:b6:82 completed (auth) [id=0 id_str=] RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 18 7d 61 3d 02 58 83 53 8b 2d cd 0b ec 98 40 aa 52 97 77 6a 2b 33 65 a9 f6 3e 7a 1e a9 21 b0 a9 98 10 77 6a 2b 33 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c7 57 30 c7 63 85 89 1c 48 87 3c 4b 44 6d 95 d6 00 20 0b 9c 67 9e a7 04 7f 3e 17 4b c5 2b ae ce c9 fb 5b ad 0c 15 b1 b5 1c c1 29 79 89 36 37 7a 89 c5 IEEE 802.1X RX: version=1 type=3 length=127 EAPOL-Key type=254 key_info 0x391 (ver=1 keyidx=1 rsvd=0 Group Ack MIC Secure) key_length=32 key_data_length=32 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 7d key_nonce - hexdump(len=32): 61 3d 02 58 83 53 8b 2d cd 0b ec 98 40 aa 52 97 77 6a 2b 33 65 a9 f6 3e 7a 1e a9 21 b0 a9 98 10 key_iv - hexdump(len=16): 77 6a 2b 33 00 00 00 00 00 00 00 00 00 00 00 02 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): c7 57 30 c7 63 85 89 1c 48 87 3c 4b 44 6d 95 d6 WPA: RX EAPOL-Key - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 18 7d 61 3d 02 58 83 53 8b 2d cd 0b ec 98 40 aa 52 97 77 6a 2b 33 65 a9 f6 3e 7a 1e a9 21 b0 a9 98 10 77 6a 2b 33 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c7 57 30 c7 63 85 89 1c 48 87 3c 4b 44 6d 95 d6 00 20 0b 9c 67 9e a7 04 7f 3e 17 4b c5 2b ae ce c9 fb 5b ad 0c 15 b1 b5 1c c1 29 79 89 36 37 7a 89 c5 WPA: RX message 1 of Group Key Handshake from 00:17:9a:f0:b6:82 (ver=1) State: COMPLETED -> GROUP_HANDSHAKE WPA: Group Key - hexdump(len=32): d5 ac 9c 27 18 64 aa dd f6 08 8c 7d e5 1f 71 d8 f7 9c 83 91 3a 2d bf b7 bd ca e2 63 3a cd 7b 66 WPA: Installing GTK to the driver (keyidx=1 tx=0 len=32). WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=1 set_tx=0 seq_len=6 key_len=32 WPA: Sending EAPOL-Key 2/2 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 03 11 00 20 00 00 00 00 00 00 18 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 5c 8b 2e a1 80 22 2d ec d9 bb 39 b5 3d 86 b6 00 00 WPA: Group rekeying completed with 00:17:9a:f0:b6:82 [GTK=TKIP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED ^CCTRL-EVENT-TERMINATING - signal 2 received Removing interface wlan0 State: COMPLETED -> DISCONNECTED wpa_driver_bsd_deauthenticate 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_del_key: addr=00:17:9a:f0:b6:82 keyidx=0 ioctl[SIOCS80211, op 20, len 7]: Can't assign requested address wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported Failed to disable WPA in the driver. 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=1 privacy=0 ELOOP: remaining socket: sock=4 eloop_data=0x28305140 user_data=0x2830d040 handler=0x8067aa0 2009/8/30 Sam Leffler > You appear to say this problem does not entirely stop traffic from flowing. > Please provide a debug wpa_supplicant log that shows a complete session > (i.e. a log with -d and/or -dd). > > Why do you set eapol_version=1. Is this really needed? What is your AP > make/model? > > Note also that country=RU is ignored on freebsd. > > Sam > --0014852f5780d7c3810472602664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 SGksIFNhbS48YnI+bWFuICg1KSBmb3Igd3BhX3N1cHBsaWNhbnQuY29uZiBzdGFuZHMgdGhhdCBp dCBpcyBkZWZhdWx0IHZhbHVlLCBidXQgd2hlbiBJIGNvbW1lbnRlZCBvdXQgdGhpcyBwYXJhbWV0 ZXIgbm90aGluZyBoYXMgY2hhbmdlZC48YnI+PGJyPkkgcGluZyBJUCBvZiBBY2Nlc3MgUG9pbnQ6 PGJyPjxicj4kIHBpbmcgMTkyLjE2OC4xMi4xwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ ClBJTkcgMTkyLjE2OC4xMi4xICgxOTIuMTY4LjEyLjEpOiA1NiBkYXRhIGJ5dGVzwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+NjQg Ynl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+ OiBpY21wX3NlcT0wIHR0bD0xMjggdGltZT02LjQ1MCBtc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIDxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEi PjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTMgdHRsPTEyOCB0aW1lPTAuNzYyIG1zwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgo2NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0 dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTI1IHR0bD0xMjgg dGltZT0wLjc0MyBtc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+NjQgYnl0ZXMg ZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21w X3NlcT03NSB0dGw9MTI4IHRpbWU9MC43NTUgbXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgPGJyPgo2NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4x NjguMTIuMTwvYT46IGljbXBfc2VxPTc5IHR0bD0xMjggdGltZT0wLjk1OSBtc8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTky LjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xMDMgdHRsPTEyOCB0aW1lPTAu NzQwIG1zwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CjY0IGJ5dGVzIGZyb20gPGEg aHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MTYy IHR0bD0xMjggdGltZT01LjMyMiBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8x OTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTE2NCB0dGw9MTI4IHRpbWU9 NS43MDUgbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4x OTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xNjUgdHRsPTEyOCB0aW1lPTIyLjEzOCBtczxicj4K NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8 L2E+OiBpY21wX3NlcT0xNjYgdHRsPTEyOCB0aW1lPTEuMjE4IG1zPGJyPjY0IGJ5dGVzIGZyb20g PGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9 MTY3IHR0bD0xMjggdGltZT0yNi43ODggbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRw Oi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xNjggdHRsPTEyOCB0 aW1lPTE3LjA5NyBtczxicj4KNjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4x Mi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xNjkgdHRsPTEyOCB0aW1lPTMuNjI4IG1z PGJyPjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4x Mi4xPC9hPjogaWNtcF9zZXE9MjE3IHR0bD0xMjggdGltZT0xLjc4OCBtczxicj42NCBieXRlcyBm cm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBf c2VxPTIxOCB0dGw9MTI4IHRpbWU9My42MjYgbXM8YnI+CjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0i aHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjE5IHR0bD0x MjggdGltZT02LjAxMSBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4 LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIyMCB0dGw9MTI4IHRpbWU9Mi42OTkg bXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4 LjEyLjE8L2E+OiBpY21wX3NlcT0yMjEgdHRsPTEyOCB0aW1lPTEuODA0IG1zPGJyPgo2NCBieXRl cyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGlj bXBfc2VxPTIyMiB0dGw9MTI4IHRpbWU9My4wNDQgbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVm PSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yMjMgdHRs PTEyOCB0aW1lPTIuNjIxIG1zPGJyPjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4x NjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjI0IHR0bD0xMjggdGltZT0yLjg1 MiBtczxicj4KNjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIu MTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yMjUgdHRsPTEyOCB0aW1lPTEuMTYxIG1zPGJyPjY0IGJ5 dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjog aWNtcF9zZXE9MjI2IHR0bD0xMjggdGltZT00LjU3OSBtczxicj42NCBieXRlcyBmcm9tIDxhIGhy ZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIyNyB0 dGw9MTI4IHRpbWU9My45MzUgbXM8YnI+CjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5 Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjI4IHR0bD0xMjggdGltZT00 LjM5MCBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5 Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIyOSB0dGw9MTI4IHRpbWU9Mi43NDEgbXM8YnI+NjQg Ynl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+ OiBpY21wX3NlcT0yMzAgdHRsPTEyOCB0aW1lPTMuNzExIG1zPGJyPgo2NCBieXRlcyBmcm9tIDxh IGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIz MSB0dGw9MTI4IHRpbWU9OC4wMDMgbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8v MTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yMzIgdHRsPTEyOCB0aW1l PTYuMDgyIG1zPGJyPjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+ MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjMzIHR0bD0xMjggdGltZT01LjA1OSBtczxicj4K NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8 L2E+OiBpY21wX3NlcT0yMzQgdHRsPTEyOCB0aW1lPTIuNDU2IG1zPGJyPjY0IGJ5dGVzIGZyb20g PGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9 MjM1IHR0bD0xMjggdGltZT0zLjE0NCBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6 Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIzNiB0dGw9MTI4IHRp bWU9MS4yMDIgbXM8YnI+CjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIu MSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjM3IHR0bD0xMjggdGltZT02LjU2NiBtczxi cj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIu MTwvYT46IGljbXBfc2VxPTIzOCB0dGw9MTI4IHRpbWU9MTMuODMwIG1zPGJyPjY0IGJ5dGVzIGZy b20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9z ZXE9MjM5IHR0bD0xMjggdGltZT01LjQ2MyBtczxicj4KNjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJo dHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yNDAgdHRsPTEy OCB0aW1lPTEuMjcyIG1zPGJyPl5DPGJyPi0tLSAxOTIuMTY4LjEyLjEgcGluZyBzdGF0aXN0aWNz IC0tLTxicj4yNDEgcGFja2V0cyB0cmFuc21pdHRlZCwgMzcgcGFja2V0cyByZWNlaXZlZCwgODQu NiUgcGFja2V0IGxvc3M8YnI+cm91bmQtdHJpcCBtaW4vYXZnL21heC9zdGRkZXYgPSAwLjc0MC81 LjE0NC8yNi43ODgvNS43MzQgbXM8YnI+Cjxicj48YnI+bG9ncyAoZHVyaW5nIHBpbmcpIHRoYXQg eW91IGFyZSByZXF1ZXN0ZWQ6PGJyPjxicj4jIHdwYV9zdXBwbGljYW50IC1LZGQgLWkgd2xhbjAg LURic2QgLWMgL2V0Yy93cGFfc3VwcGxpY2FudC5jb25mIDxicj5Jbml0aWFsaXppbmcgaW50ZXJm YWNlICYjMzk7d2xhbjAmIzM5OyBjb25mICYjMzk7L2V0Yy93cGFfc3VwcGxpY2FudC5jb25mJiMz OTsgZHJpdmVyICYjMzk7YnNkJiMzOTsgY3RybF9pbnRlcmZhY2UgJiMzOTtOL0EmIzM5OyBicmlk Z2UgJiMzOTtOL0EmIzM5O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CkNvbmZp Z3VyYXRpb24gZmlsZSAmIzM5Oy9ldGMvd3BhX3N1cHBsaWNhbnQuY29uZiYjMzk7IC0mZ3Q7ICYj Mzk7L2V0Yy93cGFfc3VwcGxpY2FudC5jb25mJiMzOTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgPGJyPlJlYWRpbmcgY29uZmlndXJhdGlvbiBmaWxlICYjMzk7L2V0Yy93cGFfc3VwcGxp Y2FudC5jb25mJiMzOTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Y3RybF9pbnRlcmZhY2VfZ3JvdXA9 JiMzOTt3aGVlbCYjMzk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CmVhcG9sX3ZlcnNpb249McKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+YXBfc2Nhbj0xwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5mYXN0X3JlYXV0aD0xwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CmNvdW50cnk9JiMzOTtSVSYjMzk7 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5MaW5lOiAxMCAt IHN0YXJ0IG9mIGEgbmV3IG5ldHdvcmsgYmxvY2vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPGJyPnNzaWQgLSBoZXhkdW1wX2FzY2lpKGxlbj04KTrCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDxicj4KwqDCoMKgwqAgNmQgNjkgNjMgNzIgNmYgNmUgNjUgNzTCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG1pY3JvbmV0wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5CU1NJRCAtIGhl eGR1bXAobGVuPTYpOiAwMCAxNyA5YSBmMCBiNiA4MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDxicj5zY2FuX3NzaWQ9MSAoMHgxKcKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4Ka2V5X21nbXQ6IDB4MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPGJyPnByb3RvOiAweDHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5wYWlyd2lzZTogMHg4wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Cmdyb3VwOiAweDjCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5QU0sgKEFTQ0lJIHBhc3NwaHJhc2UpIC0gaGV4 ZHVtcF9hc2NpaShsZW49MzEpOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoMKg wqDCoCA0ZSA2NCA0NyA2YSA1MSA3NCA1NSA0ZCAyNCA3NSA3NCA2MiA2YiAyZSA0OSAzN8KgwqAg TmRHalF0VU0kdXRiay5JN8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj4KwqDCoMKgwqAgNDQgNzMgNmIgMzcgMzYgMmUgMmUgNjYgMzAgNjEgNTkgNjEgNTUgNjUgMmXC oMKgwqDCoMKgIERzazc2Li5mMGFZYVVlLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPGJyPlBTSyAoZnJvbSBwYXNzcGhyYXNlKSAtIGhleGR1bXAobGVuPTMyKTogMTkg N2IgMTIgYTAgYzYgMGIgY2EgOTIgMTIgMmEgYTUgNzcgZTYgNzYgYzQgZWYgM2IgYmYgNDMgODgg MTggYjQgOWQgZjEgZjYgMTYgYmIgZmYgYWMgZDIgY2YgNzTCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPgpQcmlvcml0eSBncm91cCAwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+wqDCoCBpZD0wIHNzaWQ9JiMzOTttaWNyb25ldCYjMzk7wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPkluaXRpYWxpemluZyBpbnRlcmZhY2UgKDIpICYjMzk7d2xhbjAmIzM5 O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPgpPd24gTUFDIGFkZHJlc3M6IDAwOjE1OmU5OmE0OjU4OjliwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+d3BhX2RyaXZlcl9ic2Rf c2V0X3dwYTogZW5hYmxlZD0xwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9zZXRfd3BhX2ludGVybmFsOiB3 cGE9MyBwcml2YWN5PTHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgp3cGFfZHJpdmVy X2JzZF9kZWxfa2V5OiBrZXlpZHg9MMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9kZWxfa2V5OiBrZXlp ZHg9McKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9kZWxfa2V5OiBrZXlpZHg9MsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4Kd3BhX2Ry aXZlcl9ic2RfZGVsX2tleToga2V5aWR4PTPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X2NvdW50 ZXJtZWFzdXJlczogZW5hYmxlZD0wwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj53cGFfZHJpdmVyX2JzZF9zZXRfZHJvcF91bmVuY3J5cHRlZDogZW5hYmxlZD0xwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ClJTTjogZmx1c2hpbmcgUE1LSUQgbGlzdCBpbiB0 aGUgZHJpdmVywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPlNldHRpbmcgc2NhbiByZXF1ZXN0OiAwIHNlYyAxMDAwMDAgdXNlY8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+QWRkZWQgaW50ZXJmYWNlIHdsYW4w wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KU3RhdGU6IERJU0NPTk5FQ1RFRCAtJmd0OyBT Q0FOTklOR8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPlN0YXJ0aW5nIEFQIHNjYW4gKHNwZWNpZmljIFNTSUQpwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlNj YW4gU1NJRCAtIGhleGR1bXBfYXNjaWkobGVuPTgpOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CsKgwqDCoMKgIDZkIDY5IDYzIDcy IDZmIDZlIDY1IDc0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBtaWNyb25ldMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+VHJ5aW5nIHRvIGdldCBjdXJyZW50IHNjYW4gcmVzdWx0cyBmaXJz dCB3aXRob3V0IHJlcXVlc3RpbmcgYSBuZXcgc2NhbiB0byBzcGVlZCB1cCBpbml0aWFsIGFzc29j aWF0aW9uwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpS ZWNlaXZlZCAwIGJ5dGVzIG9mIHNjYW4gcmVzdWx0cyAoMCBCU1NlcynCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlNjYW4gcmVzdWx0czogMMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Q2FjaGVkIHNjYW4gcmVzdWx0cyBhcmUgZW1wdHkg LSBub3QgcG9zdGluZ8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpT ZWxlY3RpbmcgQlNTIGZyb20gcHJpb3JpdHkgZ3JvdXAgMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5UcnkgdG8gZmluZCBXUEEtZW5hYmxl ZCBBUMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5UcnkgdG8gZmluZCBub24tV1BBIEFQwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+Ck5vIHN1aXRhYmxlIEFQIGZvdW5kLsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA8YnI+U2V0dGluZyBzY2FuIHJlcXVlc3Q6IDAgc2VjIDAgdXNlY8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlN0YXJ0aW5nIEFQ IHNjYW4gKGJyb2FkY2FzdCBTU0lEKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ClJlY2VpdmVkIDAgYnl0ZXMgb2Ygc2NhbiByZXN1 bHRzICgyIEJTU2VzKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ U2NhbiByZXN1bHRzOiAywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5D VFJMLUVWRU5ULVNDQU4tUkVTVUxUU8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KU2VsZWN0aW5n IEJTUyBmcm9tIHByaW9yaXR5IGdyb3VwIDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+VHJ5IHRvIGZpbmQgV1BBLWVuYWJsZWQgQVDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+MDogMDA6MTc6OWE6ZjA6YjY6ODIgc3NpZD0mIzM5O21pY3JvbmV0JiMz OTsgd3BhX2llX2xlbj0yMiByc25faWVfbGVuPTAgY2Fwcz0weDExwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CsKgwqAgc2VsZWN0ZWQgYmFzZWQgb24gV1BBIElFwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxicj7CoMKgIHNlbGVjdGVkIFdQQSBBUCAwMDoxNzo5YTpmMDpiNjo4MiBzc2lkPSYj Mzk7bWljcm9uZXQmIzM5O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlRyeWluZyB0byBhc3NvY2lh dGUgd2l0aCAwMDoxNzo5YTpmMDpiNjo4MiAoU1NJRD0mIzM5O21pY3JvbmV0JiMzOTsgZnJlcT0y NDYyIE1IeinCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CkNhbmNlbGxpbmcg c2NhbiByZXF1ZXN0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPldQQTogY2xlYXJpbmcgb3duIFdQ QS9SU04gSUXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5BdXRvbWF0aWMgYXV0aF9hbGcgc2VsZWN0aW9uOiAweDHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPgp3cGFfZHJpdmVyX2JzZF9zZXRfYXV0aF9hbGcgYWxnIDB4MSBhdXRobW9kZSAxwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiB1c2luZyBJRUVFIDgwMi4xMWkvRDMu MMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPldQQTogU2VsZWN0ZWQgY2lwaGVyIHN1aXRlczogZ3JvdXAgOCBwYWly d2lzZSA4IGtleV9tZ210IDIgcHJvdG8gMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogc2V0IEFQIFdQQSBJRSAtIGhleGR1bXAobGVuPTI0 KTogZGQgMTYgMDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDIg MDEgMDAgMDAgNTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPldQQTog Y2xlYXJpbmcgQVAgUlNOIElFwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpXUEE6IHVzaW5nIEdU SyBUS0lQwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiB1c2luZyBQVEsgVEtJ UMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPldQQTogdXNpbmcgS0VZX01HTVQgV1BB LVBTS8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogU2V0IG93biBXUEEgSUUgZGVmYXVsdCAtIGhleGR1 bXAobGVuPTI0KTogZGQgMTYgMDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAg NTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPk5vIGtleXMgaGF2ZSBi ZWVuIGNvbmZpZ3VyZWQgLSBza2lwIGtleSBjbGVhcmluZ8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA8YnI+CndwYV9kcml2ZXJfYnNkX3NldF9kcm9wX3VuZW5jcnlwdGVkOiBlbmFibGVkPTHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5TdGF0ZTogU0NBTk5JTkcgLSZndDsg QVNTT0NJQVRJTkfCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPGJyPndwYV9kcml2ZXJfYnNkX2Fzc29jaWF0ZTogc3NpZCAmIzM5 O21pY3JvbmV0JiMzOTsgd3BhIGllIGxlbiAyNCBwYWlyd2lzZSAyIGdyb3VwIDIga2V5IG1nbXQg McKgwqDCoMKgwqAgPGJyPgp3cGFfZHJpdmVyX2JzZF9hc3NvY2lhdGU6IHNldCBQUklWQUNZIDHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlNldHRpbmcg YXV0aGVudGljYXRpb24gdGltZW91dDogMTAgc2VjIDAgdXNlY8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+U3RhdGU6IEFTU09DSUFUSU5HIC0mZ3Q7IEFTU09DSUFURUTCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+CkFzc29jaWF0ZWQgdG8gYSBuZXcgQlNTOiBCU1NJRD0wMDoxNzo5YTpmMDpiNjo4MsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Tm8ga2V5cyBoYXZlIGJlZW4gY29uZmlndXJlZCAt IHNraXAga2V5IGNsZWFyaW5nwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5Bc3NvY2lh dGVkIHdpdGggMDA6MTc6OWE6ZjA6YjY6ODLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpXUEE6IEFzc29jaWF0aW9uIGV2ZW50IC0g Y2xlYXIgcmVwbGF5IGNvdW50ZXLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJy PldQQTogQ2xlYXIgb2xkIFBUS8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+U2V0 dGluZyBhdXRoZW50aWNhdGlvbiB0aW1lb3V0OiAxMCBzZWMgMCB1c2VjwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KQ2FuY2VsbGluZyBzY2FuIHJlcXVlc3TCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+UlggRUFQT0wgZnJvbSAwMDoxNzo5YTpmMDpiNjo4MsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlJY IEVBUE9MIC0gaGV4ZHVtcChsZW49OTkpOiAwMSAwMyAwMCA1ZiBmZSAwMCA4OSAwMCAyMCAwMCAw MCAwMCAwMCAwMCAwMCAxOCA3OSBmZCAwZSBkMyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBhMSAz NCA1MCA4OCBmZCA0NCAxOSA4ZCA3ZSA5YSBiYyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5OSA0 NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8YnI+ClNldHRpbmcgYXV0aGVudGljYXRpb24gdGltZW91dDogMTAgc2VjIDAgdXNlY8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+SUVFRSA4MDIuMVggUlg6IHZlcnNpb249 MSB0eXBlPTMgbGVuZ3RoPTk1wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj7CoCBFQVBPTC1LZXkgdHlwZT0yNTTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ CsKgIGtleV9pbmZvIDB4ODkgKHZlcj0xIGtleWlkeD0wIHJzdmQ9MCBQYWlyd2lzZSBBY2spwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X2xlbmd0aD0zMiBrZXlfZGF0YV9sZW5ndGg9MMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+wqAgcmVwbGF5X2NvdW50ZXIgLSBoZXhkdW1wKGxlbj04KTogMDAgMDAgMDAgMDAgMDAgMDAg MTggNznCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X25vbmNlIC0gaGV4ZHVtcChsZW49MzIpOiBmZCAwZSBk MyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBhMSAzNCA1MCA4OCBmZCA0NCAxOSA4ZCA3ZSA5YSBi YyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5OSA0NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfaXYgLSBoZXhkdW1wKGxlbj0x Nik6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X3JzYyAtIGhleGR1bXAobGVuPTgp OiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5 X2lkIChyZXNlcnZlZCkgLSBoZXhkdW1wKGxlbj04KTogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj7CoCBrZXlfbWljIC0gaGV4ZHVtcChsZW49MTYpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJy PgpXUEE6IFJYIEVBUE9MLUtleSAtIGhleGR1bXAobGVuPTk5KTogMDEgMDMgMDAgNWYgZmUgMDAg ODkgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggNzkgZmQgMGUgZDMgNmEgZDYgZDkgYjggNTAg NWIgOWYgZTIgYTEgMzQgNTAgODggZmQgNDQgMTkgOGQgN2UgOWEgYmMgY2EgNGYgY2QgZWIgNzkg NDcgNmMgNTUgOTkgNDQgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJy PgpTdGF0ZTogQVNTT0NJQVRFRCAtJmd0OyA0V0FZX0hBTkRTSEFLRcKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJYIG1lc3NhZ2Ug MSBvZiA0LVdheSBIYW5kc2hha2UgZnJvbSAwMDoxNzo5YTpmMDpiNjo4MiAodmVyPTEpwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBSZW5ld2Vk IFNOb25jZSAtIGhleGR1bXAobGVuPTMyKTogZTcgODUgY2EgYTQgYzggMmIgZGUgM2IgMjQgYzYg OWIgOWUgNDQgMWYgMzQgNTMgYjcgN2MgYjAgMDggMjcgNmYgMjQgNTcgNTggZWMgYTkgNzQgZDUg YzEgYWQgNTDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KV1BBOiBQ VEsgZGVyaXZhdGlvbiAtIEExPTAwOjE1OmU5OmE0OjU4OjliIEEyPTAwOjE3OjlhOmYwOmI2Ojgy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj5XUEE6IFBNSyAtIGhleGR1bXAobGVuPTMyKTogMTkgN2IgMTIgYTAgYzYgMGIgY2EgOTIgMTIg MmEgYTUgNzcgZTYgNzYgYzQgZWYgM2IgYmYgNDMgODggMTggYjQgOWQgZjEgZjYgMTYgYmIgZmYg YWMgZDIgY2YgNzTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+CldQQTogUFRLIC0gaGV4ZHVtcChsZW49NjQpOiBiOCBkMSA0ZSA5 YSA3OSBkNiAyMCBjNyA4ZSA5OSBjMSBhYSAwZSAzYiAxMiA2ZiBmNCBmNCBmMSBkOSBmZCA2MyA0 NCA5ZCAxZSAwNyA5NiA5NiBmNCAzOCBlMiBlYiBjMCAwZCBlMCA3MCBjZiA0MiBlNCA5NyBlYiBl ZiAzMyA3OCAxMCBiMyBkMCA3YiBjNCA4ZSA3MSBhNCA3NCBjNCA1NCA0NiAzMSA0MCA5ZSA5ZiBl OSA5YSAxNyBmM8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgPGJyPgpXUEE6IFdQQSBJRSBmb3IgbXNnIDIvNCAtIGhleGR1bXAobGVuPTI0KTogZGQgMTYg MDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAg NTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBTZW5kaW5nIEVBUE9MLUtleSAy LzTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogVFggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49MTIz KTogMDEgMDMgMDAgNzcgZmUgMDEgMDkgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggNzkgZTcg ODUgY2EgYTQgYzggMmIgZGUgM2IgMjQgYzYgOWIgOWUgNDQgMWYgMzQgNTMgYjcgN2MgYjAgMDgg MjcgNmYgMjQgNTcgNTggZWMgYTkgNzQgZDUgYzEgYWQgNTAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgODIgMzUgYzkgZmEgNDMgYTkgMWEgN2IgZTcgYmEgYWUgZTggYjcg NDIgMDQgNjEgMDAgMTggZGQgMTYgMDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAg MDAgNTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPgpSWCBFQVBPTCBmcm9tIDAwOjE3OjlhOmYwOmI2OjgywqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ UlggRUFQT0wgLSBoZXhkdW1wKGxlbj0xMjMpOiAwMSAwMyAwMCA3NyBmZSAwMSBjOSAwMCAyMCAw MCAwMCAwMCAwMCAwMCAwMCAxOCA3YSBmZCAwZSBkMyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBh MSAzNCA1MCA4OCBmZCA0NCAxOSA4ZCA3ZSA5YSBiYyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5 OSA0NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCBjMSBhOSAyZiA1ZiAw NiA3ZSBjNCA3MyA4YyAwYSBkYiAxMiAxOCA4MyBiNyBiOCAwMCAxOCBkZCAxNiAwMCA1MCBmMiAw MSAwMSAwMCAwMCA1MCBmMiAwMiAwMSAwMCAwMCA1MCBmMiAwMiAwMSAwMCAwMCA1MCBmMiAwMsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+CklFRUUgODAyLjFYIFJYOiB2ZXJzaW9uPTEgdHlwZT0zIGxlbmd0aD0xMTnCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBFQVBPTC1LZXkgdHlwZT0yNTTCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X2luZm8gMHgxYzkgKHZlcj0xIGtleWlk eD0wIHJzdmQ9MCBQYWlyd2lzZSBJbnN0YWxsIEFjayBNSUMpwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBrZXlfbGVuZ3RoPTMyIGtleV9k YXRhX2xlbmd0aD0yNMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPsKgIHJlcGxheV9jb3VudGVyIC0gaGV4ZHVtcChsZW49OCk6IDAwIDAw IDAwIDAwIDAwIDAwIDE4IDdhwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X25vbmNlIC0gaGV4ZHVtcChsZW49 MzIpOiBmZCAwZSBkMyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBhMSAzNCA1MCA4OCBmZCA0NCAx OSA4ZCA3ZSA5YSBiYyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5OSA0NMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X2l2IC0g aGV4ZHVtcChsZW49MTYpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X3JzYyAtIGhl eGR1bXAobGVuPTgpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8YnI+wqAga2V5X2lkIChyZXNlcnZlZCkgLSBoZXhkdW1wKGxlbj04KTogMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X21pYyAtIGhleGR1bXAobGVuPTE2KTogYzEgYTkgMmYg NWYgMDYgN2UgYzQgNzMgOGMgMGEgZGIgMTIgMTggODMgYjcgYjjCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIDxicj5XUEE6IFJYIEVBUE9MLUtleSAtIGhleGR1bXAobGVuPTEyMyk6IDAxIDAz IDAwIDc3IGZlIDAxIGM5IDAwIDIwIDAwIDAwIDAwIDAwIDAwIDAwIDE4IDdhIGZkIDBlIGQzIDZh IGQ2IGQ5IGI4IDUwIDViIDlmIGUyIGExIDM0IDUwIDg4IGZkIDQ0IDE5IDhkIDdlIDlhIGJjIGNh IDRmIGNkIGViIDc5IDQ3IDZjIDU1IDk5IDQ0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIGMxIGE5IDJmIDVmIDA2IDdlIGM0IDczIDhjIDBhIGRiIDEyIDE4IDgzIGI3IGI4 IDAwIDE4IGRkIDE2IDAwIDUwIGYyIDAxIDAxIDAwIDAwIDUwIGYyIDAyIDAxIDAwIDAwIDUwIGYy IDAyIDAxIDAwIDAwIDUwIGYyIDAywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDxicj4KU3RhdGU6IDRXQVlfSEFORFNIQUtFIC0mZ3Q7IDRXQVlfSEFORFNIQUtFwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJYIG1lc3Nh Z2UgMyBvZiA0LVdheSBIYW5kc2hha2UgZnJvbSAwMDoxNzo5YTpmMDpiNjo4MiAodmVyPTEpwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBJRSBL ZXlEYXRhIC0gaGV4ZHVtcChsZW49MjQpOiBkZCAxNiAwMCA1MCBmMiAwMSAwMSAwMCAwMCA1MCBm MiAwMiAwMSAwMCAwMCA1MCBmMiAwMiAwMSAwMCAwMCA1MCBmMiAwMsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogU2VuZGluZyBFQVBPTC1LZXkgNC80wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPGJyPldQQTogVFggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49OTkpOiAwMSAwMyAw MCA1ZiBmZSAwMSAwOSAwMCAyMCAwMCAwMCAwMCAwMCAwMCAwMCAxOCA3YSAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCBkNiBlZCAzOSA5ZiBkOSBiYSA2NyAzZCA3MSAwMiAxZCA1YSA1YyBhMyA1MSBjYiAw MCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA8YnI+CldQQTogSW5zdGFsbGluZyBQVEsgdG8gdGhlIGRyaXZlci7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJT QyAtIGhleGR1bXAobGVuPTYpOiAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9zZXRfa2V5OiBhbGc9VEtJUCBhZGRy PTAwOjE3OjlhOmYwOmI2OjgyIGtleV9pZHg9MCBzZXRfdHg9MSBzZXFfbGVuPTYga2V5X2xlbj0z MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgPGJyPgpTdGF0ZTogNFdBWV9IQU5EU0hBS0UgLSZndDsgR1JPVVBfSEFORFNIQUtFwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+UlggRUFQT0wgZnJvbSAw MDoxNzo5YTpmMDpiNjo4MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlJYIEVBUE9MIC0gaGV4ZHVtcChsZW49MTMxKTogMDEg MDMgMDAgN2YgZmUgMDMgYjEgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggN2MgNzMgODYgMGMg Y2UgNmMgY2IgNTcgYmIgYjkgMTggZDkgNWYgMmMgMGMgMWQgZWUgODkgYjcgMzQgMDIgZjUgMGEg NDggYmQgNDUgMWUgZGYgMDUgNjggNDIgZDIgNzggODkgYjcgMzQgMDIgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDIgODkgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgYjggYTQgOGQgOWQgZGEgMWQgN2UgNzggMTYgZWQgYWQgZWQgMDggODYgZTEg NTkgMDAgMjAgYjYgZjYgNzkgMjIgM2MgZDUgY2UgMGIgOWEgZDkgODcgNWEgMTkgMTEgOGIgMmYg ODkgMjkgYTggYzUgZTYgNmYgMmUgM2UgMjYgOGYgNzIgZWYgMzIgNjggOTggYzjCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPgpJRUVFIDgwMi4xWCBSWDogdmVyc2lvbj0xIHR5cGU9MyBsZW5ndGg9MTI3wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAgRUFQT0wtS2V5IHR5cGU9MjU0wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPsKgIGtleV9pbmZvIDB4M2IxICh2ZXI9MSBrZXlp ZHg9MyByc3ZkPTAgR3JvdXAgQWNrIE1JQyBTZWN1cmUpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CsKgIGtleV9sZW5ndGg9MzIg a2V5X2RhdGFfbGVuZ3RoPTMywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAgcmVwbGF5X2NvdW50ZXIgLSBoZXhkdW1wKGxlbj04KTog MDAgMDAgMDAgMDAgMDAgMDAgMTggN2PCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfbm9uY2UgLSBoZXhkdW1w KGxlbj0zMik6IDczIDg2IDBjIGNlIDZjIGNiIDU3IGJiIGI5IDE4IGQ5IDVmIDJjIDBjIDFkIGVl IDg5IGI3IDM0IDAyIGY1IDBhIDQ4IGJkIDQ1IDFlIGRmIDA1IDY4IDQyIGQyIDc4wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBrZXlf aXYgLSBoZXhkdW1wKGxlbj0xNik6IDg5IGI3IDM0IDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfcnNj IC0gaGV4ZHVtcChsZW49OCk6IDg5IDAwIDAwIDAwIDAwIDAwIDAwIDAwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxicj7CoCBrZXlfaWQgKHJlc2VydmVkKSAtIGhleGR1bXAobGVuPTgpOiAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBrZXlfbWljIC0gaGV4ZHVtcChsZW49MTYpOiBiOCBh NCA4ZCA5ZCBkYSAxZCA3ZSA3OCAxNiBlZCBhZCBlZCAwOCA4NiBlMSA1OcKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPGJyPldQQTogUlggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49MTMxKTog MDEgMDMgMDAgN2YgZmUgMDMgYjEgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggN2MgNzMgODYg MGMgY2UgNmMgY2IgNTcgYmIgYjkgMTggZDkgNWYgMmMgMGMgMWQgZWUgODkgYjcgMzQgMDIgZjUg MGEgNDggYmQgNDUgMWUgZGYgMDUgNjggNDIgZDIgNzggODkgYjcgMzQgMDIgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDIgODkgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgYjggYTQgOGQgOWQgZGEgMWQgN2UgNzggMTYgZWQgYWQgZWQgMDggODYg ZTEgNTkgMDAgMjAgYjYgZjYgNzkgMjIgM2MgZDUgY2UgMGIgOWEgZDkgODcgNWEgMTkgMTEgOGIg MmYgODkgMjkgYTggYzUgZTYgNmYgMmUgM2UgMjYgOGYgNzIgZWYgMzIgNjggOTggYzjCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpXUEE6IFJYIG1l c3NhZ2UgMSBvZiBHcm91cCBLZXkgSGFuZHNoYWtlIGZyb20gMDA6MTc6OWE6ZjA6YjY6ODIgKHZl cj0xKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5TdGF0ZTogR1JP VVBfSEFORFNIQUtFIC0mZ3Q7IEdST1VQX0hBTkRTSEFLRcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IEdyb3VwIEtleSAtIGhleGR1bXAobGVuPTMyKTog NzYgNWEgMjkgMWIgYzIgMWIgODMgZjYgNjYgN2IgYWIgMTEgNjkgZGYgZDAgZDQgNGEgYWIgNmYg YjYgMzcgNmEgZjIgYzQgMGMgOGEgNTIgOGIgMTcgODYgOGEgOTfCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogSW5zdGFsbGluZyBHVEsgdG8g dGhlIGRyaXZlciAoa2V5aWR4PTMgdHg9MCBsZW49MzIpLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBSU0Mg LSBoZXhkdW1wKGxlbj02KTogODkgMDAgMDAgMDAgMDAgMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X2tleTogYWxnPVRLSVAgYWRkcj1m ZjpmZjpmZjpmZjpmZjpmZiBrZXlfaWR4PTMgc2V0X3R4PTAgc2VxX2xlbj02IGtleV9sZW49MzLC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj4KV1BBOiBTZW5kaW5nIEVBUE9MLUtleSAyLzLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBU WCBFQVBPTC1LZXkgLSBoZXhkdW1wKGxlbj05OSk6IDAxIDAzIDAwIDVmIGZlIDAzIDMxIDAwIDIw IDAwIDAwIDAwIDAwIDAwIDAwIDE4IDdjIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGZmIDM1IDM4IDZj IGEwIDViIDdmIDFhIDEzIGQ1IDE0IGVmIDg4IDljIDZmIDBiIDAwIDAwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KV1BBOiBL ZXkgbmVnb3RpYXRpb24gY29tcGxldGVkIHdpdGggMDA6MTc6OWE6ZjA6YjY6ODIgW1BUSz1US0lQ IEdUSz1US0lQXcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPkNhbmNlbGxp bmcgYXV0aGVudGljYXRpb24gdGltZW91dMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+U3RhdGU6IEdST1VQX0hBTkRTSEFLRSAtJmd0 OyBDT01QTEVURUTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA8YnI+CkNUUkwtRVZFTlQtQ09OTkVDVEVEIC0gQ29ubmVjdGlvbiB0byAwMDoxNzo5 YTpmMDpiNjo4MiBjb21wbGV0ZWQgKGF1dGgpIFtpZD0wIGlkX3N0cj1dwqDCoMKgwqAgPGJyPlJY IEVBUE9MIGZyb20gMDA6MTc6OWE6ZjA6YjY6ODLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5SWCBFQVBPTCAtIGhleGR1bXAo bGVuPTEzMSk6IDAxIDAzIDAwIDdmIGZlIDAzIDkxIDAwIDIwIDAwIDAwIDAwIDAwIDAwIDAwIDE4 IDdkIDYxIDNkIDAyIDU4IDgzIDUzIDhiIDJkIGNkIDBiIGVjIDk4IDQwIGFhIDUyIDk3IDc3IDZh IDJiIDMzIDY1IGE5IGY2IDNlIDdhIDFlIGE5IDIxIGIwIGE5IDk4IDEwIDc3IDZhIDJiIDMzIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGM3IDU3IDMwIGM3IDYzIDg1IDg5IDFjIDQ4IDg3IDNj IDRiIDQ0IDZkIDk1IGQ2IDAwIDIwIDBiIDljIDY3IDllIGE3IDA0IDdmIDNlIDE3IDRiIGM1IDJi IGFlIGNlIGM5IGZiIDViIGFkIDBjIDE1IGIxIGI1IDFjIGMxIDI5IDc5IDg5IDM2IDM3IDdhIDg5 IGM1wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4KSUVFRSA4MDIuMVggUlg6IHZlcnNpb249MSB0eXBlPTMgbGVuZ3Ro PTEyN8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPsKgIEVBUE9MLUtl eSB0eXBlPTI1NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfaW5mbyAweDM5 MSAodmVyPTEga2V5aWR4PTEgcnN2ZD0wIEdyb3VwIEFjayBNSUMgU2VjdXJlKcKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBr ZXlfbGVuZ3RoPTMyIGtleV9kYXRhX2xlbmd0aD0zMsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPsKgIHJlcGxheV9jb3VudGVyIC0gaGV4 ZHVtcChsZW49OCk6IDAwIDAwIDAwIDAwIDAwIDAwIDE4IDdkwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X25v bmNlIC0gaGV4ZHVtcChsZW49MzIpOiA2MSAzZCAwMiA1OCA4MyA1MyA4YiAyZCBjZCAwYiBlYyA5 OCA0MCBhYSA1MiA5NyA3NyA2YSAyYiAzMyA2NSBhOSBmNiAzZSA3YSAxZSBhOSAyMSBiMCBhOSA5 OCAxMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj4KwqAga2V5X2l2IC0gaGV4ZHVtcChsZW49MTYpOiA3NyA2YSAyYiAzMyAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+wqAga2V5X3JzYyAtIGhleGR1bXAobGVuPTgpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X2lkIChyZXNlcnZlZCkgLSBoZXhkdW1wKGxl bj04KTogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X21pYyAtIGhleGR1bXAo bGVuPTE2KTogYzcgNTcgMzAgYzcgNjMgODUgODkgMWMgNDggODcgM2MgNGIgNDQgNmQgOTUgZDbC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJYIEVBUE9MLUtleSAtIGhleGR1 bXAobGVuPTEzMSk6IDAxIDAzIDAwIDdmIGZlIDAzIDkxIDAwIDIwIDAwIDAwIDAwIDAwIDAwIDAw IDE4IDdkIDYxIDNkIDAyIDU4IDgzIDUzIDhiIDJkIGNkIDBiIGVjIDk4IDQwIGFhIDUyIDk3IDc3 IDZhIDJiIDMzIDY1IGE5IGY2IDNlIDdhIDFlIGE5IDIxIGIwIGE5IDk4IDEwIDc3IDZhIDJiIDMz IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGM3IDU3IDMwIGM3IDYzIDg1IDg5IDFjIDQ4IDg3 IDNjIDRiIDQ0IDZkIDk1IGQ2IDAwIDIwIDBiIDljIDY3IDllIGE3IDA0IDdmIDNlIDE3IDRiIGM1 IDJiIGFlIGNlIGM5IGZiIDViIGFkIDBjIDE1IGIxIGI1IDFjIGMxIDI5IDc5IDg5IDM2IDM3IDdh IDg5IGM1wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj4KV1BBOiBSWCBtZXNzYWdlIDEgb2YgR3JvdXAgS2V5IEhhbmRzaGFrZSBmcm9tIDAwOjE3Ojlh OmYwOmI2OjgyICh2ZXI9MSnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+U3RhdGU6IENPTVBMRVRFRCAtJmd0OyBHUk9VUF9IQU5EU0hBS0XCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBHcm91cCBLZXkg LSBoZXhkdW1wKGxlbj0zMik6IGQ1IGFjIDljIDI3IDE4IDY0IGFhIGRkIGY2IDA4IDhjIDdkIGU1 IDFmIDcxIGQ4IGY3IDljIDgzIDkxIDNhIDJkIGJmIGI3IGJkIGNhIGUyIDYzIDNhIGNkIDdiIDY2 PGJyPgpXUEE6IEluc3RhbGxpbmcgR1RLIHRvIHRoZSBkcml2ZXIgKGtleWlkeD0xIHR4PTAgbGVu PTMyKS48YnI+V1BBOiBSU0MgLSBoZXhkdW1wKGxlbj02KTogMDAgMDAgMDAgMDAgMDAgMDA8YnI+ d3BhX2RyaXZlcl9ic2Rfc2V0X2tleTogYWxnPVRLSVAgYWRkcj1mZjpmZjpmZjpmZjpmZjpmZiBr ZXlfaWR4PTEgc2V0X3R4PTAgc2VxX2xlbj02IGtleV9sZW49MzI8YnI+V1BBOiBTZW5kaW5nIEVB UE9MLUtleSAyLzI8YnI+CldQQTogVFggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49OTkpOiAwMSAw MyAwMCA1ZiBmZSAwMyAxMSAwMCAyMCAwMCAwMCAwMCAwMCAwMCAwMCAxOCA3ZCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCA2ZCA1YyA4YiAyZSBhMSA4MCAyMiAyZCBlYyBkOSBiYiAzOSBiNSAzZCA4NiBi NiAwMCAwMDxicj4KV1BBOiBHcm91cCByZWtleWluZyBjb21wbGV0ZWQgd2l0aCAwMDoxNzo5YTpm MDpiNjo4MiBbR1RLPVRLSVBdPGJyPkNhbmNlbGxpbmcgYXV0aGVudGljYXRpb24gdGltZW91dDxi cj5TdGF0ZTogR1JPVVBfSEFORFNIQUtFIC0mZ3Q7IENPTVBMRVRFRDxicj5eQ0NUUkwtRVZFTlQt VEVSTUlOQVRJTkcgLSBzaWduYWwgMiByZWNlaXZlZDxicj5SZW1vdmluZyBpbnRlcmZhY2Ugd2xh bjA8YnI+ClN0YXRlOiBDT01QTEVURUQgLSZndDsgRElTQ09OTkVDVEVEPGJyPndwYV9kcml2ZXJf YnNkX2RlYXV0aGVudGljYXRlPGJyPndwYV9kcml2ZXJfYnNkX2RlbF9rZXk6IGtleWlkeD0wPGJy PndwYV9kcml2ZXJfYnNkX2RlbF9rZXk6IGtleWlkeD0xPGJyPndwYV9kcml2ZXJfYnNkX2RlbF9r ZXk6IGtleWlkeD0yPGJyPndwYV9kcml2ZXJfYnNkX2RlbF9rZXk6IGtleWlkeD0zPGJyPndwYV9k cml2ZXJfYnNkX2RlbF9rZXk6IGFkZHI9MDA6MTc6OWE6ZjA6YjY6ODIga2V5aWR4PTA8YnI+Cmlv Y3RsW1NJT0NTODAyMTEsIG9wIDIwLCBsZW4gN106IENhbiYjMzk7dCBhc3NpZ24gcmVxdWVzdGVk IGFkZHJlc3M8YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X3dwYTogZW5hYmxlZD0wPGJyPndwYV9kcml2 ZXJfYnNkX3NldF93cGFfaW50ZXJuYWw6IHdwYT0wIHByaXZhY3k9MDxicj5pb2N0bFtTSU9DUzgw MjExLCBvcCAyNiwgYXJnIDB4MF06IE9wZXJhdGlvbiBub3Qgc3VwcG9ydGVkPGJyPgpGYWlsZWQg dG8gZGlzYWJsZSBXUEEgaW4gdGhlIGRyaXZlci48YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X2Ryb3Bf dW5lbmNyeXB0ZWQ6IGVuYWJsZWQ9MDxicj53cGFfZHJpdmVyX2JzZF9zZXRfY291bnRlcm1lYXN1 cmVzOiBlbmFibGVkPTA8YnI+Tm8ga2V5cyBoYXZlIGJlZW4gY29uZmlndXJlZCAtIHNraXAga2V5 IGNsZWFyaW5nPGJyPkNhbmNlbGxpbmcgc2NhbiByZXF1ZXN0PGJyPkNhbmNlbGxpbmcgYXV0aGVu dGljYXRpb24gdGltZW91dDxicj4Kd3BhX2RyaXZlcl9ic2Rfc2V0X3dwYV9pbnRlcm5hbDogd3Bh PTEgcHJpdmFjeT0wPGJyPkVMT09QOiByZW1haW5pbmcgc29ja2V0OiBzb2NrPTQgZWxvb3BfZGF0 YT0weDI4MzA1MTQwIHVzZXJfZGF0YT0weDI4MzBkMDQwIGhhbmRsZXI9MHg4MDY3YWEwPGJyPjxi cj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA5LzgvMzAgU2FtIExlZmZsZXIg PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86c2FtQGVycm5vLmNvbSI+c2FtQGVy cm5vLmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdp bjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+WW91IGFwcGVhciB0byBz YXkgdGhpcyBwcm9ibGVtIGRvZXMgbm90IGVudGlyZWx5IHN0b3AgdHJhZmZpYyBmcm9tIGZsb3dp bmcuIMKgUGxlYXNlIHByb3ZpZGUgYSBkZWJ1ZyB3cGFfc3VwcGxpY2FudCBsb2cgdGhhdCBzaG93 cyBhIGNvbXBsZXRlIHNlc3Npb24gKGkuZS4gYSBsb2cgd2l0aCAtZCBhbmQvb3IgLWRkKS48YnI+ Cgo8YnI+CldoeSBkbyB5b3Ugc2V0IGVhcG9sX3ZlcnNpb249MS4gwqBJcyB0aGlzIHJlYWxseSBu ZWVkZWQ/IMKgV2hhdCBpcyB5b3VyIEFQIG1ha2UvbW9kZWw/PGJyPgo8YnI+Ck5vdGUgYWxzbyB0 aGF0IGNvdW50cnk9UlUgaXMgaWdub3JlZCBvbiBmcmVlYnNkLjxicj48Zm9udCBjb2xvcj0iIzg4 ODg4OCI+Cjxicj4KIMKgIMKgIMKgIMKgU2FtPGJyPgo8L2ZvbnQ+PC9ibG9ja3F1b3RlPjwvZGl2 Pjxicj4K --0014852f5780d7c3810472602664-- From sam at FreeBSD.org Sun Aug 30 19:03:53 2009 From: sam at FreeBSD.org (sam@FreeBSD.org) Date: Sun Aug 30 19:03:59 2009 Subject: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Message-ID: <200908301903.n7UJ3qMB039737@freefall.freebsd.org> Synopsis: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Sun Aug 30 19:03:26 UTC 2009 Responsible-Changed-Why: I'll handle this http://www.freebsd.org/cgi/query-pr.cgi?pr=138331 From sinister at gmail.com Mon Aug 31 01:05:10 2009 From: sinister at gmail.com (Sin) Date: Mon Aug 31 01:05:17 2009 Subject: ath0 unable to DHCP as part of a bridge Message-ID: Hello, I'm using FreeBSD 7-STABLE. I have 6 NICs as a bridged interface, one of which is a ath0 wireless NIC. I don't understand if this acting the way it should. If I try to dhclient on interfact ath0 I'll get the request no problems. But if I dhclient to bridge0 interface, it acts like there's no server - Even though its bridged. Also note if I connect a cable to any of the wired NICs, dhclient will then work on bridge0 interface. The setup is kinda complicated, but i'm hoping someone may have a different view on it. One thing that confused me is that the line in /etc/rc.conf ifconfig_ath0="WPA" - it does not matter if this line is before or after the bridge declaration. Compiled into the kernel: options NETGRAPH options NETGRAPH_L2TP options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_MPPC_ENCRYPTION options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options IPFIREWALL_DEFAULT_TO_ACCEPT device if_bridge #Bridge interface device gre #IP over IP tunneling FreeBSD domainname 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Aug 29 05:39:09 EDT 2009 root@domainname:/tmp/CVS/src/sys/i386/compile/TESTROUTER i386 test# kldstat Id Refs Address Size Name 1 3 0xc0400000 556810 kernel 2 1 0xc0957000 6a49c acpi.ko test# ifconfig -a sk0: flags=8943 metric 0 mtu 1500 options=8 ether 00:0f:3d:88:18:31 media: Ethernet autoselect (none) status: no carrier vr0: flags=8943 metric 0 mtu 1500 options=2808 ether 00:05:5d:75:1a:12 media: Ethernet autoselect (none) status: no carrier vr1: flags=8943 metric 0 mtu 1500 options=2808 ether 00:05:5d:e9:61:79 media: Ethernet autoselect (none) status: no carrier ath0: flags=8943 metric 0 mtu 1500 ether 00:17:9a:4c:e7:83 inet 192.168.0.251 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid dts channel 2 (2417 Mhz 11g) bssid 00:17:9a:9e:f3:82 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst roaming MANUAL bintval 30 sk1: flags=8943 metric 0 mtu 1500 options=8 ether 00:11:95:d7:25:e3 media: Ethernet autoselect (none) status: no carrier sk2: flags=8943 metric 0 mtu 1500 options=8 ether 00:11:95:d7:25:ee media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 96:25:58:f9:dd:3d id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr1 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 55 member: vr0 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 55 member: sk2 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 55 member: sk1 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 55 member: sk0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 55 member: ath0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 76923 - 7.1-RELEASE upgrade to stable without mergemaster - world and kenel built from this supfile: test# cat /tmp/CVS/supfile *default tag=RELENG_7 *default host=cvsup1.ca.FreeBSD.org *default prefix=/tmp/CVS *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all example of the exact issue as found in the command line: test# dhclient bridge0 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 21 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 7 No DHCPOFFERS received. No working leases in persistent database - sleeping. test# dhclient ath0 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.177 -- renewal in 43200 seconds. From spawk at acm.poly.edu Mon Aug 31 01:17:56 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Mon Aug 31 01:18:03 2009 Subject: ath0 unable to DHCP as part of a bridge In-Reply-To: References: Message-ID: <4A9B249D.1050104@acm.poly.edu> Sin wrote: > Hello, > > > I'm using FreeBSD 7-STABLE. I have 6 NICs as a bridged interface, one of which is a ath0 wireless NIC. I don't understand if this acting the way it should. If I try to dhclient on interfact ath0 I'll get the request no problems. But if I dhclient to bridge0 interface, it acts like there's no server - Even though its bridged. Also note if I connect a cable to any of the wired NICs, dhclient will then work on bridge0 interface. > > The setup is kinda complicated, but i'm hoping someone may have a different view on it. One thing that confused me is that the line in /etc/rc.conf ifconfig_ath0="WPA" - it does not matter if this line is before or after the bridge declaration. > > > Compiled into the kernel: > > > options NETGRAPH > options NETGRAPH_L2TP > options NETGRAPH_PPP > options NETGRAPH_PPPOE > options NETGRAPH_PPTPGRE > options NETGRAPH_MPPC_ENCRYPTION > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT > options IPFIREWALL_DEFAULT_TO_ACCEPT > > device if_bridge #Bridge interface > device gre #IP over IP tunneling > > > > > FreeBSD domainname 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Aug 29 05:39:09 EDT 2009 root@domainname:/tmp/CVS/src/sys/i386/compile/TESTROUTER i386 > > > test# kldstat > Id Refs Address Size Name > 1 3 0xc0400000 556810 kernel > 2 1 0xc0957000 6a49c acpi.ko > > > test# ifconfig -a > sk0: flags=8943 metric 0 mtu 1500 > options=8 > ether 00:0f:3d:88:18:31 > media: Ethernet autoselect (none) > status: no carrier > vr0: flags=8943 metric 0 mtu 1500 > options=2808 > ether 00:05:5d:75:1a:12 > media: Ethernet autoselect (none) > status: no carrier > vr1: flags=8943 metric 0 mtu 1500 > options=2808 > ether 00:05:5d:e9:61:79 > media: Ethernet autoselect (none) > status: no carrier > ath0: flags=8943 metric 0 mtu 1500 > ether 00:17:9a:4c:e7:83 > inet 192.168.0.251 netmask 0xffffff00 broadcast 192.168.0.255 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) > status: associated > ssid dts channel 2 (2417 Mhz 11g) bssid 00:17:9a:9e:f3:82 > authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit > txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 > bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst > roaming MANUAL bintval 30 > sk1: flags=8943 metric 0 mtu 1500 > options=8 > ether 00:11:95:d7:25:e3 > media: Ethernet autoselect (none) > status: no carrier > sk2: flags=8943 metric 0 mtu 1500 > options=8 > ether 00:11:95:d7:25:ee > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > bridge0: flags=8843 metric 0 mtu 1500 > ether 96:25:58:f9:dd:3d > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: vr1 flags=143 > ifmaxaddr 0 port 3 priority 128 path cost 55 > member: vr0 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 55 > member: sk2 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 55 > member: sk1 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 55 > member: sk0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 55 > member: ath0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 76923 > > > - 7.1-RELEASE upgrade to stable without mergemaster > - world and kenel built from this supfile: > > test# cat /tmp/CVS/supfile > *default tag=RELENG_7 > *default host=cvsup1.ca.FreeBSD.org > *default prefix=/tmp/CVS > *default base=/var/db > *default release=cvs delete use-rel-suffix compress > > src-all > > > > > example of the exact issue as found in the command line: > > test# dhclient bridge0 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 4 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 5 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 10 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 14 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 21 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 7 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > test# dhclient ath0 > DHCPREQUEST on ath0 to 255.255.255.255 port 67 > DHCPACK from 192.168.0.1 > bound to 192.168.0.177 -- renewal in 43200 seconds. > > _______________________________________________ > 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" > I think you are hitting the limitation described at the bottom of the if_bridge(4) man page: Only wireless interfaces in hostap mode can be bridged due to the 802.11 framing format, bridging a wireless client is not supported yet. -Boris From paul at gtcomm.net Mon Aug 31 04:10:07 2009 From: paul at gtcomm.net (Paul) Date: Mon Aug 31 04:10:14 2009 Subject: kern/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode Message-ID: <200908310410.n7V4A7qS005349@freefall.freebsd.org> The following reply was made to PR kern/122780; it has been noted by GNATS. From: Paul To: Ed Maste Cc: bug-followup@FreeBSD.org Subject: Re: kern/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode Date: Sun, 30 Aug 2009 23:33:59 -0400 Yes next time I reboot one of the routers I can test it. Have you guys made any progress on SMP routing yet? Ed Maste wrote: > Can you retest on recent 7.x or HEAD? I think there have been BPF changes > to address this issue. > > -Ed > > -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 paul@gtcomm.net http://www.gtcomm.net From linimon at FreeBSD.org Mon Aug 31 10:32:41 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 31 10:32:53 2009 Subject: kern/138378: [altq] [patch] Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c Message-ID: <200908311032.n7VAWeDg039961@freefall.freebsd.org> Old Synopsis: Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c New Synopsis: [altq] [patch] Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 31 10:32:03 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138378 From bugmaster at FreeBSD.org Mon Aug 31 11:07:12 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:08:57 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200908311107.n7VB7Bx8070647@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/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138292 net [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/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 bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/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 o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal 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 bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] 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/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 331 problems total. From gavin at FreeBSD.org Mon Aug 31 11:58:19 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Aug 31 11:58:30 2009 Subject: kern/113432: [ucom] WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Message-ID: <200908311158.n7VBwIEt026898@freefall.freebsd.org> Synopsis: [ucom] WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Responsible-Changed-From-To: freebsd-usb->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Aug 31 11:55:54 UTC 2009 Responsible-Changed-Why: I believe this is more likely to be a problem at the netgraph level rather than USB. http://www.freebsd.org/cgi/query-pr.cgi?pr=113432 From gavin at FreeBSD.org Mon Aug 31 14:22:27 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Aug 31 14:22:38 2009 Subject: kern/138390: [gif] [patch] NULL pointer dereference in gif_input() in file sys/net/if_gif.c Message-ID: <200908311422.n7VEMREW076687@freefall.freebsd.org> Old Synopsis: NULL pointer dereference in gif_input() in file sys/net/if_gif.c New Synopsis: [gif] [patch] NULL pointer dereference in gif_input() in file sys/net/if_gif.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Aug 31 14:20:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=138390 From stef-list at memberwebs.com Mon Aug 31 17:01:39 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Mon Aug 31 17:01:45 2009 Subject: [patch] Unbreak setfib + routing daemons Message-ID: Currently route messages are sent to all listeners of PF_ROUTE, regardless or which FIB the listener socket was started on. The upshot of this is that one can't really use routing daemons together with multiple FIBs. The routing daemon sees the messages from the alternate FIBs and rapidly gets confused. In the future, someone might decide to expose FIB numbers in the route messages themselves. This could allow routing daemons to filter them out. Such a solution might be appropriate for FreeBSD 9.x and later, as it would likely break API and ABI. In any case, I'm not really qualified to argue the merits/problems of such an approach, and coding it is beyond my abilities... Attached is a patch which fixes this problem in a simple way. It limits route messages to listening PF_ROUTE sockets on the same FIB that the route message was for. It compiles and works on 7.1+ and 8.0 and CURRENT. FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931 How can I help this get into FreeBSD? It would be awesome if this fix or one like it made it in before the 8.0 release. Cheers, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd-route-messages-respect-fib.patch Type: text/x-diff Size: 578 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090831/d9136b1c/freebsd-route-messages-respect-fib.bin From stef-list at memberwebs.com Mon Aug 31 17:20:08 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Mon Aug 31 17:20:45 2009 Subject: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib Message-ID: <200908311720.n7VHK8El047213@freefall.freebsd.org> The following reply was made to PR kern/134931; it has been noted by GNATS. From: Stef Walter To: bug-followup@FreeBSD.org, count@211.ru Cc: Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib Date: Mon, 31 Aug 09 17:20:06 UTC This is a multi-part message in MIME format. --------------030509050508050401080102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As it currently stands, using routing daemons + multiple fibs in FreeBSD 7.x and 8.x is pretty much broken. Here's a patch which fixes the problem. I agree in principle with Mark that having future route messages might be able to let routing daemons differentiate between various fibs and manage them, and that this might be a feature.... However any implementation of that would likely break API and ABI, and very probably exist purely in FreeBSD 9.x. All the best, Stef --------------030509050508050401080102 Content-Type: text/x-diff; name="freebsd-route-messages-respect-fib.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-route-messages-respect-fib.patch" --- sys/net/rtsock.c.orig 2009-08-31 15:26:03.000000000 +0000 +++ sys/net/rtsock.c 2009-08-31 16:07:06.000000000 +0000 @@ -777,4 +777,5 @@ } if (m) { + M_SETFIB(m, so->so_fibnum); if (rp) { /* --- sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.000000000 +0000 +++ sys/net/raw_usrreq.c 2009-08-31 16:05:11.000000000 +0000 @@ -84,4 +84,7 @@ rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (proto->sp_family == PF_ROUTE && rp->rcb_socket && + M_GETFIB (m) != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; --------------030509050508050401080102-- From qing.li at bluecoat.com Mon Aug 31 17:26:37 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Aug 31 17:26:43 2009 Subject: [patch] Unbreak setfib + routing daemons In-Reply-To: <200908311702.n7VH2iHI022732@whisker.bluecoat.com> References: <200908311702.n7VH2iHI022732@whisker.bluecoat.com> Message-ID: Hi Stef, I am not sure if this patch is complete. There are other commands through the routing socket that can trigger routing messages. For example, issuing "ifconfig" to add and remove interface addresses. At the moment these types of routing messages do not have a fib associated with them, which may need fixing. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Stef Walter > Sent: Monday, August 31, 2009 10:03 AM > To: freebsd-net@FreeBSD.org > Subject: [patch] Unbreak setfib + routing daemons > > Currently route messages are sent to all listeners of PF_ROUTE, > regardless or which FIB the listener socket was started on. > > The upshot of this is that one can't really use routing daemons > together > with multiple FIBs. The routing daemon sees the messages from the > alternate FIBs and rapidly gets confused. > > In the future, someone might decide to expose FIB numbers in the route > messages themselves. This could allow routing daemons to filter them > out. Such a solution might be appropriate for FreeBSD 9.x and later, as > it would likely break API and ABI. In any case, I'm not really > qualified > to argue the merits/problems of such an approach, and coding it is > beyond my abilities... > > Attached is a patch which fixes this problem in a simple way. It limits > route messages to listening PF_ROUTE sockets on the same FIB that the > route message was for. It compiles and works on 7.1+ and 8.0 and > CURRENT. > > FreeBSD PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931 > > How can I help this get into FreeBSD? It would be awesome if this fix > or > one like it made it in before the 8.0 release. > > Cheers, > > Stef From linimon at FreeBSD.org Mon Aug 31 17:37:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Aug 31 17:37:17 2009 Subject: kern/138407: [gre] gre(4) interface does not come up after reboot Message-ID: <200908311737.n7VHb4NC068143@freefall.freebsd.org> Old Synopsis: gre(4) interface does not come up after reboot New Synopsis: [gre] gre(4) interface does not come up after reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 31 17:36:28 UTC 2009 Responsible-Changed-Why: Most likely a problem in the driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=138407 From bms at incunabulum.net Mon Aug 31 17:57:24 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Aug 31 17:57:36 2009 Subject: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib In-Reply-To: <200908311720.n7VHK8El047213@freefall.freebsd.org> References: <200908311720.n7VHK8El047213@freefall.freebsd.org> Message-ID: <4A9C0F00.7020208@incunabulum.net> Stef Walter wrote: > I agree in principle with Mark that having future route messages might > be able to let routing daemons differentiate between various fibs and > manage them, and that this might be a feature.... However any > implementation of that would likely break API and ABI, and very probably > exist purely in FreeBSD 9.x. > Surely a good time for someone to act on the suggestion that we implement the Netlink socket family? It is a Tag-Length-Value protocol, so it can easily adapt to new additions. It exists as an informational RFC, therefore it is not encumbered by the GPL; however it would need to be carefully implemented in FreeBSD. It's who dares wins -- I wouldn't object to doing it, but I'm committed to doing other stuff for the moment. From jhay at meraka.org.za Mon Aug 31 18:11:24 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Aug 31 18:11:31 2009 Subject: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib In-Reply-To: <200908311720.n7VHK8El047213@freefall.freebsd.org> References: <200908311720.n7VHK8El047213@freefall.freebsd.org> Message-ID: <20090831181122.GA18911@zibbi.meraka.csir.co.za> On Mon, Aug 31, 2009 at 05:20:08PM +0000, Stef Walter wrote: > The following reply was made to PR kern/134931; it has been noted by GNATS. > > From: Stef Walter > To: bug-followup@FreeBSD.org, count@211.ru > Cc: > Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners > regardless of setfib > Date: Mon, 31 Aug 09 17:20:06 UTC > > As it currently stands, using routing daemons + multiple fibs in FreeBSD > 7.x and 8.x is pretty much broken. Here's a patch which fixes the problem. This sounds good. Currently quagga gets really confused if route changes to another fib is made. For instance, if you add a default route to another fib, quagga will remove the default route from its fib. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From julian at elischer.org Mon Aug 31 18:16:30 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 31 18:16:37 2009 Subject: [patch] Unbreak setfib + routing daemons Message-ID: <4A9C137C.7020303@elischer.org> Stef Walter wrote: > Currently route messages are sent to all listeners of PF_ROUTE, > regardless or which FIB the listener socket was started on. > > The upshot of this is that one can't really use routing daemons together > with multiple FIBs. The routing daemon sees the messages from the > alternate FIBs and rapidly gets confused. > > In the future, someone might decide to expose FIB numbers in the route > messages themselves. This could allow routing daemons to filter them > out. Such a solution might be appropriate for FreeBSD 9.x and later, as > it would likely break API and ABI. In any case, I'm not really qualified > to argue the merits/problems of such an approach, and coding it is > beyond my abilities... > > Attached is a patch which fixes this problem in a simple way. It limits > route messages to listening PF_ROUTE sockets on the same FIB that the > route message was for. It compiles and works on 7.1+ and 8.0 and CURRENT. there are two ways to go with this one being what you have done teh other to add fib info to the messages, Apparently OpenBSD has implemented the second by re-using a disused field. (I'm ve only been told this second hand) I"ll look a tyour change and see what we can do. it might just make it to 8.1 at this stage but we can see what it looks like. > > FreeBSD PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931 how much have you tested this? > > How can I help this get into FreeBSD? It would be awesome if this fix or > one like it made it in before the 8.0 release. > > Cheers, > > Stef > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 stef-list at memberwebs.com Mon Aug 31 19:47:34 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Mon Aug 31 19:47:40 2009 Subject: [patch] Unbreak setfib + routing daemons References: <4A9C137C.7020303@elischer.org> Message-ID: Julian Elischer wrote: > there are two ways to go with this one being what you have done teh > other to add fib info to the messages, Apparently > OpenBSD has implemented the second by re-using a disused field. > (I'm ve only been told this second hand) It seems like they've taken apart the rtm_flags field (int), and repurposed it as rtm_tableid (u_short), rtm_priority (u_char) and padding. Obviously such a change would require patches to the various routing daemons as well. But if you think this is the only way forward (ie: filtering the messages in userland), I'd be happy to contribute. > I"ll look a tyour change and see what we can do. > it might just make it to 8.1 at this stage but we can > see what it looks like. I've posted a new patch which should handle all the various senders of route messages better. Qing Li pointed out some naive assumptions I made in my initial patch. It's more complex because we can no longer use M_GETFIB and M_SETFIB to relay FIB information into the netisr routine. > how much have you tested this? I need this for some client systems that we're upgrading. I'll be putting it into production this week. If there's any problems with it, I'll let you and the mailing list know. Cheers, Stef From stef-list at memberwebs.com Mon Aug 31 20:00:15 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Mon Aug 31 20:00:21 2009 Subject: kern/134931 [patch] Unbreak setfib + routing daemons Message-ID: <200908312000.n7VK0Eqj012791@freefall.freebsd.org> The following reply was made to PR kern/134931; it has been noted by GNATS. From: Stef Walter To: "Li, Qing" Cc: "freebsd-net@FreeBSD.org" , bug-followup@FreeBSD.org, julian@elischer.org Subject: Re: kern/134931 [patch] Unbreak setfib + routing daemons Date: Mon, 31 Aug 09 20:00:13 UTC This is a multi-part message in MIME format. --------------000601070001040803040904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Li, Qing wrote: > There are other commands through the routing socket that > can trigger routing messages. For example, issuing "ifconfig" > to add and remove interface addresses. Thanks for taking a look at this and catching that problem. Here's a new patch which does the following: * Both rt_dispatch and raw_input accept an fib, or -1 (for any fib). * Pases the fib along in the context to the netisr routine that actually dispatches route messages. * As you noted, some senders of route messages don't have the context necessary to know what fib a message would belong to. Where possible we pass in the appropriate fib to the routines that send off route messages. Cheers, Stef --------------000601070001040803040904 Content-Type: text/x-diff; name="freebsd-route-messages-respect-fib-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-route-messages-respect-fib-2.patch" --- ./sys/net/rtsock.c.orig 2009-08-31 15:26:03.000000000 +0000 +++ ./sys/net/rtsock.c 2009-08-31 19:06:53.000000000 +0000 @@ -93,4 +93,9 @@ SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, ""); +struct rt_dispatch_ctx { + unsigned short family; /* Socket family */ + int fibnum; /* FIB for message or -1 for all */ +}; + struct walkarg { int w_tmemsize; @@ -114,5 +119,5 @@ static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, const struct sockaddr *, int); static struct netisr_handler rtsock_nh = { @@ -155,17 +160,19 @@ { struct sockproto route_proto; - unsigned short *family; + struct rt_dispatch_ctx *ctx; struct m_tag *tag; + int fibnum = -1; route_proto.sp_family = PF_ROUTE; - tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL); + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); if (tag != NULL) { - family = (unsigned short *)(tag + 1); - route_proto.sp_protocol = *family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + route_proto.sp_protocol = ctx->family; + fibnum = ctx->fibnum; m_tag_delete(m, tag); } else route_proto.sp_protocol = 0; - raw_input(m, &route_proto, &route_src); + raw_input(m, &route_proto, &route_src, fibnum); } @@ -784,8 +791,8 @@ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); } } @@ -1010,5 +1017,5 @@ */ void -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error) +rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum) { struct rt_msghdr *rtm; @@ -1025,5 +1032,5 @@ rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } @@ -1050,5 +1057,5 @@ ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } @@ -1062,5 +1069,5 @@ */ void -rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt) +rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum) { struct rt_addrinfo info; @@ -1120,5 +1127,5 @@ rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } } @@ -1156,5 +1163,5 @@ ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr, -1); } @@ -1216,5 +1223,5 @@ m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } } @@ -1232,10 +1239,11 @@ m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum) { + struct rt_dispatch_ctx *ctx; struct m_tag *tag; @@ -1243,14 +1251,16 @@ * Preserve the family from the sockaddr, if any, in an m_tag for * use when injecting the mbuf into the routing socket buffer from - * the netisr. + * the netisr. Additionally save the fibnum if needed. */ - if (sa != NULL) { - tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), - M_NOWAIT); + if (sa != NULL || fibnum >= 0) { + tag = m_tag_get(PACKET_TAG_RTSOCK, + sizeof(struct rt_dispatch_ctx*), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + ctx->family = sa->sa_family; + ctx->fibnum = fibnum; m_tag_prepend(m, tag); } --- ./sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.000000000 +0000 +++ ./sys/net/raw_usrreq.c 2009-08-31 18:34:38.000000000 +0000 @@ -70,5 +70,5 @@ */ void -raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src) +raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src, int fibnum) { struct rawcb *rp; @@ -84,4 +84,7 @@ rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (fibnum >= 0 && rp->rcb_socket && + fibnum != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; --- ./sys/net/raw_cb.h.orig 2009-08-31 18:34:56.000000000 +0000 +++ ./sys/net/raw_cb.h 2009-08-31 18:35:05.000000000 +0000 @@ -73,5 +73,5 @@ int raw_attach(struct socket *, int); void raw_detach(struct rawcb *); -void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *); +void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *, int); /* --- ./sys/net/route.c.orig 2009-08-31 18:18:30.000000000 +0000 +++ ./sys/net/route.c 2009-08-31 18:59:20.000000000 +0000 @@ -384,5 +384,5 @@ bzero(&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; - rt_missmsg(msgtype, &info, 0, err); + rt_missmsg(msgtype, &info, 0, err, fibnum); } done: @@ -609,5 +609,5 @@ info.rti_info[RTAX_NETMASK] = netmask; info.rti_info[RTAX_AUTHOR] = src; - rt_missmsg(RTM_REDIRECT, &info, flags, error); + rt_missmsg(RTM_REDIRECT, &info, flags, error, fibnum); if (ifa != NULL) ifa_free(ifa); @@ -1433,5 +1433,5 @@ rt->rt_ifp->if_index; } - rt_newaddrmsg(cmd, ifa, error, rt); + rt_newaddrmsg(cmd, ifa, error, rt, fibnum); if (cmd == RTM_DELETE) { /* --- ./sys/net/route.h.orig 2009-08-31 18:56:05.000000000 +0000 +++ ./sys/net/route.h 2009-08-31 18:59:32.000000000 +0000 @@ -381,6 +381,6 @@ void rt_ifannouncemsg(struct ifnet *, int); void rt_ifmsg(struct ifnet *); -void rt_missmsg(int, struct rt_addrinfo *, int, int); -void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *); +void rt_missmsg(int, struct rt_addrinfo *, int, int, int); +void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *, int); void rt_newmaddrmsg(int, struct ifmultiaddr *); int rt_setgate(struct rtentry *, struct sockaddr *, struct sockaddr *); --- ./sys/netinet6/nd6_rtr.c.orig 2009-08-31 18:19:54.000000000 +0000 +++ ./sys/netinet6/nd6_rtr.c 2009-08-31 19:09:27.000000000 +0000 @@ -449,5 +449,5 @@ ifa = NULL; - rt_missmsg(cmd, &info, rt->rt_flags, 0); + rt_missmsg(cmd, &info, rt->rt_flags, 0, -1); if (ifa != NULL) ifa_free(ifa); --- ./sys/netinet6/in6.c.orig 2009-08-31 19:00:43.000000000 +0000 +++ ./sys/netinet6/in6.c 2009-08-31 19:01:00.000000000 +0000 @@ -1238,5 +1238,5 @@ rt_key(&rt0) = (struct sockaddr *)&addr; rt0.rt_flags = RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0); + rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0, -1); /* @@ -1831,5 +1831,5 @@ rt_key(&rt) = (struct sockaddr *)&addr; rt.rt_flags = RTF_UP | RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt); + rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt, -1); } --- ./sys/sys/mbuf.h.orig 2009-08-31 18:26:12.000000000 +0000 +++ ./sys/sys/mbuf.h 2009-08-31 18:26:24.000000000 +0000 @@ -897,5 +897,5 @@ #define PACKET_TAG_MACLABEL (19 | MTAG_PERSISTENT) /* MAC label */ #define PACKET_TAG_PF 21 /* PF + ALTQ information */ -#define PACKET_TAG_RTSOCKFAM 25 /* rtsock sa family */ +#define PACKET_TAG_RTSOCK 25 /* rtsock extra info */ #define PACKET_TAG_IPOPTIONS 27 /* Saved IP options */ #define PACKET_TAG_CARP 28 /* CARP info */ --------------000601070001040803040904-- From stef-list at memberwebs.com Mon Aug 31 19:50:38 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Mon Aug 31 20:01:42 2009 Subject: kern/134931 [patch] Unbreak setfib + routing daemons References: <200908311702.n7VH2iHI022732@whisker.bluecoat.com> Message-ID: Li, Qing wrote: > There are other commands through the routing socket that > can trigger routing messages. For example, issuing "ifconfig" > to add and remove interface addresses. Thanks for taking a look at this and catching that problem. Here's a new patch which does the following: * Both rt_dispatch and raw_input accept an fib, or -1 (for any fib). * Pases the fib along in the context to the netisr routine that actually dispatches route messages. * As you noted, some senders of route messages don't have the context necessary to know what fib a message would belong to. Where possible we pass in the appropriate fib to the routines that send off route messages. Cheers, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd-route-messages-respect-fib-2.patch Type: text/x-diff Size: 7581 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090831/f4d42ad2/freebsd-route-messages-respect-fib-2.bin From seklecki at noc.cfi.pgh.pa.us Mon Aug 31 22:20:11 2009 From: seklecki at noc.cfi.pgh.pa.us (Brian A. Seklecki) Date: Mon Aug 31 22:20:18 2009 Subject: native vlan In-Reply-To: References: Message-ID: <1251757207.25573.1794.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Mon, 2009-08-24 at 12:12 -0700, Graham Smith wrote: > requiring creation of native vlan (vlan 0) and why native vlan are > most suitable for this scene ? Cisco highly recommend changing the management VLAN away from VLAN1. Here's an example, of using alternative native VLANs, ironically, on the one Cisco product that doesn't follow that VLAN1-rule. On the Cisco Aironet AP 1200, you can run a Dot1Q VLAN trunk to map X-number of different ESSIDs-to-VLANs. You do this by setting the "bridge-group" of the Ethernet Subinterface and the Dot11Radio subinterfaces to the same VLAN that you would like to bridge. Whereas, management traffic (Monitoring, etc.) has to run on "BVI1", or Bridged Virtual Interface 1, which must transmit untagged on Ethernet0. This stipulation is set by the Bridging IOS on the AP1200. If your management VLAN is something other than VLAN1 (god forbid), you simply set the "native VLAN" on that Dot1Q trunk port on the Catalyst to some other VLAN From bzeeb-lists at lists.zabbadoz.net Mon Aug 31 22:27:47 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Aug 31 22:27:54 2009 Subject: CFR/CFT: plug mbuf leak in new arp code Message-ID: <20090831215129.V93661@maildrop.int.zabbadoz.net> Hi, I have a patch for FreeBSD 8.x / 9-CURRENT that plugs an mbuf leak in the new arp code that needs review and further testing. Find a longer description of the problem at the beginning of the patch. There is a lot of context in the patch; if you want a shorter one, apply and re-gen it. If you want to see the current problem, log in to a remote 8/9 machine and repeatedly type ... over that connection (you need to be su): arp -ad > /dev/null ; netstat -m | head -1 Watch the first number. Warning: doing it too often will make that machine panic eventually. Here's the patch: http://people.freebsd.org/~bz/20090831-01-plug-new-arp-mbuf-leak.diff Thanks for your help in advance. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From julian at elischer.org Mon Aug 31 23:04:04 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 31 23:04:12 2009 Subject: CFR/CFT: plug mbuf leak in new arp code In-Reply-To: <20090831215129.V93661@maildrop.int.zabbadoz.net> References: <20090831215129.V93661@maildrop.int.zabbadoz.net> Message-ID: <4A9C56E2.7070609@elischer.org> Bjoern A. Zeeb wrote: > Hi, > > I have a patch for FreeBSD 8.x / 9-CURRENT that plugs an mbuf leak > in the new arp code that needs review and further testing. > > Find a longer description of the problem at the beginning of the > patch. There is a lot of context in the patch; if you want a shorter > one, apply and re-gen it. > > If you want to see the current problem, log in to a remote 8/9 machine > and repeatedly type ... over that connection (you need to be su): > arp -ad > /dev/null ; netstat -m | head -1 > Watch the first number. Warning: doing it too often will make that > machine panic eventually. > > Here's the patch: > http://people.freebsd.org/~bz/20090831-01-plug-new-arp-mbuf-leak.diff > > Thanks for your help in advance. > > /bz > looks pretty right... all the paths I followed through did the right thing WRT locks and mbufs.