From delphij at FreeBSD.org Mon Jun 1 05:33:32 2009 From: delphij at FreeBSD.org (delphij@FreeBSD.org) Date: Mon Jun 1 05:33:38 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE Message-ID: <200906010533.n515XVge028227@freefall.freebsd.org> Synopsis: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE State-Changed-From-To: open->feedback State-Changed-By: delphij State-Changed-When: Mon Jun 1 05:32:22 UTC 2009 State-Changed-Why: This seems to be a known issue. I have replied with a patch and waiting for feedback. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Mon Jun 1 05:32:22 UTC 2009 Responsible-Changed-Why: Grab. (Hopefully I can close this soon as I believe that it was patched in -STABLE). http://www.freebsd.org/cgi/query-pr.cgi?pr=135091 From smallpox at gmail.com Mon Jun 1 06:06:52 2009 From: smallpox at gmail.com (smallpox) Date: Mon Jun 1 06:06:58 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE In-Reply-To: <200906010533.n515XVge028227@freefall.freebsd.org> References: <200906010533.n515XVge028227@freefall.freebsd.org> Message-ID: <4A236FF6.1020200@gmail.com> delphij, i just tried it again and earlier today or last night i had tried -STABLE, didn't work. if you would like, i'll give you access to the second server, it's in the office.. i'm using it as a test machine because the production machine is unbelievably important. thanks. delphij@FreeBSD.org wrote: > Synopsis: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE > > State-Changed-From-To: open->feedback > State-Changed-By: delphij > State-Changed-When: Mon Jun 1 05:32:22 UTC 2009 > State-Changed-Why: > This seems to be a known issue. I have replied with a patch > and waiting for feedback. > > > Responsible-Changed-From-To: freebsd-net->delphij > Responsible-Changed-By: delphij > Responsible-Changed-When: Mon Jun 1 05:32:22 UTC 2009 > Responsible-Changed-Why: > Grab. (Hopefully I can close this soon as I believe that it > was patched in -STABLE). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=135091 > _______________________________________________ > 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 delphij at delphij.net Mon Jun 1 06:25:59 2009 From: delphij at delphij.net (Xin LI) Date: Mon Jun 1 06:26:06 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE In-Reply-To: <4A236FF6.1020200@gmail.com> References: <200906010533.n515XVge028227@freefall.freebsd.org> <4A236FF6.1020200@gmail.com> Message-ID: <4A237428.8040204@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 smallpox wrote: > delphij, i just tried it again and earlier today or last night i had > tried -STABLE, didn't work. > > if you would like, i'll give you access to the second server, it's in > the office.. i'm using it as a test machine because the production > machine is unbelievably important. Could you please use 'ident /sys/dev/bce/if_bce.c' and tell me the result? For me the change fixed the problem... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkojdCgACgkQi+vbBBjt66D4RQCgkNTZXJWS8D4W6e7Vl5lyVDXQ Of4AoIzIRLzD2/1iFTgyrZb1TeUNiylw =at+t -----END PGP SIGNATURE----- From smallpox at gmail.com Mon Jun 1 06:27:39 2009 From: smallpox at gmail.com (smallpox) Date: Mon Jun 1 06:27:45 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE In-Reply-To: <4A237428.8040204@delphij.net> References: <200906010533.n515XVge028227@freefall.freebsd.org> <4A236FF6.1020200@gmail.com> <4A237428.8040204@delphij.net> Message-ID: <4A2374D6.4040005@gmail.com> /sys/dev/bce/if_bce.c: $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.34.2.8 2009/05/20 21:13:49 delphij Exp $ Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > smallpox wrote: > >> delphij, i just tried it again and earlier today or last night i had >> tried -STABLE, didn't work. >> >> if you would like, i'll give you access to the second server, it's in >> the office.. i'm using it as a test machine because the production >> machine is unbelievably important. >> > > Could you please use 'ident /sys/dev/bce/if_bce.c' and tell me the > result? For me the change fixed the problem... > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkojdCgACgkQi+vbBBjt66D4RQCgkNTZXJWS8D4W6e7Vl5lyVDXQ > Of4AoIzIRLzD2/1iFTgyrZb1TeUNiylw > =at+t > -----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 delphij at delphij.net Mon Jun 1 06:48:54 2009 From: delphij at delphij.net (Xin LI) Date: Mon Jun 1 06:49:01 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE In-Reply-To: <4A2374D6.4040005@gmail.com> References: <200906010533.n515XVge028227@freefall.freebsd.org> <4A236FF6.1020200@gmail.com> <4A237428.8040204@delphij.net> <4A2374D6.4040005@gmail.com> Message-ID: <4A237988.5020401@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 smallpox wrote: > /sys/dev/bce/if_bce.c: > $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.34.2.8 2009/05/20 21:13:49 > delphij Exp $ Em... This would be weird, are you really sure that your kernel is built against this source? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkojeYgACgkQi+vbBBjt66Ah5gCfXNMC/orZOQmJ0OZdEwMzdWfD D/MAn0L57kBou3uHOZL9tRvStyexrQmi =bNmo -----END PGP SIGNATURE----- From smallpox at gmail.com Mon Jun 1 07:06:18 2009 From: smallpox at gmail.com (smallpox) Date: Mon Jun 1 07:06:25 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE In-Reply-To: <4A237988.5020401@delphij.net> References: <200906010533.n515XVge028227@freefall.freebsd.org> <4A236FF6.1020200@gmail.com> <4A237428.8040204@delphij.net> <4A2374D6.4040005@gmail.com> <4A237988.5020401@delphij.net> Message-ID: <4A237DE5.2060308@gmail.com> yea, i'm sorry. what i did was cd /usr/src/sys/modules/bce;make clean;make;make install and reboot.. but apparently that's not enough? thanks though. Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > smallpox wrote: > >> /sys/dev/bce/if_bce.c: >> $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.34.2.8 2009/05/20 21:13:49 >> delphij Exp $ >> > > Em... This would be weird, are you really sure that your kernel is > built against this source? > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkojeYgACgkQi+vbBBjt66Ah5gCfXNMC/orZOQmJ0OZdEwMzdWfD > D/MAn0L57kBou3uHOZL9tRvStyexrQmi > =bNmo > -----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 delphij at delphij.net Mon Jun 1 07:12:03 2009 From: delphij at delphij.net (Xin LI) Date: Mon Jun 1 07:12:10 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE In-Reply-To: <4A237DE5.2060308@gmail.com> References: <200906010533.n515XVge028227@freefall.freebsd.org> <4A236FF6.1020200@gmail.com> <4A237428.8040204@delphij.net> <4A2374D6.4040005@gmail.com> <4A237988.5020401@delphij.net> <4A237DE5.2060308@gmail.com> Message-ID: <4A237F01.4060203@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 smallpox wrote: > yea, i'm sorry. what i did was cd /usr/src/sys/modules/bce;make > clean;make;make install and reboot.. but apparently that's not enough? Not enough if you have bce(4) built into kernel, which is what the default (GENERIC) kernel do... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkojfwEACgkQi+vbBBjt66CdHQCeMZGJsyupxo3aTl09E8Vh8gX7 MqAAn0mR7l210LTDj5Hv/P+fJENUdWra =NNup -----END PGP SIGNATURE----- From to.my.trociny at gmail.com Mon Jun 1 08:12:51 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Mon Jun 1 08:12:58 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 In-Reply-To: <864ov9htgq.fsf@kopusha.onet> (Mikolaj Golub's message of "Mon\, 25 May 2009 22\:29\:25 +0300") References: <864ov9htgq.fsf@kopusha.onet> Message-ID: <81bpp8l6de.fsf@zhuzha.ua1> On Mon, 25 May 2009 22:29:25 +0300 Mikolaj Golub wrote: > Hi, > > Some times ago it has been posted to fido7.ru.unix.bsd about panics when using > ipfw + ng_ipfw + ng_car. > > http://groups.google.com/group/fido7.ru.unix.bsd/browse_thread/thread/5907d1ba4e76675d > > For those who haven't learnt Russian yet ;-) here are some details. Max > Irgiznov reported that when ng_ipf+ng_car construction was used and > net.inet.ip.fw.one_pass=0 was set, the system reliably panicked on ipfw rules > reload if there was some traffic through ng_car. > > The problem here is in the following. When the packet is returning back from > ng_car queue to ipfw_chk and one_pass is turned off the next rule is being > tried. But if the rules were reloaded while the packet was sitting in ng_car, > the next rule pointer might be dangling and the kernel will panic. > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc07e1f7e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc07e2252 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc0495eb7 in db_panic (addr=Could not find the frame base for "db_panic". > ) at /usr/src/sys/ddb/db_command.c:446 > #4 0xc04968bc in db_command (last_cmdp=0xc0c97514, cmd_table=0x0, dopager=1) > at /usr/src/sys/ddb/db_command.c:413 > #5 0xc04969ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 > #6 0xc04981bd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:228 > #7 0xc080ec76 in kdb_trap (type=12, code=0, tf=0xe6945774) at /usr/src/sys/kern/subr_kdb.c:524 > #8 0xc0ad9e4f in trap_fatal (frame=0xe6945774, eva=3735929068) at /usr/src/sys/i386/i386/trap.c:930 > #9 0xc0ada790 in trap (frame=0xe6945774) at /usr/src/sys/i386/i386/trap.c:320 > #10 0xc0abeaab in calltrap () at /usr/src/sys/i386/i386/exception.s:159 > #11 0xc903328c in ipfw_chk (args=0xe6945acc) at /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2516 > #12 0xc90373f7 in ipfw_check_in (arg=0x0, m0=0xe6945bd0, ifp=0xc41f9000, dir=1, inp=0x0) > at /usr/src/sys/modules/ipfw/../../netinet/ip_fw_pfil.c:125 > #13 0xc088d6e8 in pfil_run_hooks (ph=0xc0d1f620, mp=0xe6945c24, ifp=0xc41f9000, dir=1, inp=0x0) > at /usr/src/sys/net/pfil.c:78 > #14 0xc08c766d in ip_input (m=0xc409ad00) at /usr/src/sys/netinet/ip_input.c:416 > #15 0xc9011c39 in ng_ipfw_rcvdata (hook=0xc61a1780, item=0xc8fe5090) > at /usr/src/sys/modules/netgraph/ipfw/../../../netgraph/ng_ipfw.c:250 > #16 0xc68b80af in ng_apply_item (node=0xc7054c00, item=0xc8fe5090, rw=0) > at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 > #17 0xc68b939f in ngthread (arg=0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3304 > #18 0xc07be4c8 in fork_exit (callout=0xc68b91f0 , arg=0x0, frame=0xe6945d38) > at /usr/src/sys/kern/kern_fork.c:810 > #19 0xc0abeb20 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 > (kgdb) frame 11 > #11 0xc903328c in ipfw_chk (args=0xe6945acc) at /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2516 > warning: Source file is more recent than executable. > > 2516 if (set_disable & (1 << f->set) ) > (kgdb) list > 2511 ipfw_insn *cmd; > 2512 uint32_t tablearg = 0; > 2513 int l, cmdlen, skip_or; /* skip rest of OR block */ > 2514 > 2515 again: > 2516 if (set_disable & (1 << f->set) ) > 2517 continue; > 2518 > 2519 skip_or = 0; > 2520 for (l = f->cmd_len, cmd = f->cmd ; l > 0 ; > (kgdb) p f > $1 = (struct ip_fw *) 0xdeadc0de > (kgdb) > > DUMMYNET does not have such problems as ip_dn_ruledel_ptr(rule) is called when > the rule is removed in reap_rules(). The first thought was to do the same here > i.e. to broadcast "remove the rule" message to netgraph nodes, but glancing > through the netgraph man I haven't figured out how it could be done if it is > possible at all. > > So the other solution is to have some counter that increases every time when > any rules are removed. When the packet is directed by ipfw to netgraph > subsystem, the current value of the counter is stored in mtag. When the packet > is coming back the current value of the counter is compared with one from the > mtag and if they differ the packet is dropped. > > Just to prove the concept I have modified ip_fw2.c for 7.2-STABLE accordingly > and it works for me. The patch is attached. It looks the problem has not drawn much attention :-). Anyway, another version of the patch is attached. This time almost all of the necessary modifications are done in ng_ipfw module. Only the small changes have been made in ip_fw module and I tried to make them in the same manner as it is done for dummynet. The main logic is the same as in the previous patch: have internal counter ng_ipfw_rdcnt that is increased every time when some rule is deleted from the chain and compare it with one stored in ng_ipfw_tag when a packet passes ng_ipfw_rcvdata(). The patch is against 8-CURRENT but it is applied (and has been tested) to 7-STABLE too. Actually with this version of patch it looks like there is still small chance of race when ng_ipfw_rdcnt is going to be increased and in the same time the current value is stored in packet arrived to ng_ipfw. But running attached test script in loop I was not able to crash patched system while without the patch the system reliably crashes on the second run of the script. It would be nice to have this patch at least in CURRENT. Although I think that some generic mechanism should be developed in ipfw to validate rule pointers of second pass packets to have net.inet.ip.fw.one_pass=0 feature safe. AFAIK ipfw improvements is this year Summer of Code project so this problem could be addressed there. At least it should be documented in ipfw in BUGS section that the currrent implementation of net.inet.ip.fw.one_pass=0 could panic the system when is used with netgraph. -- Mikolaj Golub -------------- next part -------------- A non-text attachment was scrubbed... Name: ng_ipfw.patch Type: text/x-diff Size: 3268 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090601/706e9990/ng_ipfw.bin From bugmaster at FreeBSD.org Mon Jun 1 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 1 11:09:01 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200906011106.n51B6uKN021170@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/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 amd64/134788 net [bce] failure to set ip address in amd64 if_bce.c, i38 o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp 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 o kern/132984 net [netgraph] swi1: net 100% cpu usage 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/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/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 kern/121983 net [fxp] fxp0 MBUF and PAE 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/114839 net [fxp] fxp looses ability to speak with traffic 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 o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/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 307 problems total. From pjd at FreeBSD.org Mon Jun 1 11:08:53 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jun 1 11:11:31 2009 Subject: PF's divert-to and divert-reply functionality. Message-ID: <20090601105024.GC1542@garage.freebsd.pl> Hi there. I ported PF changes to make IP_BINDANY option usable on FreeBSD. I didn't port kernel changes from OpenBSD (except for extending this functionality for RAW IP sockets), because we had most of the code in place already used by ipfw forward code (IPFIREWALL_FORWARD option). I still had to implement it for UDP, because IPFIREWALL_FORWARD option changes address and port and I one to be able to find original destination when using IP_RECVDSTADDR in conjunction with recvmsg(2). The patch is here: http://people.freebsd.org/~pjd/patches/transparent_proxy.patch I'm looking for reviewers and testers. PS. IPv6 support is partially implemented (it isn't also for IPFIREWALL_FORWARD option). -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- 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/20090601/f24f6322/attachment.pgp From freebsd at bengrimm.net Mon Jun 1 14:50:04 2009 From: freebsd at bengrimm.net (DutchDaemon) Date: Mon Jun 1 14:50:10 2009 Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Message-ID: <200906011450.n51Eo3Wp095320@freefall.freebsd.org> The following reply was made to PR kern/134658; it has been noted by GNATS. From: DutchDaemon To: bug-followup@FreeBSD.org, harald_jensas@dell.com Cc: Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Date: Mon, 01 Jun 2009 16:21:59 +0200 http://forums.freebsd.org/showthread.php?t=3804 From l.ribet at vdm-publishing-house.com Mon Jun 1 22:28:30 2009 From: l.ribet at vdm-publishing-house.com (l.ribet@vdm-publishing-house.com) Date: Mon Jun 1 22:28:37 2009 Subject: Academic Publication Message-ID: <20251546.3482.1243892808444.JavaMail.root@contact> Dear Paul M Bielecki, I am writing on behalf of the German publishing house, VDM Verlag Dr. M?ller AG & Co. KG. In the course of a research at Ohio University, I came across a reference to your thesis on "Rethinking Baudrys Apparatus Theory In Light Of DVD Technology". As we would like to make your work available to a larger audience, I am wondering if you may be interested in publishing your thesis in the form of a printed book. Your reply including an e-mail address to which I can send an e-mail with further information in an attachment will be greatly appreciated. I am looking forward to hearing from you. Kind regards, Laurent Ribet Acquisition Editor VDM Publishing House Ltd. 17, Meldrum Str. | Beau-Bassin | Mauritius Tel / Fax: +230 467-5601 l.ribet@vdm-publishing-house.com | www.vdm-publishing.com Business Registration No.: C07072290 Board of Directors: Katalin Bontenakels, Benoit Novel In coorperation with: VDM Verlag Dr. M?ller AG & CoKG (www.vdm-verlag.de) LAP Lambert Academic Publishing AG & CoKG (www.lap-publishing.com) SVH S?dwestdeutscher Verlag f?r Hochschulschriften AG & CoKG (www.svh-verlag.de) From cmb at pfsense.org Tue Jun 2 03:37:52 2009 From: cmb at pfsense.org (Chris Buechler) Date: Tue Jun 2 03:38:24 2009 Subject: ath(4) randomly changes MTU to 2290 after explicitly set to 1500 Message-ID: <4A249A57.1070900@pfsense.org> In FreeBSD 7.1 using this patch: http://people.freebsd.org/~sam/ath_hal-releng7.patch and 7.2 with stock ath(4) (the above does not cleanly apply to 7.2), there are numerous pfsense users seeing problems with ath when bridging. This did not occur in 7.0. Upon investigation of a few systems, though we explicitly configure the interface with MTU 1500 twice (once when bringing up the ath interface, and again when setting up the bridge interface), somehow it ends up switching MTU to 2290 when we never configure it as such. This breaks bridging to an Ethernet interface because if_bridge requires the MTU to be the same on both interfaces. None of the commands we're running to setup ath or the bridge will replicate it, no matter what I do to the interface it stays to 1500 unless it sits there for a while ("a while" might be hours or days). There isn't anything that runs in the background to touch interfaces, a completely idle untouched box will change its configuration. It is setup fine and works initially, but given time, it'll switch to 2290 and stop working. example bridge setup commands: /sbin/ifconfig bridge0 destroy /sbin/ifconfig bridge0 create /sbin/ifconfig ath0 mtu 1500 /sbin/ifconfig vr1 mtu 1500 /sbin/ifconfig ath0 up /sbin/ifconfig vr1 up /sbin/ifconfig bridge0 addm ath0 addm vr1 up example ath setup commands: /sbin/ifconfig ath0 down /sbin/ifconfig ath0 mode '11g' /sbin/ifconfig ath0 channel any /sbin/ifconfig ath0 -mediaopt turbo /sbin/ifconfig ath0 ssid 'cmb' /sbin/ifconfig ath0 -hidessid /sbin/ifconfig ath0 -mediaopt adhoc /sbin/ifconfig ath0 protmode 'off' /sbin/ifconfig ath0 -pureg /sbin/ifconfig ath0 apbridge /sbin/ifconfig ath0 -wme /sbin/ifconfig ath0 authmode open wepmode off /sbin/ifconfig ath0 txpower '99' /sbin/ifconfig ath0 mediaopt hostap /sbin/ifconfig ath0 mtu 1500 /sbin/ifconfig ath0 up /usr/sbin/hostapd -B /var/etc/hostapd_ath0.conf $ dmesg|grep ath ath0: mem 0xe00c0000-0xe00cffff irq 9 at device 12.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:84:3d:7c ath0: mac 5.9 phy 4.3 radio 3.6 ath0: promiscuous mode enabled another that can replicate it is: ath0: mem 0x80000000-0x8000ffff irq 12 at device 13.0 on pci0 $ sysctl -a hw.ath hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 I have access to several systems that can replicate this, please let me know if any further information would be helpful. thanks, Chris From cmb at pfsense.org Tue Jun 2 04:58:17 2009 From: cmb at pfsense.org (Chris Buechler) Date: Tue Jun 2 04:58:24 2009 Subject: ath(4) randomly changes MTU to 2290 after explicitly set to 1500 In-Reply-To: <4A249A57.1070900@pfsense.org> References: <4A249A57.1070900@pfsense.org> Message-ID: <4A24B166.7020000@pfsense.org> Chris Buechler wrote: > In FreeBSD 7.1 using this patch: > http://people.freebsd.org/~sam/ath_hal-releng7.patch > > and 7.2 with stock ath(4) (the above does not cleanly apply to 7.2), > there are numerous pfsense users seeing problems with ath when > bridging. This did not occur in 7.0. Upon investigation of a few > systems, though we explicitly configure the interface with MTU 1500 > twice (once when bringing up the ath interface, and again when setting > up the bridge interface), somehow it ends up switching MTU to 2290 > when we never configure it as such. This breaks bridging to an > Ethernet interface because if_bridge requires the MTU to be the same > on both interfaces. > > None of the commands we're running to setup ath or the bridge will > replicate it, no matter what I do to the interface it stays to 1500 > unless it sits there for a while ("a while" might be hours or days). > There isn't anything that runs in the background to touch interfaces, > a completely idle untouched box will change its configuration. It is > setup fine and works initially, but given time, it'll switch to 2290 > and stop working. > > example bridge setup commands: > > /sbin/ifconfig bridge0 destroy > /sbin/ifconfig bridge0 create > /sbin/ifconfig ath0 mtu 1500 > /sbin/ifconfig vr1 mtu 1500 > /sbin/ifconfig ath0 up > /sbin/ifconfig vr1 up > /sbin/ifconfig bridge0 addm ath0 addm vr1 up > > example ath setup commands: > > /sbin/ifconfig ath0 down > /sbin/ifconfig ath0 mode '11g' > /sbin/ifconfig ath0 channel any > /sbin/ifconfig ath0 -mediaopt turbo > /sbin/ifconfig ath0 ssid 'cmb' > /sbin/ifconfig ath0 -hidessid > /sbin/ifconfig ath0 -mediaopt adhoc > /sbin/ifconfig ath0 protmode 'off' > /sbin/ifconfig ath0 -pureg > /sbin/ifconfig ath0 apbridge > /sbin/ifconfig ath0 -wme > /sbin/ifconfig ath0 authmode open wepmode off > /sbin/ifconfig ath0 txpower '99' > /sbin/ifconfig ath0 mediaopt hostap > /sbin/ifconfig ath0 mtu 1500 > /sbin/ifconfig ath0 up > /usr/sbin/hostapd -B /var/etc/hostapd_ath0.conf > > $ dmesg|grep ath > ath0: mem 0xe00c0000-0xe00cffff irq 9 at device 12.0 on > pci0 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:0b:6b:84:3d:7c > ath0: mac 5.9 phy 4.3 radio 3.6 > ath0: promiscuous mode enabled > > another that can replicate it is: > ath0: mem 0x80000000-0x8000ffff irq 12 at device 13.0 > on pci0 > > $ sysctl -a hw.ath > hw.ath.txbuf: 200 > hw.ath.rxbuf: 40 > hw.ath.regdomain: 0 > hw.ath.countrycode: 0 > hw.ath.xchanmode: 1 > hw.ath.outdoor: 1 > hw.ath.calibrate: 30 > hw.ath.hal.swba_backoff: 0 > hw.ath.hal.sw_brt: 10 > hw.ath.hal.dma_brt: 2 A little more related info on two additional boxes I now have access to with similar problems. In this case, every time hostapd is started it sets the MTU to 2290. I'm not sure if hostapd is the only thing causing difficulties, as these two behave differently from the others where initially MTU is 1500 and it changes on its own at some point. I see no mention of MTU in hostapd.conf(5). The hostapd.conf being used follows: interface=ath0 driver=bsd logger_syslog=-1 logger_syslog_level=0 logger_stdout=-1 logger_stdout_level=0 dump_file=/tmp/hostapd_ath0.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=fw2 debug= auth_algs=1 wpa=2 wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP wpa_group_rekey=60 wpa_gmk_rekey=3600 wpa_strict_rekey= wpa_passphrase=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ieee8021x= From oleg at FreeBSD.org Wed Jun 3 17:18:47 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Wed Jun 3 17:18:54 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 In-Reply-To: <81bpp8l6de.fsf@zhuzha.ua1> References: <864ov9htgq.fsf@kopusha.onet> <81bpp8l6de.fsf@zhuzha.ua1> Message-ID: <20090603170311.GA18104@lath.rinet.ru> On Mon, Jun 01, 2009 at 11:12:45AM +0300, Mikolaj Golub wrote: > It looks the problem has not drawn much attention :-). I was on vacation so did not reply in time. Dummynet like solution is not enough, dummynet is affected by this problem too. I'll send patch to you for testing tomorrow. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From pisymbol at gmail.com Wed Jun 3 22:21:55 2009 From: pisymbol at gmail.com (Alexander Sack) Date: Wed Jun 3 22:22:02 2009 Subject: bge(4) input errors and LINK_LOST condition problem Message-ID: <3c0b01820906031456h6db0e2e0w1becc6835c11c723@mail.gmail.com> Hello: I'm running FreeBSD-6.1-amd64 on an Intel motherboard with an Intel Core 2 processor (6400 I believe) with 8GB of RAM. I'm using bge(4) as a monitoring port listening to traffic from a GIGE switch. The traffic is a pcap replay and its running at 2% utilization through a switch. The card auto-negotiates to the right speed as shown below. The problem is the following: input (bge3) output packets errs bytes packets errs bytes colls 32800 0 6933920 0 0 0 0 32800 0 6933920 0 0 0 0 32560 0 6883184 0 0 0 0 32800 0 6933920 0 0 0 0 32503 2 6871316 0 0 0 0 32639 0 6899718 0 0 0 0 32960 0 6967744 0 0 0 0 32880 0 6950832 0 0 0 0 32720 0 6917008 0 0 0 0 32720 0 6917008 0 0 0 0 32720 0 6917008 0 0 0 0 32437 1 6857197 0 0 0 0 32550 0 6881070 0 0 0 0 32400 0 6849360 0 0 0 0 32760 1 6925081 0 0 0 0 32832 0 6940316 0 0 0 0 32467 0 6863408 0 0 0 0 32640 0 6900096 0 0 0 0 32480 0 6866272 0 0 0 0 32668 0 6905617 0 0 0 0 32828 0 6939889 0 0 0 0 I am seeing ifp->ierrors because these receive bd descriptors are marked with the LINK_LOST bit in the bd_error_flag after some instrumentation. # ifconfig bge3 bge3: flags=48943 mtu 9000 options=1b inet6 fe80::2e0:edff:fe11:90b3%bge3 prefixlen 64 scopeid 0x4 ether 00:e0:ed:11:90:b3 media: Ethernet autoselect (1000baseTX ) status: active # pciconf -l | grep bge3 bge3@pci8:6:1: class=0x020000 card=0x164814e4 chip=0x164814e4 rev=0x10 hdr=0x00 I took the stats stuff off of CURRENT and backported it to my 6.1 kernel and I see: # sysctl -a | grep bge.3 dev.bge.3.%desc: Broadcom BCM5704 B0, ASIC rev. 0x2100 dev.bge.3.%driver: bge dev.bge.3.%location: slot=6 function=1 dev.bge.3.%pnpinfo: vendor=0x14e4 device=0x1648 subvendor=0x14e4 subdevice=0x1648 class=0x020000 dev.bge.3.%parent: pci8 dev.bge.3.rx_coal_ticks: 150 dev.bge.3.tx_coal_ticks: 1000000 dev.bge.3.rx_max_coal_bds: 16 dev.bge.3.tx_max_coal_bds: 32 dev.bge.3.debug_info: -1 dev.bge.3.reg_read: -1172242433 dev.bge.3.mem_read: -1172242433 dev.bge.3.stat_IfHcInOctets: 1824848515 dev.bge.3.stat_IfHcOutOctets: 0 dev.bge.3.stats.FramesDroppedDueToFilters: 0 dev.bge.3.stats.DmaWriteQueueFull: 0 dev.bge.3.stats.DmaWriteHighPriQueueFull: 0 dev.bge.3.stats.NoMoreRxBDs: 0 dev.bge.3.stats.InputDiscards: 0 dev.bge.3.stats.InputErrors: 3 dev.bge.3.stats.RecvThresholdHit: 1501751 dev.bge.3.stats.DmaReadQueueFull: 0 dev.bge.3.stats.DmaReadHighPriQueueFull: 0 dev.bge.3.stats.SendDataCompQueueFull: 0 dev.bge.3.stats.RingSetSendProdIndex: 0 dev.bge.3.stats.RingStatusUpdate: 1502233 dev.bge.3.stats.Interrupts: 544091 dev.bge.3.stats.AvoidedInterrupts: 958142 dev.bge.3.stats.SendThresholdHit: 0 dev.bge.3.stats.rx.Octets: 1825744579 dev.bge.3.stats.rx.Fragments: 0 dev.bge.3.stats.rx.UcastPkts: 8476045 dev.bge.3.stats.rx.MulticastPkts: 0 dev.bge.3.stats.rx.FCSErrors: 3 dev.bge.3.stats.rx.AlignmentErrors: 0 dev.bge.3.stats.rx.xonPauseFramesReceived: 0 dev.bge.3.stats.rx.xoffPauseFramesReceived: 0 dev.bge.3.stats.rx.ControlFramesReceived: 0 dev.bge.3.stats.rx.xoffStateEntered: 0 dev.bge.3.stats.rx.FramesTooLong: 0 dev.bge.3.stats.rx.Jabbers: 0 dev.bge.3.stats.rx.UndersizePkts: 0 dev.bge.3.stats.rx.inRangeLengthError: 0 dev.bge.3.stats.rx.outRangeLengthError: 0 dev.bge.3.stats.tx.Octets: 0 dev.bge.3.stats.tx.Collisions: 0 dev.bge.3.stats.tx.XonSent: 0 dev.bge.3.stats.tx.XoffSent: 0 dev.bge.3.stats.tx.flowControlDone: 0 dev.bge.3.stats.tx.InternalMacTransmitErrors: 0 dev.bge.3.stats.tx.SingleCollisionFrames: 0 dev.bge.3.stats.tx.MultipleCollisionFrames: 0 dev.bge.3.stats.tx.DeferredTransmissions: 0 dev.bge.3.stats.tx.ExcessiveCollisions: 0 dev.bge.3.stats.tx.LateCollisions: 0 dev.bge.3.stats.tx.UcastPkts: 0 dev.bge.3.stats.tx.MulticastPkts: 0 dev.bge.3.stats.tx.BroadcastPkts: 0 dev.bge.3.stats.tx.CarrierSenseErrors: 0 dev.bge.3.stats.tx.Discards: 0 dev.bge.3.stats.tx.Errors: 0 A colleague mentioned that because I am using bge(4) as a monitoring card it is passively listening and unable to send back a Ethernet clock resync if the GIGE frame clock gets out of sync which could cause micro drops during the window in which the clocks are trying to get back on track. I can believe that though I feel that after trying multiple switches I find this very odd. Do other folks who use bge(4) see this same behavior? I noticed that my FCSErrors == InputERrors which makes sense since I had 3 packets with FCS errors (CRC32 check fail I believe). Yet my input errors via LINK_LOST are constant, tiny, and random. What's more interesting is I don't even see a drop. If I record and dump the pcap, the traffic looks fine to me through Wireshark (I am going to look again but I don't see sequence out of order or lost messages anyway, its very simple TCP/IP traffic). Are these frames retried auto-magically? If so, then aren't LINK_LOST errors potentially not real drops in the monitoring case and should not be reported as such? Can someone please define causes of the LINK_LOST condition (bd_error_flag = 0x4)? Thanks! -aps From delphij at FreeBSD.org Wed Jun 3 22:38:16 2009 From: delphij at FreeBSD.org (delphij@FreeBSD.org) Date: Wed Jun 3 22:38:22 2009 Subject: amd64/134788: [bce] failure to set ip address in amd64 if_bce.c, i386 seems OK Message-ID: <200906032238.n53McFuV038138@freefall.freebsd.org> Synopsis: [bce] failure to set ip address in amd64 if_bce.c, i386 seems OK State-Changed-From-To: open->feedback State-Changed-By: delphij State-Changed-When: Wed Jun 3 22:35:55 UTC 2009 State-Changed-Why: Dear submitter, David has committed a fix 1 day ago which should fixed this issue. Could you please give it a test? (7-STABLE). If you can't use 7-STABLE, please obtain the patch here: http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/mii/brgphy.c?r1=181897&r2=193358&view=patch Please let us know if this has solved your problem, thanks! Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Wed Jun 3 22:35:55 UTC 2009 Responsible-Changed-Why: Take so I can receive feedbacks. http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 From auryn at zirakzigil.org Thu Jun 4 08:44:06 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Thu Jun 4 08:44:13 2009 Subject: NAT-T on current 8 In-Reply-To: <20090531134541.H3234@maildrop.int.zabbadoz.net> References: <4A205679.5030406@zirakzigil.org> <20090531134541.H3234@maildrop.int.zabbadoz.net> Message-ID: <4A278950.8010802@zirakzigil.org> Bjoern A. Zeeb wrote: >> >> The NATT patch is slated to hit the FreeBSD tree soon so please do >> report back your findings. > > Yes, in case you find any positiv or negative things we'd be happy to > hear back from you - or anyone else who's going to give it a try. > Sorry for late feedback, very little time on my hands... I've tried to interoperate with an old version of ipsec-tools (0.6.7) and it takes a long time to start working, but it does in the end. I didn't have much time to try anything more in-depth, but I'll keep you posted. Thanks again. From vanhu at FreeBSD.org Thu Jun 4 09:29:09 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Thu Jun 4 09:29:16 2009 Subject: NAT-T on current 8 In-Reply-To: <4A278950.8010802@zirakzigil.org> References: <4A205679.5030406@zirakzigil.org> <20090531134541.H3234@maildrop.int.zabbadoz.net> <4A278950.8010802@zirakzigil.org> Message-ID: <20090604093204.GA94385@zeninc.net> On Thu, Jun 04, 2009 at 10:44:00AM +0200, Giulio Ferro wrote: [....] > Sorry for late feedback, very little time on my hands... Hi. > I've tried to interoperate with an old version of ipsec-tools (0.6.7) > and it takes a long time to start working, but it does in the end. > I didn't have much time to try anything more in-depth, but I'll keep > you posted. Do you mean "with an ipsec-tools 0.6.7 as the peer" ? It should work, as changes are only in the kernel/userland interface, and as (AFAIR) no changes have been done in the way NAT-T is negociated with the peer between ipsec-tools 0.6 and 0.7. Could you please give us more informations about that ? And what do you mean by "it takes some time to start working" ??? Thanks, Yvan. From oleg at FreeBSD.org Thu Jun 4 20:47:23 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Thu Jun 4 20:47:30 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 In-Reply-To: <20090603170311.GA18104@lath.rinet.ru> References: <864ov9htgq.fsf@kopusha.onet> <81bpp8l6de.fsf@zhuzha.ua1> <20090603170311.GA18104@lath.rinet.ru> Message-ID: <20090604204720.GA49677@lath.rinet.ru> On Wed, Jun 03, 2009 at 09:03:11PM +0400, Oleg Bulyzhin wrote: > On Mon, Jun 01, 2009 at 11:12:45AM +0300, Mikolaj Golub wrote: > > > It looks the problem has not drawn much attention :-). > > I was on vacation so did not reply in time. > Dummynet like solution is not enough, dummynet is affected by this problem > too. > I'll send patch to you for testing tomorrow. Please test attached patch and let me know results. Patch made for -current and it changes ABI, so rebuilding ipfw with new headers required. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ -------------- next part -------------- A non-text attachment was scrubbed... Name: one_pass.diff Type: text/x-diff Size: 13980 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090604/4eab83ac/one_pass.bin From jmallet at freebsd.org Fri Jun 5 00:14:06 2009 From: jmallet at freebsd.org (Juli Mallett) Date: Fri Jun 5 00:14:12 2009 Subject: bge(4) ASF problem report... Message-ID: Hey there, On my HP DL360 G4 with bge interfaces identified as "NC7782 Gigabit Server Adapter, ASIC rev. 0x2100", I find that having ASF enabled results in a total system freeze. Is anyone else running this hardware on either 7.x or 8-CURRENT? If so, I'd love to hear whether hw.bge.allow_asf=1 (the default on 8-CURRENT) is problematic for you and whether setting it to 0 instead fixes it. I'd like to disallow ASF by device ID if this reliably affects this hardware, but this is the only DL360 G4 I've got. Any objections? Or is there anyone who cares about bge who would be interested in trying to figure out what the actual problem is? Note that I haven't tried enabling the iLO shared network port stuff, so I don't know if that would have any unfortunate interactions with ASF support or lack thereof. Thanks, Juli. From barney_cordoba at yahoo.com Fri Jun 5 11:27:05 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri Jun 5 11:28:33 2009 Subject: panic in sbflush Message-ID: <11451.10207.qm@web63902.mail.re1.yahoo.com> I'm getting a panic in sbflush where mbcnt is 0 and sb_mb is not empty. Any clues as to what might cause this? It happening during a load test. Barney From edwin at freebsd.org Fri Jun 5 13:02:48 2009 From: edwin at freebsd.org (Edwin Groothuis) Date: Fri Jun 5 13:02:55 2009 Subject: NTP - default /etc/ntp.conf Message-ID: <20090605124428.GA85576@mavetju.org> After pondering at conf/58595, I came with this text. The ntpd is not enabled by default, so the fact that the servers are commented out should not be an issue. Any objections against adding it to the tree? Index: etc/ntp.conf =================================================================== --- etc/ntp.conf (revision 0) +++ etc/ntp.conf (revision 0) @@ -0,0 +1,28 @@ +# +# $FreeBSD$ +# +# Default NTP servers for the FreeBSD operating system. +# +# Don't forget to enable ntpd in /etc/rc.conf with: +# ntpd_enable="YES" +# + +driftfile /var/db/ntpd.drift + +# +# Uncomment the following three lines to sync against three "local" +# public NTP servers. +# +# server pool.ntp.org +# server pool.ntp.org +# server pool.ntp.org + +# +# If you want to pick yourself which country's public NTP server +# you want sync against, comment out the above servers, uncomment +# the next ones and replace CC with the country's abbrevation. +# +# server CC.pool.ntp.org +# server CC.pool.ntp.org +# server CC.pool.ntp.org +# Index: etc/Makefile =================================================================== --- etc/Makefile (revision 193485) +++ etc/Makefile (working copy) @@ -14,7 +14,7 @@ hosts hosts.allow hosts.equiv \ inetd.conf libalias.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ - phones profile protocols \ + ntpd.conf phones profile protocols \ rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless \ rc.sendmail rc.shutdown \ rc.subr remote rpc services shells \ -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From roberto at keltia.freenix.fr Fri Jun 5 13:47:35 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Fri Jun 5 13:47:42 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090605124428.GA85576@mavetju.org> References: <20090605124428.GA85576@mavetju.org> Message-ID: <20090605134727.GA480@roberto-al.eurocontrol.fr> According to Edwin Groothuis: > After pondering at conf/58595, I came with this text. > > The ntpd is not enabled by default, so the fact that the servers > are commented out should not be an issue. > > Any objections against adding it to the tree? None from me. Go for it thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From scf at FreeBSD.org Fri Jun 5 13:52:07 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Jun 5 13:52:15 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090605124428.GA85576@mavetju.org> References: <20090605124428.GA85576@mavetju.org> Message-ID: On Fri, 5 Jun 2009, Edwin Groothuis wrote: > After pondering at conf/58595, I came with this text. > > The ntpd is not enabled by default, so the fact that the servers > are commented out should not be an issue. > > Any objections against adding it to the tree? I like it. I would also add restrict lines to it since ntp defaults to being open to all packets. These would ignore everything except the pools (restricted) and localhost (open): restrict default ignore restrict pool.ntp.org nomodify nopeer noquery notrap restrict pool.ntp.org nomodify nopeer noquery notrap restrict 127.0.0.1 restrict -6 ::1 > Index: etc/ntp.conf > =================================================================== > --- etc/ntp.conf (revision 0) > +++ etc/ntp.conf (revision 0) > @@ -0,0 +1,28 @@ > +# > +# $FreeBSD$ > +# > +# Default NTP servers for the FreeBSD operating system. > +# > +# Don't forget to enable ntpd in /etc/rc.conf with: > +# ntpd_enable="YES" > +# > + > +driftfile /var/db/ntpd.drift > + > +# > +# Uncomment the following three lines to sync against three "local" > +# public NTP servers. > +# > +# server pool.ntp.org > +# server pool.ntp.org > +# server pool.ntp.org > + > +# > +# If you want to pick yourself which country's public NTP server > +# you want sync against, comment out the above servers, uncomment > +# the next ones and replace CC with the country's abbrevation. > +# > +# server CC.pool.ntp.org > +# server CC.pool.ntp.org > +# server CC.pool.ntp.org > +# > Index: etc/Makefile > =================================================================== > --- etc/Makefile (revision 193485) > +++ etc/Makefile (working copy) > @@ -14,7 +14,7 @@ > hosts hosts.allow hosts.equiv \ > inetd.conf libalias.conf login.access login.conf mac.conf motd \ > netconfig network.subr networks newsyslog.conf nsswitch.conf \ > - phones profile protocols \ > + ntpd.conf phones profile protocols \ ntpd.conf or ntp.conf? Sean -- scf@FreeBSD.org From to.my.trociny at gmail.com Fri Jun 5 13:58:09 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Fri Jun 5 13:58:15 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 In-Reply-To: <20090604204720.GA49677@lath.rinet.ru> (Oleg Bulyzhin's message of "Fri\, 5 Jun 2009 00\:47\:20 +0400") References: <864ov9htgq.fsf@kopusha.onet> <81bpp8l6de.fsf@zhuzha.ua1> <20090603170311.GA18104@lath.rinet.ru> <20090604204720.GA49677@lath.rinet.ru> Message-ID: <81hbyuvl3z.fsf@zhuzha.ua1> On Fri, 5 Jun 2009 00:47:20 +0400 Oleg Bulyzhin wrote: > On Wed, Jun 03, 2009 at 09:03:11PM +0400, Oleg Bulyzhin wrote: >> On Mon, Jun 01, 2009 at 11:12:45AM +0300, Mikolaj Golub wrote: >> >> > It looks the problem has not drawn much attention :-). >> >> I was on vacation so did not reply in time. >> Dummynet like solution is not enough, dummynet is affected by this problem >> too. >> I'll send patch to you for testing tomorrow. > > Please test attached patch and let me know results. > Patch made for -current and it changes ABI, so rebuilding ipfw with new > headers required. It works for me. With the patch I has not managed to crash the system using my test. Some notes: - only ng_ipfw/ng_car subsystem has been tested (not dummynet). - my -current box is under qemu (I don't have real server running -current to test this). If you are interesting in some testing of dummynet before commiting this to current, let me know. I could try some tests but only the next week. If you are going to commit this to -current could you please fix ng_ipfw(4) man page too? Index: share/man/man4/ng_ipfw.4 =================================================================== --- share/man/man4/ng_ipfw.4 (revision 193478) +++ share/man/man4/ng_ipfw.4 (working copy) @@ -84,11 +84,12 @@ struct ng_ipfw_tag { struct m_tag mt; /* tag header */ struct ip_fw *rule; /* matching rule */ + uint32_t rule_id; /* matching rule id */ + uint32_t chain_id; /* ruleset id */ struct ifnet *ifp; /* interface, for ip_output */ int dir; /* packet direction */ #define NG_IPFW_OUT 0 #define NG_IPFW_IN 1 - int flags; /* flags, for ip_output() */ }; .Ed .Pp -- Mikolaj Golub From roberto at keltia.freenix.fr Fri Jun 5 14:06:12 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Fri Jun 5 14:06:18 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: References: <20090605124428.GA85576@mavetju.org> Message-ID: <20090605140604.GA693@roberto-al.eurocontrol.fr> According to Sean C. Farley: > I would also add restrict lines to it since ntp defaults to being open > to all packets. Now that I think of it, please add also the following lines, which helps when losing the sync on the remote servers. server 127.127.1.0 fudge 127.127.1.0 stratum 10 That adds a local clock as a fallback. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From frank at ilse.behrens.de Fri Jun 5 14:24:28 2009 From: frank at ilse.behrens.de (Frank Behrens) Date: Fri Jun 5 14:24:34 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090605124428.GA85576@mavetju.org> Message-ID: <200906051424.n55EOIrM012619@post.behrens.de> Edwin Groothuis wrote on 5 Jun 2009 22:44: > After pondering at conf/58595, I came with this text. > > The ntpd is not enabled by default, so the fact that the servers > are commented out should not be an issue. >... > +# server pool.ntp.org > +# server pool.ntp.org > +# server pool.ntp.org Isn't it better to use different entries? server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org To be sure that the IP addresses are different. See http://www.pool.ntp.org/en/use.html -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From valentin.bud at gmail.com Fri Jun 5 14:27:29 2009 From: valentin.bud at gmail.com (Valentin Bud) Date: Fri Jun 5 14:27:35 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: References: <20090605124428.GA85576@mavetju.org> Message-ID: <139b44430906050656pe72d107mfa23561f8f706461@mail.gmail.com> On Fri, Jun 5, 2009 at 4:52 PM, Sean C. Farley wrote: > On Fri, 5 Jun 2009, Edwin Groothuis wrote: > > After pondering at conf/58595, I came with this text. >> >> The ntpd is not enabled by default, so the fact that the servers >> are commented out should not be an issue. >> >> Any objections against adding it to the tree? >> > > I like it. > > I would also add restrict lines to it since ntp defaults to being open to > all packets. > > These would ignore everything except the pools (restricted) and localhost > (open): > restrict default ignore > restrict pool.ntp.org nomodify nopeer noquery notrap > restrict pool.ntp.org nomodify nopeer noquery notrap > restrict 127.0.0.1 > restrict -6 ::1 > > > Index: etc/ntp.conf >> =================================================================== >> --- etc/ntp.conf (revision 0) >> +++ etc/ntp.conf (revision 0) >> @@ -0,0 +1,28 @@ >> +# >> +# $FreeBSD$ >> +# >> +# Default NTP servers for the FreeBSD operating system. >> +# >> +# Don't forget to enable ntpd in /etc/rc.conf with: >> +# ntpd_enable="YES" >> +# >> + >> +driftfile /var/db/ntpd.drift >> + >> +# >> +# Uncomment the following three lines to sync against three "local" >> +# public NTP servers. >> +# >> +# server pool.ntp.org >> +# server pool.ntp.org >> +# server pool.ntp.org >> + >> +# >> +# If you want to pick yourself which country's public NTP server >> +# you want sync against, comment out the above servers, uncomment >> +# the next ones and replace CC with the country's abbrevation. >> +# >> +# server CC.pool.ntp.org >> +# server CC.pool.ntp.org >> +# server CC.pool.ntp.org >> +# >> Index: etc/Makefile >> =================================================================== >> --- etc/Makefile (revision 193485) >> +++ etc/Makefile (working copy) >> @@ -14,7 +14,7 @@ >> hosts hosts.allow hosts.equiv \ >> inetd.conf libalias.conf login.access login.conf mac.conf motd \ >> netconfig network.subr networks newsyslog.conf nsswitch.conf \ >> - phones profile protocols \ >> + ntpd.conf phones profile protocols \ >> > > ntpd.conf or ntp.conf? I guess it's a typo and should be ntp.conf. > > > Sean > -- > scf@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" > That's a very good idea. It provides a starting point for new users of ntpd. my 7c, v -- network warrior since 2005 From brde at optusnet.com.au Fri Jun 5 18:18:09 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Jun 5 18:18:17 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: References: <20090605124428.GA85576@mavetju.org> Message-ID: <20090606015013.Q15911@delplex.bde.org> On Fri, 5 Jun 2009, Sean C. Farley wrote: > On Fri, 5 Jun 2009, Edwin Groothuis wrote: > >> Index: etc/ntp.conf >> =================================================================== >> --- etc/ntp.conf (revision 0) >> +++ etc/ntp.conf (revision 0) >> @@ -0,0 +1,28 @@ >> +# >> +# $FreeBSD$ >> +# >> +# Default NTP servers for the FreeBSD operating system. >> +# >> +# Don't forget to enable ntpd in /etc/rc.conf with: >> +# ntpd_enable="YES" >> +# >> + >> +driftfile /var/db/ntpd.drift ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Index: etc/Makefile >> =================================================================== >> --- etc/Makefile (revision 193485) >> +++ etc/Makefile (working copy) >> @@ -14,7 +14,7 @@ >> hosts hosts.allow hosts.equiv \ >> inetd.conf libalias.conf login.access login.conf mac.conf motd \ >> netconfig network.subr networks newsyslog.conf nsswitch.conf \ >> - phones profile protocols \ >> + ntpd.conf phones profile protocols \ > > ntpd.conf or ntp.conf? Similarly, the drift file is named ntp.drift except in poorly configured FreeBSD installations. ntp sources in contrib have 80 lines matching ntp\.drift and 2 lines matching ntpd.drift. FreeBSD should only change the directory containing the drift file from /etc to /var/db or /var/db/ntp, not the file name. Bruce From oleg at FreeBSD.org Fri Jun 5 18:56:49 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Fri Jun 5 18:56:55 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 In-Reply-To: <81hbyuvl3z.fsf@zhuzha.ua1> References: <864ov9htgq.fsf@kopusha.onet> <81bpp8l6de.fsf@zhuzha.ua1> <20090603170311.GA18104@lath.rinet.ru> <20090604204720.GA49677@lath.rinet.ru> <81hbyuvl3z.fsf@zhuzha.ua1> Message-ID: <20090605185647.GA76962@lath.rinet.ru> On Fri, Jun 05, 2009 at 04:57:52PM +0300, Mikolaj Golub wrote: > It works for me. With the patch I has not managed to crash the system using my > test. Some notes: > > - only ng_ipfw/ng_car subsystem has been tested (not dummynet). > - my -current box is under qemu (I don't have real server running -current to > test this). > > If you are interesting in some testing of dummynet before commiting this to > current, let me know. I could try some tests but only the next week. I did some testing of dummynet though extra testing would not hurt. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From 000.fbsd at quip.cz Fri Jun 5 19:19:03 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Jun 5 19:19:09 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090606015013.Q15911@delplex.bde.org> References: <20090605124428.GA85576@mavetju.org> <20090606015013.Q15911@delplex.bde.org> Message-ID: <4A296FA0.2050601@quip.cz> Bruce Evans wrote: > On Fri, 5 Jun 2009, Sean C. Farley wrote: > >> On Fri, 5 Jun 2009, Edwin Groothuis wrote: >> >>> Index: etc/ntp.conf >>> =================================================================== >>> --- etc/ntp.conf (revision 0) >>> +++ etc/ntp.conf (revision 0) >>> @@ -0,0 +1,28 @@ >>> +# >>> +# $FreeBSD$ >>> +# >>> +# Default NTP servers for the FreeBSD operating system. >>> +# >>> +# Don't forget to enable ntpd in /etc/rc.conf with: >>> +# ntpd_enable="YES" >>> +# >>> + >>> +driftfile /var/db/ntpd.drift > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> Index: etc/Makefile >>> =================================================================== >>> --- etc/Makefile (revision 193485) >>> +++ etc/Makefile (working copy) >>> @@ -14,7 +14,7 @@ >>> hosts hosts.allow hosts.equiv \ >>> inetd.conf libalias.conf login.access login.conf mac.conf motd \ >>> netconfig network.subr networks newsyslog.conf nsswitch.conf \ >>> - phones profile protocols \ >>> + ntpd.conf phones profile protocols \ >> >> >> ntpd.conf or ntp.conf? > > > Similarly, the drift file is named ntp.drift except in poorly configured > FreeBSD installations. ntp sources in contrib have 80 lines matching > ntp\.drift and 2 lines matching ntpd.drift. FreeBSD should only change > the directory containing the drift file from /etc to /var/db or > /var/db/ntp, > not the file name. Also note that /var/db/ntpd.drift is specified as flags in defaults/rc.conf (I don't know if it is good or bad thing :]) # grep drift /etc/defaults/rc.conf ntpd_flags="-p /var/run/ntpd.pid -f /var/db/ntpd.drift" Miroslav Lachman From dougb at FreeBSD.org Fri Jun 5 20:39:59 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 5 20:40:05 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <200906051424.n55EOIrM012619@post.behrens.de> References: <200906051424.n55EOIrM012619@post.behrens.de> Message-ID: <4A297BB4.80002@FreeBSD.org> Frank Behrens wrote: > Edwin Groothuis wrote on 5 Jun 2009 22:44: >> After pondering at conf/58595, I came with this text. >> >> The ntpd is not enabled by default, so the fact that the servers >> are commented out should not be an issue. >> ... >> +# server pool.ntp.org >> +# server pool.ntp.org >> +# server pool.ntp.org > > Isn't it better to use different entries? > server 0.pool.ntp.org > server 1.pool.ntp.org > server 2.pool.ntp.org > > To be sure that the IP addresses are different. > See > http://www.pool.ntp.org/en/use.html I agree with this suggestion, as well as the others about adding the default restrictions and the fallback local clock. Bruce is right about the ntp.drift file name, however we already have existing stuff that mentions ntpd.drift, and since it's specified on the command line in rc.conf the problems of what it says in the code are bypassed. OTOH, we should use ntp.conf (no d) since that is what is referenced in the man page for ntpd, and the man page for the conf file is ntp.conf. (It's currently wrong in the Makefile in your patch.) One more thing, it was said some time ago that due to a quirk in how ntpd works on our system that adding the following to the server line makes it work more efficiently: server foo iburst maxpoll 9 If someone smarter than me could confirm that it would be great. :) hth, Doug -- This .signature sanitized for your protection From edwin at mavetju.org Fri Jun 5 23:44:22 2009 From: edwin at mavetju.org (Edwin Groothuis) Date: Fri Jun 5 23:44:29 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: References: <20090605124428.GA85576@mavetju.org> Message-ID: <20090605234242.GA3235@mavetju.org> First thanks to everybody who replied, I've read it all. The ntpd.conf in the etc/Makefile was a typo of me. On Fri, Jun 05, 2009 at 08:52:01AM -0500, Sean C. Farley wrote: > On Fri, 5 Jun 2009, Edwin Groothuis wrote: > > >After pondering at conf/58595, I came with this text. > > > >The ntpd is not enabled by default, so the fact that the servers > >are commented out should not be an issue. > > > >Any objections against adding it to the tree? > > I like it. > > I would also add restrict lines to it since ntp defaults to being open > to all packets. > > These would ignore everything except the pools (restricted) and > localhost (open): > restrict default ignore > restrict pool.ntp.org nomodify nopeer noquery notrap > restrict pool.ntp.org nomodify nopeer noquery notrap > restrict 127.0.0.1 > restrict -6 ::1 I'm a little bit worried about the functionality of this in combination with the round-robin DNS approach of pool.ntp.org: I have "server 0.pool.ntp.org" in my NTP configuration, which still only gives me one NTP server in its internals ("dig 0.pool.ntp.org" gives me five answers, "ntpq -p" gives me one server). Having the "server 0.pool.ntp.org" in my configuration twice will give it two NTP servers in its internals. So every hostname gives a different NTP server IP address. Now we end up at the restrictions, where it resolves 0.pool.ntp.org again to a different IP address than the previous two, making it not willing to accept any traffic from the earlier two hosts in the server statements. I don't know yet how to overcome this, except for not adding the restrict statements when using the pool.ntp.org servers :-/ Suggestions are welcome. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From edwin at mavetju.org Fri Jun 5 23:52:58 2009 From: edwin at mavetju.org (Edwin Groothuis) Date: Fri Jun 5 23:53:05 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <200906051424.n55EOIrM012619@post.behrens.de> References: <20090605124428.GA85576@mavetju.org> <200906051424.n55EOIrM012619@post.behrens.de> Message-ID: <20090605235117.GB3235@mavetju.org> Hello Frank, On Fri, Jun 05, 2009 at 04:24:18PM +0200, Frank Behrens wrote: > Edwin Groothuis wrote on 5 Jun 2009 22:44: > > After pondering at conf/58595, I came with this text. > > > > The ntpd is not enabled by default, so the fact that the servers > > are commented out should not be an issue. > >... > > +# server pool.ntp.org > > +# server pool.ntp.org > > +# server pool.ntp.org > > Isn't it better to use different entries? > server 0.pool.ntp.org > server 1.pool.ntp.org > server 2.pool.ntp.org > > To be sure that the IP addresses are different. > See > http://www.pool.ntp.org/en/use.html You are right, I was under the impression that 0, 1, 2 would give a single A record. I only checked for the geographical closeness of the pool.ntp.org results. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From randy at psg.com Sat Jun 6 02:01:57 2009 From: randy at psg.com (Randy Bush) Date: Sat Jun 6 02:02:04 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090605234242.GA3235@mavetju.org> References: <20090605124428.GA85576@mavetju.org> <20090605234242.GA3235@mavetju.org> Message-ID: > I have "server 0.pool.ntp.org" in my NTP configuration, which still > only gives me one NTP server in its internals ("dig 0.pool.ntp.org" > gives me five answers, "ntpq -p" gives me one server). Having the > "server 0.pool.ntp.org" in my configuration twice will give it two > NTP servers in its internals. So every hostname gives a different > NTP server IP address. i believe that you may relying on a behavior of a dns resolver which is not specified randy From edwin at mavetju.org Sat Jun 6 02:14:53 2009 From: edwin at mavetju.org (Edwin Groothuis) Date: Sat Jun 6 02:15:00 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: References: <20090605124428.GA85576@mavetju.org> <20090605234242.GA3235@mavetju.org> Message-ID: <20090606021451.GC3235@mavetju.org> On Sat, Jun 06, 2009 at 11:01:53AM +0900, Randy Bush wrote: > > I have "server 0.pool.ntp.org" in my NTP configuration, which still > > only gives me one NTP server in its internals ("dig 0.pool.ntp.org" > > gives me five answers, "ntpq -p" gives me one server). Having the > > "server 0.pool.ntp.org" in my configuration twice will give it two > > NTP servers in its internals. So every hostname gives a different > > NTP server IP address. > > i believe that you may relying on a behavior of a dns resolver which is > not specified While it might not be specified, it is being observed and therefore an issue when we want to restrict traffic specified by hostname. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From randy at psg.com Sat Jun 6 02:17:07 2009 From: randy at psg.com (Randy Bush) Date: Sat Jun 6 02:17:14 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090606021451.GC3235@mavetju.org> References: <20090605124428.GA85576@mavetju.org> <20090605234242.GA3235@mavetju.org> <20090606021451.GC3235@mavetju.org> Message-ID: >> i believe that you may relying on a behavior of a dns resolver which >> is not specified > While it might not be specified, it is being observed and therefore > an issue when we want to restrict traffic specified by hostname. i do not disagree. randy From joel at FreeBSD.org Sat Jun 6 06:25:30 2009 From: joel at FreeBSD.org (Joel Dahl) Date: Sat Jun 6 06:25:37 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <4A297BB4.80002@FreeBSD.org> References: <200906051424.n55EOIrM012619@post.behrens.de> <4A297BB4.80002@FreeBSD.org> Message-ID: <4A2A080C.1040402@FreeBSD.org> Doug Barton skrev: > Frank Behrens wrote: >> Edwin Groothuis wrote on 5 Jun 2009 22:44: >>> After pondering at conf/58595, I came with this text. >>> >>> The ntpd is not enabled by default, so the fact that the servers >>> are commented out should not be an issue. >>> ... >>> +# server pool.ntp.org >>> +# server pool.ntp.org >>> +# server pool.ntp.org >> Isn't it better to use different entries? >> server 0.pool.ntp.org >> server 1.pool.ntp.org >> server 2.pool.ntp.org >> >> To be sure that the IP addresses are different. >> See >> http://www.pool.ntp.org/en/use.html > > I agree with this suggestion, as well as the others about adding the > default restrictions and the fallback local clock. Bruce is right > about the ntp.drift file name, however we already have existing stuff > that mentions ntpd.drift, and since it's specified on the command line > in rc.conf the problems of what it says in the code are bypassed. > > OTOH, we should use ntp.conf (no d) since that is what is referenced > in the man page for ntpd, and the man page for the conf file is > ntp.conf. (It's currently wrong in the Makefile in your patch.) > > One more thing, it was said some time ago that due to a quirk in how > ntpd works on our system that adding the following to the server line > makes it work more efficiently: > > server foo iburst maxpoll 9 I've read the same somewhere and I've been using "iburst maxpoll 9" for a long time. If this is correct, I think it should go into the default ntp.conf. -- Joel From rwatson at FreeBSD.org Sat Jun 6 07:25:12 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Jun 6 07:25:18 2009 Subject: panic in sbflush In-Reply-To: <11451.10207.qm@web63902.mail.re1.yahoo.com> References: <11451.10207.qm@web63902.mail.re1.yahoo.com> Message-ID: On Fri, 5 Jun 2009, Barney Cordoba wrote: > I'm getting a panic in sbflush where mbcnt is 0 and sb_mb is not empty. Any > clues as to what might cause this? It happening during a load test. sbflush() panics are typically symptoms of bugs elsewhere in the network stack or kernel, often race conditions. In essence, sbflush() is called when a socket is closed and packets have to be drained from the receive socket buffer. During that draining, we sanity check that the cached length of the data in the socket buffer (sb_cc) matches the actual length of data in the buffer. If sb_cc, sb_mb, or sb_mbcnt is non-zero at the end of the function, we panic. Most of the time, it's a driver race condition where an mbuf has been injected into the stack using ifp->if_input(), but the driver has then modified the mbuf after injection (perhaps by setting a length, clearing a pointer, etc). We had a spate of them after we moved to direct dispatch because the timing changed, leading to packets being processed before the return of if_input() rather than "some time later". Once in a while it's a bug in TCP or socket buffer handling, or in some intermediate encapsulation/decapsulation layer along similar lines to the driver race scenario. I think the most recent case I'm aware of was actually a socket buffer bug, but that's fairly unusual in the history of reports of this panic. There is a kernel debugging option to perform run-time sanity checking of the sockbuf structure so that the corruption is found earlier, called "options SOCKBUF_DEBUG". My experience is that it's good for finding deterministic socket buffer corruption bugs, but that it changes the timing significantly so tends to mask narrow race conditions involving "inject the packet and then change it". Hope that helps, Robert N M Watson Computer Laboratory University of Cambridge From brde at optusnet.com.au Sat Jun 6 07:46:40 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Jun 6 07:46:47 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <4A296FA0.2050601@quip.cz> References: <20090605124428.GA85576@mavetju.org> <20090606015013.Q15911@delplex.bde.org> <4A296FA0.2050601@quip.cz> Message-ID: <20090606174545.A16690@delplex.bde.org> On Fri, 5 Jun 2009, Miroslav Lachman wrote: > Bruce Evans wrote: >> Similarly, the drift file is named ntp.drift except in poorly configured >> FreeBSD installations. ntp sources in contrib have 80 lines matching > > Also note that /var/db/ntpd.drift is specified as flags in defaults/rc.conf > (I don't know if it is good or bad thing :]) That is the cause of many poorly configured FreeBSD installations :-). Bruce From brde at optusnet.com.au Sat Jun 6 08:25:21 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Jun 6 08:25:28 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <4A297BB4.80002@FreeBSD.org> References: <200906051424.n55EOIrM012619@post.behrens.de> <4A297BB4.80002@FreeBSD.org> Message-ID: <20090606174642.I16690@delplex.bde.org> On Fri, 5 Jun 2009, Doug Barton wrote: > Frank Behrens wrote: >> Edwin Groothuis wrote on 5 Jun 2009 22:44: >>> After pondering at conf/58595, I came with this text. >>> >>> The ntpd is not enabled by default, so the fact that the servers >>> are commented out should not be an issue. >>> ... >>> +# server pool.ntp.org >>> +# server pool.ntp.org >>> +# server pool.ntp.org >> >> Isn't it better to use different entries? >> server 0.pool.ntp.org >> server 1.pool.ntp.org >> server 2.pool.ntp.org >> >> To be sure that the IP addresses are different. >> See >> http://www.pool.ntp.org/en/use.html > > I agree with this suggestion, as well as the others about adding the > default restrictions and the fallback local clock. I use 1 hard-coded server (= a local server for all machines except 1) (plus fallback to the local clock for all machines) and have never had any problems using only 1 (except if the server is not up at boot time then ntpdate (which is configured separately anyway) fails and ntpd -x takes too long to sync so I sync manually. too long:= more than 30 seconds, and I use -x since any slew except ones done at boot time by ntpdate is considered an error, and I use ntpdate instead of ntpd -g[q] since ntpdate works perfectly while at least old versions of ntpd -q are very broken). > Bruce is right > about the ntp.drift file name, however we already have existing stuff > that mentions ntpd.drift, and since it's specified on the command line > in rc.conf the problems of what it says in the code are bypassed. This is a bug in rc.conf. The drift file name is also extensively documented to be ntp.drift (in /etc even) in ntpd's man page: from "man ntpd | col -bx": % -f driftfile % Specify the name and path of the frequency file, default ^^^^^^^ % /etc/ntp.drift. This is the same operation as the driftfile ^^^^ ^^^^^^^^^ % driftfile configuration command. No, the default is not in /etc and is not named ntp.drift (even if the above is ntpd's default when a driftfile is configured without specifying a pathname to it (is this possible?) this is confusing. % outside the acceptable range, ntpd enters the same state as when the % ntp.drift file is not present. The intent of this behavior is to quickly ^^^^^^^^^ No need for a pathname here. % Frequency Discipline % The ntpd behavior at startup depends on whether the frequency file, usu- % ally ntp.drift, exists. This file contains the latest estimate of clock ^^^^ ^^^^^^^^^ "usually" instead of "default" is fine. % FILES % /etc/ntp.conf the default name of the configuration file % /etc/ntp.drift the default name of the drift file ^^^ ^^^^^^^^^ ^^^ ^^^^^^^ As above. /var/db/ntpd.drift is not documented anywhere in $(find /usr/share/man) of course. > ... > One more thing, it was said some time ago that due to a quirk in how > ntpd works on our system that adding the following to the server line > makes it work more efficiently: > > server foo iburst maxpoll 9 > > If someone smarter than me could confirm that it would be great. :) I use iburst maxpoll 6 and used to use a different maxpoll and complicated settings when I had a dialup internet connection (was 120 ms ping latency; now 8; 0.150 ms to the local server). These settings probably don't matter with fast connections. Bruce From mzaki at e-mail.ne.jp Sat Jun 6 14:10:06 2009 From: mzaki at e-mail.ne.jp (Motomichi Matsuzaki) Date: Sat Jun 6 14:10:12 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200906061410.n56EA68v095050@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Motomichi Matsuzaki To: bug-followup@FreeBSD.org, mav@FreeBSD.org Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Sat, 06 Jun 2009 22:53:08 +0900 Here is the same problem. I'm using mpd 4.4.1, which is configured to keep PPPoE connection to ISP. Mpd is also configured as a PPTP server, and it has worked fine on 7.1R; no problems both on normal PPPoE operation and incoming PPTP connection. However, upgrading to 7.2R (by freebsd-update) has changed the situation. -- Motomichi Matsuzaki, PhD From bohdan200 at gmail.com Sat Jun 6 16:33:22 2009 From: bohdan200 at gmail.com (Bohdan Tymkiv) Date: Sat Jun 6 16:33:28 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <1244304456.16706.38.camel@void-desktop> I can confirm this issue. I have a FreeBSD 7.2-STABLE box with mpd 5.3 configured as PPPoE client that connects to my ISP. If I make any PPTP VPN connection that goes through this PPPoE link my server hangs. I made some investigations and found that deadlock occurs only when pptp connection goes via pppoe link, connection from local network works fine. Deadlock occurs exactly when first data packet is sent through pptp connection. mpd can be configured as server that listens on my external pppoe interface or it can be configured as client that connects to other server in internet. In both cases it hangs. -- Bohdan Tymkiv Home From bohdan200 at gmail.com Sat Jun 6 16:40:04 2009 From: bohdan200 at gmail.com (Bohdan Tymkiv) Date: Sat Jun 6 16:40:11 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200906061640.n56Ge3Ph013274@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Bohdan Tymkiv 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: Sat, 06 Jun 2009 19:01:14 +0300 I can confirm this issue. I have a FreeBSD 7.2-STABLE box with mpd 5.3 configured as PPPoE client that connects to my ISP. If I make any PPTP VPN connection that goes through this PPPoE link my server hangs. I made some investigations and found that deadlock occurs only when pptp connection goes via pppoe link, connection from local network works fine. Deadlock occurs exactly when first data packet is sent through pptp connection. mpd can be configured as server that listens on my external pppoe interface or it can be configured as client that connects to other server in internet. In both cases it hangs. -- Bohdan Tymkiv From edwin at mavetju.org Sun Jun 7 13:28:46 2009 From: edwin at mavetju.org (Edwin Groothuis) Date: Sun Jun 7 13:28:53 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <4A297BB4.80002@FreeBSD.org> References: <200906051424.n55EOIrM012619@post.behrens.de> <4A297BB4.80002@FreeBSD.org> Message-ID: <20090607132844.GA19694@mavetju.org> Please note that it just has been committed. Everybody thanks a lot for your input! Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From roberto at keltia.freenix.fr Mon Jun 8 09:27:57 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Mon Jun 8 09:28:05 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090606174642.I16690@delplex.bde.org> References: <200906051424.n55EOIrM012619@post.behrens.de> <4A297BB4.80002@FreeBSD.org> <20090606174642.I16690@delplex.bde.org> Message-ID: <20090608092730.GA1059@roberto-al.eurocontrol.fr> According to Bruce Evans: > /var/db/ntpd.drift is not documented anywhere in $(find /usr/share/man) > of course. Keep in mind that most of our manpages are reverse-engineered from the HTML files Dave Mills only wanted to support... I'll try to update to the latest version and see if the now bshipped in manpages are any better. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From bohdan200 at gmail.com Mon Jun 8 10:00:19 2009 From: bohdan200 at gmail.com (Bohdan Tymkiv) Date: Mon Jun 8 10:00:26 2009 Subject: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Message-ID: <200906081000.n58A0JPX064682@freefall.freebsd.org> The following reply was made to PR kern/133572; it has been noted by GNATS. From: Bohdan Tymkiv To: bug-followup@FreeBSD.org, dennis.melentyev@gmail.com Cc: Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Date: Mon, 08 Jun 2009 12:51:15 +0300 Dennis, maybe this issue is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=134557 can you confirm this? -- Bohdan Tymkiv From emz at norma.perm.ru Mon Jun 8 10:10:07 2009 From: emz at norma.perm.ru (Eugene M. Zheganin) Date: Mon Jun 8 10:10:14 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd3.5 hanging up - ng_pptp problem Message-ID: <200906081010.n58AA7iK071603@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org, sergei.cherveni@gmail.com Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd3.5 hanging up - ng_pptp problem Date: Mon, 08 Jun 2009 15:37:54 +0600 Exactly same here. mpd 5.3 on 7.2-RELEASE, PPPoE client to WAN, PPTP over it. When mpd is configured as PPPoE-only client, all works just fine. When I add a pptp server fuctionality (config is proven to work on previous versions), the system starts to hang after pptp session connects and then disconnects. -- Eugene M. Zheganin From bugmaster at FreeBSD.org Mon Jun 8 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 8 11:09:06 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200906081106.n58B6wJ5020737@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/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/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp 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 o kern/132984 net [netgraph] swi1: net 100% cpu usage 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/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/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 kern/121983 net [fxp] fxp0 MBUF and PAE 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/114839 net [fxp] fxp looses ability to speak with traffic 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 o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/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 306 problems total. From bz at FreeBSD.org Mon Jun 8 17:14:21 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Mon Jun 8 17:14:33 2009 Subject: kern/134583: [hang] Machine with jail freezes after random amount of time Message-ID: <200906081714.n58HEKfY006181@freefall.freebsd.org> Old Synopsis: [jail] [hang] Machine with jail freezes after random amount of time New Synopsis: [hang] Machine with jail freezes after random amount of time Responsible-Changed-From-To: freebsd-jail->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Mon Jun 8 17:12:41 UTC 2009 Responsible-Changed-Why: This does not sounds like a jail but more a networking/tcp problem with 7.2-R hanging the machine. Re-assign so that the right people will look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=134583 From richardtector at thekeelecentre.com Mon Jun 8 20:22:42 2009 From: richardtector at thekeelecentre.com (Richard Tector) Date: Mon Jun 8 20:22:49 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <20090605235117.GB3235@mavetju.org> References: <20090605124428.GA85576@mavetju.org> <200906051424.n55EOIrM012619@post.behrens.de> <20090605235117.GB3235@mavetju.org> Message-ID: <4A2D7307.30701@thekeelecentre.com> The fact that everyone has different ideas and suggestions with regards to the contents of this file, and also that it's generally better to use time servers from your local area (http://www.pool.ntp.org/en/use.html) rather than the global pool, indicates to me that having a default configuration is not a good idea. Regards, Richard From edwin at mavetju.org Mon Jun 8 23:49:51 2009 From: edwin at mavetju.org (Edwin Groothuis) Date: Mon Jun 8 23:49:59 2009 Subject: NTP - default /etc/ntp.conf In-Reply-To: <4A2D7307.30701@thekeelecentre.com> References: <20090605124428.GA85576@mavetju.org> <200906051424.n55EOIrM012619@post.behrens.de> <20090605235117.GB3235@mavetju.org> <4A2D7307.30701@thekeelecentre.com> Message-ID: <20090608234948.GD98804@mavetju.org> Hello Richard, On Mon, Jun 08, 2009 at 09:22:31PM +0100, Richard Tector wrote: > The fact that everyone has different ideas and suggestions with regards > to the contents of this file, and also that it's generally better to use > time servers from your local area (http://www.pool.ntp.org/en/use.html) > rather than the global pool, indicates to me that having a default > configuration is not a good idea. The DNS servers for pool.ntp.org area already geographical distance aware: ;; ANSWER SECTION: 0.pool.ntp.org. 1089 IN A 119.148.81.6 0.pool.ntp.org. 1089 IN A 202.60.94.11 0.pool.ntp.org. 1089 IN A 202.89.184.139 0.pool.ntp.org. 1089 IN A 203.161.129.2 0.pool.ntp.org. 1089 IN A 203.82.209.217 ;; ANSWER SECTION: au.pool.ntp.org. 1200 IN A 119.148.81.6 au.pool.ntp.org. 1200 IN A 202.125.43.135 au.pool.ntp.org. 1200 IN A 202.60.94.11 au.pool.ntp.org. 1200 IN A 203.161.129.2 au.pool.ntp.org. 1200 IN A 203.82.209.217 I've only sorted them for easier comparing, I haven't changed them. But as you can see, they both give the same. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From delphij at delphij.net Mon Jun 8 23:50:53 2009 From: delphij at delphij.net (Xin LI) Date: Mon Jun 8 23:51:12 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <20090608224516.547F17302F@freebsd-current.sentex.ca> References: <20090608224516.547F17302F@freebsd-current.sentex.ca> Message-ID: <4A2DA390.3090704@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FreeBSD Tinderbox wrote: > cc1: warnings being treated as errors > /src/sys/net/if_gif.c: In function 'gif_ioctl': > /src/sys/net/if_gif.c:918: warning: cast to pointer from integer of different size > *** Error code 1 > > Stop in /obj/sparc64/src/sys/LINT. > *** Error code 1 The attached patch should fix this, any objections? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoto48ACgkQi+vbBBjt66C98ACgvgafjQZ/MU01V8ftN6ZI9/1U xB0AoKZipqyI0JYmBkMGNsEEYp8A0VVl =3o5u -----END PGP SIGNATURE----- -------------- next part -------------- Index: if_gif.c =================================================================== --- if_gif.c (revision 193731) +++ if_gif.c (working copy) @@ -912,10 +912,10 @@ case GIFSOPTS: if ((error = priv_check(curthread, PRIV_NET_GIF)) != 0) break; - if ((error = copyin(&options, &sc->gif_options, - sizeof(sc->gif_options)))) { + if ((error = copyin(ifr->ifr_data, &options, + sizeof(options)))) { if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) - ifr->ifr_data = (caddr_t)options; + sc->gif_options = options; else error = EINVAL; } From rea-fbsd at codelabs.ru Tue Jun 9 05:09:47 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Jun 9 05:09:53 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <4A2DA390.3090704@delphij.net> References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> Message-ID: Xin, good day. Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: > The attached patch should fix this, any objections? Yes, you missed negation operator in the copyin check. The issue was already fixed by hrs@ two hours ago: http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From dennis.melentyev at gmail.com Tue Jun 9 06:20:07 2009 From: dennis.melentyev at gmail.com (Dennis Melentyev) Date: Tue Jun 9 06:20:16 2009 Subject: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Message-ID: <200906090620.n596K6Uu039348@freefall.freebsd.org> The following reply was made to PR kern/133572; it has been noted by GNATS. From: Dennis Melentyev To: bohdan200@gmail.com Cc: bug-followup@freebsd.org Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Date: Tue, 9 Jun 2009 08:51:39 +0300 Not sure. I had no PPPoE. Only PPTP connections. One is outgoing VPN to ISP and 10 incoming VPNs for employees. Also, my configuration used to have two uplinks with extensive use of policy based routing and forwarding. daemons: mpd4, pf. It is possible that I have some kind of loops in routing, it was not very professional set-up :) BTW, I have no possibility to reproduce the problem since I've downgraded system to 7.1. /dennis 2009/6/8 Bohdan Tymkiv : > Dennis, > maybe this issue is related to > http://www.freebsd.org/cgi/query-pr.cgi?pr=134557 > can you confirm this? > > -- > Bohdan Tymkiv > > -- Dennis Melentyev From delphij at delphij.net Tue Jun 9 07:21:06 2009 From: delphij at delphij.net (Xin LI) Date: Tue Jun 9 07:21:21 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> Message-ID: <4A2E0D12.40101@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Braniss wrote: >> Xin, good day. >> >> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: >>> The attached patch should fix this, any objections? >> Yes, you missed negation operator in the copyin check. The issue >> was already fixed by hrs@ two hours ago: >> http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 > sorry to barge in, but: > if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) > is not clear, > if ((options & ~GIF_FULLOPTS) == 0) > seems to be less offuscated or I'm missing something? Yes this looks like the usually used idiom (perhaps more efficient anyway)... I just kept the style consistent with the old code. Hiroki-san, could you have a look at this and consider if we should use this idiom? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkouDRIACgkQi+vbBBjt66A1vACggjZwN3xCIHhfsEj141tAqqqX gdcAn0XM9BDHIhpWGct861T43SlmtQyv =ozhg -----END PGP SIGNATURE----- From bzeeb-lists at lists.zabbadoz.net Tue Jun 9 07:45:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Jun 9 07:45:20 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <4A2E0D12.40101@delphij.net> References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> <4A2E0D12.40101@delphij.net> Message-ID: <20090609074144.O22887@maildrop.int.zabbadoz.net> On Tue, 9 Jun 2009, Xin LI wrote: > Danny Braniss wrote: >>> Xin, good day. >>> >>> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: >>>> The attached patch should fix this, any objections? >>> Yes, you missed negation operator in the copyin check. The issue >>> was already fixed by hrs@ two hours ago: >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 >> sorry to barge in, but: >> if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) >> is not clear, >> if ((options & ~GIF_FULLOPTS) == 0) >> seems to be less offuscated or I'm missing something? > > Yes this looks like the usually used idiom (perhaps more efficient > anyway)... I just kept the style consistent with the old code. > Hiroki-san, could you have a look at this and consider if we should use > this idiom? Also see the mail I had sent in reply to the commit message yesterday. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From danny at cs.huji.ac.il Tue Jun 9 07:45:59 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Jun 9 07:46:07 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: References: <20090608224516.547F17302F@freebsd-current.sentex.ca> <4A2DA390.3090704@delphij.net> Message-ID: > Xin, good day. > > Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: > > The attached patch should fix this, any objections? > > Yes, you missed negation operator in the copyin check. The issue > was already fixed by hrs@ two hours ago: > http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 sorry to barge in, but: if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) is not clear, if ((options & ~GIF_FULLOPTS) == 0) seems to be less offuscated or I'm missing something? danny > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > _______________________________________________ > 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 hrs at FreeBSD.org Tue Jun 9 08:05:38 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Tue Jun 9 08:05:50 2009 Subject: [head tinderbox] failure on sparc64/sparc64 In-Reply-To: <20090609074144.O22887@maildrop.int.zabbadoz.net> References: <4A2E0D12.40101@delphij.net> <20090609074144.O22887@maildrop.int.zabbadoz.net> Message-ID: <20090609.170328.129820575.hrs@allbsd.org> "Bjoern A. Zeeb" wrote in <20090609074144.O22887@maildrop.int.zabbadoz.net>: bz> On Tue, 9 Jun 2009, Xin LI wrote: bz> bz> > Danny Braniss wrote: bz> >>> Xin, good day. bz> >>> bz> >>> Mon, Jun 08, 2009 at 04:49:36PM -0700, Xin LI wrote: bz> >>>> The attached patch should fix this, any objections? bz> >>> Yes, you missed negation operator in the copyin check. The issue bz> >>> was already fixed by hrs@ two hours ago: bz> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=193796 bz> >> sorry to barge in, but: bz> >> if ((options | GIF_FULLOPTS) == GIF_FULLOPTS) bz> >> is not clear, bz> >> if ((options & ~GIF_FULLOPTS) == 0) bz> >> seems to be less offuscated or I'm missing something? bz> > bz> > Yes this looks like the usually used idiom (perhaps more efficient bz> > anyway)... I just kept the style consistent with the old code. bz> > Hiroki-san, could you have a look at this and consider if we should bz> > use bz> > this idiom? bz> bz> Also see the mail I had sent in reply to the commit message yesterday. Sorry, I overlooked some of the messages I received. Yes, the logic was reversed and fixed now, but your patch including style fix looks better to me. I will commit it. Thank you for your review! -- 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/20090609/66e46eeb/attachment.pgp From vladimirt at PartyGaming.com Tue Jun 9 08:23:10 2009 From: vladimirt at PartyGaming.com (Vladimir Terziev) Date: Tue Jun 9 08:23:17 2009 Subject: Unable to clone wlan device Message-ID: Hi, on FreeBSD 7.1-RELEASE (i386) driven machine, with iwi(4) (Intel PRO/Wireless 2915ABG), i try to create a clone of the iwi0 device. Here is the device info: $ ifconfig iwi0 iwi0: flags=8802 metric 0 mtu 1500 ether 00:16:6f:8a:ee:4b media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 (2412 Mhz 11b) authmode OPEN privacy OFF bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11b 7 roam:rate11b 1 bintval 0 $ ifconfig iwi0 list caps iwi0=25818300 When i try to create the clone device i get the following: # ifconfig wlan create wlandev iwi0 ifconfig: SIOCIFCREATE2: Invalid argument I searched for a similar problem in the net, but haven't found anything meaningful. What am i missing ? Regards, Vladimir This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From onemda at gmail.com Tue Jun 9 08:34:50 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Jun 9 08:35:21 2009 Subject: Unable to clone wlan device In-Reply-To: References: Message-ID: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> wlan cloning is only available on 8.0, and iwi supports only one virtual interface at any time. -- Paul From vladimirt at partygaming.com Tue Jun 9 08:41:00 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Tue Jun 9 08:41:07 2009 Subject: Unable to clone wlan device In-Reply-To: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> References: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> Message-ID: <1244536849.41240.6.camel@daemon2.partygaming.local> Thanks Paul, i have tried the same with ral(4) device and got a similar result. What about ral(4), does it support virtual interfaces ? Regards, Vladimir On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: > wlan cloning is only available on 8.0, and iwi supports only one > virtual > interface at any time. > > -- > Paul > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From onemda at gmail.com Tue Jun 9 10:08:16 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Jun 9 10:08:23 2009 Subject: Unable to clone wlan device In-Reply-To: <1244536849.41240.6.camel@daemon2.partygaming.local> References: <3a142e750906090134h6fae7342y27c844c3acaf59af@mail.gmail.com> <1244536849.41240.6.camel@daemon2.partygaming.local> Message-ID: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> On 6/9/09, Vladimir Terziev wrote: > Thanks Paul, > > i have tried the same with ral(4) device and got a similar result. > > What about ral(4), does it support virtual interfaces ? No it doesn't. The only chips capable of multi bssid I'm aware of are atheros ones and only on >= 8.0. > On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: >> wlan cloning is only available on 8.0, and iwi supports only one >> virtual >> interface at any time. -- Paul From vladimirt at partygaming.com Tue Jun 9 10:44:16 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Tue Jun 9 10:44:23 2009 Subject: Unable to clone wlan device In-Reply-To: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> References: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> Message-ID: <1244544247.41240.16.camel@daemon2.partygaming.local> The actual problem, i play with wlan cloning because of, is, i try to set up a FreeBSD based wireless access point either based on ral(4) or iwi(4) interface. The ral(4) (which is "Edimax EW-7128g") seems more suitable for that, since it has HOSTAP capability, but when i tried to run a hostapd(8) on it, i got an error about inability TKIP to be configured by hostpad(8). Since TKIP is not present as a capability of the wireless adapter, i decided to clone it and use the wlan_tkip(4) module to do the work. Thanks for your time! Regards, Vladimir On Tue, 2009-06-09 at 13:08 +0300, Paul B. Mahol wrote: > On 6/9/09, Vladimir Terziev wrote: > > Thanks Paul, > > > > i have tried the same with ral(4) device and got a similar result. > > > > What about ral(4), does it support virtual interfaces ? > > No it doesn't. The only chips capable of multi bssid I'm aware of > are atheros ones and only on >= 8.0. > > > On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: > >> wlan cloning is only available on 8.0, and iwi supports only one > >> virtual > >> interface at any time. > > -- > Paul > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From onemda at gmail.com Tue Jun 9 12:18:13 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Jun 9 12:18:19 2009 Subject: Unable to clone wlan device In-Reply-To: <1244544247.41240.16.camel@daemon2.partygaming.local> References: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> <1244544247.41240.16.camel@daemon2.partygaming.local> Message-ID: <3a142e750906090518u6951c28clbe6e97c1f4ff1601@mail.gmail.com> On 6/9/09, Vladimir Terziev wrote: > The actual problem, i play with wlan cloning because of, is, i try to > set up a FreeBSD based wireless access point either based on ral(4) or > iwi(4) interface. > > The ral(4) (which is "Edimax EW-7128g") seems more suitable for that, > since it has HOSTAP capability, but when i tried to run a hostapd(8) on > it, i got an error about inability TKIP to be configured by hostpad(8). > Since TKIP is not present as a capability of the wireless adapter, i > decided to clone it and use the wlan_tkip(4) module to do the work. That is not important. You don't need to clone device to use TKIP. If device or device driver doesn't support encryption in hardware, software encryption will do the work via wlan_tkip(4). There is only one exception to this and that are ndis(4) drivers. NDIS do not allow such workaround. -- Paul From vladimirt at partygaming.com Tue Jun 9 12:34:26 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Tue Jun 9 12:34:37 2009 Subject: Unable to clone wlan device In-Reply-To: <3a142e750906090518u6951c28clbe6e97c1f4ff1601@mail.gmail.com> References: <3a142e750906090518u6951c28clbe6e97c1f4ff1601@mail.gmail.com> Message-ID: <1244550858.41240.19.camel@daemon2.partygaming.local> Hi Paul, this is very very important info. It means i should be able to do it once i find the actual problem. Thanks, Vladimir On Tue, 2009-06-09 at 15:18 +0300, Paul B. Mahol wrote: > On 6/9/09, Vladimir Terziev wrote: > > The actual problem, i play with wlan cloning because of, is, i try > to > > set up a FreeBSD based wireless access point either based on ral(4) > or > > iwi(4) interface. > > > > The ral(4) (which is "Edimax EW-7128g") seems more suitable for > that, > > since it has HOSTAP capability, but when i tried to run a hostapd(8) > on > > it, i got an error about inability TKIP to be configured by > hostpad(8). > > Since TKIP is not present as a capability of the wireless adapter, i > > decided to clone it and use the wlan_tkip(4) module to do the work. > > That is not important. > You don't need to clone device to use TKIP. > If device or device driver doesn't support encryption in hardware, > software > encryption will do the work via wlan_tkip(4). > There is only one exception to this and that are ndis(4) drivers. NDIS > do not allow such workaround. > > -- > Paul > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From sam at freebsd.org Tue Jun 9 15:47:22 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Jun 9 15:47:28 2009 Subject: Unable to clone wlan device In-Reply-To: <1244544247.41240.16.camel@daemon2.partygaming.local> References: <3a142e750906090308w34c1d9feye5c6e2cc67d5a953@mail.gmail.com> <1244544247.41240.16.camel@daemon2.partygaming.local> Message-ID: <4A2E7E53.2010306@freebsd.org> As Paul mentioned iwi supports only 1 vap at a time. ral supports multiple vaps but only 1 ap vap + N wds vaps. It may be possible to support more complex configurations with some ralink parts (e.g. 2860 and later) but noone has made the effort. Not sure about the tkip comment. The output of ifconfig wlanX list caps shows support for h/w crypto acceleration. When a device/driver does not support h/w acceleration the work is done in s/w. This is unrelated to cloning/vaps. Sam Vladimir Terziev wrote: > The actual problem, i play with wlan cloning because of, is, i try to > set up a FreeBSD based wireless access point either based on ral(4) or > iwi(4) interface. > > The ral(4) (which is "Edimax EW-7128g") seems more suitable for that, > since it has HOSTAP capability, but when i tried to run a hostapd(8) on > it, i got an error about inability TKIP to be configured by hostpad(8). > Since TKIP is not present as a capability of the wireless adapter, i > decided to clone it and use the wlan_tkip(4) module to do the work. > > Thanks for your time! > > Regards, > > Vladimir > > > On Tue, 2009-06-09 at 13:08 +0300, Paul B. Mahol wrote: > >> On 6/9/09, Vladimir Terziev wrote: >> >>> Thanks Paul, >>> >>> i have tried the same with ral(4) device and got a similar result. >>> >>> What about ral(4), does it support virtual interfaces ? >>> >> No it doesn't. The only chips capable of multi bssid I'm aware of >> are atheros ones and only on >= 8.0. >> >> >>> On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote: >>> >>>> wlan cloning is only available on 8.0, and iwi supports only one >>>> virtual >>>> interface at any time. >>>> >> -- >> Paul >> >> >> > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. > > > _______________________________________________ > 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 bohdan200 at gmail.com Tue Jun 9 16:20:04 2009 From: bohdan200 at gmail.com (Bohdan Tymkiv) Date: Tue Jun 9 16:20:14 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200906091620.n59GK3ia035902@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Bohdan Tymkiv 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: Tue, 09 Jun 2009 19:12:28 +0300 I confirm that downgrading to 7.1-RELEASE-p5 from svn sources on the same machine fixes the issue. -- Bohdan Tymkiv Home From takefu at airport.fm Wed Jun 10 05:40:03 2009 From: takefu at airport.fm (Takefu) Date: Wed Jun 10 05:40:11 2009 Subject: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Message-ID: <200906100540.n5A5e31R052245@freefall.freebsd.org> The following reply was made to PR kern/121257; it has been noted by GNATS. From: Takefu To: bug-followup@FreeBSD.org, vnovy@vnovy.net Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Date: Wed, 10 Jun 2009 14:14:42 +0900 > Dropped Receive Packets on Half-duplex 10/100 Networks > ------------------------------------------------------ > If you have an Intel PCI Express adapter installed, running at 10 or > 100 Mbps, half-duplex, with TCP Segment Offload (TSO) enabled, you may > observe occasional dropped receive packets. To work around this > problem, disable TSO, or update the network to operate in full-duplex > and/or 1 Gbps. http://downloadmirror.intel.com/14614/eng/rel_notes_v14_0.txt :-) From is at rambler-co.ru Wed Jun 10 12:56:09 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Jun 10 12:56:19 2009 Subject: bge interrupt coalescing sysctls Message-ID: <20090610123301.GE40250@rambler-co.ru> For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken the patch. I'm not sure how to fix the collision, and since I do not use dynamic tuning I has left only static coalescing parameters in the patch and has added a loader tunable to set number of receive descriptors and read only sysctl to read the tunable. I usually use these parameters: /boot/loader.conf: hw.bge.rxd=512 /etc/sysctl.conf: dev.bge.0.rx_coal_ticks=500 dev.bge.0.tx_coal_ticks=10000 dev.bge.0.rx_max_coal_bds=64 dev.bge.0.tx_max_coal_bds=128 # apply the above parameters dev.bge.0.program_coal=1 Could anyone commit it ? -- Igor Sysoev http://sysoev.ru/en/ -------------- next part -------------- --- sys/dev/bge/if_bge.c 2009-05-21 01:17:10.000000000 +0400 +++ sys/dev/bge/if_bge.c 2009-06-05 13:45:49.000000000 +0400 @@ -447,12 +447,16 @@ DRIVER_MODULE(miibus, bge, miibus_driver, miibus_devclass, 0, 0); static int bge_allow_asf = 0; +static int bge_rxd = BGE_SSLOTS; TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf); +TUNABLE_INT("hw.bge.rxd", &bge_rxd); SYSCTL_NODE(_hw, OID_AUTO, bge, CTLFLAG_RD, 0, "BGE driver parameters"); SYSCTL_INT(_hw_bge, OID_AUTO, allow_asf, CTLFLAG_RD, &bge_allow_asf, 0, "Allow ASF mode if available"); +SYSCTL_INT(_hw_bge, OID_AUTO, bge_rxd, CTLFLAG_RD, &bge_rxd, 0, + "Number of receive descriptors"); #define SPARC64_BLADE_1500_MODEL "SUNW,Sun-Blade-1500" #define SPARC64_BLADE_1500_PATH_BGE "/pci@1f,700000/network@2" @@ -1008,21 +1012,15 @@ return (0); } -/* - * The standard receive ring has 512 entries in it. At 2K per mbuf cluster, - * that's 1MB or memory, which is a lot. For now, we fill only the first - * 256 ring entries and hope that our CPU is fast enough to keep up with - * the NIC. - */ static int bge_init_rx_ring_std(struct bge_softc *sc) { int i; - for (i = 0; i < BGE_SSLOTS; i++) { + for (i = 0; i < bge_rxd; i++) { if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) return (ENOBUFS); - }; + } bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, sc->bge_cdata.bge_rx_std_ring_map, @@ -2383,6 +2381,52 @@ #endif static int +bge_sysctl_program_coal(SYSCTL_HANDLER_ARGS) +{ + struct bge_softc *sc; + int error, i, val; + + val = 0; + error = sysctl_handle_int(oidp, &val, 0, req); + if (error != 0 || req->newptr == NULL) + return (error); + sc = arg1; + BGE_LOCK(sc); + + /* XXX cut from bge_blockinit(): */ + + /* Disable host coalescing until we get it set up */ + CSR_WRITE_4(sc, BGE_HCC_MODE, 0x00000000); + + /* Poll to make sure it's shut down. */ + for (i = 0; i < BGE_TIMEOUT; i++) { + if (!(CSR_READ_4(sc, BGE_HCC_MODE) & BGE_HCCMODE_ENABLE)) + break; + DELAY(10); + } + + if (i == BGE_TIMEOUT) { + device_printf(sc->bge_dev, + "host coalescing engine failed to idle\n"); + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); + BGE_UNLOCK(sc); + return (ENXIO); + } + + /* Set up host coalescing defaults */ + CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); + CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, sc->bge_rx_max_coal_bds); + CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS, sc->bge_tx_max_coal_bds); + + /* Turn on host coalescing state machine */ + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); + + BGE_UNLOCK(sc); + return (0); +} + +static int bge_attach(device_t dev) { struct ifnet *ifp; @@ -4495,6 +4539,19 @@ ctx = device_get_sysctl_ctx(sc->bge_dev); children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "program_coal", + CTLTYPE_INT | CTLFLAG_RW, + sc, 0, bge_sysctl_program_coal, "I", + "program bge coalescence values"); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_coal_ticks", CTLFLAG_RW, + &sc->bge_rx_coal_ticks, 0, ""); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_coal_ticks", CTLFLAG_RW, + &sc->bge_tx_coal_ticks, 0, ""); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_max_coal_bds", CTLFLAG_RW, + &sc->bge_rx_max_coal_bds, 0, ""); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_max_coal_bds", CTLFLAG_RW, + &sc->bge_tx_max_coal_bds, 0, ""); + #ifdef BGE_REGISTER_DEBUG SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "debug_info", CTLTYPE_INT | CTLFLAG_RW, sc, 0, bge_sysctl_debug_info, "I", From excalibur at accesswave.ca Wed Jun 10 13:33:31 2009 From: excalibur at accesswave.ca (Chris Bowlby) Date: Wed Jun 10 13:33:37 2009 Subject: IPSec VPN issues Message-ID: <4A2FAF23.6090906@accesswave.ca> Hi Everyone, I let this question sit in freebsd-questions overnight before posting this here, as I did not get any responses. Any help would be appreciated. -------------------------------- I'm in the process of configuring a VPN tunnel via IPSec to another network to provide an easy means to manage both networks. I can get the VPN established from my FreeBSD box to the server on the other side, but I can't seem to route any traffic through the interface so that it goes to the other side of the VPN. I know I am missing a step, but I can't seem to find any information in the documentation about what that step might be. Here is what I have so far: I have compiled my kernel with the following options: # IP Sec Options options IPSEC # IP Security options IPSEC_DEBUG # debug for IP security options IPSEC_FILTERTUNNEL # To properly filter on the inner packets (this was done in case I needed to expand some fire-walling to this box) And added the crypto device: # IPSec device crypto the kernel is installed and running with no issues as far as I can tell. I have also installed security/ipsec-tools, though I did noticed that a kernel patch was required for something related to NAT. As I am running FreeBSD 7.2, I was not sure if that patch was still required, and I am honestly not sure if NATing is what I need/require to get this running. My interfaces are as follows: amaethon# ifconfig em0: flags=8843 metric 0 mtu 1500 options=19b inet 1xx.1xx.2xx.2xx netmask 0xffffff00 broadcast 1xx.1xx.2xx.255 media: Ethernet autoselect (100baseTX ) status: active gif0: flags=8051 metric 0 mtu 1280 tunnel inet 1xx.1xx.2xx.2 --> xxx.2xx.1xx.1xx inet 1xx.1xx.2xx.2 --> 1xx.1xx.xxx.1 netmask 0xfffffc00 The routing tables are as follows: default 1xx.1xx.2xx.1 UGS 0 1807 em0 127.0.0.1 127.0.0.1 UH 0 4 lo0 1xx.1xx.xxx.0/22 1xx.1xx.xxx.1 UGS 0 0 gif0 1xx.1xx.xxx.1 1xx.1xx.2xx.2 UH 1 327 gif0 1xx.1xx.2xx.0/24 link#1 UC 0 0 em0 1xx.1xx.2xx.1 00:13:10:09:5b:1f UHLW 2 0 em0 1114 1xx.1xx.2xx.2 00:1c:c0:94:2c:0c UHLW 1 924 lo0 Right now I am simply looking to have any local (to the host) pinging a system on the other side. As I don't have immediate access to the routing details of the other end, and it's configured exactly the same as it has been for other VPN's, I am inclined to believe the issue is on my side of the VPN. The system I have, only has one NIC in it at this time, but can easily be configured to have a second. The system is also behind another system that is handling the local routing and fire-walling, and is NATing all appropriate traffic to the various box's. I have used the examples in the freebsd handbook to guide me as far as I have gotten thus far (btw there is a step missing in there, forgetting to tell you to run setkey -f /path/to/racoon/setkey.conf). I have googled everything I can find, looked over freebsd.org and freebsddiary.org (those articles are a bit out dated I think), and have found no information to indicate what I am missing.. I suspect it might be that this system is not doing traffic NATing, or a packet filter configuration is required, but I have tried every example with no luck. At this point I am stuck, and looking for some guidance. From dr.dawn-elise_snipes at allceus.com Wed Jun 10 14:54:54 2009 From: dr.dawn-elise_snipes at allceus.com (dr.dawn-elise_snipes@allceus.com) Date: Wed Jun 10 14:55:02 2009 Subject: [AllCEUs.com] View Counseling Education Videos Online at Blip.tv Message-ID: <70a28c7f14717473cc9ee2bd62a8abe0@localhost.localdomain> -View AllCEUs counseling education videos -20% savings code for CEUs, from the already lowest industry cost (code: 4989) Don't want any more message from us, just let us know: http://allceus.com/mail_list/?p=unsubscribe&uid=37ba0c6dd4da598f351d23e5d8ff4d87 Having trouble viewing this email? View it in your browser. To update your preferences visit http://allceus.com/mail_list/?p=preferences&uid=37ba0c6dd4da598f351d23e5d8ff4d87 Dr. Dawn-Elise Snipes dr.dawn-elise_snipes@allceus.com PO BOX 1688 Alachua, FL 32616 -- Powered by PHPlist, www.phplist.com -- From seesaravanan at yahoo.co.in Wed Jun 10 14:13:58 2009 From: seesaravanan at yahoo.co.in (saravana perumal) Date: Wed Jun 10 15:56:34 2009 Subject: TCP Free-BSD setup behaviour. Message-ID: <28959.63465.qm@web8313.mail.in.yahoo.com> ?Hi , ? ? Have some behaviour change? with FREEBSD? compared to? LINUX . 1. When sending the Same? TCP packet once again [ Retranmission of TCP packet ] Whether the Same Identification field [ IP packet]used or not . but when seeing that thru packet capture, Free BSD sending the differnt one [ increases sequentially IP Identification] 2.Retranmission Time is not increasing Linearly with Respect to BSD. not keeping more time interval . AS per RFC expecting Retransmission timeout should? increase Linearly. Issue is not seen with Linux Setup 3. Active SYN open state in FREE BSD setup?, Does not reach Syn-received State. When Sending syn packet to DUT but? for that FreeBSD is not sending back SYN/ACK .? Issue is with Free BSD Setup.Linux works fine, ? 4.When checking the State - TIME-WAIT ? Sending FIN and expecting the ACK ;Getting the ACK properly. ? Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. ? Issue seen only in Free BSD. ? Same issue in FIN-WAIT2? & FIN-WAIT1 State also . ? Sending FIN and Expect the ACK : Getting the ACK ? Sending Data segment with Data : Expecting the RST signal from DUT ; but got Last transmitted TCP packet[ FIN -ACK] ? Any idea about the above scenario would be helpful ? Thanks, Saravanan. From roar.pettersen at uib.no Wed Jun 10 17:20:04 2009 From: roar.pettersen at uib.no (Roar Pettersen) Date: Wed Jun 10 17:20:10 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200906101720.n5AHK3pr036971@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Roar Pettersen To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Wed, 10 Jun 2009 19:09:00 +0200 (CEST) Hi ! We also see a similar problem with FreeBSD 7.2-Stable and MPD 5.3, after 4-5 days then the mpd process goes into a deadlock. Not able to kill the process or reload the server, have to press the Power Off button. System load is normaly 2-3%, but when the problem occur it raise to 30-35%. No error messages, nothing in the log files. The problem is releated to FreeBSD 7.2, no problem with 7.1. -- Roar Pettersen Universitetet i Bergen - The University of Bergen BERGEN - Norway From linimon at FreeBSD.org Wed Jun 10 20:51:06 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Jun 10 20:51:18 2009 Subject: kern/135451: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] Message-ID: <200906102051.n5AKp5Db005125@freefall.freebsd.org> Old Synopsis: no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 New Synopsis: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 10 20:50:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135451 From bzeeb-lists at lists.zabbadoz.net Wed Jun 10 21:05:13 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Jun 10 21:05:22 2009 Subject: fxp hack in sys/net/if.c? Message-ID: <20090610210021.N22887@maildrop.int.zabbadoz.net> Hi, could anyone having a clue why that is there look at it and either remove it or remove it and properly handle it elsewhere? I have continuesly noticed it for a while so I think the "temporary" as given in the comment rather means "forgotten"? sys/net/if.c: DELAY(100);/* XXX: temporary workaround for fxp issue*/ /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From kip.macy at gmail.com Wed Jun 10 21:31:51 2009 From: kip.macy at gmail.com (Kip Macy) Date: Wed Jun 10 21:31:57 2009 Subject: fxp hack in sys/net/if.c? In-Reply-To: <3c1674c90906101417j39a01f85k8e98c0ee19a011a7@mail.gmail.com> References: <20090610210021.N22887@maildrop.int.zabbadoz.net> <3c1674c90906101417j39a01f85k8e98c0ee19a011a7@mail.gmail.com> Message-ID: <3c1674c90906101431x7b556855pd3103d9e7a9f26dc@mail.gmail.com> The reasoning behind moving the delay in to shared code is not very compelling. -Kip On Wed, Jun 10, 2009 at 2:17 PM, Kip Macy wrote: > From "cvs blame": > > Add workaround for fxp issue at interface initialization with IPv6. > > ?Some LAN card chip for fxp is known to cause problem at > ?interface initialization with IPv6 enabled. It happens at > ?some delicate timing. > ?And also, just adding some DELAY before IPv6 address > ?autoconfiguration is known to avoid the problem. > > ?Complete fix is changing the driver not to use interrupt at > ?multicast filter initialization, but trying such change in > ?this stage will be dangerous. > > ?So I add some DELAY() only inside #ifdef INET6 part, > ?as temporal workaround only for 4.0. > > Approbed by: jkh > > Noticed by: Mattias Pantzare > > Obtained from: openbsd-tech mailing list > > > > On Wed, Jun 10, 2009 at 2:03 PM, Bjoern A. > Zeeb wrote: >> Hi, >> >> could anyone having a clue why that is there look at it and either >> remove it or remove it and properly handle it elsewhere? >> >> I have continuesly noticed it for a while so I think the "temporary" >> as given in the comment rather means "forgotten"? >> >> sys/net/if.c: ? ? ? ? ? DELAY(100);/* XXX: temporary workaround for fxp >> issue*/ >> >> /bz >> >> -- >> Bjoern A. Zeeb ? ? ? ? ? ? ? ? ? ? ?The greatest risk is not taking one. >> _______________________________________________ >> 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" >> > > > > -- > When bad men combine, the good must associate; else they will fall one > by one, an unpitied sacrifice in a contemptible struggle. > > ? ?Edmund Burke > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From kip.macy at gmail.com Wed Jun 10 21:50:36 2009 From: kip.macy at gmail.com (Kip Macy) Date: Wed Jun 10 21:50:42 2009 Subject: fxp hack in sys/net/if.c? In-Reply-To: <20090610210021.N22887@maildrop.int.zabbadoz.net> References: <20090610210021.N22887@maildrop.int.zabbadoz.net> Message-ID: <3c1674c90906101417j39a01f85k8e98c0ee19a011a7@mail.gmail.com> >From "cvs blame": Add workaround for fxp issue at interface initialization with IPv6. Some LAN card chip for fxp is known to cause problem at interface initialization with IPv6 enabled. It happens at some delicate timing. And also, just adding some DELAY before IPv6 address autoconfiguration is known to avoid the problem. Complete fix is changing the driver not to use interrupt at multicast filter initialization, but trying such change in this stage will be dangerous. So I add some DELAY() only inside #ifdef INET6 part, as temporal workaround only for 4.0. Approbed by: jkh Noticed by: Mattias Pantzare Obtained from: openbsd-tech mailing list On Wed, Jun 10, 2009 at 2:03 PM, Bjoern A. Zeeb wrote: > Hi, > > could anyone having a clue why that is there look at it and either > remove it or remove it and properly handle it elsewhere? > > I have continuesly noticed it for a while so I think the "temporary" > as given in the comment rather means "forgotten"? > > sys/net/if.c: ? ? ? ? ? DELAY(100);/* XXX: temporary workaround for fxp > issue*/ > > /bz > > -- > Bjoern A. Zeeb ? ? ? ? ? ? ? ? ? ? ?The greatest risk is not taking one. > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From brde at optusnet.com.au Thu Jun 11 01:54:38 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Jun 11 01:54:44 2009 Subject: bge interrupt coalescing sysctls In-Reply-To: <20090610123301.GE40250@rambler-co.ru> References: <20090610123301.GE40250@rambler-co.ru> Message-ID: <20090611114120.I21056@delplex.bde.org> On Wed, 10 Jun 2009, Igor Sysoev wrote: > For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: > http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html > However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken > the patch. I'm not sure how to fix the collision, and since I do not > use dynamic tuning That commit looked ugly (lots of internal API changes and bloat in interrupt handlers in many network drivers to support polling which mostly shouldn't be supported at all and mostly doesn't use the interrupt handlers). > I has left only static coalescing parameters in the patch > and has added a loader tunable to set number of receive descriptors and > read only sysctl to read the tunable. I usually use these parameters: > > /boot/loader.conf: > hw.bge.rxd=512 > > /etc/sysctl.conf: > dev.bge.0.rx_coal_ticks=500 > dev.bge.0.tx_coal_ticks=10000 > dev.bge.0.rx_max_coal_bds=64 These rx settings give to high a latency for me. > dev.bge.0.tx_max_coal_bds=128 > # apply the above parameters > dev.bge.0.program_coal=1 > > Could anyone commit it ? Not me, sorry. The patch is quite clean. If I committed then I would commit the dynamic coalescing configuration separately anyway. You can probably make hw.bge.rxd a sysctl too (it would take a down/up to get it changed, but that is already needed for too many parameters in network drivers anyway). I should use a sysctl for the ifq length too. This could be done at a high level for each driver. Limiting queue lengths may be a good way to reduce cache misses, while increasing them is sometimes good for reducing packet loss. Bruce From cbuechler at gmail.com Thu Jun 11 06:02:54 2009 From: cbuechler at gmail.com (Chris Buechler) Date: Thu Jun 11 06:03:01 2009 Subject: ath(4) randomly changes MTU to 2290 after explicitly set to 1500 In-Reply-To: <4A249A57.1070900@pfsense.org> References: <4A249A57.1070900@pfsense.org> Message-ID: <4A3099DC.5050909@gmail.com> Chris Buechler wrote: > > somehow it ends up switching MTU to 2290 when we never configure it as > such. This breaks bridging to an Ethernet interface because if_bridge > requires the MTU to be the same on both interfaces. For the sake of the archives and anyone who finds this thread in the future, the problem was resolved by Jim Thompson and Sam Leffler. This is the change: http://svn.freebsd.org/changeset/base/193524 Thanks Jim and Sam! From bra at fsn.hu Thu Jun 11 10:32:10 2009 From: bra at fsn.hu (Attila Nagy) Date: Thu Jun 11 10:32:18 2009 Subject: Redirecting traffic with IPSec and pf doesn't work Message-ID: <4A30D90B.3020007@fsn.hu> Hello, What I'm trying to accomplish is the following: - there are two machines, connected over the internet (let's call them A and B) - when A tries to connect to B:port, or B to A:port (via TCP, port is just a TCP port, in this case, 3306) the connection should be redirected to a local listener, instead of the remote - the above should only be done if I want to (I can do this with pf anchors or tables) - the connection between the two machines should be secured in kernel space (for efficiency and performance) I can redirect the connections in the unsecured (no IPSec) case with the following pf.conf (this is for machine A): rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is an alias on A's lo0) So when I do a telnet from A to B, the connection establishes and I can reach A's listener, instead of B's. Now with IPSec. ipsec.conf contains this (along with the PSK definitions): spdadd A_IP B_IP any -P out ipsec esp/transport/A_IP-B_IP/default ah/transport/A_IP-B_IP/default; and the same on B, with swapped orders. IPSec between the two machines works, but the redirection doesn't. pf.conf now has: rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is lo0's alias address in this case, but I've also tried with A's public IP and also with a gif tunnel) What I see in pflog's output seems to be OK: 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 000038 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 and the traffic shows up on enc0 as well, but is not that nice: 11:57:36.482910 (confidential): SPI 0x00003d55: IP A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 11:57:36.483009 (confidential): SPI 0x00003d55: IP A_IP.59940 > B_IP.3306: R 3107058077:3107058077(0) win 0 The command, which produced the above output is: MACHINE_A $ telnet B_IP 3306 telnet: connect to address B_IP: Interrupted system call telnet: Unable to connect to remote host I've tried to set net.enc.out.ipsec_filter_mask to different values without success, only 0x0 gave a connection refused answer, instead of "Interrupted system call". This is on 7-STABLE. Is redirecting TCP flows on IPSec secured connections impossible because some layering differences? (maybe the above redirects the packet with IPSec headers, so this causes the problem) Thanks, From sclark46 at earthlink.net Thu Jun 11 14:12:15 2009 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Jun 11 14:12:22 2009 Subject: Redirecting traffic with IPSec and pf doesn't work In-Reply-To: <4A30D90B.3020007@fsn.hu> References: <4A30D90B.3020007@fsn.hu> Message-ID: <4A310D6C.3070602@earthlink.net> Attila Nagy wrote: > Hello, > > What I'm trying to accomplish is the following: > - there are two machines, connected over the internet (let's call them A > and B) > - when A tries to connect to B:port, or B to A:port (via TCP, port is > just a TCP port, in this case, 3306) the connection should be redirected > to a local listener, instead of the remote > - the above should only be done if I want to (I can do this with pf > anchors or tables) > - the connection between the two machines should be secured in kernel > space (for efficiency and performance) > > I can redirect the connections in the unsecured (no IPSec) case with the > following pf.conf (this is for machine A): > rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 > pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to > B_IP port 3306 > (192.168.254.1 is an alias on A's lo0) > > So when I do a telnet from A to B, the connection establishes and I can > reach A's listener, instead of B's. > > Now with IPSec. > > ipsec.conf contains this (along with the PSK definitions): > spdadd A_IP B_IP any -P out ipsec > esp/transport/A_IP-B_IP/default > ah/transport/A_IP-B_IP/default; > and the same on B, with swapped orders. > > IPSec between the two machines works, but the redirection doesn't. > > pf.conf now has: > rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port > 3306 > pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to > B_IP port 3306 > > (192.168.254.1 is lo0's alias address in this case, but I've also tried > with A's public IP and also with a gif tunnel) > > What I see in pflog's output seems to be OK: > 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S > 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> > 000038 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: > S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> > > and the traffic shows up on enc0 as well, but is not that nice: > 11:57:36.482910 (confidential): SPI 0x00003d55: IP A_IP.59940 > > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> > 11:57:36.483009 (confidential): SPI 0x00003d55: IP A_IP.59940 > > B_IP.3306: R 3107058077:3107058077(0) win 0 > > The command, which produced the above output is: > MACHINE_A $ telnet B_IP 3306 > telnet: connect to address B_IP: Interrupted system call > telnet: Unable to connect to remote host > > I've tried to set net.enc.out.ipsec_filter_mask to different values > without success, only 0x0 gave a connection refused answer, instead of > "Interrupted system call". > > This is on 7-STABLE. > > Is redirecting TCP flows on IPSec secured connections impossible because > some layering differences? (maybe the above redirects the packet with > IPSec headers, so this causes the problem) > > Thanks, > _______________________________________________ > 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 don't know on 7.x but on 6.x you have to turn on options IPSEC_FILTERGIF #filter ipsec packets from a tunnel to get packets to go thru ipfilter - I assume it is the same for pf. I had the same problem not being able to redirect packets coming from a ipsec tunnel until I turned this option on. HTH, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From bra at fsn.hu Thu Jun 11 14:48:13 2009 From: bra at fsn.hu (Attila Nagy) Date: Thu Jun 11 14:48:20 2009 Subject: Redirecting traffic with IPSec and pf doesn't work In-Reply-To: <4A310D6C.3070602@earthlink.net> References: <4A30D90B.3020007@fsn.hu> <4A310D6C.3070602@earthlink.net> Message-ID: <4A311926.4010607@fsn.hu> Stephen Clark wrote: > Attila Nagy wrote: >> Hello, >> >> What I'm trying to accomplish is the following: >> - there are two machines, connected over the internet (let's call >> them A and B) >> - when A tries to connect to B:port, or B to A:port (via TCP, port is >> just a TCP port, in this case, 3306) the connection should be >> redirected to a local listener, instead of the remote >> - the above should only be done if I want to (I can do this with pf >> anchors or tables) >> - the connection between the two machines should be secured in kernel >> space (for efficiency and performance) >> >> I can redirect the connections in the unsecured (no IPSec) case with >> the following pf.conf (this is for machine A): >> rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 >> pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any >> to B_IP port 3306 >> (192.168.254.1 is an alias on A's lo0) >> >> So when I do a telnet from A to B, the connection establishes and I >> can reach A's listener, instead of B's. >> >> Now with IPSec. >> >> ipsec.conf contains this (along with the PSK definitions): >> spdadd A_IP B_IP any -P out ipsec >> esp/transport/A_IP-B_IP/default >> ah/transport/A_IP-B_IP/default; >> and the same on B, with swapped orders. >> >> IPSec between the two machines works, but the redirection doesn't. >> >> pf.conf now has: >> rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 >> port 3306 >> pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to >> B_IP port 3306 >> >> (192.168.254.1 is lo0's alias address in this case, but I've also >> tried with A's public IP and also with a gif tunnel) >> >> What I see in pflog's output seems to be OK: >> 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > >> B_IP.3306: S 3107058076:3107058076(0) win 65535 > 3,sackOK,timestamp 69415267 0> >> 000038 rule 0/0(match): rdr in on lo0: A_IP.59940 > >> 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 > 1460,nop,wscale 3,sackOK,timestamp 69415267 0> >> >> and the traffic shows up on enc0 as well, but is not that nice: >> 11:57:36.482910 (confidential): SPI 0x00003d55: IP A_IP.59940 > >> B_IP.3306: S 3107058076:3107058076(0) win 65535 > 3,sackOK,timestamp 69415267 0> >> 11:57:36.483009 (confidential): SPI 0x00003d55: IP A_IP.59940 > >> B_IP.3306: R 3107058077:3107058077(0) win 0 >> >> The command, which produced the above output is: >> MACHINE_A $ telnet B_IP 3306 >> telnet: connect to address B_IP: Interrupted system call >> telnet: Unable to connect to remote host >> >> I've tried to set net.enc.out.ipsec_filter_mask to different values >> without success, only 0x0 gave a connection refused answer, instead >> of "Interrupted system call". >> >> This is on 7-STABLE. >> >> Is redirecting TCP flows on IPSec secured connections impossible >> because some layering differences? (maybe the above redirects the >> packet with IPSec headers, so this causes the problem) >> >> Thanks, >> _______________________________________________ >> 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 don't know on 7.x but on 6.x you have to turn on > options IPSEC_FILTERGIF #filter ipsec packets from a > tunnel > > to get packets to go thru ipfilter - I assume it is the same for pf. I > had the > same problem not being able to redirect packets coming from a ipsec > tunnel until > I turned this option on. Yes, but I'm sending, not receiving. So I want to redirect on the sender side.... From bz at FreeBSD.org Thu Jun 11 20:52:10 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Thu Jun 11 20:52:22 2009 Subject: HEADS UP: INET dependencies in the kernel Message-ID: <20090611180438.G22887@maildrop.int.zabbadoz.net> Hi, over the last days I fixed a few places missing #ifdef INET as well changed the kernel build file in sys/conf/files and added depencies for those parts that really require INET to compile / work at the moment. WARNING: -------------------------------- This means for example if you build a kernel without INET you will no longer get gre, ipfw, libablias, ipsec, if_enc, if_bridge, nfsserver, .. Those will _silently_ be disabled whether or not they are in your kernel configuration. WARNING: -------------------------------- You will also not get any of the 12 interfaces I found that had a compile time dependency on INET (if you remove INET from your kernel config): if_age, if_alc, if_ale, if_em, if_igb, if_fxp, if_ixgbe, if_jme, if_msk, if_mxge, if_sk, if_txp. I will send out an extra mail with more information on each interface and how to fix later in a second. (The same may apply to some other code). See r193824, r193949-193950, 193954, 193956-193957, 193960, 193983, 193986-193988, 193990-193991, 193993-193994, 193996-193997 of sys/conf/files for what was changed and if you are looking for a network project to cleanup a bit of our stack. For now I didn't see much of a problem here, as virtually noone so far would have built a kernel without INET support and still wanted networking as it just hadn't (easily) been possible. Obviously people may be concerned that those things will rot and warn others with #error anymore and that other people will one day trip over this. Unless hit by a bus I do not intend to drop this ball but will work (together with you!) to clean things up, resolve them, etc. For now the goal was to actually see how much of impure code we have and clean things basically up before 8.0. Now do not expect that I caught all and everything. We are far away from that. The long term goal is to separate INET6 off INET. So in addition to a kernel config like: ---------------------------------------- include LINT ident LINT-NOINET6 nooptions INET6 ---------------------------------------- FreeBSD 8 LINT currently also builds a kernel with: ---------------------------------------- include LINT ident LINT-NOINET makeoptions NO_MODULES=yes nooptions INET nooptions INET6 ---------------------------------------- Note: LINT will not boot! In case of arm I include AVILA, in case of mips I used ADM5120 instead of LINT (as arm and mips do not have LINT). HINT FOR DEVELOPERS: -------------------------------- For developers this means that if you add new code you really should make sure that INET in addition to INET6 will be properly #ifdefed. KIND OF HEADS UP FOR DEVLEOPERS: -------------------------------- This is kind of a heads up that from the time 8 will be branched off and HEAD will be 9 all new code should 1) have feature parity for INET and INET6 where applicable 2) new/changed code that only has #ifdef INET6 but no #ifdef INET (where applicable) should no longer be done. 3) No it's not April 1st today;-) Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Thu Jun 11 20:52:10 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Thu Jun 11 20:52:23 2009 Subject: Ethernet NIC drivers depending unconditionally on INET Message-ID: <20090611184555.J22887@maildrop.int.zabbadoz.net> Hi, as announced in my other mail to current@ and net@ I added the mandatory "INET" dependency to 12 Ethernet NIC drivers. Additionally I am adding if_bridge here as well. Those drivers should be fixed and once done the (mandatory) inet dependency should be removed again from sys/conf/files for that driver. If you have questions, need help, compile testing, ... feel free to mail me. I won't be able to test things as I do not own all of the different cases but I can review patches, .. Generally speaking upfront: if one of the drivers mentioned here or not, supportes offload capabilities for rx or tx of v4 or v6, for tcp, udp, sctp, .. they need to be properly hidden under the apropriate #ifdefs. Everything that needs v4 belongs under #ifdef INET. Everything that needs v6 belongs under #ifdef INET6. Upper layer protocols like TCP, UDP, SCTP should be at least #if defined (INET) || defined(INET6). In case of SCTP probebly #ifdef (SCTP) as well. You will need to include opt_inet.h, opt_inet6.h, opt_sctp.h in those cases and at least the buildkernel (not building the module alone) part should properly check them. For single module builds we are kind of lost here and I think we usually enabled things by default as they are in GENERIC. Another general note that scared me while looking at CSUM_TSO and IFCAP_TSO4|IFCAP_TSO6. Almost none of the drivers actually checks that it is an IPv4 packet before grabiing the IP header, TCP header, ... How do we actually know that it is an IPv4 packet in all those drivers? Should we do a IP Version fiel check? I think em(4) is one of those that does. I hope this will improve with tuexen's work on the CSUM flags. In case you are maintaining another driver but cannot find it on the list - be sure we'll find you during the 9.x lifecycle in case you do not properly handle things;-) if_age: ---------------------------------------- I identifed two in_pseudo() calls that are INET specific. The problem is that thi is part of the (IPv4) TSO code and it seems to be mandatory for that case. The proper fix seems to be to but that block under #ifdef INET and in case INET is not defined to also disable announcing or permitting to set these features entirely as we won't be able to handle them or use them anyway. if_alc: ---------------------------------------- There is one in_pseudo(); Apart from that things seem identical to if_age. if_ale: ---------------------------------------- There is one in_pseudo(); Apart from that things seem identical to if_age. if_em: ---------------------------------------- There is one in_pseudo() in em_tso_setup() that prevented the driver from being linked into the kernel; the entire code unfortunately has at least one more place of IP/IPV6 distinction for cksum offloading em_transmit_checksum_setup() that is not properly handled either. In either case the feature should be disbaled and not be announced if the address family is not there to handle the code. Note: tuexen is working on a proper set of v4/v6 definitions for the csum offloading, so we will be able to do this more fine grained in the future. For now not having INET6 would penalize INET as well. if_igb: ---------------------------------------- igb_tso_setup() has one in_pseudo() call. See if_age for that. It also has dependencies on the entire LRO framework like tcp_lro_free(), tcp_lro_rx(), tcp_lro_flush(), tcp_lro_init(). The LRO framework is on the IPv6TODO list. For the moment if there is no INET LRO should be completely compiled out and not advertised removing the TUNABLE and SYSCTL and changing the default to 0. Be prepared in case LRO will arrive for IPv6. Side note: calling tcp_lro_free() on something that hadn't been initialized for example because lro was enabled by the sysctl after itniialization, can that be a problem? Maybe tcp_lro_free() should just return in case cntl is NULL? if_fxp: ---------------------------------------- There is one in_pseudo(); Apart from that things seem identical to if_age. ixgbe: ---------------------------------------- There is one in_pseudo() in ixgbe_tso_setup(). See if_igb for that. There is an arp_ifinit() call in ixgbe_ioctl() that already seems to check for the proper address family and only needs the #ifdefs around like the ioctl in if_em has. The same that applies for if_igb about LRO applies here as well. if_jme: ---------------------------------------- Two in_pseudo() calls; see if_age. if_msk: ---------------------------------------- An in_cksum_skip() call. Almost like if_age but this seems to be further conditional on driver flags and CSUM_TCP that seem to be set independently of TSO. I am not entirely sure if there is a proper solution or if we might be forced to return an error in that case in case there is not INET support. if_mxge: ---------------------------------------- mxge_rx_csum() has one in_pseudo(). The function and callers already seem to know how do deal with results in case the csum can't be validated. So this should be a simple #ifdef INET wrapping here; side note: the tcpudp_csum variables in the callers are not needed. side note: huge inlining going on there;) mxge_lro_flush() has another call to in_pseudo(). As with if_igb/ixgbe if there is no INET there should be no LRO for now, the capabilities not advertised, etc. Be prepared in case LRO will arrive for IPv6. if_sk: ---------------------------------------- sk_rxcksum() has an in_addword() call. It seems that sk_rxcksum is only used if IFCAP_RXCSUM is on. So similar things like to TSO should be done; hiding it under #ifdef INET and not advertising the feature etc. if_txp.c: ---------------------------------------- Now this is an interesting case as txp_download_fw_section() is using in_cksum() to validate the firmware csum before downloading it to the card it seems. I am not sure how to bes work around that one. if_bridge: ---------------------------------------- if_bridge is porobably mostly INET6 clean but doesn't have any INEt checks. It's just a matter of going through the code and adding proper #ifdef INET handling the simple cases and see what's left. This is just work; in case you are bored, read this mail to the end and would like to do something, know the difference between IPv4 and IPv6 is 2 and thinking of C doesn't make you think of scale of C major in first place, you are welcome to send patches:-) Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From gallatin at cs.duke.edu Thu Jun 11 21:48:59 2009 From: gallatin at cs.duke.edu (Andrew Gallatin) Date: Thu Jun 11 21:49:11 2009 Subject: HEADS UP: INET dependencies in the kernel In-Reply-To: <20090611180438.G22887@maildrop.int.zabbadoz.net> References: <20090611180438.G22887@maildrop.int.zabbadoz.net> Message-ID: <4A317BA6.3050300@cs.duke.edu> Bjoern A. Zeeb wrote: > This is kind of a heads up that from the time 8 will be branched off > and HEAD will be 9 all new code should > 1) have feature parity for INET and INET6 where applicable As a sort of side-note, what about feature parity for INET6 for existing IPV4 features like TSO? Who is working on that? Thanks, Drew From pyunyh at gmail.com Fri Jun 12 01:53:54 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 12 01:54:01 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090611184555.J22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> Message-ID: <20090612013406.GB72855@michelle.cdnetworks.co.kr> On Thu, Jun 11, 2009 at 08:33:28PM +0000, Bjoern A. Zeeb wrote: > Hi, > > as announced in my other mail to current@ and net@ I added the > mandatory "INET" dependency to 12 Ethernet NIC drivers. Additionally > I am adding if_bridge here as well. > > Those drivers should be fixed and once done the (mandatory) inet > dependency should be removed again from sys/conf/files for that > driver. > > If you have questions, need help, compile testing, ... feel free to > mail me. I won't be able to test things as I do not own all of the > different cases but I can review patches, .. > > > Generally speaking upfront: if one of the drivers mentioned here or > not, supportes offload capabilities for rx or tx of v4 or v6, for tcp, > udp, sctp, .. they need to be properly hidden under the apropriate > #ifdefs. > > Everything that needs v4 belongs under #ifdef INET. > Everything that needs v6 belongs under #ifdef INET6. > Upper layer protocols like TCP, UDP, SCTP should be at least > #if defined (INET) || defined(INET6). > In case of SCTP probebly #ifdef (SCTP) as well. > > You will need to include opt_inet.h, opt_inet6.h, opt_sctp.h > in those cases and at least the buildkernel (not building the module > alone) part should properly check them. For single module builds > we are kind of lost here and I think we usually enabled things by > default as they are in GENERIC. > > Another general note that scared me while looking at CSUM_TSO and > IFCAP_TSO4|IFCAP_TSO6. Almost none of the drivers actually checks > that it is an IPv4 packet before grabiing the IP header, TCP header, > ... How do we actually know that it is an IPv4 packet in all those Yeah, there are no checksum offloading support for IPv6 under FreeBSD so there are no cases the frames are IPv6 when CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > drivers? Should we do a IP Version fiel check? I think em(4) is one I believe this should be done in upper stack. Upper stack already know IP version as well as other useful fields(e.g. IP header length, TCP header length, etc). You wouldn't want to parse mbuf chains which takes a lot of CPU cycles. > of those that does. I hope this will improve with tuexen's work on > the CSUM flags. > > In case you are maintaining another driver but cannot find it on the > list - be sure we'll find you during the 9.x lifecycle in case you do > not properly handle things;-) > [ list of drivers part removed ] I guess you missed hme(4) and gem(4) in the list and most old hardwares that supports checksum offloading have no capability to handle IPv6 checksum offloading. If we do not define appropriate capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be hard to change code, I guess. From to.my.trociny at gmail.com Fri Jun 12 05:20:34 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Fri Jun 12 05:20:41 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 In-Reply-To: <20090605185647.GA76962@lath.rinet.ru> (Oleg Bulyzhin's message of "Fri\, 5 Jun 2009 22\:56\:47 +0400") References: <864ov9htgq.fsf@kopusha.onet> <81bpp8l6de.fsf@zhuzha.ua1> <20090603170311.GA18104@lath.rinet.ru> <20090604204720.GA49677@lath.rinet.ru> <81hbyuvl3z.fsf@zhuzha.ua1> <20090605185647.GA76962@lath.rinet.ru> Message-ID: <814oumni3m.fsf@zhuzha.ua1> On Fri, 5 Jun 2009 22:56:47 +0400 Oleg Bulyzhin wrote: > On Fri, Jun 05, 2009 at 04:57:52PM +0300, Mikolaj Golub wrote: > >> It works for me. With the patch I has not managed to crash the system using my >> test. Some notes: >> >> - only ng_ipfw/ng_car subsystem has been tested (not dummynet). >> - my -current box is under qemu (I don't have real server running -current to >> test this). >> >> If you are interesting in some testing of dummynet before commiting this to >> current, let me know. I could try some tests but only the next week. > > I did some testing of dummynet though extra testing would not hurt. I see the patch has been commited to 8-CURRENT :-). Thanks. I did some dummy tests on "fixed" current (simple dummynet configuration + traffic + ipfw reloaded every second) and did not have any issues. At present I don't have old -current without fix to reproduce the crash, but on 7-STABLE running this test I saw in dmesg many ipfw: ouch!, skip past end of rules, denying packet messages and one time crashed the system. So it looks like my testbase rather good and would have found problems with fixed current if they still had had. -- Mikolaj Golub From linimon at FreeBSD.org Fri Jun 12 05:46:52 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jun 12 05:47:04 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces Message-ID: <200906120546.n5C5kp0O059910@freefall.freebsd.org> Synopsis: [igb] low speed routing between two igb interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 12 05:46:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135222 From Anatoliy.Poloz at onetelecom.od.ua Fri Jun 12 06:15:21 2009 From: Anatoliy.Poloz at onetelecom.od.ua (Anatoliy.Poloz) Date: Fri Jun 12 06:15:28 2009 Subject: [ng_car] issue/whish/todo Message-ID: <4A31EE3C.80600@onetelecom.od.ua> Good day I would like ?? introduce You several issue. I would like to be able to when you call "_getstat_" to see the bytes, not only packets. This is for drawing graphs of node load. I would also like to be able to configure some "_car_nods_" after exit on output, without checking in ipfw, not depending on ip.fw.one_pass. Like per ng_car node one_pass. is it real? From mc at hack.org Fri Jun 12 06:42:25 2009 From: mc at hack.org (Michael Widerkrantz) Date: Fri Jun 12 06:42:42 2009 Subject: IPv6 Ideas References: <49F1128A.3080501@comcast.net> <49F1E2E7.5010703@lancaster.ac.uk> <49F2077D.2060701@comcast.net> Message-ID: <86hbym7y2m.fsf@brain.hack.org> Nathan Lay (2009-04-24 20:39 +0200): >> What are your problems with using radvd? I have used it quite a bit >> on FreeBSD (6.1) without any hassle. It's even written quite nicely >> in my experience so working on patches for it should be quite >> do-able if there are features missing. >> > radvd actually does support DNS advertisement (but rtsol doesn't, so > it doesn't matter). I'm sorry for the late response. I had over 500 unread messages in this mailing list. It's true that radvd supports the RDNSS option (RFC 5006). Just add something like this to your radvd.conf: interface whatever { # *snipp* RDNSS 2001:16d8:ffff:1::1 { }; }; I have written a client side implementation of RDNSS. It was developed under FreeBSD, but seems to work under Linux as well. Some early testing has been done under MacOS X as well. You can find it here: http://hack.org/mc/hacks/radns/ It doesn't support aging of the RDNSS data yet and you need some way to make it play well with a DHCP client if you're running dual stack, otherwise they will compete for /etc/resolv.conf. I'm hoping to be able to find the time to clean up radns, add aging and a script to work with dhclient. Shouldn't be too hard. I'm willing to patch FreeBSD's rtadvd to support RFC 5006 as well, if I can find the time. Cheers, MC. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome. From yongari at FreeBSD.org Fri Jun 12 07:34:25 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Fri Jun 12 07:34:31 2009 Subject: kern/135451: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] Message-ID: <200906120734.n5C7YO9O071409@freefall.freebsd.org> Synopsis: [fxp] no wol capability in fxp-driver for 82801-based chipset after upgrade to 7.2 [regression] State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Jun 12 07:32:18 UTC 2009 State-Changed-Why: Would you try the following patch and let me know how it goes? http://people.freebsd.org/~yongari/fxp/fxp.ich.patch Also show me the output of "ifconfig fxp0", I'd like to know whether the patch also adds Rx checksum offloading support to ICH based controllers. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Jun 12 07:32:18 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=135451 From freebsdusb at bindone.de Fri Jun 12 09:50:03 2009 From: freebsdusb at bindone.de (Michael) Date: Fri Jun 12 09:50:10 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces Message-ID: <200906120950.n5C9o3Y9065748@freefall.freebsd.org> The following reply was made to PR kern/135222; it has been noted by GNATS. From: Michael To: Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces Date: Fri, 12 Jun 2009 11:45:47 +0200 The original poster reported that the suggested fix works for him: --- Hello Michael, Thank you. It's working. I consider it necessary to put this into the release errata. Mishustin Andrew wrote: >> Number: 135222 >> Category: kern >> Synopsis: [igb] low speed routing between two igb interfaces >> Confidential: no >> Severity: serious >> Priority: medium >> Responsible: freebsd-bugs >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Wed Jun 03 18:30:01 UTC 2009 >> Closed-Date: >> Last-Modified: >> Originator: Mishustin Andrew >> Release: FreeBSD 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 >> Organization: > HNT >> Environment: > FreeBSD test.hnt 7.2-RELEASE FreeBSD 7.2-RELEASE #12: Thu Apr 30 18:28:15 MSD 20 > 09 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC amd64 >> Description: > I made a FreeBSD multiprocesor server to act as simple gateway. > It use onboard Intel 82575EB Dual-Port Gigabit Ethernet Controller. > I observe traffic speed near 400 Kbit/s. > I test both interfaces separately - > ftp client work at speed near 1 Gbit/s in both directions. > Then I change NIC to old Intel "em" NIC - gateway work at speed near 1 Gbit/s. > > Looks like a bug in igb driver have an effect upon forwarded traffic. > > If you try > hw.igb.enable_aim=0 > The speed is near 1 Mbit/s > > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" has no effect. > > Nothing in messages.log > > netstat -m > 516/1674/2190 mbufs in use (current/cache/total) > 515/927/1442/66560 mbuf clusters in use (current/cache/total/max) > 515/893 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/44/44/33280 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/16640 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/8320 16k jumbo clusters in use (current/cache/total/max) > 1159K/2448K/3607K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > I use only IPv4 traffic. > >> How-To-Repeat: > On machine with two igb interfaces > use rc.conf like this: > > hostname="test.test" > gateway_enable="YES" > ifconfig_igb0="inet 10.10.10.1/24" > ifconfig_igb1="inet 10.10.11.1/24" > > And try create heavy traffic between two networks. >> Fix: > > >> Release-Note: >> Audit-Trail: >> Unformatted: > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From bz at FreeBSD.org Fri Jun 12 11:00:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jun 12 11:00:19 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612013406.GB72855@michelle.cdnetworks.co.kr> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> Message-ID: <20090612100900.M22887@maildrop.int.zabbadoz.net> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: Hi, > Yeah, there are no checksum offloading support for IPv6 under > FreeBSD so there are no cases the frames are IPv6 when > CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). What I had missed was the CSUM_TSO6 (the 6 at the end) part. grepping through the tree I am even wondering a lot more now when I see what cxgb(4) is doing with that;) >> In case you are maintaining another driver but cannot find it on the >> list - be sure we'll find you during the 9.x lifecycle in case you do >> not properly handle things;-) >> > > [ list of drivers part removed ] > > I guess you missed hme(4) and gem(4) in the list and most old Nope, both have a hand crafted way of computing the cksums; not sure if that is good or bad; I guess the latter but with that they were not running into the INET dependency problematic I cared about in this pass. > hardwares that supports checksum offloading have no capability to > handle IPv6 checksum offloading. If we do not define appropriate > capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, > IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be > hard to change code, I guess. There is no such things as an IPv6 cksum. For IPv6 you only care about ULPs. I am not entirely sure (as in I forgot; it's been a month;) but Michael Tuexen (new comitter) is working on the proper flags im along with one for SCTP; The part I am usure about was if he only cared about CSUM first and not IFCAP but really both have to come along. What was the plan here? Michael, can you fill this gap (perhaps below)? To also address Drew's question: > As a sort of side-note, what about feature parity for INET6 for > existing IPV4 features like TSO? Who is working on that? Ok, maybe we should write down the big list now. What all can we have? What do we already have? What do we need? What needs to be changed? IPv4 CSUM offloading ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a different CSUM_* subset for each card, right? We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. What will that be? TSO v4/v6 We do have IFCAP_TSO4|IFCAP_TSO6 We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll need to add CSUM_TSO6? LRO v4/v6 (is anyone doing or planning to and can talk about it, LRO v6?) We do have IFCAP_LRO. TOE -- how much is that tied into IPv4/v6 and how much general infrastructure, rather than per-card, could a world need? We do have IFCAP_TOE = (IFCAP_TOE4|IFCAP_TOE6) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From gallatin at myri.com Fri Jun 12 14:23:33 2009 From: gallatin at myri.com (Andrew Gallatin) Date: Fri Jun 12 14:23:40 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> Message-ID: <4A3260BD.4040307@myri.com> Bjoern A. Zeeb wrote: >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I'm not sure what you mean by this. Right now, at least on the receive side, tcp_input() for IPv6 is completely ignoring ULP csum values sent up by drivers. > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? Cool! I had no idea that IFCAP_TSO6 was used, but apparently it is. When I get a chance to work on FreeBSD, I guess I'll flip that bit on in mxge and see if I actually get any packets with CSUM_TSO set. It would be helpful to have a CSUM_TSO{4,6} to reduce packet parsing. But as yongari pointed out, its fairly silly to make drivers parse the packets that the stack is sending them, and it would be ideal if we could easily pull the information from somewhere. > LRO v4/v6 (is anyone doing or planning to and can talk about it, LRO v6?) > We do have IFCAP_LRO. I can do it for mxge, and then Jack can port it to his version. I really need to look at finally making mxge use Jack's port of the mxge LRO. Drew From gallatin at cs.duke.edu Fri Jun 12 14:30:05 2009 From: gallatin at cs.duke.edu (Andrew Gallatin) Date: Fri Jun 12 14:30:11 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090611184555.J22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> Message-ID: <4A325883.3050206@cs.duke.edu> Bjoern A. Zeeb wrote: > if_mxge: > ---------------------------------------- > mxge_rx_csum() has one in_pseudo(). The function and callers > already seem to know how do deal with results in case the csum can't > be validated. So this should be a simple #ifdef INET wrapping here; > side note: the tcpudp_csum variables in the callers are not needed. > side note: huge inlining going on there;) > mxge_lro_flush() has another call to in_pseudo(). As with if_igb/ixgbe Thanks for pointing those out. It will be a few days before I've got time to deal with it properly. If you don't see me commit a fix within a week, please remind me. > if there is no INET there should be no LRO for now, the capabilities > not advertised, etc. Be prepared in case LRO will arrive for IPv6. As to LRO & IPV6... I was going to port our LRO for IPv6, but discovered the state of IPv6 in FreeBSD is so disgraceful that there was no point. Eg, there is no checksum offload, no TSO, etc, for INET6. Once those things are there, I'll be happy to provide LRO for IPv6. Drew From gallatin at cs.duke.edu Fri Jun 12 14:35:13 2009 From: gallatin at cs.duke.edu (Andrew Gallatin) Date: Fri Jun 12 14:35:19 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> Message-ID: <4A326797.10503@cs.duke.edu> (apologies if this is the second copy you get, I've been having email issues) Bjoern A. Zeeb wrote: >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I'm not sure what you mean by this. Right now, at least on the receive side, tcp_input() for IPv6 is completely ignoring ULP csum values sent up by drivers. > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? Cool! I had no idea that IFCAP_TSO6 was used, but apparently it is. When I get a chance to work on FreeBSD, I guess I'll flip that bit on in mxge and see if I actually get any packets with CSUM_TSO set. It would be helpful to have a CSUM_TSO{4,6} to reduce packet parsing. But as yongari pointed out, its fairly silly to make drivers parse the packets that the stack is sending them, and it would be ideal if we could easily pull the information from somewhere. > LRO v4/v6 (is anyone doing or planning to and can talk about it, LRO v6?) > We do have IFCAP_LRO. I can do it for mxge, and then Jack can port it to his version. I really need to look at finally making mxge use Jack's port of the mxge LRO. Drew From np at FreeBSD.org Fri Jun 12 17:07:03 2009 From: np at FreeBSD.org (Navdeep Parhar) Date: Fri Jun 12 17:07:10 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> Message-ID: <20090612170703.GA994@hub.freebsd.org> On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > > Hi, > > >Yeah, there are no checksum offloading support for IPv6 under > >FreeBSD so there are no cases the frames are IPv6 when > >CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > > The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > > What I had missed was the CSUM_TSO6 (the 6 at the end) part. > grepping through the tree I am even wondering a lot more now when I > see what cxgb(4) is doing with that;) I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? cxgb(4) will not let you enable IFCAP_TSO6 on the interface. It has always been disallowed as far as I can tell. Regards, Navdeep From jfvogel at gmail.com Fri Jun 12 17:26:59 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Jun 12 17:27:06 2009 Subject: Intel ESB2 problems and their solution Message-ID: <2a41acea0906121003n4e2c8a54k6ac41cc934c6d7d0@mail.gmail.com> I wanted to circulate a document from our technical marketing group that details a problem with the family of adapters called ES2LAN. These are most commonly seen as LOMs (on motherboard) in SuperMicro and other servers, the most common device ID is 0x1096 but also may be 0x1098, 0x10BA, or 0x10BB. They are a device driven by the 'em' driver. This document has some Windows symptoms that will be of no value here, but the problem does occur on FreeBSD, most often it is seen as a failure to load, due to a "Shared Code Initialization" failure. There is driver changes in 7.2 that address this problem, however the driver alone is only part of the complete solution, you MUST have firmware updates to resolve the problem, and this document provides pointers for particular systems. If you have a system that has seen this issue please obtain and apply the relevant firmware. I hope this helps resolve any of these issues customers are still seeing. Cheers everyone, Jack Vogel Intel Lan Access Division freebsd@intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ESB2_problems.pdf Type: application/pdf Size: 29539 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090612/21c541b5/ESB2_problems.pdf From bz at FreeBSD.org Fri Jun 12 17:40:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jun 12 17:40:18 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612170703.GA994@hub.freebsd.org> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> Message-ID: <20090612173728.B22887@maildrop.int.zabbadoz.net> On Fri, 12 Jun 2009, Navdeep Parhar wrote: > On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: >> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: >> >> Hi, >> >>> Yeah, there are no checksum offloading support for IPv6 under >>> FreeBSD so there are no cases the frames are IPv6 when >>> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. >> >> The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). >> >> What I had missed was the CSUM_TSO6 (the 6 at the end) part. >> grepping through the tree I am even wondering a lot more now when I >> see what cxgb(4) is doing with that;) > > I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? yes I did. > cxgb(4) > will not let you enable IFCAP_TSO6 on the interface. It has always > been disallowed as far as I can tell. Yes, you have it in the logic bu you define it to 0;) #define IFCAP_TSO6 0x0 /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Fri Jun 12 17:45:07 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jun 12 17:45:13 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <4A3260BD.4040307@myri.com> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <4A3260BD.4040307@myri.com> Message-ID: <20090612173855.T22887@maildrop.int.zabbadoz.net> On Fri, 12 Jun 2009, Andrew Gallatin wrote: > Bjoern A. Zeeb wrote: > >>> As a sort of side-note, what about feature parity for INET6 for >>> existing IPV4 features like TSO? Who is working on that? >> >> Ok, maybe we should write down the big list now. What all can we have? >> What do we already have? What do we need? What needs to be changed? >> >> IPv4 CSUM offloading >> ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 >> We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a >> different CSUM_* subset for each card, right? >> >> We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. >> What will that be? insert "need to" before "be" > I'm not sure what you mean by this. > > Right now, at least on the receive side, tcp_input() for IPv6 > is completely ignoring ULP csum values sent up by drivers. > > > >> TSO v4/v6 >> We do have IFCAP_TSO4|IFCAP_TSO6 >> >> We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll >> need to add CSUM_TSO6? > > Cool! I had no idea that IFCAP_TSO6 was used, but apparently it is. > When I get a chance to work on FreeBSD, I guess I'll flip that > bit on in mxge and see if I actually get any packets with CSUM_TSO > set. > > It would be helpful to have a CSUM_TSO{4,6} to reduce packet parsing. > But as yongari pointed out, its fairly silly to make drivers parse the > packets that the stack is sending them, and it would be ideal if > we could easily pull the information from somewhere. Yes, all for that; that's why we are talking about thing. Not sure what will make sense; perhaps we'll need to see what you all actually need for all the drivers and combinations? -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Fri Jun 12 17:50:07 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jun 12 17:50:20 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <4A325883.3050206@cs.duke.edu> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <4A325883.3050206@cs.duke.edu> Message-ID: <20090612174248.X22887@maildrop.int.zabbadoz.net> On Fri, 12 Jun 2009, Andrew Gallatin wrote: Hi, > Bjoern A. Zeeb wrote: > >> if_mxge: >> ---------------------------------------- >> mxge_rx_csum() has one in_pseudo(). The function and callers >> already seem to know how do deal with results in case the csum can't >> be validated. So this should be a simple #ifdef INET wrapping here; >> side note: the tcpudp_csum variables in the callers are not needed. >> side note: huge inlining going on there;) >> mxge_lro_flush() has another call to in_pseudo(). As with if_igb/ixgbe > > Thanks for pointing those out. It will be a few days before > I've got time to deal with it properly. If you don't see > me commit a fix within a week, please remind me. Well do not rush it; it's been like that for ages; we may first want to get infrastructure etc. in place to better fix all those maybe? It's just that it won't be forgotten in 3 months;-) >> if there is no INET there should be no LRO for now, the capabilities >> not advertised, etc. Be prepared in case LRO will arrive for IPv6. > > As to LRO & IPV6... I was going to port our LRO for IPv6, > but discovered the state of IPv6 in FreeBSD is so disgraceful > that there was no point. Eg, there is no checksum offload, > no TSO, etc, for INET6. Once those things are there, I'll > be happy to provide LRO for IPv6. With "port our LRO" you mean the driver parts? So how much does the FreeBSD infrastructure for LRO/v4 help and work for you (and the others)? Would adding v6 support there help? I will have to have a look but I can work on those things (propably post-RC1 or so). Till then a few other things still need my attention. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From gallatin at cs.duke.edu Fri Jun 12 17:43:53 2009 From: gallatin at cs.duke.edu (Andrew Gallatin) Date: Fri Jun 12 18:02:40 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612173728.B22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> Message-ID: <4A3293C8.5070101@cs.duke.edu> Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Navdeep Parhar wrote: > >> On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: >>> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: >>> >>> Hi, >>> >>>> Yeah, there are no checksum offloading support for IPv6 under >>>> FreeBSD so there are no cases the frames are IPv6 when >>>> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. >>> >>> The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). >>> >>> What I had missed was the CSUM_TSO6 (the 6 at the end) part. >>> grepping through the tree I am even wondering a lot more now when I >>> see what cxgb(4) is doing with that;) >> >> I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? > > yes I did. > >> cxgb(4) >> will not let you enable IFCAP_TSO6 on the interface. It has always >> been disallowed as far as I can tell. > > Yes, you have it in the logic bu you define it to 0;) > #define IFCAP_TSO6 0x0 So I guess TSO6 has never been tested at all on any interface on Freebsd. Is this true? Drew From gallatin at cs.duke.edu Fri Jun 12 18:19:43 2009 From: gallatin at cs.duke.edu (Andrew Gallatin) Date: Fri Jun 12 18:20:21 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612174248.X22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <4A325883.3050206@cs.duke.edu> <20090612174248.X22887@maildrop.int.zabbadoz.net> Message-ID: <4A329C38.2040808@cs.duke.edu> Bjoern A. Zeeb wrote: >>> if there is no INET there should be no LRO for now, the capabilities >>> not advertised, etc. Be prepared in case LRO will arrive for IPv6. >> >> As to LRO & IPV6... I was going to port our LRO for IPv6, >> but discovered the state of IPv6 in FreeBSD is so disgraceful >> that there was no point. Eg, there is no checksum offload, >> no TSO, etc, for INET6. Once those things are there, I'll >> be happy to provide LRO for IPv6. > > With "port our LRO" you mean the driver parts? So how much does the > FreeBSD infrastructure for LRO/v4 help and work for you (and the > others)? Would adding v6 support there help? For "port our LRO", I actually meant the LRO code itself, the IPv4 version of which was originally contributed by my employer (Myricom). Notice sys/netinet/tcp_lro.c is sys/dev/mxge/mxge_lro.c ported to be a bit more generic by Jack when he wanted LRO for ixgbe. The mxge LRO is shared among a few of our drivers for other OSes, and at least one has grown support for LRO for IPv6, so that should be trivial to port to FreeBSD. The thing I really need to do is convert mxge to use tcp_lro.c and remove mxge_lro.c. I've just been too busy. As to how much it helps.. I've seen some machines go from 3Gb/s to line rate (9.4Gb/s) for 1500b recieves. Drew From np at FreeBSD.org Fri Jun 12 18:24:05 2009 From: np at FreeBSD.org (Navdeep Parhar) Date: Fri Jun 12 18:24:13 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612173728.B22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> Message-ID: <20090612182404.GA20035@hub.freebsd.org> On Fri, Jun 12, 2009 at 05:38:46PM +0000, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Navdeep Parhar wrote: > > >On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: > >>On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > >> > >>Hi, > >> > >>>Yeah, there are no checksum offloading support for IPv6 under > >>>FreeBSD so there are no cases the frames are IPv6 when > >>>CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > >> > >>The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > >> > >>What I had missed was the CSUM_TSO6 (the 6 at the end) part. > >>grepping through the tree I am even wondering a lot more now when I > >>see what cxgb(4) is doing with that;) > > > >I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? > > yes I did. > > >cxgb(4) > >will not let you enable IFCAP_TSO6 on the interface. It has always > >been disallowed as far as I can tell. > > Yes, you have it in the logic bu you define it to 0;) > #define IFCAP_TSO6 0x0 Not quite. TSO_SUPPORTED is defined and so cxgb(4) picks up the right values of IFCAP_TSO4 and IFCAP_TSO6. It's just that IFCAP_TSO6 is not in the enabled-by-default capabilities (CXGB_CAP_ENABLE), and cxgb_ioctl will not let you enable IFCAP_TSO6. cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the way they are. If the stack's tso6 works, then this is a bug in cxgb. Regards, Navdeep > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Fri Jun 12 17:50:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jun 12 18:26:24 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <4A3293C8.5070101@cs.duke.edu> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> <4A3293C8.5070101@cs.duke.edu> Message-ID: <20090612174706.N22887@maildrop.int.zabbadoz.net> On Fri, 12 Jun 2009, Andrew Gallatin wrote: > Bjoern A. Zeeb wrote: >> On Fri, 12 Jun 2009, Navdeep Parhar wrote: >> >>> On Fri, Jun 12, 2009 at 10:56:31AM +0000, Bjoern A. Zeeb wrote: >>>> On Fri, 12 Jun 2009, Pyun YongHyeon wrote: >>>> >>>> Hi, >>>> >>>>> Yeah, there are no checksum offloading support for IPv6 under >>>>> FreeBSD so there are no cases the frames are IPv6 when >>>>> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. >>>> >>>> The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). >>>> >>>> What I had missed was the CSUM_TSO6 (the 6 at the end) part. >>>> grepping through the tree I am even wondering a lot more now when I >>>> see what cxgb(4) is doing with that;) >>> >>> I can't find a CSUM_TSO6 in head, did you mean IFCAP_TSO6? >> >> yes I did. >> >>> cxgb(4) >>> will not let you enable IFCAP_TSO6 on the interface. It has always >>> been disallowed as far as I can tell. >> >> Yes, you have it in the logic bu you define it to 0;) >> #define IFCAP_TSO6 0x0 > > So I guess TSO6 has never been tested at all on any interface on > Freebsd. Is this true? I wan't not sure; looking at em_tso_setup() in sys/dev/e1000/if_em.c, there was v6 code as well; the I spotted the return FALSE; So I guess, you are right; noone ever did TSO6 on FreeBSD probably. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Fri Jun 12 18:40:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Fri Jun 12 18:40:14 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612182404.GA20035@hub.freebsd.org> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> <20090612182404.GA20035@hub.freebsd.org> Message-ID: <20090612183349.B22887@maildrop.int.zabbadoz.net> On Fri, 12 Jun 2009, Navdeep Parhar wrote: Hi, >>> cxgb(4) >>> will not let you enable IFCAP_TSO6 on the interface. It has always >>> been disallowed as far as I can tell. >> >> Yes, you have it in the logic bu you define it to 0;) >> #define IFCAP_TSO6 0x0 > > Not quite. TSO_SUPPORTED is defined and so cxgb(4) picks up the > right values of IFCAP_TSO4 and IFCAP_TSO6. It's just that IFCAP_TSO6 > is not in the enabled-by-default capabilities (CXGB_CAP_ENABLE), and > cxgb_ioctl will not let you enable IFCAP_TSO6. > > cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the > way they are. If the stack's tso6 works, then this is a bug in > cxgb. Oki, I think once this all has settled we'll be able to text it on cxgb as well; let us get the infrastructure shaken out first. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From tedm at ipinc.net Fri Jun 12 20:10:03 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri Jun 12 20:10:10 2009 Subject: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Message-ID: <200906122010.n5CKA37i049629@freefall.freebsd.org> The following reply was made to PR kern/125195; it has been noted by GNATS. From: Ted Mittelstaedt To: bug-followup@FreeBSD.org, francisgendreau@videotron.ca Cc: Subject: Re: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Date: Fri, 12 Jun 2009 13:07:50 -0700 Some more followup - I moved my own problem fxp0 card to a FreeBSD 4.11-RELEASE system and it is detected fine, no "MII without any PHY" error message. The system that I was getting the "MII without any PHY" error message on was a FreeBSD 6.4 system. The problem fxp0 card is an Intel Etherexpress Pro/100, with a S82557 chip on it. Since it is a standalone PCI card and not embedded on the motherboard I can exchange it easily, - if anyone would like it for debugging I'd be happy to send them my card in the mail. To Francis, if possible could you download an older version of FreeBSD and check it on your hardware? You can find older versions here: ftp://ftp.cse.buffalo.edu/pub/FreeBSD-Archive/old-releases/i386/ISO-IMAGES/ The really old versions, ie: 4.11 and such, only have full-blown install ISO's and may also lack PCI IDs for your chip in which case the card wouldn't even be detected at all. But, the newer versions like 5.5 and so on do have boot-only ISO CD images which shouldn't be that bad. If an older driver version detects your card and attaches without the error message, we can assume this is a bug introduced by one of the patches to the driver, and it should be easy to zero in to the patch that is responsible. From tuexen at freebsd.org Fri Jun 12 21:16:02 2009 From: tuexen at freebsd.org (Michael Tuexen) Date: Fri Jun 12 21:16:34 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612100900.M22887@maildrop.int.zabbadoz.net> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> Message-ID: <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> On Jun 12, 2009, at 12:56 PM, Bjoern A. Zeeb wrote: > On Fri, 12 Jun 2009, Pyun YongHyeon wrote: > > Hi, > >> Yeah, there are no checksum offloading support for IPv6 under >> FreeBSD so there are no cases the frames are IPv6 when >> CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > > The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6(). > > What I had missed was the CSUM_TSO6 (the 6 at the end) part. > grepping through the tree I am even wondering a lot more now when I > see what cxgb(4) is doing with that;) > > >>> In case you are maintaining another driver but cannot find it on the >>> list - be sure we'll find you during the 9.x lifecycle in case you >>> do >>> not properly handle things;-) >>> >> >> [ list of drivers part removed ] >> >> I guess you missed hme(4) and gem(4) in the list and most old > > Nope, both have a hand crafted way of computing the cksums; not sure > if that is good or bad; I guess the latter but with that they were not > running into the INET dependency problematic I cared about in this > pass. > > >> hardwares that supports checksum offloading have no capability to >> handle IPv6 checksum offloading. If we do not define appropriate >> capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, >> IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be >> hard to change code, I guess. > > There is no such things as an IPv6 cksum. For IPv6 you only care about > ULPs. > > > I am not entirely sure (as in I forgot; it's been a month;) but > Michael Tuexen (new comitter) is working on the proper flags im along > with one for SCTP; The part I am usure about was if he only cared > about CSUM first and not IFCAP but really both have to come along. > > What was the plan here? Michael, can you fill this gap (perhaps > below)? Sure. See my comments below. > > > To also address Drew's question: > >> As a sort of side-note, what about feature parity for INET6 for >> existing IPV4 features like TSO? Who is working on that? > > Ok, maybe we should write down the big list now. What all can we have? > What do we already have? What do we need? What needs to be changed? > > IPv4 CSUM offloading > ULP (TCP|UDP|SCTP) CSUM offloading v4/v6 > We do have IFCAP_RXCSUM,IFCAP_TXCSUM but that means a > different CSUM_* subset for each card, right? Yes. Currently some driver would do CSUM_IP|CSUM_TCP|CSUM_UDP. The igb driver currently does CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP. > > We do have CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP. > What will that be? I think we should keep CSUM_IP, CSUM_TCP, CSUM_UDP, CSUM_SCTP which are for IPv4. In addition we need new flags CSUM_TCP6, CSUM_UDP6, CSUM_SCTP6 which are only for IPv6. After the change the igb driver would announce CSUM_IP|CSUM_TCP|CSUM_UDP|CSUM_SCTP|CSUM_TCP6|CSUM_UDP6|CSUM_SCTP6. The network layer and transport layer has to be changed accordingly. My plan is to provide the infrastructure and test it with the igb driver. After that is in the repository, other drivers have to be changed to announce their appropriate capabilities. I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 capabilities... Why would we want to enable IPv4 offloading and not IPv6 or vice versa? > > TSO v4/v6 > We do have IFCAP_TSO4|IFCAP_TSO6 > > We do have CSUM_TSO, so that should become CSUM_TSO4 and we'll > need to add CSUM_TSO6? > > LRO v4/v6 (is anyone doing or planning to and can talk about it, > LRO v6?) > We do have IFCAP_LRO. > > TOE -- how much is that tied into IPv4/v6 and how much general > infrastructure, rather than per-card, could a world need? > We do have IFCAP_TOE = (IFCAP_TOE4|IFCAP_TOE6) > > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking > one. > _______________________________________________ > 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 gallatin at cs.duke.edu Sat Jun 13 00:48:47 2009 From: gallatin at cs.duke.edu (Andrew Gallatin) Date: Sat Jun 13 00:48:54 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> Message-ID: <4A32F752.90003@cs.duke.edu> Michael Tuexen wrote: > I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > capabilities... Why would we want to enable IPv4 offloading and > not IPv6 or vice versa? I'd assume that some older hardware supports IPv4 offloads, but might not have support for IPv6 offloads. Drew From yongari at FreeBSD.org Sat Jun 13 01:11:59 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Sat Jun 13 01:12:05 2009 Subject: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Message-ID: <200906130111.n5D1BvOc089982@freefall.freebsd.org> Synopsis: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Jun 13 01:11:35 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=125195 From kip.macy at gmail.com Sat Jun 13 05:48:41 2009 From: kip.macy at gmail.com (Kip Macy) Date: Sat Jun 13 05:48:48 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090612182404.GA20035@hub.freebsd.org> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <20090612170703.GA994@hub.freebsd.org> <20090612173728.B22887@maildrop.int.zabbadoz.net> <20090612182404.GA20035@hub.freebsd.org> Message-ID: <3c1674c90906122248i253fd70t8330dd050279baa2@mail.gmail.com> > cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the > way they are. ?If the stack's tso6 works, then this is a bug in > cxgb. > It may not have supported it when the driver was ported - I know it didn't do v6 RSS. -Kip From tuexen at freebsd.org Sat Jun 13 07:15:09 2009 From: tuexen at freebsd.org (Michael Tuexen) Date: Sat Jun 13 07:15:17 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <4A32F752.90003@cs.duke.edu> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> Message-ID: On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: > Michael Tuexen wrote: > > > I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > > capabilities... Why would we want to enable IPv4 offloading and > > not IPv6 or vice versa? > > I'd assume that some older hardware supports IPv4 offloads, but > might not have support for IPv6 offloads. Sure. But then the driver only provides the CSUM_ flags which are appropriate. For example, a similar thing is already in the igb driver: 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); 1169 #if __FreeBSD_version >= 800000 1170 if (adapter->hw.mac.type == e1000_82576) 1171 ifp->if_hwassist |= CSUM_SCTP; 1172 #endif 1173 } For FreeBSD 8 and a particular chip, SCTP checksum offloading is supported. No need for a special IFCAP_TXCSUM. Best regards Michael > > Drew From pyunyh at gmail.com Sat Jun 13 07:58:42 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Jun 13 07:58:48 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> Message-ID: <20090613080136.GB76872@michelle.cdnetworks.co.kr> On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: > On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: > > >Michael Tuexen wrote: > > > >> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > >> capabilities... Why would we want to enable IPv4 offloading and > >> not IPv6 or vice versa? > > > >I'd assume that some older hardware supports IPv4 offloads, but > >might not have support for IPv6 offloads. > Sure. But then the driver only provides the CSUM_ flags which > are appropriate. For example, a similar thing is already in the > igb driver: > > 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { > 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); > 1169 #if __FreeBSD_version >= 800000 > 1170 if (adapter->hw.mac.type == e1000_82576) > 1171 ifp->if_hwassist |= CSUM_SCTP; > 1172 #endif > 1173 } That would disable all IPv4/IPv6 checksum offloading if administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ IFCAP_RXCSUM6 users could choose best working one even if some part of driver/controller had checksum offload bugs. > > For FreeBSD 8 and a particular chip, SCTP checksum offloading > is supported. No need for a special IFCAP_TXCSUM. > > Best regards > Michael > > > > >Drew > From jfvogel at gmail.com Sat Jun 13 08:25:22 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Sat Jun 13 08:25:28 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090613080136.GB76872@michelle.cdnetworks.co.kr> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> Message-ID: <2a41acea0906130125u4f6f6124l77e6115264ffb305@mail.gmail.com> I agree with Michael, I don't want to see this proliferation of capabilities, if you want checksum offload you get it whatever the IP type. Jack On Sat, Jun 13, 2009 at 1:01 AM, Pyun YongHyeon wrote: > On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: > > On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: > > > > >Michael Tuexen wrote: > > > > > >> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 > > >> capabilities... Why would we want to enable IPv4 offloading and > > >> not IPv6 or vice versa? > > > > > >I'd assume that some older hardware supports IPv4 offloads, but > > >might not have support for IPv6 offloads. > > Sure. But then the driver only provides the CSUM_ flags which > > are appropriate. For example, a similar thing is already in the > > igb driver: > > > > 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { > > 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); > > 1169 #if __FreeBSD_version >= 800000 > > 1170 if (adapter->hw.mac.type == e1000_82576) > > 1171 ifp->if_hwassist |= CSUM_SCTP; > > 1172 #endif > > 1173 } > > That would disable all IPv4/IPv6 checksum offloading if > administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ > IFCAP_RXCSUM6 users could choose best working one even if some part > of driver/controller had checksum offload bugs. > > > > > For FreeBSD 8 and a particular chip, SCTP checksum offloading > > is supported. No need for a special IFCAP_TXCSUM. > > > > Best regards > > Michael > > > > > > > >Drew > > > _______________________________________________ > 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 tuexen at freebsd.org Sat Jun 13 08:26:13 2009 From: tuexen at freebsd.org (Michael Tuexen) Date: Sat Jun 13 08:26:20 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <20090613080136.GB76872@michelle.cdnetworks.co.kr> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> Message-ID: <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> On Jun 13, 2009, at 10:01 AM, Pyun YongHyeon wrote: > On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: >> On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: >> >>> Michael Tuexen wrote: >>> >>>> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 >>>> capabilities... Why would we want to enable IPv4 offloading and >>>> not IPv6 or vice versa? >>> >>> I'd assume that some older hardware supports IPv4 offloads, but >>> might not have support for IPv6 offloads. >> Sure. But then the driver only provides the CSUM_ flags which >> are appropriate. For example, a similar thing is already in the >> igb driver: >> >> 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { >> 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); >> 1169 #if __FreeBSD_version >= 800000 >> 1170 if (adapter->hw.mac.type == e1000_82576) >> 1171 ifp->if_hwassist |= CSUM_SCTP; >> 1172 #endif >> 1173 } > > That would disable all IPv4/IPv6 checksum offloading if > administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ > IFCAP_RXCSUM6 users could choose best working one even if some part > of driver/controller had checksum offload bugs. Sure. That is what I wrote in my earlier mail: Do we want to provide a ability to disable/enable checksum offload for IPv4 and IPv6 individually... Besides this "working around bugs" I see no reason to do it. Some other capabilities TSO/TOE are IPv[46] specific. I have no strong opinion on this. What do others think? Best regards Michael > >> >> For FreeBSD 8 and a particular chip, SCTP checksum offloading >> is supported. No need for a special IFCAP_TXCSUM. >> >> Best regards >> Michael >> >>> >>> Drew >> From bz at FreeBSD.org Sat Jun 13 08:50:08 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Jun 13 08:50:15 2009 Subject: Ethernet NIC drivers depending unconditionally on INET In-Reply-To: <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> References: <20090611184555.J22887@maildrop.int.zabbadoz.net> <20090612013406.GB72855@michelle.cdnetworks.co.kr> <20090612100900.M22887@maildrop.int.zabbadoz.net> <71535CB2-2784-4253-B67E-017FEAD57637@freebsd.org> <4A32F752.90003@cs.duke.edu> <20090613080136.GB76872@michelle.cdnetworks.co.kr> <7472C82E-0C52-45AB-9BFF-DD6196B393C9@freebsd.org> Message-ID: <20090613084513.L22887@maildrop.int.zabbadoz.net> On Sat, 13 Jun 2009, Michael Tuexen wrote: > On Jun 13, 2009, at 10:01 AM, Pyun YongHyeon wrote: > >> On Sat, Jun 13, 2009 at 09:15:06AM +0200, Michael Tuexen wrote: >>> On Jun 13, 2009, at 2:48 AM, Andrew Gallatin wrote: >>> >>>> Michael Tuexen wrote: >>>> >>>>> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6 >>>>> capabilities... Why would we want to enable IPv4 offloading and >>>>> not IPv6 or vice versa? >>>> >>>> I'd assume that some older hardware supports IPv4 offloads, but >>>> might not have support for IPv6 offloads. >>> Sure. But then the driver only provides the CSUM_ flags which >>> are appropriate. For example, a similar thing is already in the >>> igb driver: >>> >>> 1167 if (ifp->if_capenable & IFCAP_TXCSUM) { >>> 1168 ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); >>> 1169 #if __FreeBSD_version >= 800000 >>> 1170 if (adapter->hw.mac.type == e1000_82576) >>> 1171 ifp->if_hwassist |= CSUM_SCTP; >>> 1172 #endif >>> 1173 } >> >> That would disable all IPv4/IPv6 checksum offloading if >> administrator disable IFCAP_TXCSUM. If we have IFCAP_TXCSUM6/ >> IFCAP_RXCSUM6 users could choose best working one even if some part >> of driver/controller had checksum offload bugs. > Sure. That is what I wrote in my earlier mail: Do we want to > provide a ability to disable/enable checksum offload for > IPv4 and IPv6 individually... > Besides this "working around bugs" I see no reason to do > it. Some other capabilities TSO/TOE are IPv[46] specific. > I have no strong opinion on this. What do others think? I think if there are bugs the driver would have to make sure to handle if_hwassist appropriately ; actually we are already doing this. Often it would be chip revision specific I guess so it doesn't really make sense to break it down to IPv4/v6. Either you turn it on and get what the driver thinks this chip can do or you don't get any. If there is a bug for a chip revision, enhance the driver to know to handle it correctly and be done. Actuallt that is exactly what you sample above is doing - enabling CSUM_SCTP only for a specific chip. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From louie at transsys.com Sat Jun 13 17:41:22 2009 From: louie at transsys.com (Louis Mamakos) Date: Sat Jun 13 17:41:29 2009 Subject: TCP Free-BSD setup behaviour. In-Reply-To: <28959.63465.qm@web8313.mail.in.yahoo.com> References: <28959.63465.qm@web8313.mail.in.yahoo.com> Message-ID: <865C7FF6-F9DD-4684-8AF3-204941032330@transsys.com> On Jun 10, 2009, at 9:47 AM, saravana perumal wrote: > Hi , > > Have some behaviour change with FREEBSD compared to LINUX . You probably ought to verify the behavior against the protocol specifications, and not what some other TCP implementation happens to to. > > 1. When sending the Same TCP packet once again [ Retranmission of > TCP packet ] Whether the Same Identification field [ IP packet]used > or not . > but when seeing that thru packet capture, Free BSD sending the > differnt one [ increases sequentially IP Identification] The IPID header field is used for reassembly of IP fragments, and is not of consequence to TCP. If the protocol stack absolutely knows that a TCP retransmission is identical to the previous segment, then in theory, it could use the same IPID fields to increase the chance that a previously fragmented TCP segment with a lost segment could get reassembled with fragments from the retransmission. Since there's much work done to avoid fragmentation in the first place (e.g., using Path MTU discovery), this "feature" probably never gets used. This behavior makes more sense if the TCP implementation keeps around a retransmit queue of previously sent packets, rather than simply generating new TCP segments with whatever data happens to be in the TCP send window at the time of the retransmission attempt. > > 2.Retranmission Time is not increasing Linearly with Respect to BSD. > not keeping more time interval . AS per RFC > expecting Retransmission timeout should increase Linearly. Issue is > not seen with Linux Setup Retransmission time is highly dependent on many factors, like the implementation of TCP slow-start, what the TCP stack has estimated as the round-trip time, etc. In the general case, over the span of many retransmissions, the sending TCP stack should back-off the retransmit times. > > 3. Active SYN open state in FREE BSD setup , Does not reach Syn- > received State. When Sending syn packet to DUT but for that FreeBSD > is not sending back > SYN/ACK . Issue is with Free BSD Setup.Linux works fine, If the FreeBSD system is doing a TCP active open (e.g., a connect() system call), then it sends a SYN to the remote TCP, and expects a SYN/ ACK back from the remote system. At that point, since the remote has ACK'd the SYN, it should correctly respond with simply an ACK of the remote TCP's SYN, and perhaps any data that might have been piggybacked in the ACK segment. There's no need to retransmit the SYN. Or is the remote system doing the active open to the FreeBSD system? It's hard to believe that the FreeBSD TCP can't respond to an incoming TCP segment to a listening socket carrying a SYN segment? > > 4.When checking the State - TIME-WAIT > Sending FIN and expecting the ACK ;Getting the ACK properly. > Sending Data Segment and Expecting the RST signal not getting the > RST ; Instead DUT is sending the Last TCP packet. > > Issue seen only in Free BSD. I may be misunderstanding. When in TIME-WAIT state, the local TCP is waiting for a bit in case the "final" ACK of the remote TCP's FIN got lost, and the remote retransmits the FIN (and perhaps any data that might have been in the window along with the FIN). The local TCP shouldn't generate a RST assuming that the remote's retransmitted TCP segment is still within the window. I'm not sure what's in the "Last TCP packet." > > Same issue in FIN-WAIT2 & FIN-WAIT1 State also . > Sending FIN and Expect the ACK : Getting the ACK > Sending Data segment with Data : Expecting the RST signal from > DUT ; but got Last transmitted TCP packet[ FIN -ACK] > Ditto. > Any idea about the above scenario would be helpful > > Thanks, > Saravanan. The TCP in Linux is hardly the reference implementation; with the TCP stack in various 4.xBSD varients preceeding it by many years, not to mention many others implementations in other platforms. I'm not sure looking for variances between some random Linux TCP stack is really the right way to approach testing. louie From stef-list at memberwebs.com Sun Jun 14 04:28:51 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Sun Jun 14 04:28:58 2009 Subject: 32 bit compatibility for getifaddrs() Message-ID: <20090614035859.A057517056D@mx.npubs.com> I've started running 64-bit FreeBSD (version 7.2) in production. I have a lot of old 6.3 32-bit jails I need to run as is for now. One problem I ran into is 32-bit getifaddrs() would crash accessing a 64-bit kernel via the sysctl NET_RT_IFLIST method. Attached is a patch that adds 32-bit compatibility to the rtsock.c route messages. Who would I work with to get this (or something like it) committed? Cheers, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: getifaddrs-rtsock-compat32.patch Type: text/x-diff Size: 8994 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090614/6dd763ca/getifaddrs-rtsock-compat32.bin From marco.borsatino at poste.it Sun Jun 14 08:50:22 2009 From: marco.borsatino at poste.it (marco.borsatino@poste.it) Date: Sun Jun 14 08:50:30 2009 Subject: NFS - exports syntax Message-ID: Hi to all. My problem concerns NFS configuration. I'm trying to simulate a little network using Sun VirtualBox in a Windows host and most of operations work fine, but I've some problems with /etc/exports syntax. This is my current exports file: -- /cond1 /cond2 -mapall=user1 pc01 pc02 /usr/home -alldirs pc01 pc02 --- When I type: #showmount -e I get /usr/home??? ???? pc02 pc02 /cond1??? ??? ??? pc01 pc02 /cond2??? ??? ??? pc01 pc02 which is ok. But I wold like to use different "mapall" options for different filesystems; for example, something like this: /usr/home -alldirs??? ??? pc02 pc02 /cond1 -mapall=user2 /cond2 -mapall=user1 pc01 pc02 which does not work: only /usr/home is exported. Or /usr/home??? ??? pc02 pc02 /cond1 -mapall=user2 pc01 pc02 /cond2 -mapall=user1 pc01 pc02 Only /usr/home and /cond1 are exported. FreeBSD exports man page states: "Each line in the file (other than comment lines that begin with a #) specifies the mount point(s) and export flags within one local server file system for one or more hosts.". So, is it impossible to export different directories to different users using mapping? Thanks. Sorry for my bad english. Marco From brian at Awfulhak.org Sun Jun 14 18:20:35 2009 From: brian at Awfulhak.org (Brian Somers) Date: Sun Jun 14 18:20:42 2009 Subject: NFS - exports syntax In-Reply-To: References: Message-ID: <20090614105223.4f859708@dev.lan.Awfulhak.org> On Sun, 14 Jun 2009 10:29:21 +0200 "marco\.borsatino\@poste\.it" wrote: > Hi to all. > My problem concerns NFS configuration. I'm trying to simulate a little network using Sun VirtualBox in a Windows host and most of operations work fine, but I've some problems with /etc/exports syntax. > This is my current exports file: > -- > /cond1 /cond2 -mapall=user1 pc01 pc02 > /usr/home -alldirs pc01 pc02 > --- > When I type: > #showmount -e > I get > /usr/home??? ???? pc02 pc02 > /cond1??? ??? ??? pc01 pc02 > /cond2??? ??? ??? pc01 pc02 > which is ok. But I wold like to use different "mapall" options for different filesystems; for example, something like this: > /usr/home -alldirs??? ??? pc02 pc02 > /cond1 -mapall=user2 /cond2 -mapall=user1 pc01 pc02 > which does not work: only /usr/home is exported. Or > /usr/home??? ??? pc02 pc02 > /cond1 -mapall=user2 pc01 pc02 > /cond2 -mapall=user1 pc01 pc02 > Only /usr/home and /cond1 are exported. > FreeBSD exports man page states: > "Each line in the file (other than comment lines that begin with a #) specifies the mount point(s) and export flags within one local server file system for one or more hosts.". So, is it impossible to export different directories to different users using mapping? > Thanks. Sorry for my bad english. > Marco FreeBSD's exports implementation will only allow you to associate mount options per local filesystem per remote machine, so this version: > /usr/home??? ??? pc02 pc02 > /cond1 -mapall=user2 pc01 pc02 > /cond2 -mapall=user1 pc01 pc02 is correct, but only if /cond1 and /cond2 are different filesystems. If they're the same, this won't work. Maybe you do something clever with exporting nullfs versions of them and adding those to exports, but I haven't tried that. -- Brian Somers Don't _EVER_ lose your sense of humour ! From seesaravanan at yahoo.co.in Mon Jun 15 07:44:17 2009 From: seesaravanan at yahoo.co.in (saravana perumal) Date: Mon Jun 15 07:44:24 2009 Subject: TCP Free-BSD setup behaviour. Message-ID: <882612.80583.qm@web8320.mail.in.yahoo.com> Hi Louie , ? ? Thanks for the Response on my Queries. ? For QUERY 3, ACTIVE open frm Free BSD end: ? ?????? FREE BSD????????? APPLICATION ??????????????? Send ---------> syn ??????????????? Receive <-------- SYN ? Expect SYN & ACK-------------> Getting only ACK in this Scenario, ?Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. 4??? .When checking the State - TIME-WAIT????Sending FIN and expecting the ACK ;Getting the ACK properly.???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet.?Issue seen only in Free BSD ? ? For this Issue mentioned above, Last TCP packet is jst a Testing packet with the following Field set? in TIME-WAIT state , ? ? TCP: ---- TCP Packet ---- TCP: TCP: Source Port?????????? = 16815 (16815) TCP: Destination Port????? = 16816 (16816) TCP: Sequence Number?????? = 3865716731 (0xE66A27FB) TCP: Acknowledgment Number = 0 (0x00000000) TCP: Data Offset?????????? = 5 (20 bytes) TCP: Reserved????????????? = 0 TCP: Control Bits????????? = 0x10 TCP:? |543210 TCP:? |0.....????????????? = Urgent Pointer Isn't Significant TCP:? |.1....????????????? = Acknowledgment Is Significant TCP:? |..0...????????????? = No Push Function TCP:? |...0..????????????? = No Reset Connection TCP:? |....0.????????????? = No Synchronize Sequence Numbers TCP:? |.....0????????????? = More Data From Sender TCP: Window??????????????? = 32752 bytes TCP: Checksum????????????? = 0x41A0 (Correct) TCP: Urgent Pointer??????? = 0 (Not Significant) TCP: TCP: --- Trailing Data [12 bytes] --- TCP:? 53 61 6D 70 6C 65 20 44 61 74 61 00?????????????? Sample Data. TCP: --- Trailing Data End --- >From machine Sending? to the FREE BSD machine, ? This is to verify that Free BSD is in TIME-WAIT state. ? ? Thanks, Saravanan --- On Sat, 6/13/09, Louis Mamakos wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Saturday, June 13, 2009, 10:54 PM On Jun 10, 2009, at 9:47 AM, saravana perumal wrote: >? Hi , > >???Have some behaviour change? with FREEBSD? compared to? LINUX . You probably ought to verify the behavior against the protocol specifications, and not what some other TCP implementation happens to to. > > 1. When sending the Same? TCP packet once again [ Retranmission of TCP packet ] Whether the Same Identification field [ IP packet]used or not . > but when seeing that thru packet capture, Free BSD sending the differnt one [ increases sequentially IP Identification] The IPID header field is used for reassembly of IP fragments, and is not of consequence to TCP.? If the protocol stack absolutely knows that a TCP retransmission is identical to the previous segment, then in theory, it could use the same IPID fields to increase the chance that a previously fragmented TCP segment with a lost segment could get reassembled with fragments from the retransmission.? Since there's much work done to avoid fragmentation in the first place (e.g., using Path MTU discovery), this "feature" probably never gets used. This behavior makes more sense if the TCP implementation keeps around a retransmit queue of previously sent packets, rather than simply generating new TCP segments with whatever data happens to be in the TCP send window at the time of the retransmission attempt. > > 2.Retranmission Time is not increasing Linearly with Respect to BSD. not keeping more time interval . AS per RFC > expecting Retransmission timeout should? increase Linearly. Issue is not seen with Linux Setup Retransmission time is highly dependent on many factors, like the implementation of TCP slow-start, what the TCP stack has estimated as the round-trip time, etc.? In the general case, over the span of many retransmissions, the sending TCP stack should back-off the retransmit times. > > 3. Active SYN open state in FREE BSD setup , Does not reach Syn-received State. When Sending syn packet to DUT but? for that FreeBSD is not sending back > SYN/ACK .? Issue is with Free BSD Setup.Linux works fine, If the FreeBSD system is doing a TCP active open (e.g., a connect() system call), then it sends a SYN to the remote TCP, and expects a SYN/ACK back from the remote system.? At that point, since the remote has ACK'd the SYN, it should correctly respond with simply an ACK of the remote TCP's SYN, and perhaps any data that might have been piggybacked in the ACK segment.? There's no need to retransmit the SYN. Or is the remote system doing the active open to the FreeBSD system?? It's hard to believe that the FreeBSD TCP can't respond to an incoming TCP segment to a listening socket carrying a SYN segment? > > 4.When checking the State - TIME-WAIT >???Sending FIN and expecting the ACK ;Getting the ACK properly. >???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. > > Issue seen only in Free BSD. I may be misunderstanding.? When in TIME-WAIT state, the local TCP is waiting for a bit in case the "final" ACK of the remote TCP's FIN got lost, and the remote retransmits the FIN (and perhaps any data that might have been in the window along with the FIN).? The local TCP shouldn't generate a RST assuming that the remote's retransmitted TCP segment is still within the window.? I'm not sure what's in the "Last TCP packet." > > Same issue in FIN-WAIT2? & FIN-WAIT1 State also . >???Sending FIN and Expect the ACK : Getting the ACK >???Sending Data segment with Data : Expecting the RST signal from DUT ; but got Last transmitted TCP packet[ FIN -ACK] > Ditto. > Any idea about the above scenario would be helpful > > Thanks, > Saravanan. The TCP in Linux is hardly the reference implementation; with the TCP stack in various 4.xBSD varients preceeding it by many years, not to mention many others implementations in other platforms.? I'm not sure looking for variances between some random Linux TCP stack is really the right way to approach testing. louie From bugmaster at FreeBSD.org Mon Jun 15 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 15 11:09:03 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200906151106.n5FB6xjf077012@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/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/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp 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 o kern/132984 net [netgraph] swi1: net 100% cpu usage 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/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/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 kern/121983 net [fxp] fxp0 MBUF and PAE 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/114839 net [fxp] fxp looses ability to speak with traffic 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 o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/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 307 problems total. From marco.borsatino at poste.it Mon Jun 15 16:46:39 2009 From: marco.borsatino at poste.it (marco.borsatino@poste.it) Date: Mon Jun 15 16:46:46 2009 Subject: NFS - exports syntax Message-ID: First, thank you for your help. > > FreeBSD's exports implementation will only allow you to associate > mount options per local filesystem per remote machine, so this > version: > > > /usr/home??? ??? pc02 pc02 > > /cond1 -mapall=user2 pc01 pc02 > > /cond2 -mapall=user1 pc01 pc02 > > is correct, but only if /cond1 and /cond2 are different filesystems. > If they're the same, this won't work. > /cond1 and /cond2 are folders under root on /dev/ad0s1a; this is the reason whi my exports does not work. So should I do something like this: #mkdir /usr/shared/cond1 #mkdir /usr/shared/cond2 (this is, I think, a better choice also from different points of view). (exports) /usr/shared -alldirs pc01 pc02 (or -network 192.168.0) (mount for different users) #mount _nfs server:/usr/shared/cond1 /mnt/for-user-1 #mount _nfs server:/usr/shared/cond2 /mnt/for-user-2 But, if this sintax is correct, how can I use mapall option? ? > Maybe you do something clever with exporting nullfs versions > of them and adding those to exports, but I haven't tried that. > This will be the next step. Thank you. Marco From louie at transsys.com Mon Jun 15 21:36:02 2009 From: louie at transsys.com (Louis Mamakos) Date: Mon Jun 15 21:36:08 2009 Subject: TCP Free-BSD setup behaviour. In-Reply-To: <882612.80583.qm@web8320.mail.in.yahoo.com> References: <882612.80583.qm@web8320.mail.in.yahoo.com> Message-ID: On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > Hi Louie , > > > Thanks for the Response on my Queries. > > For QUERY 3, > ACTIVE open frm Free BSD end: > > FREE BSD APPLICATION > Send ---------> syn > Receive <-------- SYN > > Expect SYN & ACK-------------> Getting only ACK in this Scenario, > > Now Expects FREE BSD to respond back with the SYN & ACK , but BSD > is sending only ACK message as the response. There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN. Once the SYN has been ACK'd, there's no reason to resend it. I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? > 4 .When checking the State - TIME-WAIT Sending FIN and > expecting the ACK ;Getting the ACK properly. Sending Data Segment > and Expecting the RST signal not getting the RST ; Instead DUT is > sending the Last TCP packet. Issue seen only in Free BSD > > > For this Issue mentioned above, Last TCP packet is jst a Testing > packet with the > following Field set in TIME-WAIT state , > > > TCP: ---- TCP Packet ---- > TCP: > TCP: Source Port = 16815 (16815) > TCP: Destination Port = 16816 (16816) > TCP: Sequence Number = 3865716731 (0xE66A27FB) > TCP: Acknowledgment Number = 0 (0x00000000) > TCP: Data Offset = 5 (20 bytes) > TCP: Reserved = 0 > TCP: Control Bits = 0x10 > TCP: |543210 > TCP: |0..... = Urgent Pointer Isn't Significant > TCP: |.1.... = Acknowledgment Is Significant > TCP: |..0... = No Push Function > TCP: |...0.. = No Reset Connection > TCP: |....0. = No Synchronize Sequence Numbers > TCP: |.....0 = More Data From Sender > TCP: Window = 32752 bytes > TCP: Checksum = 0x41A0 (Correct) > TCP: Urgent Pointer = 0 (Not Significant) > TCP: > TCP: --- Trailing Data [12 bytes] --- > TCP: 53 61 6D 70 6C 65 20 44 61 74 61 00 Sample Data. > TCP: --- Trailing Data End --- > From machine Sending to the FREE BSD machine, > > This is to verify that Free BSD is in TIME-WAIT state. Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus. Perhaps that the send sequence is outside the window. If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? louie From seesaravanan at yahoo.co.in Tue Jun 16 09:45:49 2009 From: seesaravanan at yahoo.co.in (saravana perumal) Date: Tue Jun 16 09:45:55 2009 Subject: TCP Free-BSD setup behaviour. Message-ID: <690988.68233.qm@web8320.mail.in.yahoo.com> Hi Louie ? ?We are trying to make Active Sync Received state. ? As per our testing we are trying to received Syn packet from APPLICATION end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-RECEIVED state. ? So initially make the application to send SYN sending the Initial SYN and once Received the SYN packet , expecting the Device to Send SYN & ACK ? I hope the expectation should be rite in case of ACTIVE-SYN received State. ? Thanks. Saravanan ? --- On Tue, 6/16/09, Louis Mamakos wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Tuesday, June 16, 2009, 3:05 AM On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > Hi Louie , > > > Thanks for the Response on my Queries. > > For QUERY 3, > ACTIVE open frm Free BSD end: > >? ? ? ? FREE BSD? ? ? ? ? APPLICATION >? ? ? ? ? ? ? ???Send ---------> syn >? ? ? ? ? ? ? ???Receive <-------- SYN > > Expect SYN & ACK-------------> Getting only ACK in this Scenario, > >? Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN.? Once the SYN has been ACK'd, there's no reason to resend it.? I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? > 4? ? .When checking the State - TIME-WAIT? ? Sending FIN and expecting the ACK ;Getting the ACK properly.???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. Issue seen only in Free BSD > > > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the > following Field set? in TIME-WAIT state , > > > TCP: ---- TCP Packet ---- > TCP: > TCP: Source Port? ? ? ? ???= 16815 (16815) > TCP: Destination Port? ? ? = 16816 (16816) > TCP: Sequence Number? ? ???= 3865716731 (0xE66A27FB) > TCP: Acknowledgment Number = 0 (0x00000000) > TCP: Data Offset? ? ? ? ???= 5 (20 bytes) > TCP: Reserved? ? ? ? ? ? ? = 0 > TCP: Control Bits? ? ? ? ? = 0x10 > TCP:? |543210 > TCP:? |0.....? ? ? ? ? ? ? = Urgent Pointer Isn't Significant > TCP:? |.1....? ? ? ? ? ? ? = Acknowledgment Is Significant > TCP:? |..0...? ? ? ? ? ? ? = No Push Function > TCP:? |...0..? ? ? ? ? ? ? = No Reset Connection > TCP:? |....0.? ? ? ? ? ? ? = No Synchronize Sequence Numbers > TCP:? |.....0? ? ? ? ? ? ? = More Data From Sender > TCP: Window? ? ? ? ? ? ? ? = 32752 bytes > TCP: Checksum? ? ? ? ? ? ? = 0x41A0 (Correct) > TCP: Urgent Pointer? ? ? ? = 0 (Not Significant) > TCP: > TCP: --- Trailing Data [12 bytes] --- > TCP:? 53 61 6D 70 6C 65 20 44 61 74 61 00? ? ? ? ? ? ???Sample Data. > TCP: --- Trailing Data End --- > From machine Sending? to the FREE BSD machine, > > This is to verify that Free BSD is in TIME-WAIT state. Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus.? Perhaps that the send sequence is outside the window.? If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? louie From seesaravanan at yahoo.co.in Tue Jun 16 11:07:37 2009 From: seesaravanan at yahoo.co.in (saravana perumal) Date: Tue Jun 16 11:07:45 2009 Subject: TCP Free-BSD setup behaviour. Message-ID: <925929.71164.qm@web8315.mail.in.yahoo.com> Hi? Louie. ? As per Testing ? 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] 2. Then Expects to RECEIVE SYN packet and 3. To Send SYN & ACK? to reach? SYN-RCVD state. ? In Free BSD active SYN-RCVD state is not happening . ? In TCP state tranistion my expectation is represented for SYN_RCVD state. ? ? Thanks. Saravanan --- On Tue, 6/16/09, saravana perumal wrote: From: saravana perumal Subject: Re: TCP Free-BSD setup behaviour. To: "Louis Mamakos" Cc: "FreeBSD Mailer List" Date: Tuesday, June 16, 2009, 3:15 PM Hi Louie ? ?We are trying to make Active Sync Received state. ? As per our testing we are trying to received Syn packet from APPLICATION end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-RECEIVED state. ? So initially make the application to send SYN sending the Initial SYN and once Received the SYN packet , expecting the Device to Send SYN & ACK ? I hope the expectation should be rite in case of ACTIVE-SYN received State. ? Thanks. Saravanan ? --- On Tue, 6/16/09, Louis Mamakos wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Tuesday, June 16, 2009, 3:05 AM On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > Hi Louie , > > > Thanks for the Response on my Queries. > > For QUERY 3, > ACTIVE open frm Free BSD end: > >? ? ? ? FREE BSD? ? ? ? ? APPLICATION >? ? ? ? ? ? ? ???Send ---------> syn >? ? ? ? ? ? ? ???Receive <-------- SYN > > Expect SYN & ACK-------------> Getting only ACK in this Scenario, > >? Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN.? Once the SYN has been ACK'd, there's no reason to resend it.? I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? > 4? ? .When checking the State - TIME-WAIT? ? Sending FIN and expecting the ACK ;Getting the ACK properly.???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. Issue seen only in Free BSD > > > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the > following Field set? in TIME-WAIT state , > > > TCP: ---- TCP Packet ---- > TCP: > TCP: Source Port? ? ? ? ???= 16815 (16815) > TCP: Destination Port? ? ? = 16816 (16816) > TCP: Sequence Number? ? ???= 3865716731 (0xE66A27FB) > TCP: Acknowledgment Number = 0 (0x00000000) > TCP: Data Offset? ? ? ? ???= 5 (20 bytes) > TCP: Reserved? ? ? ? ? ? ? = 0 > TCP: Control Bits? ? ? ? ? = 0x10 > TCP:? |543210 > TCP:? |0.....? ? ? ? ? ? ? = Urgent Pointer Isn't Significant > TCP:? |.1....? ? ? ? ? ? ? = Acknowledgment Is Significant > TCP:? |..0...? ? ? ? ? ? ? = No Push Function > TCP:? |...0..? ? ? ? ? ? ? = No Reset Connection > TCP:? |....0.? ? ? ? ? ? ? = No Synchronize Sequence Numbers > TCP:? |.....0? ? ? ? ? ? ? = More Data From Sender > TCP: Window? ? ? ? ? ? ? ? = 32752 bytes > TCP: Checksum? ? ? ? ? ? ? = 0x41A0 (Correct) > TCP: Urgent Pointer? ? ? ? = 0 (Not Significant) > TCP: > TCP: --- Trailing Data [12 bytes] --- > TCP:? 53 61 6D 70 6C 65 20 44 61 74 61 00? ? ? ? ? ? ???Sample Data. > TCP: --- Trailing Data End --- > From machine Sending? to the FREE BSD machine, > > This is to verify that Free BSD is in TIME-WAIT state. Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus.? Perhaps that the send sequence is outside the window.? If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? louie From ertr1013 at student.uu.se Tue Jun 16 11:52:33 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Tue Jun 16 11:52:40 2009 Subject: TCP Free-BSD setup behaviour. In-Reply-To: <925929.71164.qm@web8315.mail.in.yahoo.com> References: <925929.71164.qm@web8315.mail.in.yahoo.com> Message-ID: <20090616113659.GA99604@owl.midgard.homeip.net> On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: > Hi? Louie. > ? > As per Testing > ? > 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] > 2. Then Expects to RECEIVE SYN packet and > 3. To Send SYN & ACK? to reach? SYN-RCVD state. That does not sound quite correct. The normal sequence for the TCP three-way handshake is: -----> SYN <----- SYN+ACK -----> ACK while you for some reason seem to be expecting -----> SYN <----- SYN -----> SYN+ACK which is not what I would expect. > ? > In Free BSD active SYN-RCVD state is not happening . > ? > In TCP state tranistion my expectation is represented for SYN_RCVD state. > ? > ? > Thanks. > Saravanan > > > --- On Tue, 6/16/09, saravana perumal wrote: > > > From: saravana perumal > Subject: Re: TCP Free-BSD setup behaviour. > To: "Louis Mamakos" > Cc: "FreeBSD Mailer List" > Date: Tuesday, June 16, 2009, 3:15 PM > > > > > > > > Hi Louie > ? > ?We are trying to make Active Sync Received state. > ? > As per our testing we are trying to received Syn packet from APPLICATION end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-RECEIVED state. > ? > So initially make the application to send SYN sending the Initial SYN and once Received the SYN packet , expecting the Device to Send SYN & ACK > ? > I hope the expectation should be rite in case of ACTIVE-SYN received State. > ? > Thanks. > Saravanan > ? > > > --- On Tue, 6/16/09, Louis Mamakos wrote: > > > From: Louis Mamakos > Subject: Re: TCP Free-BSD setup behaviour. > To: "saravana perumal" > Cc: freebsd-net@freebsd.org, sarbalas@gmail.com > Date: Tuesday, June 16, 2009, 3:05 AM > > > > On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > > > Hi Louie , > > > > > > Thanks for the Response on my Queries. > > > > For QUERY 3, > > ACTIVE open frm Free BSD end: > > > >? ? ? ? FREE BSD? ? ? ? ? APPLICATION > >? ? ? ? ? ? ? ???Send ---------> syn > >? ? ? ? ? ? ? ???Receive <-------- SYN > > > > Expect SYN & ACK-------------> Getting only ACK in this Scenario, > > > >? Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. > > There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN.? Once the SYN has been ACK'd, there's no reason to resend it.? I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? > > > 4? ? .When checking the State - TIME-WAIT? ? Sending FIN and expecting the ACK ;Getting the ACK properly.???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. Issue seen only in Free BSD > > > > > > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the > > following Field set? in TIME-WAIT state , > > > > > > TCP: ---- TCP Packet ---- > > TCP: > > TCP: Source Port? ? ? ? ???= 16815 (16815) > > TCP: Destination Port? ? ? = 16816 (16816) > > TCP: Sequence Number? ? ???= 3865716731 (0xE66A27FB) > > TCP: Acknowledgment Number = 0 (0x00000000) > > TCP: Data Offset? ? ? ? ???= 5 (20 bytes) > > TCP: Reserved? ? ? ? ? ? ? = 0 > > TCP: Control Bits? ? ? ? ? = 0x10 > > TCP:? |543210 > > TCP:? |0.....? ? ? ? ? ? ? = Urgent Pointer Isn't Significant > > TCP:? |.1....? ? ? ? ? ? ? = Acknowledgment Is Significant > > TCP:? |..0...? ? ? ? ? ? ? = No Push Function > > TCP:? |...0..? ? ? ? ? ? ? = No Reset Connection > > TCP:? |....0.? ? ? ? ? ? ? = No Synchronize Sequence Numbers > > TCP:? |.....0? ? ? ? ? ? ? = More Data From Sender > > TCP: Window? ? ? ? ? ? ? ? = 32752 bytes > > TCP: Checksum? ? ? ? ? ? ? = 0x41A0 (Correct) > > TCP: Urgent Pointer? ? ? ? = 0 (Not Significant) > > TCP: > > TCP: --- Trailing Data [12 bytes] --- > > TCP:? 53 61 6D 70 6C 65 20 44 61 74 61 00? ? ? ? ? ? ???Sample Data. > > TCP: --- Trailing Data End --- > > From machine Sending? to the FREE BSD machine, > > > > This is to verify that Free BSD is in TIME-WAIT state. > > Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus.? Perhaps that the send sequence is outside the window.? If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? > > louie > > > > > > _______________________________________________ > 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" -- Erik Trulsson ertr1013@student.uu.se From hartmut.brandt at dlr.de Tue Jun 16 12:16:28 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Tue Jun 16 12:16:36 2009 Subject: TCP Free-BSD setup behaviour. In-Reply-To: <20090616113659.GA99604@owl.midgard.homeip.net> References: <925929.71164.qm@web8315.mail.in.yahoo.com> <20090616113659.GA99604@owl.midgard.homeip.net> Message-ID: <20090616141644.L82919@beagle.kn.op.dlr.de> On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi? Louie. ET>> ? ET>> As per Testing ET>> ? ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] ET>> 2. Then Expects to RECEIVE SYN packet and ET>> 3. To Send SYN & ACK? to reach? SYN-RCVD state. ET> ET>That does not sound quite correct. The normal sequence for the TCP ET>three-way handshake is: ET> ET> -----> SYN ET> <----- SYN+ACK ET> -----> ACK ET> ET>while you for some reason seem to be expecting ET> ET> -----> SYN ET> <----- SYN ET> -----> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> ? ET>> In Free BSD active SYN-RCVD state is not happening . ET>> ? ET>> In TCP state tranistion my expectation is represented for SYN_RCVD state. ET>> ? ET>> ? ET>> Thanks. ET>> Saravanan ET>> ET>> ET>> --- On Tue, 6/16/09, saravana perumal wrote: ET>> ET>> ET>> From: saravana perumal ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" ET>> Cc: "FreeBSD Mailer List" ET>> Date: Tuesday, June 16, 2009, 3:15 PM ET>> ET>> ET>> ET>> ET>> ET>> ET>> ET>> Hi Louie ET>> ? ET>> ?We are trying to make Active Sync Received state. ET>> ? ET>> As per our testing we are trying to received Syn packet from APPLICATION end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-RECEIVED state. ET>> ? ET>> So initially make the application to send SYN sending the Initial SYN and once Received the SYN packet , expecting the Device to Send SYN & ACK ET>> ? ET>> I hope the expectation should be rite in case of ACTIVE-SYN received State. ET>> ? ET>> Thanks. ET>> Saravanan ET>> ? ET>> ET>> ET>> --- On Tue, 6/16/09, Louis Mamakos wrote: ET>> ET>> ET>> From: Louis Mamakos ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" ET>> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com ET>> Date: Tuesday, June 16, 2009, 3:05 AM ET>> ET>> ET>> ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: ET>> ET>> > Hi Louie , ET>> > ET>> > ET>> > Thanks for the Response on my Queries. ET>> > ET>> > For QUERY 3, ET>> > ACTIVE open frm Free BSD end: ET>> > ET>> >? ? ? ? FREE BSD? ? ? ? ? APPLICATION ET>> >? ? ? ? ? ? ? ???Send ---------> syn ET>> >? ? ? ? ? ? ? ???Receive <-------- SYN ET>> > ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario, ET>> > ET>> >? Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. ET>> ET>> There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN.? Once the SYN has been ACK'd, there's no reason to resend it.? I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? ET>> ET>> > 4? ? .When checking the State - TIME-WAIT? ? Sending FIN and expecting the ACK ;Getting the ACK properly.???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. Issue seen only in Free BSD ET>> > ET>> > ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the ET>> > following Field set? in TIME-WAIT state , ET>> > ET>> > ET>> > TCP: ---- TCP Packet ---- ET>> > TCP: ET>> > TCP: Source Port? ? ? ? ???= 16815 (16815) ET>> > TCP: Destination Port? ? ? = 16816 (16816) ET>> > TCP: Sequence Number? ? ???= 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number = 0 (0x00000000) ET>> > TCP: Data Offset? ? ? ? ???= 5 (20 bytes) ET>> > TCP: Reserved? ? ? ? ? ? ? = 0 ET>> > TCP: Control Bits? ? ? ? ? = 0x10 ET>> > TCP:? |543210 ET>> > TCP:? |0.....? ? ? ? ? ? ? = Urgent Pointer Isn't Significant ET>> > TCP:? |.1....? ? ? ? ? ? ? = Acknowledgment Is Significant ET>> > TCP:? |..0...? ? ? ? ? ? ? = No Push Function ET>> > TCP:? |...0..? ? ? ? ? ? ? = No Reset Connection ET>> > TCP:? |....0.? ? ? ? ? ? ? = No Synchronize Sequence Numbers ET>> > TCP:? |.....0? ? ? ? ? ? ? = More Data From Sender ET>> > TCP: Window? ? ? ? ? ? ? ? = 32752 bytes ET>> > TCP: Checksum? ? ? ? ? ? ? = 0x41A0 (Correct) ET>> > TCP: Urgent Pointer? ? ? ? = 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP:? 53 61 6D 70 6C 65 20 44 61 74 61 00? ? ? ? ? ? ???Sample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending? to the FREE BSD machine, ET>> > ET>> > This is to verify that Free BSD is in TIME-WAIT state. ET>> ET>> Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus.? Perhaps that the send sequence is outside the window.? If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? ET>> ET>> louie ET>> ET>> ET>> ET>> ET>> ET>> _______________________________________________ ET>> freebsd-net@freebsd.org mailing list ET>> http://lists.freebsd.org/mailman/listinfo/freebsd-net ET>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ET> ET> From seesaravanan at yahoo.co.in Tue Jun 16 14:14:51 2009 From: seesaravanan at yahoo.co.in (saravana perumal) Date: Tue Jun 16 14:14:58 2009 Subject: TCP Free-BSD setup behaviour. Message-ID: <576824.58716.qm@web8318.mail.in.yahoo.com> Hi Erik ? ? Have a look into the below link ? http://www.jxos.org/Projects/TCP/tcpstate.html ? See how from CLOSED----------> SYN sent ---------> syn Received? state. ? Let me know if anything I am missing here. ? Thanks. Saravanan --- On Tue, 6/16/09, Harti Brandt wrote: From: Harti Brandt Subject: Re: TCP Free-BSD setup behaviour. To: "Erik Trulsson" Cc: "saravana perumal" , "FreeBSD Mailer List" Date: Tuesday, June 16, 2009, 5:47 PM On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi? Louie. ET>> ? ET>> As per Testing ET>> ? ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] ET>> 2. Then Expects to RECEIVE SYN packet and ET>> 3. To Send SYN & ACK? to reach? SYN-RCVD state. ET> ET>That does not sound quite correct.? The normal sequence for the TCP ET>three-way handshake is: ET> ET>? ? -----> SYN ET>? ? <----- SYN+ACK ET>? ? -----> ACK ET> ET>while you for some reason seem to be expecting ET> ET>? ? -----> SYN ET>? ? <----- SYN ET>? ? -----> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> ? ET>> In Free BSD active SYN-RCVD state is not happening . ET>> ? ET>> In TCP state tranistion my expectation is represented for SYN_RCVD state. ET>> ? ET>> ? ET>> Thanks. ET>> Saravanan ET>> ET>> ET>> --- On Tue, 6/16/09, saravana perumal wrote: ET>> ET>> ET>> From: saravana perumal ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" ET>> Cc: "FreeBSD Mailer List" ET>> Date: Tuesday, June 16, 2009, 3:15 PM ET>> ET>> ET>> ET>> ET>> ET>> ET>> ET>> Hi Louie ET>> ? ET>> ?We are trying to make Active Sync Received state. ET>> ? ET>> As per our testing we are trying to received Syn packet from APPLICATION end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-RECEIVED state. ET>> ? ET>> So initially make the application to send SYN sending the Initial SYN and once Received the SYN packet , expecting the Device to Send SYN & ACK ET>> ? ET>> I hope the expectation should be rite in case of ACTIVE-SYN received State. ET>> ? ET>> Thanks. ET>> Saravanan ET>> ? ET>> ET>> ET>> --- On Tue, 6/16/09, Louis Mamakos wrote: ET>> ET>> ET>> From: Louis Mamakos ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" ET>> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com ET>> Date: Tuesday, June 16, 2009, 3:05 AM ET>> ET>> ET>> ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: ET>> ET>> > Hi Louie , ET>> > ET>> > ET>> > Thanks for the Response on my Queries. ET>> > ET>> > For QUERY 3, ET>> > ACTIVE open frm Free BSD end: ET>> > ET>> >? ? ? ? FREE BSD? ? ? ? ? APPLICATION ET>> >? ? ? ? ? ? ? ???Send ---------> syn ET>> >? ? ? ? ? ? ? ???Receive <-------- SYN ET>> > ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario, ET>> > ET>> >? Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. ET>> ET>> There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN.? Once the SYN has been ACK'd, there's no reason to resend it.? I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? ET>> ET>> > 4? ? .When checking the State - TIME-WAIT? ? Sending FIN and expecting the ACK ;Getting the ACK properly.???Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. Issue seen only in Free BSD ET>> > ET>> > ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the ET>> > following Field set? in TIME-WAIT state , ET>> > ET>> > ET>> > TCP: ---- TCP Packet ---- ET>> > TCP: ET>> > TCP: Source Port? ? ? ? ???= 16815 (16815) ET>> > TCP: Destination Port? ? ? = 16816 (16816) ET>> > TCP: Sequence Number? ? ???= 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number = 0 (0x00000000) ET>> > TCP: Data Offset? ? ? ? ???= 5 (20 bytes) ET>> > TCP: Reserved? ? ? ? ? ? ? = 0 ET>> > TCP: Control Bits? ? ? ? ? = 0x10 ET>> > TCP:? |543210 ET>> > TCP:? |0.....? ? ? ? ? ? ? = Urgent Pointer Isn't Significant ET>> > TCP:? |.1....? ? ? ? ? ? ? = Acknowledgment Is Significant ET>> > TCP:? |..0...? ? ? ? ? ? ? = No Push Function ET>> > TCP:? |...0..? ? ? ? ? ? ? = No Reset Connection ET>> > TCP:? |....0.? ? ? ? ? ? ? = No Synchronize Sequence Numbers ET>> > TCP:? |.....0? ? ? ? ? ? ? = More Data From Sender ET>> > TCP: Window? ? ? ? ? ? ? ? = 32752 bytes ET>> > TCP: Checksum? ? ? ? ? ? ? = 0x41A0 (Correct) ET>> > TCP: Urgent Pointer? ? ? ? = 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP:? 53 61 6D 70 6C 65 20 44 61 74 61 00? ? ? ? ? ? ???Sample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending? to the FREE BSD machine, ET>> > ET>> > This is to verify that Free BSD is in TIME-WAIT state. ET>> ET>> Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus.? Perhaps that the send sequence is outside the window.? If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? ET>> ET>> louie ET>> ET>> ET>> ET>> ET>> ET>> _______________________________________________ ET>> freebsd-net@freebsd.org mailing list ET>> http://lists.freebsd.org/mailman/listinfo/freebsd-net ET>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ET> ET> From nugundam at nugundam.best.vwh.net Tue Jun 16 17:00:16 2009 From: nugundam at nugundam.best.vwh.net (Joseph Lee) Date: Tue Jun 16 17:00:24 2009 Subject: kern/124753: [ieee80211] net80211 discards power-save queue packets early Message-ID: <200906161700.n5GH0ERq004798@freefall.freebsd.org> The following reply was made to PR kern/124753; it has been noted by GNATS. From: Joseph Lee To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early Date: Tue, 16 Jun 2009 09:34:11 -0700 Seems to be FINALLY noticed and fixed by http://thread.gmane.org/gmane.os.freebsd.current/110707 Thanks. From vwe at FreeBSD.org Tue Jun 16 21:30:10 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Tue Jun 16 21:30:45 2009 Subject: kern/135502: [periodic] Warning message raised by rtfree function in kernel logs Message-ID: <200906162130.n5GLUAfc014693@freefall.freebsd.org> Synopsis: [periodic] Warning message raised by rtfree function in kernel logs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Tue Jun 16 21:26:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). This may happen for gif tunnels and v6 interfaces as cscope suggests there're direct calls to rtfree() from in6_gif.c, in6_ifattach.c and nd6_nbr.c http://www.freebsd.org/cgi/query-pr.cgi?pr=135502 From brian at Awfulhak.org Tue Jun 16 21:55:09 2009 From: brian at Awfulhak.org (Brian Somers) Date: Tue Jun 16 21:55:15 2009 Subject: NFS - exports syntax In-Reply-To: References: Message-ID: <20090616142646.173b092d@Awfulhak.org> On Mon, 15 Jun 2009 18:46:35 +0200, "marco\.borsatino\@poste\.it" wrote: > First, thank you for your help. > > > > > > > FreeBSD's exports implementation will only allow you to associate > > mount options per local filesystem per remote machine, so this > > version: > > > > > /usr/home??? ??? pc02 pc02 > > > /cond1 -mapall=user2 pc01 pc02 > > > /cond2 -mapall=user1 pc01 pc02 > > > > is correct, but only if /cond1 and /cond2 are different filesystems. > > If they're the same, this won't work. > > > > /cond1 and /cond2 are folders under root on /dev/ad0s1a; this is the reason whi my exports does not work. Yes. > So should I do something like this: > #mkdir /usr/shared/cond1 > #mkdir /usr/shared/cond2 > (this is, I think, a better choice also from different points of view). > (exports) > /usr/shared -alldirs pc01 pc02 (or -network 192.168.0) > (mount for different users) > #mount _nfs server:/usr/shared/cond1 /mnt/for-user-1 > #mount _nfs server:/usr/shared/cond2 /mnt/for-user-2 > > But, if this sintax is correct, how can I use mapall option? Your exports file should say: /usr/shared/cond1 -maproot=whatever pc01 /usr/shared/cond2 -maproot=somethingelse pc02 The two entries for the same physical filesystem are fine as long as you don't atempt to duplicate the remote host. -- Brian Somers Don't _EVER_ lose your sense of humour ! From bob at veznat.com Wed Jun 17 05:16:17 2009 From: bob at veznat.com (Bob Van Zant) Date: Wed Jun 17 05:16:25 2009 Subject: Debugging a netgraph node Message-ID: I'm experimenting with netgraph to try to implement an IPv6 -> IPv4 gateway, as specified here: http://tools.ietf.org/html/draft-xli-behave-ivi-02 This is my first time ever working with netgraph and I admit to being a bit lost. I have a netgraph node that gets wired up with an ng_ether node. My lower hook gets wired to the ng_ether lower hook and my upper to his upper. It's receiving IPv6 + UDP packets, creating IPv4 + UDP packets and then writing the new packets out with NG_FWD_NEW_DATA. I'm perfectly willing to waste time making stupid mistakes on this project, however, right now I'm stuck. I can't "find" the translated packets I'm writing anywhere to see what, if anything, is wrong with them. They don't show up in tcpdump on the local machine (I've tried writing to both the upper and lower hook). They don't show up in tcpdump on other machines on the network. I tried attaching nghook to the "orphans" hook of the ng_ether node but it doesn't appear to be seeing any data. netstat -s -p udp doesn't show any packets when my node is enabled (I think this means my node is effectively swallowing them). I've tried to figure out how to wire in an ng_tee node but I'm a little lost as to how to do this (I still haven't figured out the ngctl syntax). Any tips for figuring out what I'm doing wrong? Debug options to enable that will show me more information about what's happening after I call NG_FWD_NEW_DATA? If I got ng_tee wired in would it's tap hooks show me what I want? A better way to try to tee the data? Thanks, Bob From julian at elischer.org Wed Jun 17 06:24:21 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Jun 17 06:24:27 2009 Subject: Debugging a netgraph node In-Reply-To: References: Message-ID: <4A388C13.8050700@elischer.org> Bob Van Zant wrote: > I'm experimenting with netgraph to try to implement an IPv6 -> IPv4 gateway, > as specified here: > > http://tools.ietf.org/html/draft-xli-behave-ivi-02 hi bob, I can give you a hand if you want.. I'm busy tomorrow Morning but I can give you a call tomorrow afternoon if you like.. also, Joe in India has been using netgraph.. > > This is my first time ever working with netgraph and I admit to being a bit > lost. I have a netgraph node that gets wired up with an ng_ether node. My > lower hook gets wired to the ng_ether lower hook and my upper to his upper. > It's receiving IPv6 + UDP packets, creating IPv4 + UDP packets and then > writing the new packets out with NG_FWD_NEW_DATA. > > I'm perfectly willing to waste time making stupid mistakes on this project, > however, right now I'm stuck. I can't "find" the translated packets I'm > writing anywhere to see what, if anything, is wrong with them. They don't > show up in tcpdump on the local machine (I've tried writing to both the > upper and lower hook). They don't show up in tcpdump on other machines on > the network. > > I tried attaching nghook to the "orphans" hook of the ng_ether node but it > doesn't appear to be seeing any data. add a tee node between your node and the ether hook to see what you are sending. > > netstat -s -p udp doesn't show any packets when my node is enabled (I think > this means my node is effectively swallowing them). probably > > I've tried to figure out how to wire in an ng_tee node but I'm a little lost > as to how to do this (I still haven't figured out the ngctl syntax). ahh #add a tee to the ethernet lower hook ngctl mkpeer em3: tee lower left ngctl name em3:lower lowertee #then add your node to the right hook of the tee. ngctl mkpeer lowertee: mytype right lower ngctl name lowertee:right mynode #similar for the upper hook except that you use connect instead of #mkpeer for the last step as your node already exists. ngctl mkpeer em3: tee upper left mgctl name em3:upper uppertee ngctl connect uppertee: mynode: upper upper ------- now you can examine traffic on the two tee nodes let2right hook and rigt2left hook > > Any tips for figuring out what I'm doing wrong? Debug options to enable that > will show me more information about what's happening after I call > NG_FWD_NEW_DATA? If I got ng_tee wired in would it's tap hooks show me what > I want? A better way to try to tee the data? > > Thanks, > > Bob > > > _______________________________________________ > 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 barney_cordoba at yahoo.com Wed Jun 17 14:39:13 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Wed Jun 17 14:39:19 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces Message-ID: <714551.8026.qm@web63902.mail.re1.yahoo.com> --- On Fri, 6/12/09, Michael wrote: > From: Michael > Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces > To: freebsd-net@FreeBSD.org > Date: Friday, June 12, 2009, 5:50 AM > The following reply was made to PR > kern/135222; it has been noted by GNATS. > > From: Michael > To: Cc: freebsd-gnats-submit@FreeBSD.org > Subject: Re: kern/135222: [igb] low speed routing between > two igb interfaces > Date: Fri, 12 Jun 2009 11:45:47 +0200 > > The original poster reported that the suggested fix works > for him: > --- > Hello Michael, > > Thank you. It's working. > > I consider it necessary to put this into the release > errata. > > > Mishustin Andrew wrote: > >> Number:? ? ? > ???135222 > >> Category:? ? ???kern > >> Synopsis:? ? ???[igb] > low speed routing between two igb interfaces > >> Confidential:???no > >> Severity:? ? ???serious > >> Priority:? ? ???medium > >> Responsible:? ? freebsd-bugs > >> State:? ? ? ? ? open > >> Quarter:? ? ? ? > >> Keywords:? ? ??? > >> Date-Required: > >> Class:? ? ? ? ? sw-bug > >> Submitter-Id:???current-users > >> Arrival-Date:???Wed Jun 03 > 18:30:01 UTC 2009 > >> Closed-Date: > >> Last-Modified: > >> Originator:? ???Mishustin > Andrew > >> Release:? ? ? ? FreeBSD > 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 > >> Organization: > > HNT > >> Environment: > > FreeBSD test.hnt 7.2-RELEASE FreeBSD 7.2-RELEASE #12: > Thu Apr 30 18:28:15 MSD 20 > > 09? ???admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC? > amd64 > >> Description: > > I made a FreeBSD multiprocesor server to act as > simple gateway. > > It use onboard Intel 82575EB Dual-Port Gigabit > Ethernet Controller. > > I observe traffic speed near 400 Kbit/s. > > I test both interfaces separately - > > ftp client work at speed near 1 Gbit/s in both > directions. > > Then I change NIC to old Intel "em" NIC - gateway > work at speed near 1 Gbit/s. > > > > Looks like a bug in igb driver have an effect upon > forwarded traffic. > > > > If you try > > hw.igb.enable_aim=0 > > The speed is near 1 Mbit/s > > > > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" has no > effect. > > > > Nothing in messages.log > > > > netstat -m > > 516/1674/2190 mbufs in use (current/cache/total) > > 515/927/1442/66560 mbuf clusters in use > (current/cache/total/max) > > 515/893 mbuf+clusters out of packet secondary zone in > use (current/cache) > > 0/44/44/33280 4k (page size) jumbo clusters in use > (current/cache/total/max) > > 0/0/0/16640 9k jumbo clusters in use > (current/cache/total/max) > > 0/0/0/8320 16k jumbo clusters in use > (current/cache/total/max) > > 1159K/2448K/3607K bytes allocated to network > (current/cache/total) > > 0/0/0 requests for mbufs denied > (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/0/0 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > 0 calls to protocol drain routines > > > > I use only IPv4 traffic. > > > >> How-To-Repeat: > > On machine with two igb interfaces > > use rc.conf like this: > > > > hostname="test.test" > > gateway_enable="YES" > > ifconfig_igb0="inet 10.10.10.1/24" > > ifconfig_igb1="inet 10.10.11.1/24" > > > > And try create heavy traffic between two networks. > >> Fix: > > > > > >> Release-Note: > >> Audit-Trail: > >> Unformatted: > > _______________________________________________ > > freebsd-bugs@freebsd.org This is not a bug. Unless you consider poorly written drivers to be bugs. You need to provide your tuning parameters for the card as well otherwise there's nothing to learn. The issue is that the driver doesn't address the purpose of the controller; which is to utilize multiprocessor systems more effectively. The effect is that lock contention actually makes things worse than if you just use a single task as em does. Until the multiqueue drivers are re-written to manage locks properly you are best advised to save your money and stick with em. You should get similar performance using 1 queue as with em. You could also force legacy configuration by forcing igb_setup_msix to return 0. Sadly, this is the best performance you will get from the stock driver. Barney Barney From freebsdusb at bindone.de Wed Jun 17 21:53:48 2009 From: freebsdusb at bindone.de (Michael) Date: Wed Jun 17 21:53:55 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces In-Reply-To: <714551.8026.qm@web63902.mail.re1.yahoo.com> References: <714551.8026.qm@web63902.mail.re1.yahoo.com> Message-ID: <4A395FE6.1040003@bindone.de> Barney Cordoba wrote: > > > --- On Fri, 6/12/09, Michael wrote: > >> From: Michael >> Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces >> To: freebsd-net@FreeBSD.org >> Date: Friday, June 12, 2009, 5:50 AM >> The following reply was made to PR >> kern/135222; it has been noted by GNATS. >> >> From: Michael >> To: Cc: freebsd-gnats-submit@FreeBSD.org >> Subject: Re: kern/135222: [igb] low speed routing between >> two igb interfaces >> Date: Fri, 12 Jun 2009 11:45:47 +0200 >> >> The original poster reported that the suggested fix works >> for him: >> --- >> Hello Michael, >> >> Thank you. It's working. >> >> I consider it necessary to put this into the release >> errata. >> >> >> Mishustin Andrew wrote: >> >> Number: >> 135222 >> >> Category: kern >> >> Synopsis: [igb] >> low speed routing between two igb interfaces >> >> Confidential: no >> >> Severity: serious >> >> Priority: medium >> >> Responsible: freebsd-bugs >> >> State: open >> >> Quarter: >> >> Keywords: >> >> Date-Required: >> >> Class: sw-bug >> >> Submitter-Id: current-users >> >> Arrival-Date: Wed Jun 03 >> 18:30:01 UTC 2009 >> >> Closed-Date: >> >> Last-Modified: >> >> Originator: Mishustin >> Andrew >> >> Release: FreeBSD >> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 >> >> Organization: >> > HNT >> >> Environment: >> > FreeBSD test.hnt 7.2-RELEASE FreeBSD 7.2-RELEASE #12: >> Thu Apr 30 18:28:15 MSD 20 >> > 09 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC >> amd64 >> >> Description: >> > I made a FreeBSD multiprocesor server to act as >> simple gateway. >> > It use onboard Intel 82575EB Dual-Port Gigabit >> Ethernet Controller. >> > I observe traffic speed near 400 Kbit/s. >> > I test both interfaces separately - >> > ftp client work at speed near 1 Gbit/s in both >> directions. >> > Then I change NIC to old Intel "em" NIC - gateway >> work at speed near 1 Gbit/s. >> > >> > Looks like a bug in igb driver have an effect upon >> forwarded traffic. >> > >> > If you try >> > hw.igb.enable_aim=0 >> > The speed is near 1 Mbit/s >> > >> > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" has no >> effect. >> > >> > Nothing in messages.log >> > >> > netstat -m >> > 516/1674/2190 mbufs in use (current/cache/total) >> > 515/927/1442/66560 mbuf clusters in use >> (current/cache/total/max) >> > 515/893 mbuf+clusters out of packet secondary zone in >> use (current/cache) >> > 0/44/44/33280 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> > 0/0/0/16640 9k jumbo clusters in use >> (current/cache/total/max) >> > 0/0/0/8320 16k jumbo clusters in use >> (current/cache/total/max) >> > 1159K/2448K/3607K bytes allocated to network >> (current/cache/total) >> > 0/0/0 requests for mbufs denied >> (mbufs/clusters/mbuf+clusters) >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> > 0/0/0 sfbufs in use (current/peak/max) >> > 0 requests for sfbufs denied >> > 0 requests for sfbufs delayed >> > 0 requests for I/O initiated by sendfile >> > 0 calls to protocol drain routines >> > >> > I use only IPv4 traffic. >> > >> >> How-To-Repeat: >> > On machine with two igb interfaces >> > use rc.conf like this: >> > >> > hostname="test.test" >> > gateway_enable="YES" >> > ifconfig_igb0="inet 10.10.10.1/24" >> > ifconfig_igb1="inet 10.10.11.1/24" >> > >> > And try create heavy traffic between two networks. >> >> Fix: >> > >> > >> >> Release-Note: >> >> Audit-Trail: >> >> Unformatted: >> > _______________________________________________ >> > freebsd-bugs@freebsd.org > > > This is not a bug. Unless you consider poorly written drivers to be bugs. You need to provide your tuning parameters for the card as well otherwise there's nothing to learn. > > The issue is that the driver doesn't address the purpose of the controller; which is to utilize multiprocessor systems more effectively. The effect is that lock contention actually makes things worse than if you just use a single task as em does. Until the multiqueue drivers are re-written to manage locks properly you are best advised to save your money and stick with em. > > You should get similar performance using 1 queue as with em. You could also force legacy configuration by forcing igb_setup_msix to return 0. Sadly, this is the best performance you will get from the stock driver. > > Barney > > Barney > > > I tried using 1 queue and it didn't make things any better (actually I'm not sure if that worked at all). If it is considered a bug or not doesn't really matter, what actually matters for users (who cannot always chose which network controller will be on-board) is that they get a least decent performance when doing IP forwarding (and not the 5-50kb/s I've seen). You can get this out of the controller, when disabling lro through the sysctl. That's why I've been asking to put this into the release errata section and/or at least the igb man page, because the sysctl isn't documented anywhere. Also the fact, that tuning the sysctl only affects the behaviour when it's set on boot might be considered problematic. So at the very least, I think the following should be done: 1. Document the sysctl in man igb(4) 2. Put a known issues paragraph to man igb(4) which explains the issue and what to put in sysctl.conf to stop this from happening 3. Add an entry to the release errata page about this issue (like I suggested in one of my earlier emails) and stating something like "see man igb(4) for details) This is not about using the controller to its full potential, but to safe Joe Admin from spending days on figuring out why the machine is forwarding packages slower than his BSD 2.x machine did in the 90s. cheers Michael From freebsdusb at bindone.de Thu Jun 18 01:40:03 2009 From: freebsdusb at bindone.de (Michael) Date: Thu Jun 18 01:40:10 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces Message-ID: <200906180140.n5I1e2Pi052320@freefall.freebsd.org> The following reply was made to PR kern/135222; it has been noted by GNATS. From: Michael To: Barney Cordoba Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces Date: Thu, 18 Jun 2009 03:32:15 +0200 Barney Cordoba wrote: > > > --- On Wed, 6/17/09, Michael wrote: > >> From: Michael >> Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces >> To: "Barney Cordoba" >> Cc: freebsd-net@FreeBSD.org >> Date: Wednesday, June 17, 2009, 5:28 PM >> Barney Cordoba wrote: >>> >>> --- On Fri, 6/12/09, Michael >> wrote: >>>> From: Michael >>>> Subject: Re: kern/135222: [igb] low speed routing >> between two igb interfaces >>>> To: freebsd-net@FreeBSD.org >>>> Date: Friday, June 12, 2009, 5:50 AM >>>> The following reply was made to PR >>>> kern/135222; it has been noted by GNATS. >>>> >>>> From: Michael >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org >>>> Subject: Re: kern/135222: [igb] low speed routing >> between >>>> two igb interfaces >>>> Date: Fri, 12 Jun 2009 11:45:47 +0200 >>>> >>>> The original poster reported that the >> suggested fix works >>>> for him: >>>> --- >>>> Hello Michael, >>>> >>>> Thank you. It's working. >>>> >>>> I consider it necessary to put this into the >> release >>>> errata. >>>> >>>> >>>> Mishustin Andrew wrote: >>>> >> Number: >>>> 135222 >>>> >> Category: >> kern >>>> >> Synopsis: >> [igb] >>>> low speed routing between two igb interfaces >>>> >> Confidential: no >>>> >> Severity: >> serious >>>> >> Priority: >> medium >>>> >> Responsible: >> freebsd-bugs >>>> >> State: >> open >>>> >> Quarter: >>>> >> Keywords: >> >>>> >> Date-Required: >>>> >> Class: >> sw-bug >>>> >> >> Submitter-Id: current-users >>>> >> Arrival-Date: Wed >> Jun 03 >>>> 18:30:01 UTC 2009 >>>> >> Closed-Date: >>>> >> Last-Modified: >>>> >> Originator: >> Mishustin >>>> Andrew >>>> >> Release: >> FreeBSD >>>> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 >>>> >> Organization: >>>> > HNT >>>> >> Environment: >>>> > FreeBSD test.hnt 7.2-RELEASE FreeBSD >> 7.2-RELEASE #12: >>>> Thu Apr 30 18:28:15 MSD 20 >>>> > 09 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC >>>> amd64 >>>> >> Description: >>>> > I made a FreeBSD multiprocesor server >> to act as >>>> simple gateway. >>>> > It use onboard Intel 82575EB Dual-Port >> Gigabit >>>> Ethernet Controller. >>>> > I observe traffic speed near 400 >> Kbit/s. >>>> > I test both interfaces separately - >>>> > ftp client work at speed near 1 Gbit/s >> in both >>>> directions. >>>> > Then I change NIC to old Intel "em" NIC >> - gateway >>>> work at speed near 1 Gbit/s. >>>> > >>>> > Looks like a bug in igb driver have an >> effect upon >>>> forwarded traffic. >>>> > >>>> > If you try >>>> > hw.igb.enable_aim=0 >>>> > The speed is near 1 Mbit/s >>>> > >>>> > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" >> has no >>>> effect. >>>> > >>>> > Nothing in messages.log >>>> > >>>> > netstat -m >>>> > 516/1674/2190 mbufs in use >> (current/cache/total) >>>> > 515/927/1442/66560 mbuf clusters in >> use >>>> (current/cache/total/max) >>>> > 515/893 mbuf+clusters out of packet >> secondary zone in >>>> use (current/cache) >>>> > 0/44/44/33280 4k (page size) jumbo >> clusters in use >>>> (current/cache/total/max) >>>> > 0/0/0/16640 9k jumbo clusters in use >>>> (current/cache/total/max) >>>> > 0/0/0/8320 16k jumbo clusters in use >>>> (current/cache/total/max) >>>> > 1159K/2448K/3607K bytes allocated to >> network >>>> (current/cache/total) >>>> > 0/0/0 requests for mbufs denied >>>> (mbufs/clusters/mbuf+clusters) >>>> > 0/0/0 requests for jumbo clusters >> denied (4k/9k/16k) >>>> > 0/0/0 sfbufs in use (current/peak/max) >>>> > 0 requests for sfbufs denied >>>> > 0 requests for sfbufs delayed >>>> > 0 requests for I/O initiated by >> sendfile >>>> > 0 calls to protocol drain routines >>>> > >>>> > I use only IPv4 traffic. >>>> > >>>> >> How-To-Repeat: >>>> > On machine with two igb interfaces >>>> > use rc.conf like this: >>>> > >>>> > hostname="test.test" >>>> > gateway_enable="YES" >>>> > ifconfig_igb0="inet 10.10.10.1/24" >>>> > ifconfig_igb1="inet 10.10.11.1/24" >>>> > >>>> > And try create heavy traffic between >> two networks. >>>> >> Fix: >>>> > >>>> > >>>> >> Release-Note: >>>> >> Audit-Trail: >>>> >> Unformatted: >>>> > >> _______________________________________________ >>>> > freebsd-bugs@freebsd.org >>> >>> This is not a bug. Unless you consider poorly written >> drivers to be bugs. You need to provide your tuning >> parameters for the card as well otherwise there's nothing to >> learn. >>> The issue is that the driver doesn't address the >> purpose of the controller; which is to utilize >> multiprocessor systems more effectively. The effect is that >> lock contention actually makes things worse than if you just >> use a single task as em does. Until the multiqueue drivers >> are re-written to manage locks properly you are best advised >> to save your money and stick with em. >>> You should get similar performance using 1 queue as >> with em. You could also force legacy configuration by >> forcing igb_setup_msix to return 0. Sadly, this is the best >> performance you will get from the stock driver. >>> Barney >>> >>> Barney >>> >>> >>> >> I tried using 1 queue and it didn't make things any better >> (actually I'm >> not sure if that worked at all). If it is considered a bug >> or not >> doesn't really matter, what actually matters for users (who >> cannot >> always chose which network controller will be on-board) is >> that they get >> a least decent performance when doing IP forwarding (and >> not the >> 5-50kb/s I've seen). You can get this out of the >> controller, when >> disabling lro through the sysctl. That's why I've been >> asking to put >> this into the release errata section and/or at least the >> igb man page, >> because the sysctl isn't documented anywhere. Also the >> fact, that tuning >> the sysctl only affects the behaviour when it's set on boot >> might be >> considered problematic. >> >> So at the very least, I think the following should be >> done: >> 1. Document the sysctl in man igb(4) >> 2. Put a known issues paragraph to man igb(4) which >> explains the issue >> and what to put in sysctl.conf to stop this from happening >> 3. Add an entry to the release errata page about this issue >> (like I >> suggested in one of my earlier emails) and stating >> something like "see >> man igb(4) for details) >> >> This is not about using the controller to its full >> potential, but to >> safe Joe Admin from spending days on figuring out why the >> machine is >> forwarding packages slower than his BSD 2.x machine did in >> the 90s. >> >> cheers >> Michael > > None of the offload crap should be enabled by default. > > The real point is that "Joe Admin" shouldn't be using controllers that have bad drivers at all. If you have to use whatever hardware you have laying around, and don't have enough flexibility to lay out $100 for a 2 port controller that works to use with your $2000 server, than you need to get your priorities in order. People go out and buy redundant power supplies, high GHZ quad core processors and gobs of memory and then they use whatever crappy onboard controller they get no matter how poorly its suppo rted. Its mindless. > > Barney > > > How should anybody know that the controller is poorly supported if there is nothing in the documentation, release notes, man pages or anywhere else about this? The fact of the matter is that "the offload crap" _is_ enabled by default. The release is out, it claims to support the controller. There _is_ a workaround and I'm asked if somebody could document this so users will have a chance. I'm also not convinced that it is a crappy controller per se, but just poorly supported. We used those a lot before without any issues, unfortunately now we had touse IP forwarding in a machine that has that controller (it has 6 interfaces in total, four em ports and two igb ports, all of them are in use and I don't feel like hooking up the sodering iron). So bottomline: I said, there is a problem with the driver, there is a workaround and it should be documented. You say, the driver is bad and nobody should use it and if they do it's their own damn fault. We won't do anything about it and refuse to tell anybody, because we are the only ones who should know. We don't care if people can actually use our software and still claim the hardware is actually supported. Your attitude is really contra productive (actually googling around I see you made similar statements in the past about stupid people not willing to spend xxx$ on whatever piece of hardware, so maybe you're just trolling). Michael From andrew at modulus.org Thu Jun 18 02:06:04 2009 From: andrew at modulus.org (Andrew Snow) Date: Thu Jun 18 02:06:10 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces In-Reply-To: <200906180140.n5I1e2Pi052320@freefall.freebsd.org> References: <200906180140.n5I1e2Pi052320@freefall.freebsd.org> Message-ID: <4A399C7F.4000203@modulus.org> > The real point is that "Joe Admin" shouldn't be using controllers that have bad drivers at all. If you have to use whatever hardware you have laying around, and don't have enough flexibility to lay out $100 for a 2 port controller that works to use with your $2000 server, than you need to get your priorities in order. Intel 82575EB (and friends) are *the* premier ethernet controllers to use with FreeBSD in a server. igb should be the most stable and supported driver in the whole kernel. I can't think of any other driver and series of controllers I would rather use in a server like this. The "Offload crap" is also rather important for people who want to achieve the full rates of network transfer speeds they are paying for. If the drivers for these chips are now "bad", this is a very sad day for people who wanted to use FreeBSD in their dual socket servers. - Andrew From vladimirt at partygaming.com Thu Jun 18 06:59:51 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Thu Jun 18 06:59:58 2009 Subject: hostapd with 802.1X EAP-TLS/TTLS support Message-ID: <1245308384.28444.14.camel@daemon2.partygaming.local> Hi, i try to setup wireless access point at home, based on FreeBSD 7.2R-i386, ral(4) wireless card and hostpad(8). I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. I issued a custom SSL certificate for the hostapd(8) and put the following directives in hostapd.conf: eap_server=0 ca_cert=/usr/local/etc/myCA.crt.pem server_cert=/usr/local/etc/hostapd.server.crt.pem private_key=/usr/local/etc/hostapd.server.key.pem private_key_passwd=some_pass When i tried to start the hostapd(8) i got the following errors: Line 15: unknown configuration item 'eap_server' Line 16: unknown configuration item 'ca_cert' Line 17: unknown configuration item 'server_cert' Line 18: unknown configuration item 'private_key' Line 19: unknown configuration item 'private_key_passwd' Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at all and if "not" why ? Regards, -- Vladimir Terziev, CISSP This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From onemda at gmail.com Thu Jun 18 10:55:21 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Jun 18 10:55:28 2009 Subject: hostapd with 802.1X EAP-TLS/TTLS support In-Reply-To: <1245308384.28444.14.camel@daemon2.partygaming.local> References: <1245308384.28444.14.camel@daemon2.partygaming.local> Message-ID: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> On 6/18/09, Vladimir Terziev wrote: > Hi, > > i try to setup wireless access point at home, based on FreeBSD > 7.2R-i386, ral(4) wireless card and hostpad(8). > > I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. I > issued a custom SSL certificate for the hostapd(8) and put the following > directives in hostapd.conf: > > eap_server=0 > ca_cert=/usr/local/etc/myCA.crt.pem > server_cert=/usr/local/etc/hostapd.server.crt.pem > private_key=/usr/local/etc/hostapd.server.key.pem > private_key_passwd=some_pass > > When i tried to start the hostapd(8) i got the following errors: > > Line 15: unknown configuration item 'eap_server' > Line 16: unknown configuration item 'ca_cert' > Line 17: unknown configuration item 'server_cert' > Line 18: unknown configuration item 'private_key' > Line 19: unknown configuration item 'private_key_passwd' > > Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at all > and if "not" why ? 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). -- Paul From vladimirt at partygaming.com Thu Jun 18 11:07:38 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Thu Jun 18 11:07:45 2009 Subject: hostapd with 802.1X EAP-TLS/TTLS support In-Reply-To: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> References: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> Message-ID: <1245323250.28444.48.camel@daemon2.partygaming.local> Hi Paul, is there some special reason behind this? Why the server is made part of the main distribution with stripped functionality ? Also, how can i enable it ? Thanks, Vladimir On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > On 6/18/09, Vladimir Terziev wrote: > > Hi, > > > > i try to setup wireless access point at home, based on FreeBSD > > 7.2R-i386, ral(4) wireless card and hostpad(8). > > > > I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. > I > > issued a custom SSL certificate for the hostapd(8) and put the > following > > directives in hostapd.conf: > > > > eap_server=0 > > ca_cert=/usr/local/etc/myCA.crt.pem > > server_cert=/usr/local/etc/hostapd.server.crt.pem > > private_key=/usr/local/etc/hostapd.server.key.pem > > private_key_passwd=some_pass > > > > When i tried to start the hostapd(8) i got the following errors: > > > > Line 15: unknown configuration item 'eap_server' > > Line 16: unknown configuration item 'ca_cert' > > Line 17: unknown configuration item 'server_cert' > > Line 18: unknown configuration item 'private_key' > > Line 19: unknown configuration item 'private_key_passwd' > > > > Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > all > > and if "not" why ? > > 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). > > -- > Paul > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From is at rambler-co.ru Thu Jun 18 14:24:15 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Thu Jun 18 14:24:23 2009 Subject: bge interrupt coalescing sysctls In-Reply-To: <20090611114120.I21056@delplex.bde.org> References: <20090610123301.GE40250@rambler-co.ru> <20090611114120.I21056@delplex.bde.org> Message-ID: <20090618141925.GG60354@rambler-co.ru> On Thu, Jun 11, 2009 at 11:54:29AM +1000, Bruce Evans wrote: > On Wed, 10 Jun 2009, Igor Sysoev wrote: > > >For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: > >http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html > >However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken > >the patch. I'm not sure how to fix the collision, and since I do not > >use dynamic tuning > > That commit looked ugly (lots of internal API changes and bloat in interrupt > handlers in many network drivers to support polling which mostly shouldn't > be supported at all and mostly doesn't use the interrupt handlers). > > >I has left only static coalescing parameters in the patch > >and has added a loader tunable to set number of receive descriptors and > >read only sysctl to read the tunable. I usually use these parameters: > > > >/boot/loader.conf: > >hw.bge.rxd=512 > > > >/etc/sysctl.conf: > >dev.bge.0.rx_coal_ticks=500 > >dev.bge.0.tx_coal_ticks=10000 > >dev.bge.0.rx_max_coal_bds=64 > > These rx settings give to high a latency for me. Probably, however, I use this on a host that has 6000 packets/s. > >dev.bge.0.tx_max_coal_bds=128 > ># apply the above parameters > >dev.bge.0.program_coal=1 > > > >Could anyone commit it ? > > Not me, sorry. > > The patch is quite clean. If I committed then I would commit the > dynamic coalescing configuration separately anyway. So have you any objections if some one else will commit this patch ? > You can probably make hw.bge.rxd a sysctl too (it would take a down/up > to get it changed, but that is already needed for too many parameters > in network drivers anyway). I should use a sysctl for the ifq length > too. This could be done at a high level for each driver. Limiting > queue lengths may be a good way to reduce cache misses, while increasing > them is sometimes good for reducing packet loss. Do you mean simple command sequence: sysctl hw.bge.rxd=512 ifconfig down ifconfig up or SYSCTL_ADD_PROC for hw.bge.rxd ? -- Igor Sysoev http://sysoev.ru/en/ From news at markvoxx.com Thu Jun 18 16:21:34 2009 From: news at markvoxx.com (news@markvoxx.com) Date: Thu Jun 18 16:21:52 2009 Subject: PRESSRELEASE MARK VOXX FEAT. MC GRACE =?iso-8859-1?q?=B4=B4_SUBM?= =?iso-8859-1?q?ISSION=B4=B4?= -->> OUTNOW Message-ID: <505656668421844159@smtpa.netcabo.pt> Clica na imagem para ir para a loja do BeatPort ! Click on the image to go to BeatPort Shop! www.myspace.com/djmarkvoxxproducer www.myspace.com/themcgracespace To cancel your subscription to this newsletter, please reply to this message with the word REMOVE in the Subject line. Para cancelar a subscri??o desta newsletter, por favor responde a esta mensagem com a palavra REMOVER no assunto. From sam at freebsd.org Thu Jun 18 17:36:07 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Jun 18 17:36:13 2009 Subject: hostapd with 802.1X EAP-TLS/TTLS support In-Reply-To: <1245323250.28444.48.camel@daemon2.partygaming.local> References: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> <1245323250.28444.48.camel@daemon2.partygaming.local> Message-ID: <4A3A7B04.2020906@freebsd.org> EAP/TLS and TTLS should be configured by default in HEAD. Not sure what is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ the functionality you want by definitions to your src.conf: HOSTAPD_CFLAGS HOSTAPD_DPADD HOSTAPD_LDADD (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check usr.sbin/wpa/hostapd/Makefile). As to what should be enabled by default, I can only say that I tried to choose the most common setup as the default. Choosing this configuration also balances between bloat and inclusion of code that might not be as well audited and/or tested as other code. Hence the default setup used to be WPA-PSK only but has since grown to include various EAP flavors. My assumption was that anyone building a system using these tools would want to go through and choose what they wanted anyway so enabling everything was a bad idea. Sam Vladimir Terziev wrote: > Hi Paul, > > is there some special reason behind this? Why the server is made part of > the main distribution with stripped functionality ? > > Also, how can i enable it ? > > Thanks, > > Vladimir > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > >> On 6/18/09, Vladimir Terziev wrote: >> >>> Hi, >>> >>> i try to setup wireless access point at home, based on FreeBSD >>> 7.2R-i386, ral(4) wireless card and hostpad(8). >>> >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. >>> >> I >> >>> issued a custom SSL certificate for the hostapd(8) and put the >>> >> following >> >>> directives in hostapd.conf: >>> >>> eap_server=0 >>> ca_cert=/usr/local/etc/myCA.crt.pem >>> server_cert=/usr/local/etc/hostapd.server.crt.pem >>> private_key=/usr/local/etc/hostapd.server.key.pem >>> private_key_passwd=some_pass >>> >>> When i tried to start the hostapd(8) i got the following errors: >>> >>> Line 15: unknown configuration item 'eap_server' >>> Line 16: unknown configuration item 'ca_cert' >>> Line 17: unknown configuration item 'server_cert' >>> Line 18: unknown configuration item 'private_key' >>> Line 19: unknown configuration item 'private_key_passwd' >>> >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at >>> >> all >> >>> and if "not" why ? >>> >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). >> >> -- >> Paul >> >> >> > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. > > > _______________________________________________ > 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 axel at freakout.de Thu Jun 18 19:23:22 2009 From: axel at freakout.de (Axel Reinhold) Date: Thu Jun 18 19:23:30 2009 Subject: Bridging and using the interfaces concurrently Message-ID: <200906181910.n5IJAJ2u007974@bongo.freakout.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have two FreeBSD-7.1 servers in a data-center hosted. Both servers have two em[01] gigabit network links. First server's (call it "first") em0 is connected to the data-centers internet uplink - the em1 is connected to the seconds servers (call it "second") em1. first's /etc/rc.conf: ifconfig_em0="inet 212.144.103.230 netmask 255.255.254.0" defaultrouter="212.144.102.1" ifconfig_em1="inet 192.168.102.1 netmask 255.255.255.0" seconds's /etc/rc.conf: ifconfig_em1="inet 192.168.102.131 netmask 255.255.255.0" In this way the 192.168.102/24 network is for private connection between the two servers and "second" is not connected to the internet at all. Since i would have to pay extra charges to get the "second" server also connected to the internet, i thought of bridging the em0 and em1 of "first" and to alias another ip for the second server (i have more ip's in the data-center left) on "seconds" em1. Is this possible? What would i have to setup? The private 192.168.102/24 network should remain intakt! I just want to bridge "seconds" em1-MAC to the data-centers switch-port which is connected to "first" em0. Any help? Or is this not possible? Axel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9-PB (GNU/Linux) iD8DBQFKOpEIHQ9JwE2bDw0RAh9mAKCy2R7DAZYzqLfU/wKlwHiZWsQfAwCfUGne 7nsmXfuWgxyo+HAM76VRU6w= =LKp+ -----END PGP SIGNATURE----- From kfl at xiplink.com Thu Jun 18 20:33:54 2009 From: kfl at xiplink.com (Karim Fodil-Lemelin) Date: Thu Jun 18 20:34:00 2009 Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <4A3AA118.9020609@xiplink.com> Hello, Concerning this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I have one of those 'strange' silicon here: FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 kernel: mskc2: port 0xee00-0xeeff mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 kernel: msk2: on mskc2 kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 kernel: miibus2: on msk2 kernel: e1000phy2: PHY 0 on miibus2 kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved the problem. But applying the attached patch (written by Pyun I believe) also solved the problem. I think your patch should be committed for others to benefit. Best regards, Karim. -------------- next part -------------- Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 186497) +++ sys/dev/msk/if_msk.c (working copy) @@ -1355,27 +1355,25 @@ CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); /* Set the status list last index. */ CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { - /* WA for dev. #4.3 */ - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); - /* WA for dev. #4.18 */ - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); - } else { - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); - else - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); - } /* - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. + * Interrupt moderation and coalescing frames should be + * controllable with sysctl variables or loader tunables + * but the relationship between status updates and + * interrupt moderation are not clear. Some hardware + * revisions seem to very sensitive to these parameters + * and could be resulted in poor performance as well as + * non-working situation if improper values were chosen. */ + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); + else + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); /* Enable status unit. */ CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); @@ -3586,6 +3584,10 @@ domore = msk_handle_events(sc); if ((status & Y2_IS_STAT_BMU) != 0) CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); + if (CSR_READ_1(sc, STAT_TX_TIMER_CTRL) == TIM_START) { + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_STOP); + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_START); + } if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 && !IFQ_DRV_IS_EMPTY(&ifp0->if_snd)) From pyunyh at gmail.com Fri Jun 19 00:32:58 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 19 00:33:05 2009 Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering In-Reply-To: <4A3AA118.9020609@xiplink.com> References: <4A3AA118.9020609@xiplink.com> Message-ID: <20090619003709.GF93360@michelle.cdnetworks.co.kr> On Thu, Jun 18, 2009 at 04:18:32PM -0400, Karim Fodil-Lemelin wrote: > Hello, > Hi, > Concerning this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I > have one of those 'strange' silicon here: > > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 > > kernel: mskc2: port 0xee00-0xeeff > mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 > kernel: msk2: on > mskc2 > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 > kernel: miibus2: on msk2 > kernel: e1000phy2: PHY 0 on miibus2 > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseTX-FDX, auto > > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved > the problem. But applying the attached patch (written by Pyun I believe) > also solved the problem. > > I think your patch should be committed for others to benefit. > Thanks a lot! I'll write a follow-up mail to the PR. > Best regards, > > Karim. > > From pyunyh at gmail.com Fri Jun 19 00:40:06 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 19 00:40:13 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200906190040.n5J0e519069495@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: Duckhawk Cc: bug-followup@FreeBSD.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Fri, 19 Jun 2009 09:43:05 +0900 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 22, 2009 at 07:50:03AM +0000, Duckhawk wrote: > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Duckhawk > To: bug-followup@FreeBSD.org, skylord@linkline.ru > Cc: > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- > recovering > Date: Sun, 22 Feb 2009 12:26:51 +0500 > > --001636c5a26744f2de04637ccfc6 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > also, same problem. D-Link DGE-560T > > %uname -a > FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009 > duckhawk@:/usr/obj/usr/src/sys/GENERIC i386 > > %dmesg | grep "msk" > mskc0: port 0x7000-0x70ff mem > 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1 > msk0: on mskc0 > msk0: Ethernet address: 00:1b:11:79:53:eb > miibus0: on msk0 > mskc0: [FILTER] > > %pciconf -lv > mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 > rev=0x13 hdr=0x00 > vendor = 'D-Link System Inc' > device = 'DGE-560T PCIe Gigabit Ethernet Adapter' > class = network > subclass = ethernet Please try the following patch. --47eKBCiAZYFK5l32 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.EC.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 194467) +++ sys/dev/msk/if_msk.c (working copy) @@ -1387,27 +1387,26 @@ CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); /* Set the status list last index. */ CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { - /* WA for dev. #4.3 */ - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); - /* WA for dev. #4.18 */ - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); - } else { - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); - else - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); - } /* - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. + * XXX + * Interrupt moderation and coalescing frames should be + * controllable with sysctl variables or loader tunables + * but the relationship between status updates and + * interrupt moderation are not clear to me. Some hardware + * revisions seem to very sensitive to these parameters + * and could be resulted in poor performance as well as + * non-working situation if improper values were chosen. */ + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); + else + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); /* Enable status unit. */ CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); --47eKBCiAZYFK5l32-- From pyunyh at gmail.com Fri Jun 19 00:50:06 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 19 00:50:13 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200906190050.n5J0o6PN076484@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: sam Cc: yongari@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Fri, 19 Jun 2009 09:40:46 +0900 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 31, 2008 at 04:06:42PM +0400, sam wrote: > ----------------------------------------------- > Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > ----------------------------------------------- > > ----------------------------------------------- > Jul 29 23:18:28 moon3 kernel: mskc0: Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device > 0.0 on pci2 > Jul 29 23:18:28 moon3 kernel: msk0: Yukon EC Id 0xb6 Rev 0x02> on mskc0 > > Jul 29 23:18:28 moon3 kernel: miibus0: on msk0 > ----------------------------------------------- > > ----------------------------------------------- > FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 > 15:00:14 MSD 2008 root@moon3:/usr/src/sys/i386/compile/MOON3 i386 > ----------------------------------------------- > > I confirm this problem. > > /Vladimir Ermakov > > Would you try attached patch and let me know hot it goes? --pQhZXvAqiZgbeUkD Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.EC.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 194467) +++ sys/dev/msk/if_msk.c (working copy) @@ -1387,27 +1387,26 @@ CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); /* Set the status list last index. */ CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { - /* WA for dev. #4.3 */ - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); - /* WA for dev. #4.18 */ - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); - } else { - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); - else - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); - } /* - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. + * XXX + * Interrupt moderation and coalescing frames should be + * controllable with sysctl variables or loader tunables + * but the relationship between status updates and + * interrupt moderation are not clear to me. Some hardware + * revisions seem to very sensitive to these parameters + * and could be resulted in poor performance as well as + * non-working situation if improper values were chosen. */ + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); + else + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); /* Enable status unit. */ CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); --pQhZXvAqiZgbeUkD-- From dd at justlinuxhosting.com Fri Jun 19 07:10:04 2009 From: dd at justlinuxhosting.com (Daniel Duerr) Date: Fri Jun 19 07:10:14 2009 Subject: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface Message-ID: <200906190710.n5J7A2cD078751@freefall.freebsd.org> The following reply was made to PR kern/132107; it has been noted by GNATS. From: Daniel Duerr To: bug-followup@FreeBSD.org, adaugherity@tamu.edu Cc: Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface Date: Thu, 18 Jun 2009 23:51:09 -0700 Having the same issue here and the workaround isn't working for me -- it preserves the advskew but the vpn doesn't seem to work without the devd attach event. Hope someone will fix this soon. From rea-fbsd at codelabs.ru Fri Jun 19 08:55:07 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jun 19 08:55:15 2009 Subject: Bridging and using the interfaces concurrently In-Reply-To: <200906181910.n5IJAJ2u007974@bongo.freakout.de> References: <200906181910.n5IJAJ2u007974@bongo.freakout.de> Message-ID: Axel, good day. Thu, Jun 18, 2009 at 09:10:19PM +0200, Axel Reinhold wrote: > Since i would have to pay extra charges to get the "second" > server also connected to the internet, i thought of bridging > the em0 and em1 of "first" and to alias another ip for the > second server (i have more ip's in the data-center left) on > "seconds" em1. > > Is this possible? What would i have to setup? > The private 192.168.102/24 network should remain intakt! NAT the "second" box on your "first" one and that's it. Bridging won't help much here, because your "second"s IPs are unroutable, so someone will still need to translate them. If your intention is to provide only client-level connectivity to the "second" box (when it initiates all connections), simple NAT will work. If you need some port to be opened at the "second" host and the should be reachable from the outside, then you'll additionally need port mirroring. Or, if you really want to spend an extra IP for the second box, then just binat (in the terms of pf.conf(5)) your private address to the second IP on the "first" server. The exact solution for NAT depends on the firewall type you're using on the "first" server. For ipfw you probably should look at the natd(8), for ipfilter -- at ipnat(8), for pf -- at pf(4) and pf.conf(5). May be netgraph(4) will be of some help, but this adds some extra complexity for people who aren't familiar with Netgraph concepts and tools. If you really want bridging, then the easiest thing will be to create two VLAN (if_vlan(4)) interfaces on your link between two servers: one VLAN for the 192.168.102/24 network and one for the public network. After this, packets from 192.168 will flow as they flowed before, and you should bridge your "first"'s external interface with the second VLAN interface on this host. Put your extra external IP to the other side of the VLAN interface and it should do what you need. NAT should be easier, bridging should be faster, but the difference strongly depends on the type of traffic and usage of the inter-server link. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From jroberson at jroberson.net Fri Jun 19 09:43:37 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Fri Jun 19 09:43:53 2009 Subject: mbuf layout optimizations Message-ID: http://people.freebsd.org/~jeff/mbuf2.diff Hello, This is a call for testers and feedback on my mbuf layout improvements. I'm trying to decide whether I will push to have these included in 8.0. After reducing the scope slightly from my last patch, I have not encountered any problems. Kip Macy has also been using it for the past few weeks without issue. You should not expect any functional changes from this patch. The goal is mostly to pave the way fors more sensible mbuf handling in the future, although it does offer a few performance benefits. The only issue is that cxgb support requires another set of patches from Kip. If anyone needs those I will prod him to reply with that diff. Thanks, Jeff From vladimirt at partygaming.com Fri Jun 19 10:55:34 2009 From: vladimirt at partygaming.com (Vladimir Terziev) Date: Fri Jun 19 10:55:41 2009 Subject: hostapd with 802.1X EAP-TLS/TTLS support In-Reply-To: <4A3A7B04.2020906@freebsd.org> References: <4A3A7B04.2020906@freebsd.org> Message-ID: <1245408926.31855.26.camel@daemon2.partygaming.local> Thanks Sam, What should i put for HOSTAPD_CFLAGS, HOSTAPD_DPADD, HOSTAPD_LDADD or WPA_SUPPLICANT_* (not sure which ones i should use) in order to get hostapd rebuilt with the functionality i want ? Regards, Vladimir On Thu, 2009-06-18 at 20:36 +0300, Sam Leffler wrote: > EAP/TLS and TTLS should be configured by default in HEAD. Not sure > what > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ > the functionality you want by definitions to your src.conf: > > HOSTAPD_CFLAGS > HOSTAPD_DPADD > HOSTAPD_LDADD > > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check > usr.sbin/wpa/hostapd/Makefile). > > As to what should be enabled by default, I can only say that I tried > to > choose the most common setup as the default. Choosing this > configuration also balances between bloat and inclusion of code that > might not be as well audited and/or tested as other code. Hence the > default setup used to be WPA-PSK only but has since grown to include > various EAP flavors. My assumption was that anyone building a system > using these tools would want to go through and choose what they wanted > anyway so enabling everything was a bad idea. > > Sam > > > Vladimir Terziev wrote: > > Hi Paul, > > > > is there some special reason behind this? Why the server is made > part of > > the main distribution with stripped functionality ? > > > > Also, how can i enable it ? > > > > Thanks, > > > > Vladimir > > > > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > > > >> On 6/18/09, Vladimir Terziev wrote: > >> > >>> Hi, > >>> > >>> i try to setup wireless access point at home, based on FreeBSD > >>> 7.2R-i386, ral(4) wireless card and hostpad(8). > >>> > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS > authentication. > >>> > >> I > >> > >>> issued a custom SSL certificate for the hostapd(8) and put the > >>> > >> following > >> > >>> directives in hostapd.conf: > >>> > >>> eap_server=0 > >>> ca_cert=/usr/local/etc/myCA.crt.pem > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem > >>> private_key=/usr/local/etc/hostapd.server.key.pem > >>> private_key_passwd=some_pass > >>> > >>> When i tried to start the hostapd(8) i got the following errors: > >>> > >>> Line 15: unknown configuration item 'eap_server' > >>> Line 16: unknown configuration item 'ca_cert' > >>> Line 17: unknown configuration item 'server_cert' > >>> Line 18: unknown configuration item 'private_key' > >>> Line 19: unknown configuration item 'private_key_passwd' > >>> > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > >>> > >> all > >> > >>> and if "not" why ? > >>> > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's > hostapd(8). > >> > >> -- > >> Paul > >> > >> > >> > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > > > > _______________________________________________ > > 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 vanhu at FreeBSD.org Fri Jun 19 12:37:17 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Jun 19 12:37:25 2009 Subject: IPsec crash, patch for review Message-ID: <20090619130040.GA53996@zeninc.net> Hi all. We (NETASQ) had some IPsec related kernel crashes, and hunted them, here are some informations and a possible patch: First, problem only occurs when asynchronous crypto is done (hardware encryption such as hifn cards, or software patch to do encryption on a separate kthread when having multiple CPUs). More or less exploitable backtraces always shows a problem with an isr which seems to be used but already freed. While looking at the code, we noticed that there is probably a race condition when using asynchronous crypto: ip_output (well, ip_ipsec_output() now) releases refcnt to the SPD entry when IPsec processing needs to be done, but SPD's isr will still be used by [esp|ah|ipcomp]_output_cb(). The attached patch moves the KEY_FREESP() from ip_ipsec_output() to [esp|ah|ipcomp]_output_cb() when there will be IPsec processing (when ip_ipsec_output()returns -1). (note for George and Bjoern: this is a newer version of the patch, which also fixes a refcnt leak). This patches solves our problem (no more crashes for a week, when we had at least 2-3 crashes / day), and has also successfully passed our non regression testsuite. As it may still have some unexpected impacts on other parts of the code, I'd like to have some feedback on it before commiting it. Thanks, Yvan. -------------- next part -------------- Index: netinet/ip_ipsec.c =================================================================== --- netinet/ip_ipsec.c (revision 193698) +++ netinet/ip_ipsec.c (working copy) @@ -405,8 +405,6 @@ done: KEY_FREESP(&sp); return 0; reinjected: - if (sp != NULL) - KEY_FREESP(&sp); return -1; bad: if (sp != NULL) Index: netipsec/xform_esp.c =================================================================== --- netipsec/xform_esp.c (revision 193698) +++ netipsec/xform_esp.c (working copy) @@ -979,11 +979,15 @@ esp_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ipcomp.c =================================================================== --- netipsec/xform_ipcomp.c (revision 193698) +++ netipsec/xform_ipcomp.c (working copy) @@ -588,11 +588,15 @@ ipcomp_output_cb(struct cryptop *crp) error = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); return error; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ah.c =================================================================== --- netipsec/xform_ah.c (revision 193698) +++ netipsec/xform_ah.c (working copy) @@ -1210,11 +1210,15 @@ ah_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); if (m) m_freem(m); free(tc, M_XDATA); -------------- next part -------------- Index: netinet/ip_ipsec.c =================================================================== --- netinet/ip_ipsec.c (revision 194337) +++ netinet/ip_ipsec.c (working copy) @@ -347,6 +347,11 @@ ip_ipsec_output(struct mbuf **m, struct /* NB: callee frees mbuf */ *error = ipsec4_process_packet(*m, sp->req, *flags, 0); + + /* Release SP now if an error occured (including acquire) */ + if(error) + KEY_FREESP(&sp); + if (*error == EJUSTRETURN) { /* * We had a SP with a level of 'use' and no SA. We @@ -358,6 +363,7 @@ ip_ipsec_output(struct mbuf **m, struct ip->ip_off = ntohs(ip->ip_off); goto done; } + /* * Preserve KAME behaviour: ENOENT can be returned * when an SA acquire is in progress. Don't propagate @@ -405,8 +411,6 @@ done: KEY_FREESP(&sp); return 0; reinjected: - if (sp != NULL) - KEY_FREESP(&sp); return -1; bad: if (sp != NULL) Index: netipsec/xform_esp.c =================================================================== --- netipsec/xform_esp.c (revision 194337) +++ netipsec/xform_esp.c (working copy) @@ -979,11 +979,15 @@ esp_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ipcomp.c =================================================================== --- netipsec/xform_ipcomp.c (revision 194337) +++ netipsec/xform_ipcomp.c (working copy) @@ -588,11 +588,15 @@ ipcomp_output_cb(struct cryptop *crp) error = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); return error; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ah.c =================================================================== --- netipsec/xform_ah.c (revision 194337) +++ netipsec/xform_ah.c (working copy) @@ -1210,11 +1210,15 @@ ah_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); if (m) m_freem(m); free(tc, M_XDATA); From vanhu at FreeBSD.org Fri Jun 19 12:38:54 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Jun 19 12:39:02 2009 Subject: IPsec crash, patch for review In-Reply-To: <20090619130040.GA53996@zeninc.net> References: <20090619130040.GA53996@zeninc.net> Message-ID: <20090619130219.GB53996@zeninc.net> Sorry, I made a mistake and send both an older version and the latest version of the patch. The good one is patch-xform_freespfix-3 Yvan. From barney_cordoba at yahoo.com Fri Jun 19 14:56:02 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri Jun 19 14:56:09 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces Message-ID: <436489.18496.qm@web63904.mail.re1.yahoo.com> --- On Wed, 6/17/09, Michael wrote: > From: Michael > Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces > To: freebsd-net@FreeBSD.org > Date: Wednesday, June 17, 2009, 9:40 PM > The following reply was made to PR > kern/135222; it has been noted by GNATS. > > From: Michael > To: Barney Cordoba > Cc: freebsd-gnats-submit@FreeBSD.org > Subject: Re: kern/135222: [igb] low speed routing between > two igb interfaces > Date: Thu, 18 Jun 2009 03:32:15 +0200 > > Barney Cordoba wrote: > > > > > > --- On Wed, 6/17/09, Michael > wrote: > > > >> From: Michael > >> Subject: Re: kern/135222: [igb] low speed routing > between two igb interfaces > >> To: "Barney Cordoba" > >> Cc: freebsd-net@FreeBSD.org > >> Date: Wednesday, June 17, 2009, 5:28 PM > >> Barney Cordoba wrote: > >>> > >>> --- On Fri, 6/12/09, Michael > >> wrote: > >>>> From: Michael > >>>> Subject: Re: kern/135222: [igb] low speed > routing > >> between two igb interfaces > >>>> To: freebsd-net@FreeBSD.org > >>>> Date: Friday, June 12, 2009, 5:50 AM > >>>> The following reply was made to PR > >>>> kern/135222; it has been noted by GNATS. > >>>> > >>>> From: Michael > >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org > >>>> Subject: Re: kern/135222: [igb] low speed > routing > >> between > >>>> two igb interfaces > >>>> Date: Fri, 12 Jun 2009 11:45:47 +0200 > >>>> > >>>>???The original poster > reported that the > >> suggested fix works > >>>> for him: > >>>>???--- > >>>>???Hello Michael, > >>>>??? > >>>>???Thank you. It's > working. > >>>>??? > >>>>???I consider it necessary > to put this into the > >> release > >>>> errata. > >>>>??? > >>>>??? > >>>>???Mishustin Andrew wrote: > >>>>???>> Number:? > ??? > >>>>? ???135222 > >>>>???>> > Category:??? > >>? ? kern > >>>>???>> > Synopsis:??? > >>? ? [igb] > >>>> low speed routing between two igb > interfaces > >>>>???>> > Confidential:???no > >>>>???>> > Severity:??? > >>? ? serious > >>>>???>> > Priority:??? > >>? ? medium > >>>>???>> > Responsible:??? > >> freebsd-bugs > >>>>???>> State:? > ? ??? > >>???open > >>>>???>> Quarter:? > ? ??? > >>>>???>> > Keywords:??? > >>? ? > >>>>???>> Date-Required: > >>>>???>> Class:? > ? ??? > >>???sw-bug > >>>>???>> > >> Submitter-Id:???current-users > >>>>???>> > Arrival-Date:???Wed > >> Jun 03 > >>>> 18:30:01 UTC 2009 > >>>>???>> Closed-Date: > >>>>???>> Last-Modified: > >>>>???>> Originator: > >>? ? Mishustin > >>>> Andrew > >>>>???>> Release:? > ? ??? > >> FreeBSD > >>>> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE > amd64 > >>>>???>> Organization: > >>>>???> HNT > >>>>???>> Environment: > >>>>???> FreeBSD test.hnt > 7.2-RELEASE FreeBSD > >> 7.2-RELEASE #12: > >>>> Thu Apr 30 18:28:15 MSD 20 > >>>>???> 09? > ???admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC > >>>> amd64 > >>>>???>> Description: > >>>>???> I made a FreeBSD > multiprocesor server > >> to act as > >>>> simple gateway. > >>>>???> It use onboard > Intel 82575EB Dual-Port > >> Gigabit > >>>> Ethernet Controller. > >>>>???> I observe traffic > speed near 400 > >> Kbit/s. > >>>>???> I test both > interfaces separately - > >>>>???> ftp client work at > speed near 1 Gbit/s > >> in both > >>>> directions. > >>>>???> Then I change NIC > to old Intel "em" NIC > >> - gateway > >>>> work at speed near 1 Gbit/s. > >>>>???> > >>>>???> Looks like a bug in > igb driver have an > >> effect upon > >>>> forwarded traffic. > >>>>???> > >>>>???> If you try > >>>>???> > hw.igb.enable_aim=0 > >>>>???> The speed is near 1 > Mbit/s > >>>>???> > >>>>???> hw.igb.rxd, > hw.igb.txd, "ifconfig -tso" > >> has no > >>>> effect. > >>>>???> > >>>>???> Nothing in > messages.log > >>>>???> > >>>>???> netstat -m > >>>>???> 516/1674/2190 mbufs > in use > >> (current/cache/total) > >>>>???> 515/927/1442/66560 > mbuf clusters in > >> use > >>>> (current/cache/total/max) > >>>>???> 515/893 > mbuf+clusters out of packet > >> secondary zone in > >>>> use (current/cache) > >>>>???> 0/44/44/33280 4k > (page size) jumbo > >> clusters in use > >>>> (current/cache/total/max) > >>>>???> 0/0/0/16640 9k > jumbo clusters in use > >>>> (current/cache/total/max) > >>>>???> 0/0/0/8320 16k > jumbo clusters in use > >>>> (current/cache/total/max) > >>>>???> 1159K/2448K/3607K > bytes allocated to > >> network > >>>> (current/cache/total) > >>>>???> 0/0/0 requests for > mbufs denied > >>>> (mbufs/clusters/mbuf+clusters) > >>>>???> 0/0/0 requests for > jumbo clusters > >> denied (4k/9k/16k) > >>>>???> 0/0/0 sfbufs in use > (current/peak/max) > >>>>???> 0 requests for > sfbufs denied > >>>>???> 0 requests for > sfbufs delayed > >>>>???> 0 requests for I/O > initiated by > >> sendfile > >>>>???> 0 calls to protocol > drain routines > >>>>???> > >>>>???> I use only IPv4 > traffic. > >>>>???> > >>>>???>> How-To-Repeat: > >>>>???> On machine with two > igb interfaces > >>>>???> use rc.conf like > this: > >>>>???> > >>>>???> > hostname="test.test" > >>>>???> > gateway_enable="YES" > >>>>???> ifconfig_igb0="inet > 10.10.10.1/24" > >>>>???> ifconfig_igb1="inet > 10.10.11.1/24" > >>>>???> > >>>>???> And try create > heavy traffic between > >> two networks. > >>>>???>> Fix: > >>>>???> > >>>>???> > >>>>???>> Release-Note: > >>>>???>> Audit-Trail: > >>>>???>> Unformatted: > >>>>???> > >> _______________________________________________ > >>>>???> freebsd-bugs@freebsd.org > >>> > >>> This is not a bug. Unless you consider poorly > written > >> drivers to be bugs. You need to provide your > tuning > >> parameters for the card as well otherwise there's > nothing to > >> learn. > >>> The issue is that the driver doesn't address > the > >> purpose of the controller; which is to utilize > >> multiprocessor systems more effectively. The > effect is that > >> lock contention actually makes things worse than > if you just > >> use a single task as em does. Until the > multiqueue drivers > >> are re-written to manage locks properly you are > best advised > >> to save your money and stick with em. > >>> You should get similar performance using 1 > queue as > >> with em. You could also force legacy > configuration by > >> forcing igb_setup_msix to return 0. Sadly, this > is the best > >> performance you will get from the stock driver. > >>> Barney > >>> > >>> Barney > >>> > >>> > >>>? ? ? ? > >> I tried using 1 queue and it didn't make things > any better > >> (actually I'm > >> not sure if that worked at all). If it is > considered a bug > >> or not > >> doesn't really matter, what actually matters for > users (who > >> cannot > >> always chose which network controller will be > on-board) is > >> that they get > >> a least decent performance when doing IP > forwarding (and > >> not the > >> 5-50kb/s I've seen). You can get this out of the > >> controller, when > >> disabling lro through the sysctl. That's why I've > been > >> asking to put > >> this into the release errata section and/or at > least the > >> igb man page, > >> because the sysctl isn't documented anywhere. > Also the > >> fact, that tuning > >> the sysctl only affects the behaviour when it's > set on boot > >> might be > >> considered problematic. > >> > >> So at the very least, I think the following > should be > >> done: > >> 1. Document the sysctl in man igb(4) > >> 2. Put a known issues paragraph to man igb(4) > which > >> explains the issue > >> and what to put in sysctl.conf to stop this from > happening > >> 3. Add an entry to the release errata page about > this issue > >> (like I > >> suggested in one of my earlier emails) and > stating > >> something like "see > >> man igb(4) for details) > >> > >> This is not about using the controller to its > full > >> potential, but to > >> safe Joe Admin from spending days on figuring out > why the > >> machine is > >> forwarding packages slower than his BSD 2.x > machine did in > >> the 90s. > >> > >> cheers > >> Michael > > > > None of the offload crap should be enabled by > default. > > > > The real point is that "Joe Admin" shouldn't be using > controllers that have bad drivers at all. If you have to use > whatever hardware you have laying around, and don't have > enough flexibility to lay out $100 for a 2 port controller > that works to use with your $2000 server, than you need to > get your priorities in order. People go out and buy > redundant power supplies, high GHZ quad core processors and > gobs of memory and then they use whatever crappy onboard > controller they get no matter how poorly its suppo rted. Its > mindless. > > > > Barney > > > > > >? ? ??? > > How should anybody know that the controller is poorly > supported if there > is nothing in the documentation, release notes, man pages > or anywhere > else about this? > > The fact of the matter is that "the offload crap" _is_ > enabled by > default. The release is out, it claims to support the > controller. There > _is_ a workaround and I'm asked if somebody could document > this so users > will have a chance. I'm also not convinced that it is a > crappy > controller per se, but just poorly supported. We used > those a lot before > without any issues, unfortunately now we had touse IP > forwarding in a > machine that has that controller (it has 6 interfaces in > total, four em > ports and two igb ports, all of them are in use and I > don't feel like > hooking up the sodering iron). > > So bottomline: > I said, there is a problem with the driver, there is a > workaround and it > should be documented. > > You say, the driver is bad and nobody should use it and if > they do it's > their own damn fault. We won't do anything about it and > refuse to tell > anybody, because we are the only ones who should know. We > don't care if > people can actually use our software and still claim the > hardware is > actually supported. > > Your attitude is really contra productive (actually > googling around I > see? you made similar statements in the past about > stupid people not > willing to spend xxx$ on whatever piece of hardware, so > maybe you're > just trolling). > > Michael Tuning the card to be brain-dead isn't really a workaround. I'm sorry that you're not able to understand, but you can't educate the woodchucks, so carry on and feel free to do whatever you wish. BC From barney_cordoba at yahoo.com Fri Jun 19 14:59:55 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri Jun 19 15:00:07 2009 Subject: mbuf layout optimizations Message-ID: <603332.84337.qm@web63906.mail.re1.yahoo.com> --- On Fri, 6/19/09, Jeff Roberson wrote: > From: Jeff Roberson > Subject: mbuf layout optimizations > To: net@freebsd.org, current@freebsd.org > Date: Friday, June 19, 2009, 5:12 AM > http://people.freebsd.org/~jeff/mbuf2.diff > > Hello, > > This is a call for testers and feedback on my mbuf layout > improvements. I'm trying to decide whether I will push to > have these included in 8.0. After reducing the scope > slightly from my last patch, I have not encountered any > problems.? Kip Macy has also been using it for the past > few weeks without issue. > > You should not expect any functional changes from this > patch.? The goal is mostly to pave the way fors more > sensible mbuf handling in the future, although it does offer > a few performance benefits. > > The only issue is that cxgb support requires another set of > patches from Kip.? If anyone needs those I will prod > him to reply with that diff. > > Thanks, > Jeff I thought that the purpose of m_tags was to keep individual applications from having to "patch" mbufs. Has that idea proven to be too performance-challenged? Barney From freebsdusb at bindone.de Fri Jun 19 15:39:15 2009 From: freebsdusb at bindone.de (Michael) Date: Fri Jun 19 15:39:22 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces In-Reply-To: <436489.18496.qm@web63904.mail.re1.yahoo.com> References: <436489.18496.qm@web63904.mail.re1.yahoo.com> Message-ID: <4A3BB0F3.80005@bindone.de> Barney Cordoba wrote: > > > --- On Wed, 6/17/09, Michael wrote: > >> From: Michael >> Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces >> To: freebsd-net@FreeBSD.org >> Date: Wednesday, June 17, 2009, 9:40 PM >> The following reply was made to PR >> kern/135222; it has been noted by GNATS. >> >> From: Michael >> To: Barney Cordoba >> Cc: freebsd-gnats-submit@FreeBSD.org >> Subject: Re: kern/135222: [igb] low speed routing between >> two igb interfaces >> Date: Thu, 18 Jun 2009 03:32:15 +0200 >> >> Barney Cordoba wrote: >> > >> > >> > --- On Wed, 6/17/09, Michael >> wrote: >> > >> >> From: Michael >> >> Subject: Re: kern/135222: [igb] low speed routing >> between two igb interfaces >> >> To: "Barney Cordoba" >> >> Cc: freebsd-net@FreeBSD.org >> >> Date: Wednesday, June 17, 2009, 5:28 PM >> >> Barney Cordoba wrote: >> >>> >> >>> --- On Fri, 6/12/09, Michael >> >> wrote: >> >>>> From: Michael >> >>>> Subject: Re: kern/135222: [igb] low speed >> routing >> >> between two igb interfaces >> >>>> To: freebsd-net@FreeBSD.org >> >>>> Date: Friday, June 12, 2009, 5:50 AM >> >>>> The following reply was made to PR >> >>>> kern/135222; it has been noted by GNATS. >> >>>> >> >>>> From: Michael >> >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org >> >>>> Subject: Re: kern/135222: [igb] low speed >> routing >> >> between >> >>>> two igb interfaces >> >>>> Date: Fri, 12 Jun 2009 11:45:47 +0200 >> >>>> >> >>>> The original poster >> reported that the >> >> suggested fix works >> >>>> for him: >> >>>> --- >> >>>> Hello Michael, >> >>>> >> >>>> Thank you. It's >> working. >> >>>> >> >>>> I consider it necessary >> to put this into the >> >> release >> >>>> errata. >> >>>> >> >>>> >> >>>> Mishustin Andrew wrote: >> >>>> >> Number: >> >> >>>> 135222 >> >>>> >> >> Category: >> >> kern >> >>>> >> >> Synopsis: >> >> [igb] >> >>>> low speed routing between two igb >> interfaces >> >>>> >> >> Confidential: no >> >>>> >> >> Severity: >> >> serious >> >>>> >> >> Priority: >> >> medium >> >>>> >> >> Responsible: >> >> freebsd-bugs >> >>>> >> State: >> >> >> open >> >>>> >> Quarter: >> >> >>>> >> >> Keywords: >> >> >> >>>> >> Date-Required: >> >>>> >> Class: >> >> >> sw-bug >> >>>> >> >> >> Submitter-Id: current-users >> >>>> >> >> Arrival-Date: Wed >> >> Jun 03 >> >>>> 18:30:01 UTC 2009 >> >>>> >> Closed-Date: >> >>>> >> Last-Modified: >> >>>> >> Originator: >> >> Mishustin >> >>>> Andrew >> >>>> >> Release: >> >> >> FreeBSD >> >>>> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE >> amd64 >> >>>> >> Organization: >> >>>> > HNT >> >>>> >> Environment: >> >>>> > FreeBSD test.hnt >> 7.2-RELEASE FreeBSD >> >> 7.2-RELEASE #12: >> >>>> Thu Apr 30 18:28:15 MSD 20 >> >>>> > 09 >> admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC >> >>>> amd64 >> >>>> >> Description: >> >>>> > I made a FreeBSD >> multiprocesor server >> >> to act as >> >>>> simple gateway. >> >>>> > It use onboard >> Intel 82575EB Dual-Port >> >> Gigabit >> >>>> Ethernet Controller. >> >>>> > I observe traffic >> speed near 400 >> >> Kbit/s. >> >>>> > I test both >> interfaces separately - >> >>>> > ftp client work at >> speed near 1 Gbit/s >> >> in both >> >>>> directions. >> >>>> > Then I change NIC >> to old Intel "em" NIC >> >> - gateway >> >>>> work at speed near 1 Gbit/s. >> >>>> > >> >>>> > Looks like a bug in >> igb driver have an >> >> effect upon >> >>>> forwarded traffic. >> >>>> > >> >>>> > If you try >> >>>> > >> hw.igb.enable_aim=0 >> >>>> > The speed is near 1 >> Mbit/s >> >>>> > >> >>>> > hw.igb.rxd, >> hw.igb.txd, "ifconfig -tso" >> >> has no >> >>>> effect. >> >>>> > >> >>>> > Nothing in >> messages.log >> >>>> > >> >>>> > netstat -m >> >>>> > 516/1674/2190 mbufs >> in use >> >> (current/cache/total) >> >>>> > 515/927/1442/66560 >> mbuf clusters in >> >> use >> >>>> (current/cache/total/max) >> >>>> > 515/893 >> mbuf+clusters out of packet >> >> secondary zone in >> >>>> use (current/cache) >> >>>> > 0/44/44/33280 4k >> (page size) jumbo >> >> clusters in use >> >>>> (current/cache/total/max) >> >>>> > 0/0/0/16640 9k >> jumbo clusters in use >> >>>> (current/cache/total/max) >> >>>> > 0/0/0/8320 16k >> jumbo clusters in use >> >>>> (current/cache/total/max) >> >>>> > 1159K/2448K/3607K >> bytes allocated to >> >> network >> >>>> (current/cache/total) >> >>>> > 0/0/0 requests for >> mbufs denied >> >>>> (mbufs/clusters/mbuf+clusters) >> >>>> > 0/0/0 requests for >> jumbo clusters >> >> denied (4k/9k/16k) >> >>>> > 0/0/0 sfbufs in use >> (current/peak/max) >> >>>> > 0 requests for >> sfbufs denied >> >>>> > 0 requests for >> sfbufs delayed >> >>>> > 0 requests for I/O >> initiated by >> >> sendfile >> >>>> > 0 calls to protocol >> drain routines >> >>>> > >> >>>> > I use only IPv4 >> traffic. >> >>>> > >> >>>> >> How-To-Repeat: >> >>>> > On machine with two >> igb interfaces >> >>>> > use rc.conf like >> this: >> >>>> > >> >>>> > >> hostname="test.test" >> >>>> > >> gateway_enable="YES" >> >>>> > ifconfig_igb0="inet >> 10.10.10.1/24" >> >>>> > ifconfig_igb1="inet >> 10.10.11.1/24" >> >>>> > >> >>>> > And try create >> heavy traffic between >> >> two networks. >> >>>> >> Fix: >> >>>> > >> >>>> > >> >>>> >> Release-Note: >> >>>> >> Audit-Trail: >> >>>> >> Unformatted: >> >>>> > >> >> _______________________________________________ >> >>>> > freebsd-bugs@freebsd.org >> >>> >> >>> This is not a bug. Unless you consider poorly >> written >> >> drivers to be bugs. You need to provide your >> tuning >> >> parameters for the card as well otherwise there's >> nothing to >> >> learn. >> >>> The issue is that the driver doesn't address >> the >> >> purpose of the controller; which is to utilize >> >> multiprocessor systems more effectively. The >> effect is that >> >> lock contention actually makes things worse than >> if you just >> >> use a single task as em does. Until the >> multiqueue drivers >> >> are re-written to manage locks properly you are >> best advised >> >> to save your money and stick with em. >> >>> You should get similar performance using 1 >> queue as >> >> with em. You could also force legacy >> configuration by >> >> forcing igb_setup_msix to return 0. Sadly, this >> is the best >> >> performance you will get from the stock driver. >> >>> Barney >> >>> >> >>> Barney >> >>> >> >>> >> >>> >> >> I tried using 1 queue and it didn't make things >> any better >> >> (actually I'm >> >> not sure if that worked at all). If it is >> considered a bug >> >> or not >> >> doesn't really matter, what actually matters for >> users (who >> >> cannot >> >> always chose which network controller will be >> on-board) is >> >> that they get >> >> a least decent performance when doing IP >> forwarding (and >> >> not the >> >> 5-50kb/s I've seen). You can get this out of the >> >> controller, when >> >> disabling lro through the sysctl. That's why I've >> been >> >> asking to put >> >> this into the release errata section and/or at >> least the >> >> igb man page, >> >> because the sysctl isn't documented anywhere. >> Also the >> >> fact, that tuning >> >> the sysctl only affects the behaviour when it's >> set on boot >> >> might be >> >> considered problematic. >> >> >> >> So at the very least, I think the following >> should be >> >> done: >> >> 1. Document the sysctl in man igb(4) >> >> 2. Put a known issues paragraph to man igb(4) >> which >> >> explains the issue >> >> and what to put in sysctl.conf to stop this from >> happening >> >> 3. Add an entry to the release errata page about >> this issue >> >> (like I >> >> suggested in one of my earlier emails) and >> stating >> >> something like "see >> >> man igb(4) for details) >> >> >> >> This is not about using the controller to its >> full >> >> potential, but to >> >> safe Joe Admin from spending days on figuring out >> why the >> >> machine is >> >> forwarding packages slower than his BSD 2.x >> machine did in >> >> the 90s. >> >> >> >> cheers >> >> Michael >> > >> > None of the offload crap should be enabled by >> default. >> > >> > The real point is that "Joe Admin" shouldn't be using >> controllers that have bad drivers at all. If you have to use >> whatever hardware you have laying around, and don't have >> enough flexibility to lay out $100 for a 2 port controller >> that works to use with your $2000 server, than you need to >> get your priorities in order. People go out and buy >> redundant power supplies, high GHZ quad core processors and >> gobs of memory and then they use whatever crappy onboard >> controller they get no matter how poorly its suppo rted. Its >> mindless. >> > >> > Barney >> > >> > >> > >> >> How should anybody know that the controller is poorly >> supported if there >> is nothing in the documentation, release notes, man pages >> or anywhere >> else about this? >> >> The fact of the matter is that "the offload crap" _is_ >> enabled by >> default. The release is out, it claims to support the >> controller. There >> _is_ a workaround and I'm asked if somebody could document >> this so users >> will have a chance. I'm also not convinced that it is a >> crappy >> controller per se, but just poorly supported. We used >> those a lot before >> without any issues, unfortunately now we had touse IP >> forwarding in a >> machine that has that controller (it has 6 interfaces in >> total, four em >> ports and two igb ports, all of them are in use and I >> don't feel like >> hooking up the sodering iron). >> >> So bottomline: >> I said, there is a problem with the driver, there is a >> workaround and it >> should be documented. >> >> You say, the driver is bad and nobody should use it and if >> they do it's >> their own damn fault. We won't do anything about it and >> refuse to tell >> anybody, because we are the only ones who should know. We >> don't care if >> people can actually use our software and still claim the >> hardware is >> actually supported. >> >> Your attitude is really contra productive (actually >> googling around I >> see you made similar statements in the past about >> stupid people not >> willing to spend xxx$ on whatever piece of hardware, so >> maybe you're >> just trolling). >> >> Michael > > Tuning the card to be brain-dead isn't really a workaround. I'm sorry that you're not able to understand, but you can't educate the woodchucks, so carry on and feel free to do whatever you wish. > > BC > > > Without tuning the card: 5kb/s, with tuning the card: 50mb/s That's the definition of a workaround, the fix would be making lro work correctly - in general I prefer a brain-dead card to a brain-dead mailing list subscriber. Welcome to the real world :) Anyway, I'll stop feeding you now, this is getting boring and leads nowhere. I still think that this should be noted somewhere in the docs, whoever has permissions to commit might proceed in doing so... From barney_cordoba at yahoo.com Fri Jun 19 16:01:30 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri Jun 19 16:01:37 2009 Subject: kern/135222: [igb] low speed routing between two igb interfaces Message-ID: <904439.18775.qm@web63908.mail.re1.yahoo.com> --- On Fri, 6/19/09, Michael wrote: > From: Michael > Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces > To: "Barney Cordoba" > Cc: freebsd-net@FreeBSD.org > Date: Friday, June 19, 2009, 11:38 AM > Barney Cordoba wrote: > > > > > > --- On Wed, 6/17/09, Michael > wrote: > > > >> From: Michael > >> Subject: Re: kern/135222: [igb] low speed routing > between two igb interfaces > >> To: freebsd-net@FreeBSD.org > >> Date: Wednesday, June 17, 2009, 9:40 PM > >> The following reply was made to PR > >> kern/135222; it has been noted by GNATS. > >> > >> From: Michael > >> To: Barney Cordoba > >> Cc: freebsd-gnats-submit@FreeBSD.org > >> Subject: Re: kern/135222: [igb] low speed routing > between > >> two igb interfaces > >> Date: Thu, 18 Jun 2009 03:32:15 +0200 > >> > >>? Barney Cordoba wrote: > >>? > > >>? > > >>? > --- On Wed, 6/17/09, Michael > >> wrote: > >>? > > >>? >> From: Michael > >>? >> Subject: Re: kern/135222: [igb] low > speed routing > >> between two igb interfaces > >>? >> To: "Barney Cordoba" > >>? >> Cc: freebsd-net@FreeBSD.org > >>? >> Date: Wednesday, June 17, 2009, > 5:28 PM > >>? >> Barney Cordoba wrote: > >>? >>> > >>? >>> --- On Fri, 6/12/09, Michael > > >>? >> wrote: > >>? >>>> From: Michael > >>? >>>> Subject: Re: kern/135222: > [igb] low speed > >> routing > >>? >> between two igb interfaces > >>? >>>> To: freebsd-net@FreeBSD.org > >>? >>>> Date: Friday, June 12, > 2009, 5:50 AM > >>? >>>> The following reply was > made to PR > >>? >>>> kern/135222; it has been > noted by GNATS. > >>? >>>> > >>? >>>> From: Michael > >>? >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org > >>? >>>> Subject: Re: kern/135222: > [igb] low speed > >> routing > >>? >> between > >>? >>>> two igb interfaces > >>? >>>> Date: Fri, 12 Jun 2009 > 11:45:47 +0200 > >>? >>>> > >>? >>>>???The > original poster > >> reported that the > >>? >> suggested fix works > >>? >>>> for him: > >>? >>>>???--- > >>? >>>>???Hello > Michael, > >>? >>>>??? > >>? >>>>???Thank you. > It's > >> working. > >>? >>>>??? > >>? >>>>???I consider > it necessary > >> to put this into the > >>? >> release > >>? >>>> errata. > >>? >>>>??? > >>? >>>>??? > >>? >>>>???Mishustin > Andrew wrote: > >>? >>>>???>> > Number: > >>? ? > >>? >>>>? > ???135222 > >>? >>>>???>> > >> Category:??? > >>? >>? ? kern > >>? >>>>???>> > >> Synopsis:??? > >>? >>? ? [igb] > >>? >>>> low speed routing between > two igb > >> interfaces > >>? >>>>???>> > >> Confidential:???no > >>? >>>>???>> > >> Severity:??? > >>? >>? ? serious > >>? >>>>???>> > >> Priority:??? > >>? >>? ? medium > >>? >>>>???>> > >> Responsible:??? > >>? >> freebsd-bugs > >>? >>>>???>> > State: > >>? ? ? > >>? >>???open > >>? >>>>???>> > Quarter: > >>? ? ? > >>? >>>>???>> > >> Keywords:??? > >>? >>? ? > >>? >>>>???>> > Date-Required: > >>? >>>>???>> > Class: > >>? ? ? > >>? >>???sw-bug > >>? >>>>???>> > >>? >> > Submitter-Id:???current-users > >>? >>>>???>> > >> Arrival-Date:???Wed > >>? >> Jun 03 > >>? >>>> 18:30:01 UTC 2009 > >>? >>>>???>> > Closed-Date: > >>? >>>>???>> > Last-Modified: > >>? >>>>???>> > Originator: > >>? >>? ? Mishustin > >>? >>>> Andrew > >>? >>>>???>> > Release: > >>? ? ? > >>? >> FreeBSD > >>? >>>> 7.1-RELEASE amd64, FreeBSD > 7.2-RELEASE > >> amd64 > >>? >>>>???>> > Organization: > >>? >>>>???> HNT > >>? >>>>???>> > Environment: > >>? >>>>???> > FreeBSD test.hnt > >> 7.2-RELEASE FreeBSD > >>? >> 7.2-RELEASE #12: > >>? >>>> Thu Apr 30 18:28:15 MSD 20 > >>? >>>>???> 09 > >>? ? admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC > >>? >>>> amd64 > >>? >>>>???>> > Description: > >>? >>>>???> I > made a FreeBSD > >> multiprocesor server > >>? >> to act as > >>? >>>> simple gateway. > >>? >>>>???> It > use onboard > >> Intel 82575EB Dual-Port > >>? >> Gigabit > >>? >>>> Ethernet Controller. > >>? >>>>???> I > observe traffic > >> speed near 400 > >>? >> Kbit/s. > >>? >>>>???> I > test both > >> interfaces separately - > >>? >>>>???> ftp > client work at > >> speed near 1 Gbit/s > >>? >> in both > >>? >>>> directions. > >>? >>>>???> Then > I change NIC > >> to old Intel "em" NIC > >>? >> - gateway > >>? >>>> work at speed near 1 > Gbit/s. > >>? >>>>???> > >>? >>>>???> Looks > like a bug in > >> igb driver have an > >>? >> effect upon > >>? >>>> forwarded traffic. > >>? >>>>???> > >>? >>>>???> If > you try > >>? >>>>???> > >> hw.igb.enable_aim=0 > >>? >>>>???> The > speed is near 1 > >> Mbit/s > >>? >>>>???> > >>? >>>>???> > hw.igb.rxd, > >> hw.igb.txd, "ifconfig -tso" > >>? >> has no > >>? >>>> effect. > >>? >>>>???> > >>? >>>>???> > Nothing in > >> messages.log > >>? >>>>???> > >>? >>>>???> > netstat -m > >>? >>>>???> > 516/1674/2190 mbufs > >> in use > >>? >> (current/cache/total) > >>? >>>>???> > 515/927/1442/66560 > >> mbuf clusters in > >>? >> use > >>? >>>> (current/cache/total/max) > >>? >>>>???> > 515/893 > >> mbuf+clusters out of packet > >>? >> secondary zone in > >>? >>>> use (current/cache) > >>? >>>>???> > 0/44/44/33280 4k > >> (page size) jumbo > >>? >> clusters in use > >>? >>>> (current/cache/total/max) > >>? >>>>???> > 0/0/0/16640 9k > >> jumbo clusters in use > >>? >>>> (current/cache/total/max) > >>? >>>>???> > 0/0/0/8320 16k > >> jumbo clusters in use > >>? >>>> (current/cache/total/max) > >>? >>>>???> > 1159K/2448K/3607K > >> bytes allocated to > >>? >> network > >>? >>>> (current/cache/total) > >>? >>>>???> 0/0/0 > requests for > >> mbufs denied > >>? >>>> > (mbufs/clusters/mbuf+clusters) > >>? >>>>???> 0/0/0 > requests for > >> jumbo clusters > >>? >> denied (4k/9k/16k) > >>? >>>>???> 0/0/0 > sfbufs in use > >> (current/peak/max) > >>? >>>>???> 0 > requests for > >> sfbufs denied > >>? >>>>???> 0 > requests for > >> sfbufs delayed > >>? >>>>???> 0 > requests for I/O > >> initiated by > >>? >> sendfile > >>? >>>>???> 0 > calls to protocol > >> drain routines > >>? >>>>???> > >>? >>>>???> I use > only IPv4 > >> traffic. > >>? >>>>???> > >>? >>>>???>> > How-To-Repeat: > >>? >>>>???> On > machine with two > >> igb interfaces > >>? >>>>???> use > rc.conf like > >> this: > >>? >>>>???> > >>? >>>>???> > >> hostname="test.test" > >>? >>>>???> > >> gateway_enable="YES" > >>? >>>>???> > ifconfig_igb0="inet > >> 10.10.10.1/24" > >>? >>>>???> > ifconfig_igb1="inet > >> 10.10.11.1/24" > >>? >>>>???> > >>? >>>>???> And > try create > >> heavy traffic between > >>? >> two networks. > >>? >>>>???>> > Fix: > >>? >>>>???> > >>? >>>>???> > >>? >>>>???>> > Release-Note: > >>? >>>>???>> > Audit-Trail: > >>? >>>>???>> > Unformatted: > >>? >>>>???> > >>? >> > _______________________________________________ > >>? >>>>???> freebsd-bugs@freebsd.org > >>? >>> > >>? >>> This is not a bug. Unless you > consider poorly > >> written > >>? >> drivers to be bugs. You need to > provide your > >> tuning > >>? >> parameters for the card as well > otherwise there's > >> nothing to > >>? >> learn. > >>? >>> The issue is that the driver > doesn't address > >> the > >>? >> purpose of the controller; which is > to utilize > >>? >> multiprocessor systems more > effectively. The > >> effect is that > >>? >> lock contention actually makes > things worse than > >> if you just > >>? >> use a single task as em does. Until > the > >> multiqueue drivers > >>? >> are re-written to manage locks > properly you are > >> best advised > >>? >> to save your money and stick with > em. > >>? >>> You should get similar > performance using 1 > >> queue as > >>? >> with em. You could also force > legacy > >> configuration by > >>? >> forcing igb_setup_msix to return 0. > Sadly, this > >> is the best > >>? >> performance you will get from the > stock driver. > >>? >>> Barney > >>? >>> > >>? >>> Barney > >>? >>> > >>? >>> > >>? >>>? ? ? ? > >>? >> I tried using 1 queue and it didn't > make things > >> any better > >>? >> (actually I'm > >>? >> not sure if that worked at all). If > it is > >> considered a bug > >>? >> or not > >>? >> doesn't really matter, what > actually matters for > >> users (who > >>? >> cannot > >>? >> always chose which network > controller will be > >> on-board) is > >>? >> that they get > >>? >> a least decent performance when > doing IP > >> forwarding (and > >>? >> not the > >>? >> 5-50kb/s I've seen). You can get > this out of the > >>? >> controller, when > >>? >> disabling lro through the sysctl. > That's why I've > >> been > >>? >> asking to put > >>? >> this into the release errata > section and/or at > >> least the > >>? >> igb man page, > >>? >> because the sysctl isn't documented > anywhere. > >> Also the > >>? >> fact, that tuning > >>? >> the sysctl only affects the > behaviour when it's > >> set on boot > >>? >> might be > >>? >> considered problematic. > >>? >> > >>? >> So at the very least, I think the > following > >> should be > >>? >> done: > >>? >> 1. Document the sysctl in man > igb(4) > >>? >> 2. Put a known issues paragraph to > man igb(4) > >> which > >>? >> explains the issue > >>? >> and what to put in sysctl.conf to > stop this from > >> happening > >>? >> 3. Add an entry to the release > errata page about > >> this issue > >>? >> (like I > >>? >> suggested in one of my earlier > emails) and > >> stating > >>? >> something like "see > >>? >> man igb(4) for details) > >>? >> > >>? >> This is not about using the > controller to its > >> full > >>? >> potential, but to > >>? >> safe Joe Admin from spending days > on figuring out > >> why the > >>? >> machine is > >>? >> forwarding packages slower than his > BSD 2.x > >> machine did in > >>? >> the 90s. > >>? >> > >>? >> cheers > >>? >> Michael > >>? > > >>? > None of the offload crap should be > enabled by > >> default. > >>? > > >>? > The real point is that "Joe Admin" > shouldn't be using > >> controllers that have bad drivers at all. If you > have to use > >> whatever hardware you have laying around, and > don't have > >> enough flexibility to lay out $100 for a 2 port > controller > >> that works to use with your $2000 server, than you > need to > >> get your priorities in order. People go out and > buy > >> redundant power supplies, high GHZ quad core > processors and > >> gobs of memory and then they use whatever crappy > onboard > >> controller they get no matter how poorly its suppo > rted. Its > >> mindless. > >>? > > >>? > Barney > >>? > > >>? > > >>? >? ? ??? > >>? > >>? How should anybody know that the controller > is poorly > >> supported if there > >>? is nothing in the documentation, release > notes, man pages > >> or anywhere > >>? else about this? > >>? > >>? The fact of the matter is that "the offload > crap" _is_ > >> enabled by > >>? default. The release is out, it claims to > support the > >> controller. There > >>? _is_ a workaround and I'm asked if somebody > could document > >> this so users > >>? will have a chance. I'm also not convinced > that it is a > >> crappy > >>? controller per se, but just poorly > supported. We used > >> those a lot before > >>? without any issues, unfortunately now we had > touse IP > >> forwarding in a > >>? machine that has that controller (it has 6 > interfaces in > >> total, four em > >>? ports and two igb ports, all of them are in > use and I > >> don't feel like > >>? hooking up the sodering iron). > >>? > >>? So bottomline: > >>? I said, there is a problem with the driver, > there is a > >> workaround and it > >>? should be documented. > >>? > >>? You say, the driver is bad and nobody should > use it and if > >> they do it's > >>? their own damn fault. We won't do anything > about it and > >> refuse to tell > >>? anybody, because we are the only ones who > should know. We > >> don't care if > >>? people can actually use our software and > still claim the > >> hardware is > >>? actually supported. > >>? > >>? Your attitude is really contra productive > (actually > >> googling around I > >>? see? you made similar statements in the > past about > >> stupid people not > >>? willing to spend xxx$ on whatever piece of > hardware, so > >> maybe you're > >>? just trolling). > >>? > >>? Michael > > > > Tuning the card to be brain-dead isn't really a > workaround. I'm sorry that you're not able to understand, > but you can't educate the woodchucks, so carry on and feel > free to do whatever you wish. > > > > BC > > > > > >? ? ??? > > Without tuning the card: 5kb/s, with tuning the card: > 50mb/s > That's the definition of a workaround, the fix would be > making lro work > correctly - in general I prefer a brain-dead card to a > brain-dead > mailing list subscriber. Welcome to the real world :) > > Anyway, I'll stop feeding you now, this is getting boring > and leads nowhere. > > I still think that this should be noted somewhere in the > docs, whoever > has permissions to commit might proceed in doing so... > _______________________________________________ > 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" > Ignorance is Bliss, as they say. BC From jroberson at jroberson.net Fri Jun 19 17:43:15 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Fri Jun 19 17:43:22 2009 Subject: mbuf layout optimizations In-Reply-To: <603332.84337.qm@web63906.mail.re1.yahoo.com> References: <603332.84337.qm@web63906.mail.re1.yahoo.com> Message-ID: On Fri, 19 Jun 2009, Barney Cordoba wrote: > > > > --- On Fri, 6/19/09, Jeff Roberson wrote: > >> From: Jeff Roberson >> Subject: mbuf layout optimizations >> To: net@freebsd.org, current@freebsd.org >> Date: Friday, June 19, 2009, 5:12 AM >> http://people.freebsd.org/~jeff/mbuf2.diff >> >> Hello, >> >> This is a call for testers and feedback on my mbuf layout >> improvements. I'm trying to decide whether I will push to >> have these included in 8.0. After reducing the scope >> slightly from my last patch, I have not encountered any >> problems.? Kip Macy has also been using it for the past >> few weeks without issue. >> >> You should not expect any functional changes from this >> patch.? The goal is mostly to pave the way fors more >> sensible mbuf handling in the future, although it does offer >> a few performance benefits. >> >> The only issue is that cxgb support requires another set of >> patches from Kip.? If anyone needs those I will prod >> him to reply with that diff. >> >> Thanks, >> Jeff > > I thought that the purpose of m_tags was to keep individual applications from having to "patch" mbufs. Has that idea proven to be too > performance-challenged? m_tags are unrelated to this diff. This addresses the fundamental memory allocation mechanisms and layout of the mbuf. It reduces the amount of book keeping necessary and makes reference counts more pervasive. Thanks, Jeff > > Barney > From hartmut.brandt at dlr.de Fri Jun 19 17:44:35 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Fri Jun 19 17:44:42 2009 Subject: TCP bug? Message-ID: <20090619191756.R581@beagle.kn.op.dlr.de> Hi all, one of my TCP test cases breaks in what one could call an edge case: When the TCP is in SYN-SENT state (the user has called connect()) and the peer answers with an almost-lamp test packet which has SYN, FIN, ACK and data larger than the window, TCP ACKs a window full of data, drops the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to me. When dropping the data that is outside the window, it should also drop the FIN. The problem seems to be very old - I found it alread in rev. 1.1 of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of the incoming segment is the next expected one, the reassembly queue is empty and we are in an established state, the segment data is added to the socket buffer and all TCP header flags are cleared except for TH_FIN. Unfortunately here the original header flags are taken instead of the cached version in thflags. Earlier in the processing the out-of-window data and the FIN in thflags were chopped off and now TH_FIN reappears. The fix should be easy: instead of using the original flag byte to get the FIN use the cached copy. Index: tcp_input.c =================================================================== --- tcp_input.c (revision 194499) +++ tcp_input.c (working copy) @@ -2587,7 +2587,7 @@ else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt += tlen; - thflags = th->th_flags & TH_FIN; + thflags &= TH_FIN; TCPSTAT_INC(tcps_rcvpack); TCPSTAT_ADD(tcps_rcvbyte, tlen); ND6_HINT(tp); I wonder, though, why the code is as it is, i.e. why it takes the original FIN flag. Any idea? harti From hartmut.brandt at dlr.de Fri Jun 19 17:58:33 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Fri Jun 19 17:58:42 2009 Subject: TCP bug? Message-ID: <20090619194608.W697@beagle.kn.op.dlr.de> Hi all, one of my TCP test cases breaks in what one could call an edge case: When the TCP is in SYN-SENT state (the user has called connect()) and the peer answers with an almost-lamp test packet which has SYN, FIN, ACK and data larger than the window, TCP ACKs a window full of data, drops the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to me. When dropping the data that is outside the window, it should also drop the FIN. The problem seems to be very old - I found it alread in rev. 1.1 of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of the incoming segment is the next expected one, the reassembly queue is empty and we are in an established state, the segment data is added to the socket buffer and all TCP header flags are cleared except for TH_FIN. Unfortunately here the original header flags are taken instead of the cached version in thflags. Earlier in the processing the out-of-window data and the FIN in thflags were chopped off and now TH_FIN reappears. The fix should be easy: instead of using the original flag byte to get the FIN use the cached copy. Index: tcp_input.c =================================================================== --- tcp_input.c (revision 194499) +++ tcp_input.c (working copy) @@ -2587,7 +2587,7 @@ else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt += tlen; - thflags = th->th_flags & TH_FIN; + thflags &= TH_FIN; TCPSTAT_INC(tcps_rcvpack); TCPSTAT_ADD(tcps_rcvbyte, tlen); ND6_HINT(tp); I wonder, though, why the code is as it is, i.e. why it takes the original FIN flag. Any idea? harti From cswiger at mac.com Fri Jun 19 19:32:58 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Jun 19 19:33:05 2009 Subject: TCP bug? In-Reply-To: <20090619191756.R581@beagle.kn.op.dlr.de> References: <20090619191756.R581@beagle.kn.op.dlr.de> Message-ID: <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> Hi-- On Jun 19, 2009, at 10:44 AM, Harti Brandt wrote: > When the TCP is in SYN-SENT state (the user has called connect()) > and the peer answers with an almost-lamp test packet which has SYN, > FIN, ACK and data larger than the window, TCP ACKs a window full of > data, drops the rest, but processes the FIN - it goes into > CLOSE_WAIT. This looks wrong to me. When dropping the data that is > outside the window, it should also drop the FIN. Clearly, you shouldn't process a FIN which happens outside of the current window: "For sequence number purposes, the SYN is considered to occur before the first actual data octet of the segment in which it occurs, while the FIN is considered to occur after the last actual data octet in a segment in which it occurs." If the socket was in a synchronized state, RFC-793 pg 37 says: "3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state." ...if it's before the connection is fully setup, ie, in SYN-SENT state as you say, then the fact that the packet contains data which does not fit in the window suggests it should be handled by the rules for half- open connections: "As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case." See figure 12-- I think you should be sending a RST back.... Regards, -- -Chuck From kfl at xiplink.com Fri Jun 19 19:55:37 2009 From: kfl at xiplink.com (Karim Fodil-Lemelin) Date: Fri Jun 19 19:55:42 2009 Subject: TCP bug? In-Reply-To: <20090619194608.W697@beagle.kn.op.dlr.de> References: <20090619194608.W697@beagle.kn.op.dlr.de> Message-ID: <4A3BE910.6080502@xiplink.com> Hi There, Looking at Steven's book TCP/IP Volume 2 (1995 edition) page 988 (Processing and Received Data) they call TCP_REASS(tp, ti, m, so, tiflags) where tiflags is thflags and inside the TCP_REASS macro (page 908), this code is used (where ti is the tcpiphdr pointer): flags = (ti)->ti_flags & TH_FIN; \ Same problem there as well ... Also, looking at tcp_reass(), the same approach of using the header version is used there: flags = q->tqe_th->th_flags & TH_FIN; This seems to work since the data was kept inside the reassembly queue and not dropped If this problem is confirmed you've probably found an original implementation bug. Can you describe better the test condition to reproduce this problem? Cheers, Karim. Harti Brandt wrote: > > Hi all, > > one of my TCP test cases breaks in what one could call an edge case: > > When the TCP is in SYN-SENT state (the user has called connect()) and the > peer answers with an almost-lamp test packet which has SYN, FIN, ACK and > data larger than the window, TCP ACKs a window full of data, drops the > rest, but processes the FIN - it goes into CLOSE_WAIT. This looks > wrong to > me. When dropping the data that is outside the window, it should also > drop > the FIN. > > The problem seems to be very old - I found it alread in rev. 1.1 > of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number > of the incoming segment is the next expected one, the reassembly queue is > empty and we are in an established state, the segment data is added to > the > socket buffer and all TCP header flags are cleared except for TH_FIN. > Unfortunately here the original header flags are taken instead of the > cached version in thflags. Earlier in the processing the out-of-window > data and the FIN in thflags were chopped off and now TH_FIN reappears. > > The fix should be easy: instead of using the original flag byte to get > the > FIN use the cached copy. > > Index: tcp_input.c > =================================================================== > --- tcp_input.c (revision 194499) > +++ tcp_input.c (working copy) > @@ -2587,7 +2587,7 @@ > else > tp->t_flags |= TF_ACKNOW; > tp->rcv_nxt += tlen; > - thflags = th->th_flags & TH_FIN; > + thflags &= TH_FIN; > TCPSTAT_INC(tcps_rcvpack); > TCPSTAT_ADD(tcps_rcvbyte, tlen); > ND6_HINT(tp); > > I wonder, though, why the code is as it is, i.e. why it takes the > original > FIN flag. Any idea? > > harti > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From hartmut.brandt at dlr.de Fri Jun 19 20:04:52 2009 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Fri Jun 19 20:04:59 2009 Subject: TCP bug? In-Reply-To: <4A3BE910.6080502@xiplink.com> References: <20090619194608.W697@beagle.kn.op.dlr.de> <4A3BE910.6080502@xiplink.com> Message-ID: <20090619215930.V970@beagle.kn.op.dlr.de> Hi, On Fri, 19 Jun 2009, Karim Fodil-Lemelin wrote: KF>Looking at Steven's book TCP/IP Volume 2 (1995 edition) page 988 (Processing KF>and Received Data) they call TCP_REASS(tp, ti, m, so, tiflags) where tiflags KF>is thflags and inside the TCP_REASS macro (page 908), this code is used KF>(where ti is the tcpiphdr pointer): KF> KF>flags = (ti)->ti_flags & TH_FIN; \ KF> KF>Same problem there as well ... KF> KF>Also, looking at tcp_reass(), the same approach of using the header version KF>is used there: KF> KF>flags = q->tqe_th->th_flags & TH_FIN; KF> KF>This seems to work since the data was kept inside the reassembly queue and KF>not dropped KF> KF>If this problem is confirmed you've probably found an original implementation KF>bug. Can you describe better the test condition to reproduce this problem? Sure. I've a test environment for TCP which does for this test the following: - open a TCP socket, set the socket send buffer to 32768 byte - call connect() and expect SYN seq= win=32768 - tester responds with SYN, FIN, ACK= data=(41000 bytes) seq= - expect ACK= seq= - check that TCP is in EsTABLISHED state Everything is fine except that TCP ends up in CLOSE_WAIT. harti KF>Harti Brandt wrote: KF>> KF>> Hi all, KF>> KF>> one of my TCP test cases breaks in what one could call an edge case: KF>> KF>> When the TCP is in SYN-SENT state (the user has called connect()) and the KF>> peer answers with an almost-lamp test packet which has SYN, FIN, ACK and KF>> data larger than the window, TCP ACKs a window full of data, drops the KF>> rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to KF>> me. When dropping the data that is outside the window, it should also drop KF>> the FIN. KF>> KF>> The problem seems to be very old - I found it alread in rev. 1.1 KF>> of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number KF>> of the incoming segment is the next expected one, the reassembly queue is KF>> empty and we are in an established state, the segment data is added to the KF>> socket buffer and all TCP header flags are cleared except for TH_FIN. KF>> Unfortunately here the original header flags are taken instead of the KF>> cached version in thflags. Earlier in the processing the out-of-window KF>> data and the FIN in thflags were chopped off and now TH_FIN reappears. KF>> KF>> The fix should be easy: instead of using the original flag byte to get the KF>> FIN use the cached copy. KF>> KF>> Index: tcp_input.c KF>> =================================================================== KF>> --- tcp_input.c (revision 194499) KF>> +++ tcp_input.c (working copy) KF>> @@ -2587,7 +2587,7 @@ KF>> else KF>> tp->t_flags |= TF_ACKNOW; KF>> tp->rcv_nxt += tlen; KF>> - thflags = th->th_flags & TH_FIN; KF>> + thflags &= TH_FIN; KF>> TCPSTAT_INC(tcps_rcvpack); KF>> TCPSTAT_ADD(tcps_rcvbyte, tlen); KF>> ND6_HINT(tp); KF>> KF>> I wonder, though, why the code is as it is, i.e. why it takes the original KF>> FIN flag. Any idea? KF>> KF>> harti KF>> KF>> _______________________________________________ KF>> freebsd-net@freebsd.org mailing list KF>> http://lists.freebsd.org/mailman/listinfo/freebsd-net KF>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" KF> KF> From hartmut.brandt at dlr.de Fri Jun 19 20:15:42 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Fri Jun 19 20:15:49 2009 Subject: TCP bug? In-Reply-To: <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> References: <20090619191756.R581@beagle.kn.op.dlr.de> <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> Message-ID: <20090619220901.Y970@beagle.kn.op.dlr.de> Hi, On Fri, 19 Jun 2009, Chuck Swiger wrote: CS>On Jun 19, 2009, at 10:44 AM, Harti Brandt wrote: CS>> When the TCP is in SYN-SENT state (the user has called connect()) and the CS>> peer answers with an almost-lamp test packet which has SYN, FIN, ACK and CS>> data larger than the window, TCP ACKs a window full of data, drops the CS>> rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to CS>> me. When dropping the data that is outside the window, it should also drop CS>> the FIN. CS> CS>Clearly, you shouldn't process a FIN which happens outside of the current CS>window: "For sequence number purposes, the SYN is considered to occur before CS>the first actual data octet of the segment in which it occurs, while the FIN CS>is considered to occur after the last actual data octet in a segment in which CS>it occurs." CS> CS>If the socket was in a synchronized state, RFC-793 pg 37 says: CS> CS>"3. If the connection is in a synchronized state (ESTABLISHED, CS> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), CS> any unacceptable segment (out of window sequence number or CS> unacceptible acknowledgment number) must elicit only an empty CS> acknowledgment segment containing the current send-sequence number CS> and an acknowledgment indicating the next sequence number expected CS> to be received, and the connection remains in the same state." CS> CS>...if it's before the connection is fully setup, ie, in SYN-SENT state as you CS>say, then the fact that the packet contains data which does not fit in the CS>window suggests it should be handled by the rules for half-open connections: CS> CS> "As a general rule, reset (RST) must be sent whenever a segment arrives CS> which apparently is not intended for the current connection. A reset CS> must not be sent if it is not clear that this is the case." CS> CS>See figure 12-- I think you should be sending a RST back.... I think this is too drastic. A segment is unacceptable only if it is completly out of the window. Here part is in the window. Also conceptually TCP enters the ESTABLISHED state as soon as it finds that the ACK in the SYN,ACK is correct before it starts to process the data and the FIN (p.68 of RFC793 - first you enter ESTABLISHED and ACK, then you goto step 6). So taking into account the explanation at top of page 70 (which logically belongs to step 6) you just drop everything outside the window - part of the data and the FIN in our case - and proceed. Note, that the data in the SYN,ACK is always partly in the window because this segment contains the IRS, except if the window is 0 and the segment contains data or FIN. harti From andre at freebsd.org Fri Jun 19 20:46:22 2009 From: andre at freebsd.org (Andre Oppermann) Date: Fri Jun 19 20:46:28 2009 Subject: TCP bug? In-Reply-To: <20090619191756.R581@beagle.kn.op.dlr.de> References: <20090619191756.R581@beagle.kn.op.dlr.de> Message-ID: <4A3BF2DF.6080603@freebsd.org> Harti Brandt wrote: > Hi all, > > one of my TCP test cases breaks in what one could call an edge case: > > When the TCP is in SYN-SENT state (the user has called connect()) and > the peer answers with an almost-lamp test packet which has SYN, FIN, ACK > and data larger than the window, TCP ACKs a window full of data, drops > the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks > wrong to me. When dropping the data that is outside the window, it > should also drop the FIN. Indeed. > The problem seems to be very old - I found it alread in rev. 1.1 of > tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of > the incoming segment is the next expected one, the reassembly queue is > empty and we are in an established state, the segment data is added to > the socket buffer and all TCP header flags are cleared except for > TH_FIN. Unfortunately here the original header flags are taken instead > of the cached version in thflags. Earlier in the processing the > out-of-window data and the FIN in thflags were chopped off and now > TH_FIN reappears. > > The fix should be easy: instead of using the original flag byte to get > the FIN use the cached copy. ... > I wonder, though, why the code is as it is, i.e. why it takes the > original FIN flag. Any idea? I guess there are two, possibly interrelated, explanations for that bug: 1) there are two code paths in TCP input processing depending on the current state of the connection. The header prediction path and the "slow" path. It's not always easy to keep them in sync. Sometimes adjustments or additions are only made to one of them. 2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN combination was a valid one, though not directly intended for SYN/ACK/FIN. It's easily imaginable that a bug or unforeseen interaction could creep in there. Your proposed patch does exactly the right thing by using the cached copy. I don't see any reason why thflags should be derived from th->th_flags way down here again. -- Andre From bms at incunabulum.net Fri Jun 19 21:35:43 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Jun 19 21:35:50 2009 Subject: TCP bug? In-Reply-To: <4A3BF2DF.6080603@freebsd.org> References: <20090619191756.R581@beagle.kn.op.dlr.de> <4A3BF2DF.6080603@freebsd.org> Message-ID: <4A3C04A8.101@incunabulum.net> Andre Oppermann wrote: > ... > 2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN > combination was a valid one, though not directly intended for > SYN/ACK/FIN. T/TCP has been superseded by SCTP, and should be completely deprecated in the stack, IMHO. I believe this has been done, this could well be a corner case exposed by incomplete removal of T/TCP support. thanks BMS From debsmith at juniper.net Fri Jun 19 21:40:03 2009 From: debsmith at juniper.net (Debra Smith) Date: Fri Jun 19 21:40:10 2009 Subject: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? Message-ID: <497B6D90E0023142AF34948DEFFAB38D396A867EEC@EMBX01-HQ.jnpr.net> Hello: Is it possible to post this opening with you? Thanks for your time... Software Engineer Layer 2 (Kernel/Networking/TCP/IP) As a key member of team, you will be responsible for developing embedded networking software for complex networking platforms. Develop detailed software functional and design specifications and implement the software. Demonstrate good teamwork across various teams. Experience: Requires working knowledge of Layer-2/Layer-3 switching/routing protocols, data forwarding and embedded systems programming. Strong understanding of routing and switching technologies including TCP/IP, 802.3 protocol understanding - 802.1D, 802.1w, 802.1q, 802.1p, 802.1x is required. Hands on experience of TCP/IP stack in linux or BSD kernel. Requires MSEE/MSCS with 5-7 years of related experience or BSEE/CS with 7-9+ years of related experience. From wollman at hergotha.csail.mit.edu Fri Jun 19 21:43:27 2009 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Fri Jun 19 21:43:34 2009 Subject: TCP bug? In-Reply-To: <4A3BF2DF.6080603@freebsd.org> References: <20090619191756.R581@beagle.kn.op.dlr.de> Message-ID: <200906192127.n5JLRTtE042617@hergotha.csail.mit.edu> In article <4A3BF2DF.6080603@freebsd.org>, Andre writes: >2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN > combination was a valid one, though not directly intended for SYN/ACK/FIN. It still is valid, and should be possible to generate using sendmsg() and MSG_EOF. Nothing about this depends on T/TCP, which is solely about reducing the three-way handshake to a two-way handshake. -GAWollman From cswiger at mac.com Fri Jun 19 21:56:40 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Jun 19 21:56:47 2009 Subject: TCP bug? In-Reply-To: <20090619220901.Y970@beagle.kn.op.dlr.de> References: <20090619191756.R581@beagle.kn.op.dlr.de> <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> <20090619220901.Y970@beagle.kn.op.dlr.de> Message-ID: <670B545A-71FD-4591-B466-96B0B8BA046B@mac.com> Hi-- On Jun 19, 2009, at 1:15 PM, Harti Brandt wrote: > CS>See figure 12-- I think you should be sending a RST back.... > > I think this is too drastic. A segment is unacceptable only if it is > completly out of the window. Here part is in the window. Well, perhaps you're right that it would be drastic. I'll agree that the start of the segment falls within the window, at least if the window size is greater than 0. If you decide that the incoming segment is "possibly valid", then the conclusion that you should move to ESTABLISHED, accept and ACK the data which lies within the valid window, and drop/ignore the rest including the FIN seems to be a sensible consequence. Moving to CLOSE_WAIT state is not appropriate until you actually accept and process the sequence # which includes that FIN. > Also conceptually TCP enters the ESTABLISHED state as soon as it > finds that the ACK in the > SYN,ACK is correct before it starts to process the data and the FIN > (p.68 > of RFC793 - first you enter ESTABLISHED and ACK, then you goto step > 6). So > taking into account the explanation at top of page 70 (which logically > belongs to step 6) you just drop everything outside the window - > part of > the data and the FIN in our case - and proceed. > > Note, that the data in the SYN,ACK is always partly in the window > because > this segment contains the IRS, except if the window is 0 and the > segment contains data or FIN. If the window size is 0, only acks without any data are acceptable, but your test case seems to have a non-0 initial window size, so we don't need to belabor that point too much. -- -Chuck From barney_cordoba at yahoo.com Fri Jun 19 23:27:33 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri Jun 19 23:27:40 2009 Subject: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? Message-ID: <387640.9423.qm@web63908.mail.re1.yahoo.com> --- On Fri, 6/19/09, Debra Smith wrote: > From: Debra Smith > Subject: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? > To: "freebsd-net@freebsd.org" > Date: Friday, June 19, 2009, 5:22 PM > Hello: > > Is it possible to post this opening with you? > > Thanks for your time... > > > Software Engineer Layer 2 (Kernel/Networking/TCP/IP) > > As a key member of team, you will be responsible for > developing embedded networking software for complex > networking platforms. Develop detailed software functional > and design specifications and implement the software. > Demonstrate good teamwork across various teams. Experience: > Requires working knowledge of Layer-2/Layer-3 > switching/routing protocols, data forwarding and embedded > systems programming. Strong understanding of routing and > switching technologies including TCP/IP, 802.3 protocol > understanding - 802.1D, 802.1w, 802.1q, 802.1p, 802.1x is > required. Hands on experience of TCP/IP stack in linux or > BSD kernel. Requires MSEE/MSCS with 5-7 years of related > experience or BSEE/CS with 7-9+ years of related > experience. No, you can't. I love these arbitrary degree+years of experience. Why do they say 7-9+ years, instead of just 7+? Are they trying to confuse us? From wmoran at collaborativefusion.com Fri Jun 19 23:57:39 2009 From: wmoran at collaborativefusion.com (Bill Moran) Date: Fri Jun 19 23:57:45 2009 Subject: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? In-Reply-To: <387640.9423.qm@web63908.mail.re1.yahoo.com> References: <387640.9423.qm@web63908.mail.re1.yahoo.com> Message-ID: <20090619194734.ba0f2e6a.wmoran@collaborativefusion.com> Barney Cordoba wrote: > > > experience or BSEE/CS with 7-9+ years of related > > experience. > > No, you can't. > > I love these arbitrary degree+years of experience. Why do they say 7-9+ years, instead of just 7+? Are they trying to confuse us? Up to 30-50% of those requirements are arbitrary anyway ... -- Bill Moran Collaborative Fusion Inc. wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From valeranew at ukr.net Sat Jun 20 08:48:51 2009 From: valeranew at ukr.net (=?WINDOWS-1251?Q? =D1=E8=F1=F2=E5=EC=ED=FB=E9_=E0=E4=EC=E8=ED=E8?= =?WINDOWS-1251?Q?=F1=F2=F0=E0=F2=EE=F0 ?=) Date: Sat Jun 20 08:49:00 2009 Subject: freebsd-net Digest, Vol 324, Issue 5 In-Reply-To: <20090619120024.5E1731065688@hub.freebsd.org> References: <20090619120024.5E1731065688@hub.freebsd.org> Message-ID: --- ???????? ????????? --- ?? ????: freebsd-net-request@freebsd.org ????: freebsd-net@freebsd.org ????: Jun 19, 2009 15:00:24 ????: freebsd-net Digest, Vol 324, Issue 5 Send freebsd-net mailing list submissions to > freebsd-net@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-net > or, via email, send a message with subject or body 'help' to > freebsd-net-request@freebsd.org > > You can reach the person managing the list at > freebsd-net-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-net digest..." > > Today's Topics: > > 1. Re: bge interrupt coalescing sysctls (Igor Sysoev) > 2. PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->> > OUTNOW (news@markvoxx.com) > 3. Re: hostapd with 802.1X EAP-TLS/TTLS support (Sam Leffler) > 4. Bridging and using the interfaces concurrently (Axel Reinhold) > 5. [msk] watchdog timeout (missed Tx interrupts) -- recovering > (Karim Fodil-Lemelin) > 6. Re: [msk] watchdog timeout (missed Tx interrupts) -- > recovering (Pyun YongHyeon) > 7. Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering (Pyun YongHyeon) > 8. Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering (Pyun YongHyeon) > 9. Re: kern/132107: [carp] carp(4) advskew setting ignored when > carp IP used on a gif(4) interface (Daniel Duerr) > 10. Re: Bridging and using the interfaces concurrently > (Eygene Ryabinkin) > 11. mbuf layout optimizations (Jeff Roberson) > 12. Re: hostapd with 802.1X EAP-TLS/TTLS support (Vladimir Terziev) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Jun 2009 18:19:25 +0400 > From: Igor Sysoev > Subject: Re: bge interrupt coalescing sysctls > To: Bruce Evans > Cc: freebsd-net@FreeBSD.org > Message-ID: <20090618141925.GG60354@rambler-co.ru> > Content-Type: text/plain; charset=koi8-r > > On Thu, Jun 11, 2009 at 11:54:29AM +1000, Bruce Evans wrote: > > > On Wed, 10 Jun 2009, Igor Sysoev wrote: > > > > >For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: > > >http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html > > >However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken > > >the patch. I'm not sure how to fix the collision, and since I do not > > >use dynamic tuning > > > > That commit looked ugly (lots of internal API changes and bloat in interrupt > > handlers in many network drivers to support polling which mostly shouldn't > > be supported at all and mostly doesn't use the interrupt handlers). > > > > >I has left only static coalescing parameters in the patch > > >and has added a loader tunable to set number of receive descriptors and > > >read only sysctl to read the tunable. I usually use these parameters: > > > > > >/boot/loader.conf: > > >hw.bge.rxd=512 > > > > > >/etc/sysctl.conf: > > >dev.bge.0.rx_coal_ticks=500 > > >dev.bge.0.tx_coal_ticks=10000 > > >dev.bge.0.rx_max_coal_bds=64 > > > > These rx settings give to high a latency for me. > > Probably, however, I use this on a host that has 6000 packets/s. > > > >dev.bge.0.tx_max_coal_bds=128 > > ># apply the above parameters > > >dev.bge.0.program_coal=1 > > > > > >Could anyone commit it ? > > > > Not me, sorry. > > > > The patch is quite clean. If I committed then I would commit the > > dynamic coalescing configuration separately anyway. > > So have you any objections if some one else will commit this patch ? > > > You can probably make hw.bge.rxd a sysctl too (it would take a down/up > > to get it changed, but that is already needed for too many parameters > > in network drivers anyway). I should use a sysctl for the ifq length > > too. This could be done at a high level for each driver. Limiting > > queue lengths may be a good way to reduce cache misses, while increasing > > them is sometimes good for reducing packet loss. > > Do you mean simple command sequence: > > sysctl hw.bge.rxd=512 > ifconfig down > ifconfig up > > or SYSCTL_ADD_PROC for hw.bge.rxd ? > > -- > Igor Sysoev > http://sysoev.ru/en/ > > ------------------------------ > > Message: 2 > Date: Thu, 18 Jun 2009 16:52:30 +0100 > From: "news@markvoxx.com" > Subject: PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->> > OUTNOW > To: freebsd-net@freebsd.org > Message-ID: <505656668421844159@smtpa.netcabo.pt> > Content-Type: text/plain ; charset="ISO-8859-1" > > Clica na imagem para ir para a loja do BeatPort ! > Click on the image to go to BeatPort Shop! > > > > > > www.myspace.com/djmarkvoxxproducer > www.myspace.com/themcgracespace > > > > To cancel your subscription to this newsletter, please reply to this message with the word REMOVE in the Subject line. > Para cancelar a subscri??o desta newsletter, por favor responde a esta mensagem com a palavra REMOVER no assunto. > > ------------------------------ > > Message: 3 > Date: Thu, 18 Jun 2009 10:36:04 -0700 > From: Sam Leffler > Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support > To: Vladimir Terziev > Cc: freebsd-net@freebsd.org, "Paul B. Mahol" > Message-ID: <4A3A7B04.2020906@freebsd.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > EAP/TLS and TTLS should be configured by default in HEAD. Not sure what > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ > the functionality you want by definitions to your src.conf: > > HOSTAPD_CFLAGS > HOSTAPD_DPADD > HOSTAPD_LDADD > > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check > usr.sbin/wpa/hostapd/Makefile). > > As to what should be enabled by default, I can only say that I tried to > choose the most common setup as the default. Choosing this > configuration also balances between bloat and inclusion of code that > might not be as well audited and/or tested as other code. Hence the > default setup used to be WPA-PSK only but has since grown to include > various EAP flavors. My assumption was that anyone building a system > using these tools would want to go through and choose what they wanted > anyway so enabling everything was a bad idea. > > Sam > > Vladimir Terziev wrote: > > Hi Paul, > > > > is there some special reason behind this? Why the server is made part of > > the main distribution with stripped functionality ? > > > > Also, how can i enable it ? > > > > Thanks, > > > > Vladimir > > > > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > > > >> On 6/18/09, Vladimir Terziev wrote: > >> > >>> Hi, > >>> > >>> i try to setup wireless access point at home, based on FreeBSD > >>> 7.2R-i386, ral(4) wireless card and hostpad(8). > >>> > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. > >>> > >> I > >> > >>> issued a custom SSL certificate for the hostapd(8) and put the > >>> > >> following > >> > >>> directives in hostapd.conf: > >>> > >>> eap_server=0 > >>> ca_cert=/usr/local/etc/myCA.crt.pem > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem > >>> private_key=/usr/local/etc/hostapd.server.key.pem > >>> private_key_passwd=some_pass > >>> > >>> When i tried to start the hostapd(8) i got the following errors: > >>> > >>> Line 15: unknown configuration item 'eap_server' > >>> Line 16: unknown configuration item 'ca_cert' > >>> Line 17: unknown configuration item 'server_cert' > >>> Line 18: unknown configuration item 'private_key' > >>> Line 19: unknown configuration item 'private_key_passwd' > >>> > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > >>> > >> all > >> > >>> and if "not" why ? > >>> > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). > >> > >> -- > >> Paul > >> > >> > >> > > > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. > > > > > > _______________________________________________ > > 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" > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Jun 2009 21:10:19 +0200 (CEST) > From: Axel Reinhold > Subject: Bridging and using the interfaces concurrently > To: freebsd-net@freebsd.org > Message-ID: <200906181910.n5IJAJ2u007974@bongo.freakout.de> > Content-Type: text/plain; format=text; x-action=sign; > charset="US-ASCII" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have two FreeBSD-7.1 servers in a data-center hosted. > > Both servers have two em[01] gigabit network links. > First server's (call it "first") em0 is connected to the data-centers > internet uplink - the em1 is connected to the seconds servers > (call it "second") em1. > > first's /etc/rc.conf: > ifconfig_em0="inet 212.144.103.230 netmask 255.255.254.0" > defaultrouter="212.144.102.1" > ifconfig_em1="inet 192.168.102.1 netmask 255.255.255.0" > > seconds's /etc/rc.conf: > ifconfig_em1="inet 192.168.102.131 netmask 255.255.255.0" > > In this way the 192.168.102/24 network is for private > connection between the two servers and "second" is not connected > to the internet at all. > > Since i would have to pay extra charges to get the "second" > server also connected to the internet, i thought of bridging > the em0 and em1 of "first" and to alias another ip for the > second server (i have more ip's in the data-center left) on > "seconds" em1. > > Is this possible? What would i have to setup? > The private 192.168.102/24 network should remain intakt! > I just want to bridge "seconds" em1-MAC to the data-centers > switch-port which is connected to "first" em0. > > Any help? Or is this not possible? > > Axel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9-PB (GNU/Linux) > > iD8DBQFKOpEIHQ9JwE2bDw0RAh9mAKCy2R7DAZYzqLfU/wKlwHiZWsQfAwCfUGne > 7nsmXfuWgxyo+HAM76VRU6w= > =LKp+ > -----END PGP SIGNATURE----- > > ------------------------------ > > Message: 5 > Date: Thu, 18 Jun 2009 16:18:32 -0400 > From: Karim Fodil-Lemelin > Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering > To: Pyun YongHyeon > Cc: freebsd-net@freebsd.org > Message-ID: <4A3AA118.9020609@xiplink.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > Concerning this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I > have one of those 'strange' silicon here: > > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 > > kernel: mskc2: port 0xee00-0xeeff mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 > kernel: msk2: on mskc2 > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 > kernel: miibus2: on msk2 > kernel: e1000phy2: PHY 0 on miibus2 > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto > > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved > the problem. But applying the attached patch (written by Pyun I believe) > also solved the problem. > > I think your patch should be committed for others to benefit. > > Best regards, > > Karim. > > -------------- next part -------------- > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 186497) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -1355,27 +1355,25 @@ > CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); > /* Set the status list last index. */ > CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); > - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && > - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { > - /* WA for dev. #4.3 */ > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); > - /* WA for dev. #4.18 */ > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); > - } else { > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > - else > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); > - } > /* > - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. > + * Interrupt moderation and coalescing frames should be > + * controllable with sysctl variables or loader tunables > + * but the relationship between status updates and > + * interrupt moderation are not clear. Some hardware > + * revisions seem to very sensitive to these parameters > + * and could be resulted in poor performance as well as > + * non-working situation if improper values were chosen. > */ > + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > + else > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); > + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); > + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); > > /* Enable status unit. */ > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); > @@ -3586,6 +3584,10 @@ > domore = msk_handle_events(sc); > if ((status & Y2_IS_STAT_BMU) != 0) > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); > + if (CSR_READ_1(sc, STAT_TX_TIMER_CTRL) == TIM_START) { > + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_STOP); > + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_START); > + } > > if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 && > !IFQ_DRV_IS_EMPTY(&ifp0->if_snd)) > > ------------------------------ > > Message: 6 > Date: Fri, 19 Jun 2009 09:37:09 +0900 > From: Pyun YongHyeon > Subject: Re: [msk] watchdog timeout (missed Tx interrupts) -- > recovering > To: Karim Fodil-Lemelin > Cc: freebsd-net@freebsd.org > Message-ID: <20090619003709.GF93360@michelle.cdnetworks.co.kr> > Content-Type: text/plain; charset=us-ascii > > On Thu, Jun 18, 2009 at 04:18:32PM -0400, Karim Fodil-Lemelin wrote: > > Hello, > > > > Hi, > > > Concerning this pr: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I > > have one of those 'strange' silicon here: > > > > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 > > > > kernel: mskc2: port 0xee00-0xeeff > > mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 > > kernel: msk2: on > > mskc2 > > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 > > kernel: miibus2: on msk2 > > kernel: e1000phy2: PHY 0 on miibus2 > > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseTX-FDX, auto > > > > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved > > the problem. But applying the attached patch (written by Pyun I believe) > > also solved the problem. > > > > I think your patch should be committed for others to benefit. > > > > Thanks a lot! I'll write a follow-up mail to the PR. > > > Best regards, > > > > Karim. > > > > > > ------------------------------ > > Message: 7 > Date: Fri, 19 Jun 2009 00:40:05 GMT > From: Pyun YongHyeon > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering > To: freebsd-net@FreeBSD.org > Message-ID: <200906190040.n5J0e519069495@freefall.freebsd.org> > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Pyun YongHyeon > To: Duckhawk > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering > Date: Fri, 19 Jun 2009 09:43:05 +0900 > > --47eKBCiAZYFK5l32 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Sun, Feb 22, 2009 at 07:50:03AM +0000, Duckhawk wrote: > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > > > From: Duckhawk > > To: bug-followup@FreeBSD.org, skylord@linkline.ru > > Cc: > > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- > > recovering > > Date: Sun, 22 Feb 2009 12:26:51 +0500 > > > > --001636c5a26744f2de04637ccfc6 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > > > also, same problem. D-Link DGE-560T > > > > %uname -a > > FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009 > > duckhawk@:/usr/obj/usr/src/sys/GENERIC i386 > > > > %dmesg | grep "msk" > > mskc0: port 0x7000-0x70ff mem > > 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1 > > msk0: on mskc0 > > msk0: Ethernet address: 00:1b:11:79:53:eb > > miibus0: on msk0 > > mskc0: [FILTER] > > > > %pciconf -lv > > mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 > > rev=0x13 hdr=0x00 > > vendor = 'D-Link System Inc' > > device = 'DGE-560T PCIe Gigabit Ethernet Adapter' > > class = network > > subclass = ethernet > > Please try the following patch. > > --47eKBCiAZYFK5l32 > Content-Type: text/x-diff; charset=us-ascii > Content-Disposition: attachment; filename="msk.EC.patch" > > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 194467) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -1387,27 +1387,26 @@ > CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); > /* Set the status list last index. */ > CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); > - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && > - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { > - /* WA for dev. #4.3 */ > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); > - /* WA for dev. #4.18 */ > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); > - } else { > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > - else > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); > - } > /* > - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. > + * XXX > + * Interrupt moderation and coalescing frames should be > + * controllable with sysctl variables or loader tunables > + * but the relationship between status updates and > + * interrupt moderation are not clear to me. Some hardware > + * revisions seem to very sensitive to these parameters > + * and could be resulted in poor performance as well as > + * non-working situation if improper values were chosen. > */ > + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > + else > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); > + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); > + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); > > /* Enable status unit. */ > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); > > --47eKBCiAZYFK5l32-- > > ------------------------------ > > Message: 8 > Date: Fri, 19 Jun 2009 00:50:06 GMT > From: Pyun YongHyeon > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering > To: freebsd-net@FreeBSD.org > Message-ID: <200906190050.n5J0o6PN076484@freefall.freebsd.org> > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Pyun YongHyeon > To: sam > Cc: yongari@freebsd.org, bug-followup@FreeBSD.org > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering > Date: Fri, 19 Jun 2009 09:40:46 +0900 > > --pQhZXvAqiZgbeUkD > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Jul 31, 2008 at 04:06:42PM +0400, sam wrote: > > ----------------------------------------------- > > Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx > > interrupts) -- recovering > > Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx > > interrupts) -- recovering > > ----------------------------------------------- > > > > ----------------------------------------------- > > Jul 29 23:18:28 moon3 kernel: mskc0: > Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device > > 0.0 on pci2 > > Jul 29 23:18:28 moon3 kernel: msk0: > Yukon EC Id 0xb6 Rev 0x02> on mskc0 > > > > Jul 29 23:18:28 moon3 kernel: miibus0: on msk0 > > ----------------------------------------------- > > > > ----------------------------------------------- > > FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 > > 15:00:14 MSD 2008 root@moon3:/usr/src/sys/i386/compile/MOON3 i386 > > ----------------------------------------------- > > > > I confirm this problem. > > > > /Vladimir Ermakov > > > > > > Would you try attached patch and let me know hot it goes? > > --pQhZXvAqiZgbeUkD > Content-Type: text/x-diff; charset=us-ascii > Content-Disposition: attachment; filename="msk.EC.patch" > > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 194467) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -1387,27 +1387,26 @@ > CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); > /* Set the status list last index. */ > CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); > - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && > - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { > - /* WA for dev. #4.3 */ > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); > - /* WA for dev. #4.18 */ > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); > - } else { > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > - else > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); > - } > /* > - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. > + * XXX > + * Interrupt moderation and coalescing frames should be > + * controllable with sysctl variables or loader tunables > + * but the relationship between status updates and > + * interrupt moderation are not clear to me. Some hardware > + * revisions seem to very sensitive to these parameters > + * and could be resulted in poor performance as well as > + * non-working situation if improper values were chosen. > */ > + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > + else > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); > + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); > + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); > > /* Enable status unit. */ > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); > > --pQhZXvAqiZgbeUkD-- > > ------------------------------ > > Message: 9 > Date: Fri, 19 Jun 2009 07:10:02 GMT > From: Daniel Duerr > Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when > carp IP used on a gif(4) interface > To: freebsd-net@FreeBSD.org > Message-ID: <200906190710.n5J7A2cD078751@freefall.freebsd.org> > > The following reply was made to PR kern/132107; it has been noted by GNATS. > > From: Daniel Duerr > To: bug-followup@FreeBSD.org, > adaugherity@tamu.edu > Cc: > Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface > Date: Thu, 18 Jun 2009 23:51:09 -0700 > > Having the same issue here and the workaround isn't working for me -- > it preserves the advskew but the vpn doesn't seem to work without the > devd attach event. Hope someone will fix this soon. > > > > > ------------------------------ > > Message: 10 > Date: Fri, 19 Jun 2009 12:55:03 +0400 > From: Eygene Ryabinkin > Subject: Re: Bridging and using the interfaces concurrently > To: Axel Reinhold > Cc: freebsd-net@freebsd.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Axel, good day. > > Thu, Jun 18, 2009 at 09:10:19PM +0200, Axel Reinhold wrote: > > Since i would have to pay extra charges to get the "second" > > server also connected to the internet, i thought of bridging > > the em0 and em1 of "first" and to alias another ip for the > > second server (i have more ip's in the data-center left) on > > "seconds" em1. > > > > Is this possible? What would i have to setup? > > The private 192.168.102/24 network should remain intakt! > > NAT the "second" box on your "first" one and that's it. Bridging > won't help much here, because your "second"s IPs are unroutable, so > someone will still need to translate them. If your intention is to > provide only client-level connectivity to the "second" box (when it > initiates all connections), simple NAT will work. If you need some > port to be opened at the "second" host and the should be reachable > from the outside, then you'll additionally need port mirroring. > > Or, if you really want to spend an extra IP for the second box, then > just binat (in the terms of pf.conf(5)) your private address to the > second IP on the "first" server. > > The exact solution for NAT depends on the firewall type you're using on > the "first" server. For ipfw you probably should look at the natd(8), > for ipfilter -- at ipnat(8), for pf -- at pf(4) and pf.conf(5). May be > netgraph(4) will be of some help, but this adds some extra complexity > for people who aren't familiar with Netgraph concepts and tools. > > If you really want bridging, then the easiest thing will be to create > two VLAN (if_vlan(4)) interfaces on your link between two servers: one > VLAN for the 192.168.102/24 network and one for the public network. > After this, packets from 192.168 will flow as they flowed before, and > you should bridge your "first"'s external interface with the second VLAN > interface on this host. Put your extra external IP to the other side of > the VLAN interface and it should do what you need. > > NAT should be easier, bridging should be faster, but the difference > strongly depends on the type of traffic and usage of the inter-server > link. > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > > ------------------------------ > > Message: 11 > Date: Thu, 18 Jun 2009 23:12:45 -1000 (HST) > From: Jeff Roberson > Subject: mbuf layout optimizations > To: net@freebsd.org, current@freebsd.org > Message-ID: > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > http://people.freebsd.org/~jeff/mbuf2.diff > > Hello, > > This is a call for testers and feedback on my mbuf layout improvements. > I'm trying to decide whether I will push to have these included in 8.0. > After reducing the scope slightly from my last patch, I have not > encountered any problems. Kip Macy has also been using it for the past > few weeks without issue. > > You should not expect any functional changes from this patch. The goal > is mostly to pave the way fors more sensible mbuf handling in the future, > although it does offer a few performance benefits. > > The only issue is that cxgb support requires another set of patches from > Kip. If anyone needs those I will prod him to reply with that diff. > > Thanks, > Jeff > > ------------------------------ > > Message: 12 > Date: Fri, 19 Jun 2009 13:55:26 +0300 > From: Vladimir Terziev > Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support > To: Sam Leffler > Cc: freebsd-net@freebsd.org, "Paul B. Mahol" > Message-ID: <1245408926.31855.26.camel@daemon2.partygaming.local> > Content-Type: text/plain > > Thanks Sam, > > What should i put for HOSTAPD_CFLAGS, HOSTAPD_DPADD, HOSTAPD_LDADD or > WPA_SUPPLICANT_* (not sure which ones i should use) in order to get > hostapd rebuilt with the functionality i want ? > > Regards, > > Vladimir > > On Thu, 2009-06-18 at 20:36 +0300, Sam Leffler wrote: > > EAP/TLS and TTLS should be configured by default in HEAD. Not sure > > what > > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ > > the functionality you want by definitions to your src.conf: > > > > HOSTAPD_CFLAGS > > HOSTAPD_DPADD > > HOSTAPD_LDADD > > > > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check > > usr.sbin/wpa/hostapd/Makefile). > > > > As to what should be enabled by default, I can only say that I tried > > to > > choose the most common setup as the default. Choosing this > > configuration also balances between bloat and inclusion of code that > > might not be as well audited and/or tested as other code. Hence the > > default setup used to be WPA-PSK only but has since grown to include > > various EAP flavors. My assumption was that anyone building a system > > using these tools would want to go through and choose what they wanted > > anyway so enabling everything was a bad idea. > > > > Sam > > > > > > Vladimir Terziev wrote: > > > Hi Paul, > > > > > > is there some special reason behind this? Why the server is made > > part of > > > the main distribution with stripped functionality ? > > > > > > Also, how can i enable it ? > > > > > > Thanks, > > > > > > Vladimir > > > > > > > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > > > > > >> On 6/18/09, Vladimir Terziev wrote: > > >> > > >>> Hi, > > >>> > > >>> i try to setup wireless access point at home, based on FreeBSD > > >>> 7.2R-i386, ral(4) wireless card and hostpad(8). > > >>> > > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS > > authentication. > > >>> > > >> I > > >> > > >>> issued a custom SSL certificate for the hostapd(8) and put the > > >>> > > >> following > > >> > > >>> directives in hostapd.conf: > > >>> > > >>> eap_server=0 > > >>> ca_cert=/usr/local/etc/myCA.crt.pem > > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem > > >>> private_key=/usr/local/etc/hostapd.server.key.pem > > >>> private_key_passwd=some_pass > > >>> > > >>> When i tried to start the hostapd(8) i got the following errors: > > >>> > > >>> Line 15: unknown configuration item 'eap_server' > > >>> Line 16: unknown configuration item 'ca_cert' > > >>> Line 17: unknown configuration item 'server_cert' > > >>> Line 18: unknown configuration item 'private_key' > > >>> Line 19: unknown configuration item 'private_key_passwd' > > >>> > > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > > >>> > > >> all > > >> > > >>> and if "not" why ? > > >>> > > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's > > hostapd(8). > > >> > > >> -- > > >> Paul > > >> > > >> > > >> > > > > > > This email and any attachments are confidential, and may be legally > > privileged and protected by copyright. If you are not the intended > > recipient dissemination or copying of this email is prohibited. If you > > have received this in error, please notify the sender by replying by > > email and then delete the email completely from your system. > > > > > > Any views or opinions are solely those of the sender. This > > communication is not intended to form a binding contract unless > > expressly indicated to the contrary and properly authorised. Any > > actions taken on the basis of this email are at the recipient's own > > risk. > > > > > > > > > _______________________________________________ > > > 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" > > End of freebsd-net Digest, Vol 324, Issue 5 > ******************************************* > > ? ?????????, ???????. ????????: Linux&FreeBSD 4+ mailto: wel@skm.net.ua ? ??? ??????? ? ?????????? ?????? ??? ????????? Skyhome From freebsd-listen at fabiankeil.de Sat Jun 20 10:52:53 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sat Jun 20 10:53:06 2009 Subject: mbuf layout optimizations In-Reply-To: References: Message-ID: <20090620123657.21728020@fabiankeil.de> Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf2.diff > This is a call for testers and feedback on my mbuf layout improvements. > I'm trying to decide whether I will push to have these included in 8.0. > After reducing the scope slightly from my last patch, I have not > encountered any problems. Kip Macy has also been using it for the past > few weeks without issue. > > You should not expect any functional changes from this patch. The goal > is mostly to pave the way fors more sensible mbuf handling in the > future, although it does offer a few performance benefits. So far I haven't been able to reproduce the em-related panic I reported with an earlier version of the patch. I'm not sure if it was reproducible back then, though. Fabian From remko at FreeBSD.org Sat Jun 20 19:22:31 2009 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat Jun 20 19:22:43 2009 Subject: kern/135836: bce BCM5709 Watchdog [i386] after warm boot - ok after cold boot Message-ID: <200906201922.n5KJMU5N020466@freefall.freebsd.org> Synopsis: bce BCM5709 Watchdog [i386] after warm boot - ok after cold boot Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Jun 20 19:21:52 UTC 2009 Responsible-Changed-Why: reassign to -net team, as this is for the BCE driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=135836 From pg at 2lazy.ru Sat Jun 20 20:46:11 2009 From: pg at 2lazy.ru (Pavel Gubin) Date: Sat Jun 20 20:46:23 2009 Subject: Wireless, Realtek RTL8185L-based PCI adapter. Message-ID: <4A3D43AF.7060009@2lazy.ru> Hi All, Recently I've got 802.11b/g adapter TL-WN353GD from TP-Link, based on Realtek RTL8185L chip. Seems that there is no support for it in FreeBSD yet, but there are some mentionings about 8185 in /sys/dev/usb/wlan/if_urtw*. Also, Realtek has a Linux driver for it, and this driver is partly based on NetBSD's if_rtw driver for RTL8180 (which seems to be 802.11a/b predecessor of 8185). So, I'm wondering - does someone work already on a driver for this chip, or maybe I should try to write a driver myself? Thanks, -- Pavel Gubin Jabber: xmpp:pg@2lazy.ru / Phone +79218959055 / sip:pg@2lazy.ru From cmb at pfsense.org Sun Jun 21 00:02:16 2009 From: cmb at pfsense.org (Chris Buechler) Date: Sun Jun 21 00:02:22 2009 Subject: IPsec crash, patch for review In-Reply-To: <20090619130040.GA53996@zeninc.net> References: <20090619130040.GA53996@zeninc.net> Message-ID: <4A3D7885.9010809@pfsense.org> Hi, VANHULLEBUS Yvan wrote: > Hi all. > > We (NETASQ) had some IPsec related kernel crashes, and hunted them, > here are some informations and a possible patch: > > > First, problem only occurs when asynchronous crypto is done > (hardware encryption such as hifn cards, or software patch to do > encryption on a separate kthread when having multiple CPUs). > We tried this patch on 7.2 (with patch-natt-7.2-2009-05-12.diff from your ~) due to a seemingly similar problem, but IPsec stops working with the patch applied. Using test setup: Host A -- fwA -- fwB -- Host B where fwA has the patch and fwB is the same 7.2 minus this patch, and there is an IPsec connection between fwA and fwB. It brings up the connection no problem, and if I leave a constant ping going, every time I restart racoon on fwA I get exactly one response through. From tcpdump on enc0 on both ends and the actual NICs, I see that traffic from Host B to Host A gets all the way through the tunnel to Host A, it responds, the response is seen on fwA's LAN port, but it doesn't hit enc0. Traffic from Host A to Host B is seen on the LAN port of fwA, but not on enc0 and not on enc0 of the remote side. Replace the kernel on fwA with one minus the patch and it works fine (except it will spontaneously reboot under high load). That's with patch-xform_freespfix-3. Should that work with 7.2 in combination with the NAT-T patch? It applies cleanly. thanks, Chris From brde at optusnet.com.au Sun Jun 21 03:49:43 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sun Jun 21 03:49:49 2009 Subject: bge interrupt coalescing sysctls In-Reply-To: <20090618141925.GG60354@rambler-co.ru> References: <20090610123301.GE40250@rambler-co.ru> <20090611114120.I21056@delplex.bde.org> <20090618141925.GG60354@rambler-co.ru> Message-ID: <20090621131437.B1458@besplex.bde.org> On Thu, 18 Jun 2009, Igor Sysoev wrote: > On Thu, Jun 11, 2009 at 11:54:29AM +1000, Bruce Evans wrote: > >> On Wed, 10 Jun 2009, Igor Sysoev wrote: >> ... >>> I has left only static coalescing parameters in the patch >>> and has added a loader tunable to set number of receive descriptors and >>> read only sysctl to read the tunable. I usually use these parameters: >>> >>> /boot/loader.conf: >>> hw.bge.rxd=512 >>> >>> /etc/sysctl.conf: >>> dev.bge.0.rx_coal_ticks=500 >>> dev.bge.0.tx_coal_ticks=10000 >>> dev.bge.0.rx_max_coal_bds=64 >> >> These rx settings give to high a latency for me. > > Probably, however, I use this on a host that has 6000 packets/s. 6000 is not very high, so you might be able to tune for latency at no significant cost. The normal (unpatched) value for rx_coal_ticks is 150 uS. This tends to give an interrupt rate of 6666 packets/S, and this is a good default maximum rate (it takes about 100000 interrupts/S to eat up 2GHz of CPU). If packets normally arrive at 6000/S, then you can tune for minimal latency = no rx interrupt moderation at all by setting rx_coal_ticks to 1, without affecting the interrupt rate at all (there will always by 6000 interrupts/S, but with rx_coal_ticks=1 the packets will br processed with minimal delay (more like 20 uS than 1 uS) instead of after 150 uS (default). Your settings should give about 2000 interrupts/S, with 3 packets handled every interrupt after a delay of up to 500 uS. >>> dev.bge.0.tx_max_coal_bds=128 >>> # apply the above parameters >>> dev.bge.0.program_coal=1 >>> >>> Could anyone commit it ? >> >> Not me, sorry. >> >> The patch is quite clean. If I committed then I would commit the >> dynamic coalescing configuration separately anyway. > > So have you any objections if some one else will commit this patch ? No objections. >> You can probably make hw.bge.rxd a sysctl too (it would take a down/up >> to get it changed, but that is already needed for too many parameters >> in network drivers anyway). I should use a sysctl for the ifq length >> too. This could be done at a high level for each driver. Limiting >> queue lengths may be a good way to reduce cache misses, while increasing >> them is sometimes good for reducing packet loss. > > Do you mean simple command sequence: > > sysctl hw.bge.rxd=512 > ifconfig down > ifconfig up > > or SYSCTL_ADD_PROC for hw.bge.rxd ? The simple command sequence. It's painful to write a SYSCTL_ADD_PROC() for every sysctl, even if the procedure is trival, and the procedure would be highly nontrivial for at least reducing rxd since for reduction it would have to wait for descriptors to become inactive, and decouple them without races... I made program_coal a SYSCTL_PROC() because I wanted to change the settings a lot for testing, but I didn't make the individual coal settings SYSCTL_PROC()s since there is no need to change 1 at a time and it might be wrong to change 1 at a time (they have some interactions). Bruce From realliukai at gmail.com Mon Jun 22 03:41:07 2009 From: realliukai at gmail.com (=?GB2312?B?wfW/rQ==?=) Date: Mon Jun 22 03:41:14 2009 Subject: Wireless,Atheros AR5008-based PCI adapter,mode 11n Message-ID: <7237120a0906212012o141363e6u7231dbd0927bfaf@mail.gmail.com> Hi All, Recently I've got 802.11b/g adapter TL-WN353GD from TP-Link, based on Atheros AR5008 chip.It's a 802.11n NIC. I can make it work in mode 11g in stead of 11n with the FreeBSD 8.0 current. So,I have a question that whether there is support for 802.11n in FreeBSD 8.0 current yet. And if It support 802.11n, how can I config the parameters to make it work in mode 11n. Thanks, -- Kevi From weongyo.jeong at gmail.com Mon Jun 22 04:54:51 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Mon Jun 22 04:55:02 2009 Subject: Wireless, Realtek RTL8185L-based PCI adapter. In-Reply-To: <4A3D43AF.7060009@2lazy.ru> References: <4A3D43AF.7060009@2lazy.ru> Message-ID: <20090622043224.GC31161@weongyo.cdnetworks.kr> On Sun, Jun 21, 2009 at 12:16:47AM +0400, Pavel Gubin wrote: > Hi All, > > Recently I've got 802.11b/g adapter TL-WN353GD from TP-Link, based on > Realtek RTL8185L chip. > > Seems that there is no support for it in FreeBSD yet, but there are some > mentionings about 8185 in /sys/dev/usb/wlan/if_urtw*. Also, Realtek has > a Linux driver for it, and this driver is partly based on NetBSD's > if_rtw driver for RTL8180 (which seems to be 802.11a/b predecessor of 8185). > > So, I'm wondering - does someone work already on a driver for this chip, > or maybe I should try to write a driver myself? As far as I know, there's no one to work on it. regards, Weongyo Jeong From sam at freebsd.org Mon Jun 22 05:16:35 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Jun 22 05:16:41 2009 Subject: Wireless,Atheros AR5008-based PCI adapter,mode 11n In-Reply-To: <7237120a0906212012o141363e6u7231dbd0927bfaf@mail.gmail.com> References: <7237120a0906212012o141363e6u7231dbd0927bfaf@mail.gmail.com> Message-ID: <4A3F13B2.2030108@freebsd.org> ???? wrote: > Hi All, > > Recently I've got 802.11b/g adapter TL-WN353GD from TP-Link, based on > Atheros AR5008 chip.It's a 802.11n NIC. > > I can make it work in mode 11g in stead of 11n with the FreeBSD 8.0 current. > So,I have a question that whether there is support for 802.11n in FreeBSD > 8.0 current yet. > And if It support 802.11n, how can I config the parameters to make it work > in mode 11n. > > Thanks, You can trivially turn on 802.11n RX by enabling HT capabilities in the driver (that'll give you 11n downlink transfers w/ AMPDU even). That's worked ever since I brought 11n support code into the tree (18 months ago?). 11n transmit requires an 11n-aware rate control algorithm and as far as I know noone is working on that. Sam From bugmaster at FreeBSD.org Mon Jun 22 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 22 11:08:57 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200906221107.n5MB709b018121@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/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/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp 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 o kern/132984 net [netgraph] swi1: net 100% cpu usage 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/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/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 kern/121983 net [fxp] fxp0 MBUF and PAE 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/114839 net [fxp] fxp looses ability to speak with traffic 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 o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/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 309 problems total. From rpaulo at freebsd.org Mon Jun 22 22:46:51 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Mon Jun 22 22:46:58 2009 Subject: 802.11s (wireless mesh) project status report Message-ID: <496A0799-0661-4651-B8CE-6C635A6DCEA0@freebsd.org> Hi all, The wireless mesh project is now in a more usable stage and your support and testing is appreciated. Today I've been able to exchange packets between three nodes using the following network topology: node1 <-> node2 <-> node3. With the currently committed code it's now possible to send packets from node1 to node3 via node2. Other mesh topologies will be tested in the future. I've created a wiki page that's still under construction but should be able to help you setup your wireless mesh: http://wiki.freebsd.org/WifiMesh 802.11s is interesting both to companies who want to create wide range wireless networks and also to home users who would like to expand their wireless networks. They can now start using the FreeBSD operating system to fullfil their needs. The project is still unfinished and has some rough edges, though. If you have any questions, dont hesitate asking. This project is being sponsored by The FreeBSD Foundation. Thanks, -- Rui Paulo From jrytoung at gmail.com Tue Jun 23 00:42:16 2009 From: jrytoung at gmail.com (Jerry Toung) Date: Tue Jun 23 00:42:22 2009 Subject: in_pcb crash on 7.2 RELEASE 64bits Message-ID: <86068e730906221718o7b37660ei640fe85085624e06@mail.gmail.com> Hi List, may be someone has seen this already before I dig into the issue myself. A consistent crash with the following trace. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x164 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff806016c8 stack pointer = 0x10:0xfffffffefc079840 frame pointer = 0x10:0xc0000000 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1352 (gated) trap number = 12 panic: page fault cpuid = 4 Uptime: 5m37s Dumping 4093 MB (4 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 3326MB (851284 pages) 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2222 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok chunk 2: 1MB (1 pages) ... ok chunk 3: 768MB (196607 pages) 753 737 721 705 689 673 657 641 625 609 593 577 561 545 529 513 497 481 465 449 433 417 401 385 369 353 337 321 305 289 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff80521d59 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff80522162 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff807e6a93 in trap_fatal (frame=0xffffff00038a06e0, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff807e6e65 in trap_pfault (frame=0xfffffffefc079790, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0xffffffff807e77a4 in trap (frame=0xfffffffefc079790) at /usr/src/sys/amd64/amd64/trap.c:444 #7 0xffffffff807cb90e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0xffffffff806016c8 in in_pcbconnect_setup (inp=0xffffff001439d6c0, nam=Variable "nam" is not available. ) at /usr/src/sys/netinet/in_pcb.c:833 #9 0xffffffff806795a1 in udp_send (so=Variable "so" is not available. ) at /usr/src/sys/netinet/udp_usrreq.c:961 #10 0xffffffff8057d1a1 in sosend_dgram (so=0xffffff00143442d0, addr=0xffffff0003b6e530, uio=Variable "uio" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1059 #11 0xffffffff80581d77 in kern_sendit (td=0xffffff00038a06e0, s=22, mp=0xfffffffefc079af0, flags=4, control=0x0, segflg=Variable "segflg" is not available. ) at /usr/src/sys/kern/uipc_syscalls.c:805 #12 0xffffffff80584d4f in sendit (td=0xffffff00038a06e0, s=22, mp=0xfffffffefc079af0, flags=4) at /usr/src/sys/kern/uipc_syscalls.c:742 #13 0xffffffff80584de9 in sendmsg (td=0xffffff00038a06e0, uap=0xfffffffefc079bf0) at /usr/src/sys/kern/uipc_syscalls.c:938 #14 0xffffffff807e70e7 in syscall (frame=0xfffffffefc079c80) at /usr/src/sys/amd64/amd64/trap.c:900 #15 0xffffffff807cbb1b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #16 0x0000000801c1a00c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 8 #8 0xffffffff806016c8 in in_pcbconnect_setup (inp=0xffffff001439d6c0, nam=Variable "nam" is not available. ) at /usr/src/sys/netinet/in_pcb.c:833 833 /usr/src/sys/netinet/in_pcb.c: No such file or directory. in /usr/src/sys/netinet/in_pcb.c (kgdb) p *ia Cannot access memory at address 0x0 (kgdb) i loc ia = (struct in_ifaddr *) 0x0 oinp = Variable "oinp" is not available. (kgdb) thanks, Jerry From vanhu at FreeBSD.org Tue Jun 23 07:54:13 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Jun 23 07:54:20 2009 Subject: IPsec crash, patch for review In-Reply-To: <4A3D7885.9010809@pfsense.org> References: <20090619130040.GA53996@zeninc.net> <4A3D7885.9010809@pfsense.org> Message-ID: <20090623081845.GA68752@zeninc.net> On Sat, Jun 20, 2009 at 08:02:13PM -0400, Chris Buechler wrote: > VANHULLEBUS Yvan wrote: > Hi, Hi. [...] > We tried this patch on 7.2 (with patch-natt-7.2-2009-05-12.diff from > your ~) due to a seemingly similar problem, but IPsec stops working with > the patch applied. Using test setup: > > Host A -- fwA -- fwB -- Host B > > where fwA has the patch and fwB is the same 7.2 minus this patch, and > there is an IPsec connection between fwA and fwB. It brings up the > connection no problem, and if I leave a constant ping going, every time > I restart racoon on fwA I get exactly one response through. Bjoern reported me that the actual patch will break things on IPv6 (another patch will be posted soon which should solve this problem), are you in a full IPv4 world, ordo you have some IPv6 + IPsec configuration ? > From tcpdump on enc0 on both ends and the actual NICs, I see that > traffic from Host B to Host A gets all the way through the tunnel to > Host A, it responds, the response is seen on fwA's LAN port, but it > doesn't hit enc0. Traffic from Host A to Host B is seen on the LAN port > of fwA, but not on enc0 and not on enc0 of the remote side. > > Replace the kernel on fwA with one minus the patch and it works fine > (except it will spontaneously reboot under high load). > > That's with patch-xform_freespfix-3. Should that work with 7.2 in > combination with the NAT-T patch? It applies cleanly. Pathc has been done against TRUNK, but it is probably exactly the same for 7.2. And yes, we're using it in combination with NAT-T patch. Can you test again with an INVARIANT kernel, which (I hope) will raise any locking issue ? Thanks for the report, Yvan. From yongari at FreeBSD.org Tue Jun 23 07:57:14 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Jun 23 07:57:21 2009 Subject: kern/87194: [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum Message-ID: <200906230757.n5N7vEpk022405@freefall.freebsd.org> Synopsis: [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jun 23 07:55:36 UTC 2009 State-Changed-Why: I guess you came across old bug of bridge(4) which it failed to disable Tx checksum offloading when one of member interface of a bridge can't handle Tx checksum offload. I believe that bug was fixed long time ago. Does this still problems on newer releases? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jun 23 07:55:36 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=87194 From yongari at FreeBSD.org Tue Jun 23 08:28:42 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Jun 23 08:28:49 2009 Subject: kern/114839: [fxp] fxp looses ability to speak with traffic Message-ID: <200906230828.n5N8Sfi9048897@freefall.freebsd.org> Synopsis: [fxp] fxp looses ability to speak with traffic State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jun 23 08:27:34 UTC 2009 State-Changed-Why: It seems your controller is plain i82559. Since you said you can see incoming traffics I think the controller do not have lock-up bug. By chance do you use fxp(4) on PAE environments or systems with more than 4GB of memory? Show me the output of "sysctl hw.busdma" to see whether bounce buffers are used. Also there was a lot of fxp(4) changes in HEAD. Could you try latest fxp(4) in HEAD? If you're using 7-stable or 7.2-RELEASE you can just copy if_fxp.c, if_fxpreg.h and if_fxpvar.h files from HEAD to 7-stable/7.2-RELEASE and rebuild kernel. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jun 23 08:27:34 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 From yongari at FreeBSD.org Tue Jun 23 08:31:15 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Jun 23 08:31:22 2009 Subject: kern/121983: [fxp] fxp0 MBUF and PAE Message-ID: <200906230831.n5N8VEDr056991@freefall.freebsd.org> Synopsis: [fxp] fxp0 MBUF and PAE State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jun 23 08:30:24 UTC 2009 State-Changed-Why: There was a couple of bus_dma(9) fixes in HEAD which may fix the issue on PAE environments. Could you try latest fxp(4) in HEAD? If you're using 7-stable or 7.2-RELEASE you can just copy if_fxp.c, if_fxpreg.h and if_fxpvar.h files from HEAD to 7-stable/7.2-RELEASE and rebuild kernel. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jun 23 08:30:24 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=121983 From yongari at FreeBSD.org Tue Jun 23 08:41:27 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Jun 23 08:41:33 2009 Subject: kern/124904: [fxp] EEPROM corruption with Compaq NC3163 NIC Message-ID: <200906230841.n5N8fQg9064842@freefall.freebsd.org> Synopsis: [fxp] EEPROM corruption with Compaq NC3163 NIC State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jun 23 08:39:57 UTC 2009 State-Changed-Why: Would you show me the output of "pciconf -lcv"? Also please give me more information for what other operating systems do when it detects EEPROM corruption. Do they write updated checksum to EEPROM? FreeBSD never write new data to EEPROM unless it have to disable dynamic standby mode. Did you see the message something like the following while fxp(4) probe is in progress? fxp0: Disabling dynamic standby mode in EEPROM Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jun 23 08:39:57 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=124904 From dave at daveg.ca Tue Jun 23 17:23:53 2009 From: dave at daveg.ca (David Gilbert) Date: Tue Jun 23 17:24:00 2009 Subject: kern/114839: [fxp] fxp looses ability to speak with traffic In-Reply-To: <200906230828.n5N8Sfi9048897@freefall.freebsd.org> References: <200906230828.n5N8Sfi9048897@freefall.freebsd.org> Message-ID: <4A410A1A.3050403@daveg.ca> yongari@FreeBSD.org wrote: > Synopsis: [fxp] fxp looses ability to speak with traffic > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Tue Jun 23 08:27:34 UTC 2009 > State-Changed-Why: > It seems your controller is plain i82559. Since you said you can > see incoming traffics I think the controller do not have lock-up > bug. By chance do you use fxp(4) on PAE environments or systems > with more than 4GB of memory? Show me the output of > "sysctl hw.busdma" to see whether bounce buffers are used. > > Also there was a lot of fxp(4) changes in HEAD. Could you try > latest fxp(4) in HEAD? If you're using 7-stable or 7.2-RELEASE you > can just copy if_fxp.c, if_fxpreg.h and if_fxpvar.h files from HEAD > to 7-stable/7.2-RELEASE and rebuild kernel. > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Tue Jun 23 08:27:34 UTC 2009 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 > Unfortunately, I lost access to that machine due to some business issues :). But I can tell you that it didn't have PAE enabled nor did it have 4G of memory (it either had 1G or 2G, but definately not 4G). Congrats on the cleanup of old tickets, but I can't do any testing for you as I don't have any other machines that did this. The server in question was a busy core router. My current core routers use em and bge chipsets. From pyunyh at gmail.com Wed Jun 24 01:14:45 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jun 24 01:14:54 2009 Subject: kern/114839: [fxp] fxp looses ability to speak with traffic In-Reply-To: <4A410A1A.3050403@daveg.ca> References: <200906230828.n5N8Sfi9048897@freefall.freebsd.org> <4A410A1A.3050403@daveg.ca> Message-ID: <20090624011958.GE10712@michelle.cdnetworks.co.kr> On Tue, Jun 23, 2009 at 01:00:10PM -0400, David Gilbert wrote: > yongari@FreeBSD.org wrote: > >Synopsis: [fxp] fxp looses ability to speak with traffic > > > >State-Changed-From-To: open->feedback > >State-Changed-By: yongari > >State-Changed-When: Tue Jun 23 08:27:34 UTC 2009 > >State-Changed-Why: > >It seems your controller is plain i82559. Since you said you can > >see incoming traffics I think the controller do not have lock-up > >bug. By chance do you use fxp(4) on PAE environments or systems > >with more than 4GB of memory? Show me the output of > >"sysctl hw.busdma" to see whether bounce buffers are used. > > > >Also there was a lot of fxp(4) changes in HEAD. Could you try > >latest fxp(4) in HEAD? If you're using 7-stable or 7.2-RELEASE you > >can just copy if_fxp.c, if_fxpreg.h and if_fxpvar.h files from HEAD > >to 7-stable/7.2-RELEASE and rebuild kernel. > > > > > >Responsible-Changed-From-To: freebsd-net->yongari > >Responsible-Changed-By: yongari > >Responsible-Changed-When: Tue Jun 23 08:27:34 UTC 2009 > >Responsible-Changed-Why: > >Grab. > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 > > > Unfortunately, I lost access to that machine due to some business issues > :). But I can tell you that it didn't have PAE enabled nor did it have > 4G of memory (it either had 1G or 2G, but definately not 4G). > Ok, thanks for reply. > Congrats on the cleanup of old tickets, but I can't do any testing for > you as I don't have any other machines that did this. The server in > question was a busy core router. My current core routers use em and bge The server was SMP box? Also you used to rely on DEVICE_POLLING on fxp(4)? It's hard to say what was wrong here. You didn't encounter watchdog timeouts and you saw incoming traffic so I guess the controller is alive. What makes me wonder is why other end can't see frames sent from fxp(4). Are you sure you could be able to see incoming traffic? Checking netstat(1) also may have helped to analyze the issue as fxp(4) uses hardware MAC counters. ATM the only possible cause of the issue I can think of is the side-effect of disabling dynamic standby mode. You have to cold reboot(shutdown and remove power cord and wait a couple of min before replug the power cord) your box if you see the following message. fxp0: Disabling dynamic standby mode in EEPROM Otherwise you may encounter watchdog timeouts or odd behaviour. > chipsets. > From gnn at neville-neil.com Wed Jun 24 21:08:41 2009 From: gnn at neville-neil.com (George Neville-Neil) Date: Wed Jun 24 21:08:48 2009 Subject: in_pcb crash on 7.2 RELEASE 64bits In-Reply-To: <86068e730906221718o7b37660ei640fe85085624e06@mail.gmail.com> References: <86068e730906221718o7b37660ei640fe85085624e06@mail.gmail.com> Message-ID: <6A71F680-1A9A-4F0A-AF96-CE67BA286CBE@neville-neil.com> On Jun 22, 2009, at 20:18 , Jerry Toung wrote: > Hi List, > may be someone has seen this already before I dig into the issue > myself. A > consistent crash > with the following trace. > Sorry, but what causes the crash? Is this spontaneous or are you running something on the machine that someone could use to reproduce this? Best, George From jrytoung at gmail.com Thu Jun 25 04:26:03 2009 From: jrytoung at gmail.com (Jerry Toung) Date: Thu Jun 25 04:26:10 2009 Subject: in_pcb crash on 7.2 RELEASE 64bits In-Reply-To: <6A71F680-1A9A-4F0A-AF96-CE67BA286CBE@neville-neil.com> References: <86068e730906221718o7b37660ei640fe85085624e06@mail.gmail.com> <6A71F680-1A9A-4F0A-AF96-CE67BA286CBE@neville-neil.com> Message-ID: <86068e730906242126l290cf49ahd314165368c1416b@mail.gmail.com> On Wed, Jun 24, 2009 at 2:07 PM, George Neville-Neil wrote: > > On Jun 22, 2009, at 20:18 , Jerry Toung wrote: > > Hi List, >> may be someone has seen this already before I dig into the issue myself. >> A >> consistent crash >> with the following trace. >> >> Sorry, but what causes the crash? Is this spontaneous or are you running > something on the machine that someone could use to reproduce this? > > Best, > George it turned out to be a false alarm. a bad build caused this. sorry for the noise. Jerry From nvass9573 at gmx.com Thu Jun 25 08:43:20 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Thu Jun 25 08:43:27 2009 Subject: ndis and USB wirelless ethernet Message-ID: <4A43386D.80500@gmx.com> Hello, I am trying to use a wireless ethernet USB thingy, but the ndis interface never appears. Any hints? ndis0: NDIS API version: 5.1 lock order reversal: 1st 0xc0edc900 HAL preemption lock (HAL lock) @ /usr/src/sys/compat/ndis/subr_hal.c:416 2nd 0xc23a61ec NDIS USB (network driver) @ /usr/src/sys/compat/ndis/subr_usbd.c:802 KDB: stack backtrace: db_trace_self_wrapper(c0c0f65b,c75527e4,c08af235,c08a015b,c0c1249e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c7552840,...) at kdb_backtrace+0x29 _witness_debugger(c0c1249e,c23a61ec,c0c3cf54,c2114040,c0c36d8d,...) at _witness_debugger+0x25 witness_checkorder(c23a61ec,9,c0c36d8d,322,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c23a61ec,0,c0c36d8d,322,c27f2a00,...) at _mtx_lock_flags+0xc4 usbd_irpcancel(c26c3100,c27f2a00,c7552954,c75529a0,c0acfe2a,...) at usbd_irpcancel+0x5c end(c27f2a00,c75529f8,c2980c80,0,40000,...) at 0xc220c2e1 end(40000000,c2980c80,c23a5000,c2706000,0,...) at 0xc22036e1 ndis_wg111v3_sys_drv_data_start(c2706000,0,5,ff44,0,...) at ndis_wg111v3_sys_drv_data_start+0x768f ndis_wg111v3_sys_drv_data_start(c2706000,0,44,c7552a08,c2706000,...) at ndis_wg111v3_sys_drv_data_start+0x3d86 ndis_wg111v3_sys_drv_data_start(c2706000,44,c7552a2c,c26e077a,c2706000,...) at ndis_wg111v3_sys_drv_data_start+0x4a73 ndis_wg111v3_sys_drv_data_start(c2706000,c2706000,c7552a48,c26cf5d2,c2706000,...) at 0xc26f24b2 ndis_wg111v3_sys_drv_data_start(c2706000,c7552a68,c7552a94,c23a6000,c2706000,...) at 0xc26e077a ndis_wg111v3_sys_drv_data_start(c7552ad4,c7552ad0,c23a5000,0,c2703000,...) at ndis_wg111v3_sys_drv_data_start+0x65d2 x86_stdcall_call(c23a6000,c220bac0,c2703000,1,c085f2ac,...) at x86_stdcall_call+0x1e ndis_attach(c2460a80,c2460a80,c0bb64fd,0,c22bc864,...) at ndis_attach+0x33c ndisusb_attach(c2460a80,c221885c,c0cef938,c0bfc63d,80000000,...) at ndisusb_attach+0xdb device_attach(c2460a80,4,c0c0ed75,9f1) at device_attach+0x36f device_probe_and_attach(c2460a80,c7552c1c,ffffffff,c23ae400,0,...) at device_probe_and_attach+0x4e usb_probe_and_attach_sub(c23ae400,0,c0bf354f,4c4,c7552c18,...) at usb_probe_and_attach_sub+0xde usb_probe_and_attach(c23ae400,ff,1e,c7552ca8,c07a4654,...) at usb_probe_and_attach+0x1b3 uhub_explore(c2399c00,0,c0bf1fec,cd,c228add4,...) at uhub_explore+0x766 usb_bus_explore(c228add4,c228ae4c,c0bfb560,51,c0d5fec0,...) at usb_bus_explore+0xbb usb_process(c228ad74,c7552d38,c0c079d2,334,c237d7f8,...) at usb_process+0xde fork_exit(c07a6de0,c228ad74,c7552d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc7552d70, ebp = 0 --- ndis0: warning: not enough write buffer space (1). ndis0: warning: not enough write buffer space (1). ndis0: warning: not enough write buffer space (1). ndis0: warning: not enough write buffer space (1). ndis0: warning: not enough write buffer space (1). Then it goes on repeating the "ndis0: ..." message. Thanks in advance for any hint, Nikos From weongyo.jeong at gmail.com Thu Jun 25 10:34:27 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Thu Jun 25 10:34:34 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <4A43386D.80500@gmx.com> References: <4A43386D.80500@gmx.com> Message-ID: <20090625103420.GD31161@weongyo.cdnetworks.kr> On Thu, Jun 25, 2009 at 11:42:21AM +0300, Nikos Vassiliadis wrote: > Hello, > > I am trying to use a wireless ethernet USB thingy, > but the ndis interface never appears. Any hints? > > > ndis0: NDIS API version: 5.1 > lock order reversal: > 1st 0xc0edc900 HAL preemption lock (HAL lock) @ > /usr/src/sys/compat/ndis/subr_hal.c:416 > 2nd 0xc23a61ec NDIS USB (network driver) @ > /usr/src/sys/compat/ndis/subr_usbd.c:802 > KDB: stack backtrace: > db_trace_self_wrapper(c0c0f65b,c75527e4,c08af235,c08a015b,c0c1249e,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c7552840,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c1249e,c23a61ec,c0c3cf54,c2114040,c0c36d8d,...) at > _witness_debugger+0x25 > witness_checkorder(c23a61ec,9,c0c36d8d,322,0,...) at > witness_checkorder+0x839 > _mtx_lock_flags(c23a61ec,0,c0c36d8d,322,c27f2a00,...) at > _mtx_lock_flags+0xc4 > usbd_irpcancel(c26c3100,c27f2a00,c7552954,c75529a0,c0acfe2a,...) at > usbd_irpcancel+0x5c > end(c27f2a00,c75529f8,c2980c80,0,40000,...) at 0xc220c2e1 > end(40000000,c2980c80,c23a5000,c2706000,0,...) at 0xc22036e1 > ndis_wg111v3_sys_drv_data_start(c2706000,0,5,ff44,0,...) at > ndis_wg111v3_sys_drv_data_start+0x768f > ndis_wg111v3_sys_drv_data_start(c2706000,0,44,c7552a08,c2706000,...) at > ndis_wg111v3_sys_drv_data_start+0x3d86 > ndis_wg111v3_sys_drv_data_start(c2706000,44,c7552a2c,c26e077a,c2706000,...) > at ndis_wg111v3_sys_drv_data_start+0x4a73 > ndis_wg111v3_sys_drv_data_start(c2706000,c2706000,c7552a48,c26cf5d2,c2706000,...) > at 0xc26f24b2 > ndis_wg111v3_sys_drv_data_start(c2706000,c7552a68,c7552a94,c23a6000,c2706000,...) > at 0xc26e077a > ndis_wg111v3_sys_drv_data_start(c7552ad4,c7552ad0,c23a5000,0,c2703000,...) > at ndis_wg111v3_sys_drv_data_start+0x65d2 > x86_stdcall_call(c23a6000,c220bac0,c2703000,1,c085f2ac,...) at > x86_stdcall_call+0x1e > ndis_attach(c2460a80,c2460a80,c0bb64fd,0,c22bc864,...) at ndis_attach+0x33c > ndisusb_attach(c2460a80,c221885c,c0cef938,c0bfc63d,80000000,...) at > ndisusb_attach+0xdb > device_attach(c2460a80,4,c0c0ed75,9f1) at device_attach+0x36f > device_probe_and_attach(c2460a80,c7552c1c,ffffffff,c23ae400,0,...) at > device_probe_and_attach+0x4e > usb_probe_and_attach_sub(c23ae400,0,c0bf354f,4c4,c7552c18,...) at > usb_probe_and_attach_sub+0xde > usb_probe_and_attach(c23ae400,ff,1e,c7552ca8,c07a4654,...) at > usb_probe_and_attach+0x1b3 > uhub_explore(c2399c00,0,c0bf1fec,cd,c228add4,...) at uhub_explore+0x766 > usb_bus_explore(c228add4,c228ae4c,c0bfb560,51,c0d5fec0,...) at > usb_bus_explore+0xbb > usb_process(c228ad74,c7552d38,c0c079d2,334,c237d7f8,...) at usb_process+0xde > fork_exit(c07a6de0,c228ad74,c7552d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc7552d70, ebp = 0 --- > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > > Then it goes on repeating the "ndis0: ..." message. > > Thanks in advance for any hint, Hello Nikos, Could you please test with attached patch and show me the result? regards, Weongyo Jeong -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_ndisusb_20090625.diff Type: text/x-diff Size: 986 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090625/d1bd99fa/patch_ndisusb_20090625.bin From nvass9573 at gmx.com Thu Jun 25 12:17:11 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Thu Jun 25 12:17:18 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <20090625103420.GD31161@weongyo.cdnetworks.kr> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> Message-ID: <4A436A8A.1000405@gmx.com> Weongyo Jeong wrote: > Could you please test with attached patch and show me the result? The repeating warning message went away and the ndis0 interface appeared. Now, when I try to 'up' the interface, ifconfig gets stuck in KeWFS state. If I try a second ifconfig, it will show the ndis0 in up state, though I am not sure it really is. Any subsequent command(assign an IP address, change media, change MTU etc) fails. The ether command also stucks in KeWFS. Thanks a lot for the patch Weongyo, if you have any other idea, I'll be happy to test it! Nikos From weongyo.jeong at gmail.com Fri Jun 26 04:12:53 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Fri Jun 26 04:13:03 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <4A436A8A.1000405@gmx.com> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> Message-ID: <20090626041246.GE31161@weongyo.cdnetworks.kr> On Thu, Jun 25, 2009 at 03:16:10PM +0300, Nikos Vassiliadis wrote: > Weongyo Jeong wrote: > >Could you please test with attached patch and show me the result? > > The repeating warning message went away and the ndis0 interface > appeared. Now, when I try to 'up' the interface, ifconfig gets > stuck in KeWFS state. If I try a second ifconfig, it will show > the ndis0 in up state, though I am not sure it really is. Any > subsequent command(assign an IP address, change media, change > MTU etc) fails. The ether command also stucks in KeWFS. > > Thanks a lot for the patch Weongyo, if you have any other > idea, I'll be happy to test it! Could you show me the *full* result after enabling `sysctl debug.ndis=1'? Maybe steps would be as follows: # kldload ndis if_ndis NDIS_module # sysctl debug.ndis=1 [then plug-in USB stick] # ifconfig wlan0 create wlandev ndis0 # ifconfig wlan0 ssid blah up regards, Weongyo Jeong From callumgibson at optusnet.com.au Fri Jun 26 04:15:03 2009 From: callumgibson at optusnet.com.au (Callum Gibson) Date: Fri Jun 26 04:15:10 2009 Subject: bwi mac address changes? Message-ID: <20090626013829.GA49997@omma.gibson.athome> G'day, I'm giving the new bwi driver a spin on my HP nx6125 which has a Broadcom BCM4309 wireless nic. This machine came with 32bit WinXP and under FreeBSD I've been using ndis with a 64bit Windows driver from Asus (I think). As a general report, the bwi driver in combination with the bwi-firmware-kmod port is working well. I am experiencing a display glitch on my X root window which seems to be related to using this driver, but no issues apart from that so far. Today I noticed I'd retrieved a new IP with DHCP and tracked it down to a change in MAC address. Going through the messages file I noticed it was always one less when using bwi and reverted back to the original MAC address under ndis (and Windows XP with the 32 bit driver). ndis: XX:XX:XX:XX:XX:39 bwi: XX:XX:XX:XX:XX:38 Is this expected behaviour or is something odd happening? It's not related to the firmware kmod because the logs showed it changed MAC with bwi before I'd installed that port. Someone suggested it might be trimming the LSB. I'm running fairly recent current (a week old): FreeBSD incant 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Thu Jun 25 20:48:42 EST 2009 root@incant:/usr/obj/usr/src/sys/INCANT amd64 regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From aman.jassal at esigetel.fr Fri Jun 26 07:59:00 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Fri Jun 26 07:59:07 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <4A43386D.80500@gmx.com> References: <4A43386D.80500@gmx.com> Message-ID: <12249.195.115.85.204.1246001992.squirrel@webmail.esigetel.fr> Hello Mr.Vassiliadis, I see you were trying to use a Netgear WG111v3 WiFi dongle. I had also tried to work with this dongle last year with FreeBSD 7.0 but to no avail, ndis never managed to build a correct driver module for this dongle. I don't know if the more recent versions of FreeBSD have added support for this dongle, but if you are in a hurry, you can try using Hercules' WiFi dongle for example, they are well taken in charge of by the rum driver. NDIS works well when you have devices and their XP drivers, I don't really know if the guys working on Project Evil have also performed some work to build modules with Vista drivers. Good luck Aman Jassal Le Jeu 25 juin 2009 10:42, Nikos Vassiliadis a ?crit : > Hello, > > > I am trying to use a wireless ethernet USB thingy, > but the ndis interface never appears. Any hints? > > > ndis0: NDIS API version: 5.1 > lock order reversal: 1st 0xc0edc900 HAL preemption lock (HAL lock) @ > /usr/src/sys/compat/ndis/subr_hal.c:416 > 2nd 0xc23a61ec NDIS USB (network driver) @ > /usr/src/sys/compat/ndis/subr_usbd.c:802 > KDB: stack backtrace: > db_trace_self_wrapper(c0c0f65b,c75527e4,c08af235,c08a015b,c0c1249e,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c7552840,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c1249e,c23a61ec,c0c3cf54,c2114040,c0c36d8d,...) at > _witness_debugger+0x25 > witness_checkorder(c23a61ec,9,c0c36d8d,322,0,...) at > witness_checkorder+0x839 > _mtx_lock_flags(c23a61ec,0,c0c36d8d,322,c27f2a00,...) at > _mtx_lock_flags+0xc4 > usbd_irpcancel(c26c3100,c27f2a00,c7552954,c75529a0,c0acfe2a,...) at > usbd_irpcancel+0x5c end(c27f2a00,c75529f8,c2980c80,0,40000,...) at > 0xc220c2e1 > end(40000000,c2980c80,c23a5000,c2706000,0,...) at 0xc22036e1 > ndis_wg111v3_sys_drv_data_start(c2706000,0,5,ff44,0,...) at > ndis_wg111v3_sys_drv_data_start+0x768f > ndis_wg111v3_sys_drv_data_start(c2706000,0,44,c7552a08,c2706000,...) at > ndis_wg111v3_sys_drv_data_start+0x3d86 > ndis_wg111v3_sys_drv_data_start(c2706000,44,c7552a2c,c26e077a,c2706000,.. > .) > at ndis_wg111v3_sys_drv_data_start+0x4a73 > ndis_wg111v3_sys_drv_data_start(c2706000,c2706000,c7552a48,c26cf5d2,c2706 > 000,...) > at 0xc26f24b2 > ndis_wg111v3_sys_drv_data_start(c2706000,c7552a68,c7552a94,c23a6000,c2706 > 000,...) > at 0xc26e077a > ndis_wg111v3_sys_drv_data_start(c7552ad4,c7552ad0,c23a5000,0,c2703000,... > ) > at ndis_wg111v3_sys_drv_data_start+0x65d2 > x86_stdcall_call(c23a6000,c220bac0,c2703000,1,c085f2ac,...) at > x86_stdcall_call+0x1e > ndis_attach(c2460a80,c2460a80,c0bb64fd,0,c22bc864,...) at > ndis_attach+0x33c > ndisusb_attach(c2460a80,c221885c,c0cef938,c0bfc63d,80000000,...) at > ndisusb_attach+0xdb device_attach(c2460a80,4,c0c0ed75,9f1) at > device_attach+0x36f > device_probe_and_attach(c2460a80,c7552c1c,ffffffff,c23ae400,0,...) at > device_probe_and_attach+0x4e > usb_probe_and_attach_sub(c23ae400,0,c0bf354f,4c4,c7552c18,...) at > usb_probe_and_attach_sub+0xde > usb_probe_and_attach(c23ae400,ff,1e,c7552ca8,c07a4654,...) at > usb_probe_and_attach+0x1b3 > uhub_explore(c2399c00,0,c0bf1fec,cd,c228add4,...) at uhub_explore+0x766 > usb_bus_explore(c228add4,c228ae4c,c0bfb560,51,c0d5fec0,...) at > usb_bus_explore+0xbb > usb_process(c228ad74,c7552d38,c0c079d2,334,c237d7f8,...) at > usb_process+0xde fork_exit(c07a6de0,c228ad74,c7552d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = > 0xc7552d70, ebp = 0 --- > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > ndis0: warning: not enough write buffer space (1). > > > Then it goes on repeating the "ndis0: ..." message. > > > Thanks in advance for any hint, > > > Nikos > _______________________________________________ > 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 hrs at FreeBSD.org Fri Jun 26 08:01:14 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Fri Jun 26 08:02:34 2009 Subject: RFC: convert net.inet6.ip6.{accept_rtadv,auto_linklocal} to per-interface flags Message-ID: <20090626.170006.244306978.hrs@allbsd.org> Skipped content of type multipart/mixed-------------- 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/20090626/322c709b/attachment.pgp From bms at FreeBSD.org Fri Jun 26 16:35:40 2009 From: bms at FreeBSD.org (Bruce Simpson) Date: Fri Jun 26 16:35:47 2009 Subject: RFC: convert net.inet6.ip6.{accept_rtadv, auto_linklocal} to per-interface flags In-Reply-To: <20090626.170006.244306978.hrs@allbsd.org> References: <20090626.170006.244306978.hrs@allbsd.org> Message-ID: <4A44F49B.7020403@FreeBSD.org> Hiroki Sato wrote: > The ip6.autolinklocal had been enabled but disabled since 6.2R by > default because automatic configuration of L3 address is insecure. > However, it makes IPv6 configuration complex because of no link-local > address on an interface. Malformed address configuration can be > happened easily on a system with $ipv6_enable="NO". for example. In > addition, the rc.conf knob does not mean the IPv6 functionality is > completely disabled. Using an interface for IPv4-only is difficult. > The MLDv2 code will use the link-local address by default if available, otherwise if the link is in DAD it will use ::. In fact, link-local addresses are needed to make stuff like OSPFv3 and MLDv2 work properly. So we are in fact shooting ourselves in the foot over people's paranoia. Link-scope addresses starting 'fe80' don't belong in traffic beyond one L2 hop. We already have a check for 169.254.0.0/16 in ip_forward(), ip6_forward() performs a scope check. If people have legitimate security concerns about these address ranges, the place to implement that is at the perimeter, or in other forwarding policy, not by breaking IPv6 deployment for end-users. > So, I want to add the following changes: > > 1. Use per-interface ND6 flag "ifdisabled" as a flag for if it is > IPv6-enabled or not. Set it by default. > > 2. Automatic link-local address configuration is performed when the > ifdisabled flag is clear, not at attach time of the interface. > This is implemented as a per-interface flag "auto_linklocal". > This seems perfectly reasonable -- in fact -- it's closer to how other platforms do it. > 3. Accepting Router Advertisement message is also controlled by > per-interface flag "accept_rtadv". > Again, RTADV is something which most people who use IPv6 on an endpoint in a stub network are going to use, so it's reasonable to have it controllable on a per-interface basis. > The patch for the latest current is attached. Thanks. > Patch looks fine, but I'd fix the style(9) bugs before committing; && operators, etc should be before the line break, and initializers in variable declarations are generally discouraged. Also there should be whitespace between code and variable declarations. thanks, BMS From atkin901 at yahoo.com Fri Jun 26 18:36:40 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Fri Jun 26 18:36:46 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> Message-ID: Jack Vogel wrote: > I'm willing to bet that its in fact the same problem that VMWare is > having. Our method of getting the mac address changed, and the emulations > seem to be unprepared for it. > > This was done for a real customer requirement to allow support of > alternate mac addressing in firmware. What happens now is a warm reset of > the hardware is done, followed by reading the RAR[0] register. In a real > Intel NIC the mac > address will be valid in that register, but in VMWare, and I'm willing to > bet in > VirtualBox as well, its 0. > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > you tell me when you pick e1000 what real adapter it claims to emulate? > > I am considering options for this problem. The one I lean toward right now > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > Express > hardware, it will be frozen as it were, the idea is that with no new work > on it > it will not suffer from any regression type failures. If I do this, there > are some > strategy issues, and its those I'm thinking about. > > In any case, I intend to have this problem resolved for 8's release. Stay > tuned. Just FYI. this is a real machine with real cards. Older fiber cards. em0: mem 0xdb000000-0xdb01ffff irq 28 at device 4.0 on pci19 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: mem 0xdb020000-0xdb03ffff irq 29 at device 9.0 on pci19 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000 em1: Invalid MAC address device_attach: em1 attach returned 5 $ pciconf -v -l |grep -A4 -e "^em" em0@pci0:19:4:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci0:19:9:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From jfvogel at gmail.com Sat Jun 27 00:25:30 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Sat Jun 27 00:25:36 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> Message-ID: <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> Oh, hmmm, so this card is completely broken with the new driver then? What was the last working version you used? Jack On Fri, Jun 26, 2009 at 11:36 AM, Mark Atkinson wrote: > Jack Vogel wrote: > > > I'm willing to bet that its in fact the same problem that VMWare is > > having. Our method of getting the mac address changed, and the emulations > > seem to be unprepared for it. > > > > This was done for a real customer requirement to allow support of > > alternate mac addressing in firmware. What happens now is a warm reset of > > the hardware is done, followed by reading the RAR[0] register. In a real > > Intel NIC the mac > > address will be valid in that register, but in VMWare, and I'm willing to > > bet in > > VirtualBox as well, its 0. > > > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > > you tell me when you pick e1000 what real adapter it claims to emulate? > > > > I am considering options for this problem. The one I lean toward right > now > > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > > Express > > hardware, it will be frozen as it were, the idea is that with no new work > > on it > > it will not suffer from any regression type failures. If I do this, there > > are some > > strategy issues, and its those I'm thinking about. > > > > In any case, I intend to have this problem resolved for 8's release. Stay > > tuned. > > Just FYI. this is a real machine with real cards. Older fiber cards. > > em0: mem > 0xdb000000-0xdb01ffff > irq 28 at device 4.0 on pci19 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000 > em0: Invalid MAC address > device_attach: em0 attach returned 5 > em1: mem > 0xdb020000-0xdb03ffff > irq 29 at device 9.0 on pci19 > em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000 > em1: Invalid MAC address > device_attach: em1 attach returned 5 > > > $ pciconf -v -l |grep -A4 -e "^em" > em0@pci0:19:4:0: class=0x020000 card=0x10008086 chip=0x10008086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82542 Gigabit Ethernet Controller' > class = network > subclass = ethernet > em1@pci0:19:9:0: class=0x020000 card=0x10008086 chip=0x10008086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82542 Gigabit Ethernet Controller' > class = network > subclass = ethernet > > > > -- > Mark Atkinson > atkin901@yahoo.com > (!wired)?(coffee++):(wired); > > > _______________________________________________ > 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 rpaulo at freebsd.org Sat Jun 27 10:45:21 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sat Jun 27 10:45:53 2009 Subject: RFC: convert net.inet6.ip6.{accept_rtadv, auto_linklocal} to per-interface flags In-Reply-To: <20090626.170006.244306978.hrs@allbsd.org> References: <20090626.170006.244306978.hrs@allbsd.org> Message-ID: On 26 Jun 2009, at 09:00, Hiroki Sato wrote: > Hi all, > > I want to convert net.inet6.ip6.{accept_rtadv,auto_linklocal} to > per-interface flags to nuke rc.d/auto_linklocal. The motivations and > changes are as follow. If you are using IPv6 and/or familiar with > the IPv6 implementation, please let me know your comments. > > The ip6.autolinklocal had been enabled but disabled since 6.2R by > default because automatic configuration of L3 address is insecure. > However, it makes IPv6 configuration complex because of no link-local > address on an interface. Malformed address configuration can be > happened easily on a system with $ipv6_enable="NO". for example. In > addition, the rc.conf knob does not mean the IPv6 functionality is > completely disabled. Using an interface for IPv4-only is difficult. > > So, I want to add the following changes: > > 1. Use per-interface ND6 flag "ifdisabled" as a flag for if it is > IPv6-enabled or not. Set it by default. This looks okay, but "ifdisabled" seems to mean "disable the interface" instead of the actual meaning: "disable ipv6 neighbor discovery / disable ipv6 link local". Bikeshed apart, what about: # ifconfig fxp0 -nd6 (to disable ND6) # ifconfig fxp0 nd6 (to enable it) And ifconfig fxp0 will show "nd6" or "-nd6" depending on wether the bit is on or off, respectively. "accept_rtadvd" could follow the same principles. What do you think? -- Rui Paulo From nvass9573 at gmx.com Sat Jun 27 13:14:36 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Sat Jun 27 13:14:44 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <20090626041246.GE31161@weongyo.cdnetworks.kr> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> Message-ID: <4A461AF9.7040900@gmx.com> Weongyo Jeong wrote: > Could you show me the *full* result after enabling `sysctl debug.ndis=1'? > Maybe steps would be as follows: > > # kldload ndis if_ndis NDIS_module > # sysctl debug.ndis=1 > [then plug-in USB stick] It goes like this: ugen1.2: at usbus1 ndis0: NDIS API version: 5.1 attach done. lock order reversal: 1st 0xc0edc900 HAL preemption lock (HAL lock) @ /usr/src/sys/compat/ndis/subr_hal.c:416 2nd 0xc23b19ec NDIS USB (network driver) @ /usr/src/sys/compat/ndis/subr_usbd.c:803 KDB: stack backtrace: db_trace_self_wrapper(c0c0f65b,c755e8b8,c08af235,c08a015b,c0c1249e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c755e914,...) at kdb_backtrace+0x29 _witness_debugger(c0c1249e,c23b19ec,c0c3cf54,c2114040,c0c36d8d,...) at _witness_debugger+0x25 witness_checkorder(c23b19ec,9,c0c36d8d,323,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c23b19ec,0,c0c36d8d,323,c2692400,...) at _mtx_lock_flags+0xc4 usbd_irpcancel(c24f1400,c2692400,c755ea28,c755ea74,c0acfe2a,...) at usbd_irpcancel+0x5c end(c2692400,c2976b80,c26ea000,c26ea000,c755ea5c,...) at 0xc220c2e1 end(c26ea000,0,0,c26ea294,c755ea78,...) at 0xc22036e1 ndis_wg111v3_sys_drv_data_start(c26ea000,0,c26ea000,c26ea000,0,...) at ndis_wg111v3_sys_drv_data_start+0x5cac ndis_wg111v3_sys_drv_data_start(c26ea000,c2202000,c26ea000,0,c755eaa8,...) at ndis_wg111v3_sys_drv_data_start+0x5fec ndis_wg111v3_sys_drv_data_start(c26ea000,c755eab4,c755eacc,c26b206a,c755eae4,...) at ndis_wg111v3_sys_drv_data_start+0x603f ndis_wg111v3_sys_drv_data_start(c26ea000,c23b186c,c26ea000,c0ac7429,c26b206a,...) at ndis_wg111v3_sys_drv_data_start+0x611f x86_stdcall_call(c23b1800,c755eb0e,c755eb14,c755eb18,c2aa60e4,...) at x86_stdcall_call+0x1e ndis_attach(c23d6b80,c23d6b80,c0bb64fd,0,c238da24,...) at ndis_attach+0xf71 ndisusb_attach(c23d6b80,c221885c,c0cef938,c0bfc63d,80000000,...) at ndisusb_attach+0xdb device_attach(c23d6b80,4,c0c0ed75,9f1) at device_attach+0x36f device_probe_and_attach(c23d6b80,c755ec1c,ffffffff,c2275800,0,...) at device_probe_and_attach+0x4e usb_probe_and_attach_sub(c2275800,0,c0bf354f,4c4,0,...) at usb_probe_and_attach_sub+0xde usb_probe_and_attach(c2275800,ff,c2399800,1,0,...) at usb_probe_and_attach+0x1b3 uhub_explore(c2399800,0,c0bf1fec,cd,c229ed34,...) at uhub_explore+0x766 usb_bus_explore(c229ed34,c229edac,c0bfb560,51,c0d5fec0,...) at usb_bus_explore+0xbb usb_process(c229ecd4,c755ed38,c0c079d2,334,c21a7d48,...) at usb_process+0xde fork_exit(c07a6de0,c229ecd4,c755ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc755ed70, ebp = 0 --- > # ifconfig wlan0 create wlandev ndis0 > # ifconfig wlan0 ssid blah up lab# ifconfig wlan0 ssid blah up load: 0.06 cmd: ifconfig 1245 [-] 1.92r 0.02u 0.12s 0% 1568k load: 0.06 cmd: ifconfig 1245 [-] 2.25r 0.02u 0.12s 0% 1568k lab# ifconfig ndis0 up load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.27r 0.00u 0.01s 0% 1568k load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.66r 0.00u 0.01s 0% 1568k lab# ifconfig ndis0 ndis0: flags=8803 metric 0 mtu 2290 ether 00:1b:2f:be:78:aa media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated lab# ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:1b:2f:be:78:aa media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid blah channel 1 (2412 Mhz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bintval 0 lab# ifconfig wlan0 scan lab# ifconfig wlan0 list scan lab# Any ideas? Thanks, Nikos From onemda at gmail.com Sat Jun 27 15:43:16 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Jun 27 15:43:24 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <4A461AF9.7040900@gmx.com> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> Message-ID: <3a142e750906270843u2c44d240r9d8cadcf5f800855@mail.gmail.com> On 6/27/09, Nikos Vassiliadis wrote: > Weongyo Jeong wrote: >> Could you show me the *full* result after enabling `sysctl debug.ndis=1'? >> Maybe steps would be as follows: >> >> # kldload ndis if_ndis NDIS_module >> # sysctl debug.ndis=1 >> [then plug-in USB stick] > > It goes like this: > > ugen1.2: at usbus1 > ndis0: NDIS API version: 5.1 > attach done. > lock order reversal: > 1st 0xc0edc900 HAL preemption lock (HAL lock) @ > /usr/src/sys/compat/ndis/subr_hal.c:416 > 2nd 0xc23b19ec NDIS USB (network driver) @ > /usr/src/sys/compat/ndis/subr_usbd.c:803 > KDB: stack backtrace: > db_trace_self_wrapper(c0c0f65b,c755e8b8,c08af235,c08a015b,c0c1249e,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c755e914,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c1249e,c23b19ec,c0c3cf54,c2114040,c0c36d8d,...) at > _witness_debugger+0x25 > witness_checkorder(c23b19ec,9,c0c36d8d,323,0,...) at > witness_checkorder+0x839 > _mtx_lock_flags(c23b19ec,0,c0c36d8d,323,c2692400,...) at > _mtx_lock_flags+0xc4 > usbd_irpcancel(c24f1400,c2692400,c755ea28,c755ea74,c0acfe2a,...) at > usbd_irpcancel+0x5c > end(c2692400,c2976b80,c26ea000,c26ea000,c755ea5c,...) at 0xc220c2e1 > end(c26ea000,0,0,c26ea294,c755ea78,...) at 0xc22036e1 > ndis_wg111v3_sys_drv_data_start(c26ea000,0,c26ea000,c26ea000,0,...) at > ndis_wg111v3_sys_drv_data_start+0x5cac > ndis_wg111v3_sys_drv_data_start(c26ea000,c2202000,c26ea000,0,c755eaa8,...) > at ndis_wg111v3_sys_drv_data_start+0x5fec > ndis_wg111v3_sys_drv_data_start(c26ea000,c755eab4,c755eacc,c26b206a,c755eae4,...) > at ndis_wg111v3_sys_drv_data_start+0x603f > ndis_wg111v3_sys_drv_data_start(c26ea000,c23b186c,c26ea000,c0ac7429,c26b206a,...) > at ndis_wg111v3_sys_drv_data_start+0x611f > x86_stdcall_call(c23b1800,c755eb0e,c755eb14,c755eb18,c2aa60e4,...) at > x86_stdcall_call+0x1e > ndis_attach(c23d6b80,c23d6b80,c0bb64fd,0,c238da24,...) at ndis_attach+0xf71 > ndisusb_attach(c23d6b80,c221885c,c0cef938,c0bfc63d,80000000,...) at > ndisusb_attach+0xdb > device_attach(c23d6b80,4,c0c0ed75,9f1) at device_attach+0x36f > device_probe_and_attach(c23d6b80,c755ec1c,ffffffff,c2275800,0,...) at > device_probe_and_attach+0x4e > usb_probe_and_attach_sub(c2275800,0,c0bf354f,4c4,0,...) at > usb_probe_and_attach_sub+0xde > usb_probe_and_attach(c2275800,ff,c2399800,1,0,...) at > usb_probe_and_attach+0x1b3 > uhub_explore(c2399800,0,c0bf1fec,cd,c229ed34,...) at uhub_explore+0x766 > usb_bus_explore(c229ed34,c229edac,c0bfb560,51,c0d5fec0,...) at > usb_bus_explore+0xbb > usb_process(c229ecd4,c755ed38,c0c079d2,334,c21a7d48,...) at usb_process+0xde > fork_exit(c07a6de0,c229ecd4,c755ed38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc755ed70, ebp = 0 --- > >> # ifconfig wlan0 create wlandev ndis0 >> # ifconfig wlan0 ssid blah up > > lab# ifconfig wlan0 ssid blah up > load: 0.06 cmd: ifconfig 1245 [-] 1.92r 0.02u 0.12s 0% 1568k > load: 0.06 cmd: ifconfig 1245 [-] 2.25r 0.02u 0.12s 0% 1568k > > lab# ifconfig ndis0 up > load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.27r 0.00u 0.01s 0% 1568k > load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.66r 0.00u 0.01s 0% 1568k > > > lab# ifconfig ndis0 > ndis0: flags=8803 metric 0 mtu 2290 > ether 00:1b:2f:be:78:aa > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > status: associated > lab# ifconfig wlan0 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:1b:2f:be:78:aa > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid blah channel 1 (2412 Mhz 11b) > country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 > bintval 0 > lab# ifconfig wlan0 scan > lab# ifconfig wlan0 list scan > lab# > > Any ideas? Are you saying that nothing is displayed on console(dmesg) by kernel? -- Paul From hrs at FreeBSD.org Sun Jun 28 00:08:52 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sun Jun 28 00:09:06 2009 Subject: RFC: convert net.inet6.ip6.{accept_rtadv,auto_linklocal} to per-interface flags In-Reply-To: References: <20090626.170006.244306978.hrs@allbsd.org> Message-ID: <20090628.083534.177750036.hrs@allbsd.org> Rui Paulo wrote in : rp> On 26 Jun 2009, at 09:00, Hiroki Sato wrote: rp> > So, I want to add the following changes: rp> > rp> > 1. Use per-interface ND6 flag "ifdisabled" as a flag for if it is rp> > IPv6-enabled or not. Set it by default. rp> rp> This looks okay, but "ifdisabled" seems to mean "disable the rp> interface" instead of the actual meaning: "disable ipv6 neighbor rp> discovery / disable ipv6 link local". Bikeshed apart, what about: rp> # ifconfig fxp0 -nd6 (to disable ND6) rp> # ifconfig fxp0 nd6 (to enable it) This is actually "ifconfig fxp0 *inet6* ifdisabled". The reason why I used this name is ndp(8) uses "disabled" and the flag constant is named as ND6_IFF_IFDISABLED. The "ifconfig fxp0 inet6 -nd6" is technically correct, but it sounds rather cryptic from viewpoint that we use it as a flag to disable IPv6. It means disabling NDP as well as marking all of the AF_INET6 addresses on that interface as IN6_IFF_TENTATIVE. Hm, actually I do not stick to the name "ifdisabled". Is "nd6" better? -- 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/20090628/e5e13dae/attachment.pgp From hrs at FreeBSD.org Sun Jun 28 00:08:53 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sun Jun 28 00:09:06 2009 Subject: RFC: convert net.inet6.ip6.{accept_rtadv,auto_linklocal} to per-interface flags In-Reply-To: <4A44F49B.7020403@FreeBSD.org> References: <20090626.170006.244306978.hrs@allbsd.org> <4A44F49B.7020403@FreeBSD.org> Message-ID: <20090628.090533.207531760.hrs@allbsd.org> Skipped content of type multipart/mixed-------------- 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/20090628/41f3451b/attachment.pgp From rpaulo at FreeBSD.org Sun Jun 28 00:11:29 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sun Jun 28 00:11:43 2009 Subject: RFC: convert net.inet6.ip6.{accept_rtadv, auto_linklocal} to per-interface flags In-Reply-To: <20090628.083534.177750036.hrs@allbsd.org> References: <20090626.170006.244306978.hrs@allbsd.org> <20090628.083534.177750036.hrs@allbsd.org> Message-ID: On 28 Jun 2009, at 00:35, Hiroki Sato wrote: > Rui Paulo wrote > in : > > rp> On 26 Jun 2009, at 09:00, Hiroki Sato wrote: > rp> > So, I want to add the following changes: > rp> > > rp> > 1. Use per-interface ND6 flag "ifdisabled" as a flag for if it > is > rp> > IPv6-enabled or not. Set it by default. > rp> > rp> This looks okay, but "ifdisabled" seems to mean "disable the > rp> interface" instead of the actual meaning: "disable ipv6 neighbor > rp> discovery / disable ipv6 link local". Bikeshed apart, what about: > rp> # ifconfig fxp0 -nd6 (to disable ND6) > rp> # ifconfig fxp0 nd6 (to enable it) > > This is actually "ifconfig fxp0 *inet6* ifdisabled". The reason why > I used this name is ndp(8) uses "disabled" and the flag constant is > named as ND6_IFF_IFDISABLED. Oh, I didn't catch that. Makes more sense. > The "ifconfig fxp0 inet6 -nd6" is technically correct, but it sounds > rather cryptic from viewpoint that we use it as a flag to disable > IPv6. It means disabling NDP as well as marking all of the AF_INET6 > addresses on that interface as IN6_IFF_TENTATIVE. > > Hm, actually I do not stick to the name "ifdisabled". Is "nd6" > better? Well, since I now understand it includes inet6 as part of the command, I don't care whichever name gets selected. Pick the one you prefer :-) -- Rui Paulo From atkin901 at yahoo.com Sun Jun 28 06:02:51 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Sun Jun 28 06:02:58 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> Message-ID: <688430.20427.qm@web37906.mail.mud.yahoo.com> ________________________________ >From: Jack Vogel >Oh, hmmm, so this card is completely broken with the new driver then? Completely, unfortunately (they don't show up in ifconfig, only in dmesg/pciconf). >What was the last working version you used? I was running a kernel from -current May 27th, 2009. I don't recall any significant em updates between then and when the new driver went in. On Fri, Jun 26, 2009 at 11:36 AM, Mark Atkinson wrote: Jack Vogel wrote: > I'm willing to bet that its in fact the same problem that VMWare is > having. Our method of getting the mac address changed, and the emulations > seem to be unprepared for it. > > This was done for a real customer requirement to allow support of > alternate mac addressing in firmware. What happens now is a warm reset of > the hardware is done, followed by reading the RAR[0] register. In a real > Intel NIC the mac > address will be valid in that register, but in VMWare, and I'm willing to > bet in > VirtualBox as well, its 0. > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > you tell me when you pick e1000 what real adapter it claims to emulate? > > I am considering options for this problem. The one I lean toward right now > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > Express > hardware, it will be frozen as it were, the idea is that with no new work > on it > it will not suffer from any regression type failures. If I do this, there > are some > strategy issues, and its those I'm thinking about. > > In any case, I intend to have this problem resolved for 8's release. Stay > tuned. Just FYI. this is a real machine with real cards. Older fiber cards. em0: mem 0xdb000000-0xdb01ffff irq 28 at device 4.0 on pci19 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: mem 0xdb020000-0xdb03ffff irq 29 at device 9.0 on pci19 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000 em1: Invalid MAC address device_attach: em1 attach returned 5 $ pciconf -v -l |grep -A4 -e "^em" em0@pci0:19:4:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci0:19:9:0: class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); _______________________________________________ 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 Sun Jun 28 12:24:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sun Jun 28 12:25:05 2009 Subject: Anyone working on RNDIS support? Message-ID: <4A476114.3010808@incunabulum.net> Hi, Is anyone out there working on RNDIS driver support for FreeBSD? For the uninitiated: RNDIS is a movement towards unifying device support, mostly instigated by Microsoft, where the hardware specifics of dealing with a device are pushed onto the device itself, perhaps using a microcontroller or in logic. The device itself is treated as an NDIS 'miniport', and the role of the kernel driver is just to tunnel NDIS itself across whatever commodity bus (PCI, PCI-e, USB, etc) is in use to physically connect the device. Just interested if anyone is doing it; the only RNDIS device I have is my cable modem (which already has an Ethernet port), however, we are seeing more Wi-Fi and DSL devices with USB RNDIS, and it would be great to have this support. cheers, BMS From nvass9573 at gmx.com Sun Jun 28 13:50:44 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Sun Jun 28 13:50:51 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <3a142e750906270843u2c44d240r9d8cadcf5f800855@mail.gmail.com> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> <3a142e750906270843u2c44d240r9d8cadcf5f800855@mail.gmail.com> Message-ID: <4A4774E9.70907@gmx.com> Paul B. Mahol wrote: > On 6/27/09, Nikos Vassiliadis wrote: >> Weongyo Jeong wrote: >>> Could you show me the *full* result after enabling `sysctl debug.ndis=1'? >>> Maybe steps would be as follows: >>> >>> # kldload ndis if_ndis NDIS_module >>> # sysctl debug.ndis=1 >>> [then plug-in USB stick] >> It goes like this: >> >> ugen1.2: at usbus1 >> ndis0: NDIS API version: 5.1 >> attach done. >> lock order reversal: >> 1st 0xc0edc900 HAL preemption lock (HAL lock) @ >> /usr/src/sys/compat/ndis/subr_hal.c:416 >> 2nd 0xc23b19ec NDIS USB (network driver) @ >> /usr/src/sys/compat/ndis/subr_usbd.c:803 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0c0f65b,c755e8b8,c08af235,c08a015b,c0c1249e,...) >> at db_trace_self_wrapper+0x26 >> kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c755e914,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c0c1249e,c23b19ec,c0c3cf54,c2114040,c0c36d8d,...) at >> _witness_debugger+0x25 >> witness_checkorder(c23b19ec,9,c0c36d8d,323,0,...) at >> witness_checkorder+0x839 >> _mtx_lock_flags(c23b19ec,0,c0c36d8d,323,c2692400,...) at >> _mtx_lock_flags+0xc4 >> usbd_irpcancel(c24f1400,c2692400,c755ea28,c755ea74,c0acfe2a,...) at >> usbd_irpcancel+0x5c >> end(c2692400,c2976b80,c26ea000,c26ea000,c755ea5c,...) at 0xc220c2e1 >> end(c26ea000,0,0,c26ea294,c755ea78,...) at 0xc22036e1 >> ndis_wg111v3_sys_drv_data_start(c26ea000,0,c26ea000,c26ea000,0,...) at >> ndis_wg111v3_sys_drv_data_start+0x5cac >> ndis_wg111v3_sys_drv_data_start(c26ea000,c2202000,c26ea000,0,c755eaa8,...) >> at ndis_wg111v3_sys_drv_data_start+0x5fec >> ndis_wg111v3_sys_drv_data_start(c26ea000,c755eab4,c755eacc,c26b206a,c755eae4,...) >> at ndis_wg111v3_sys_drv_data_start+0x603f >> ndis_wg111v3_sys_drv_data_start(c26ea000,c23b186c,c26ea000,c0ac7429,c26b206a,...) >> at ndis_wg111v3_sys_drv_data_start+0x611f >> x86_stdcall_call(c23b1800,c755eb0e,c755eb14,c755eb18,c2aa60e4,...) at >> x86_stdcall_call+0x1e >> ndis_attach(c23d6b80,c23d6b80,c0bb64fd,0,c238da24,...) at ndis_attach+0xf71 >> ndisusb_attach(c23d6b80,c221885c,c0cef938,c0bfc63d,80000000,...) at >> ndisusb_attach+0xdb >> device_attach(c23d6b80,4,c0c0ed75,9f1) at device_attach+0x36f >> device_probe_and_attach(c23d6b80,c755ec1c,ffffffff,c2275800,0,...) at >> device_probe_and_attach+0x4e >> usb_probe_and_attach_sub(c2275800,0,c0bf354f,4c4,0,...) at >> usb_probe_and_attach_sub+0xde >> usb_probe_and_attach(c2275800,ff,c2399800,1,0,...) at >> usb_probe_and_attach+0x1b3 >> uhub_explore(c2399800,0,c0bf1fec,cd,c229ed34,...) at uhub_explore+0x766 >> usb_bus_explore(c229ed34,c229edac,c0bfb560,51,c0d5fec0,...) at >> usb_bus_explore+0xbb >> usb_process(c229ecd4,c755ed38,c0c079d2,334,c21a7d48,...) at usb_process+0xde >> fork_exit(c07a6de0,c229ecd4,c755ed38) at fork_exit+0xb8 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xc755ed70, ebp = 0 --- >> >>> # ifconfig wlan0 create wlandev ndis0 >>> # ifconfig wlan0 ssid blah up >> lab# ifconfig wlan0 ssid blah up >> load: 0.06 cmd: ifconfig 1245 [-] 1.92r 0.02u 0.12s 0% 1568k >> load: 0.06 cmd: ifconfig 1245 [-] 2.25r 0.02u 0.12s 0% 1568k >> >> lab# ifconfig ndis0 up >> load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.27r 0.00u 0.01s 0% 1568k >> load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.66r 0.00u 0.01s 0% 1568k >> >> >> lab# ifconfig ndis0 >> ndis0: flags=8803 metric 0 mtu 2290 >> ether 00:1b:2f:be:78:aa >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11b >> status: associated >> lab# ifconfig wlan0 >> wlan0: flags=8843 metric 0 mtu 1500 >> ether 00:1b:2f:be:78:aa >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> ssid blah channel 1 (2412 Mhz 11b) >> country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 >> bintval 0 >> lab# ifconfig wlan0 scan >> lab# ifconfig wlan0 list scan >> lab# >> >> Any ideas? > > Are you saying that nothing is displayed on console(dmesg) by kernel? > > The only line that I omitted from my e-mail is: wlan0: Ethernet address: 00:1b:2f:be:78:aa From jfvogel at gmail.com Sun Jun 28 16:52:56 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Jun 28 16:53:04 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <688430.20427.qm@web37906.mail.mud.yahoo.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> Message-ID: <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> Sigh.. both windows and linux have frozen drivers for this old hardware, therefore they never see the regressions they cause in the current code :( I will make a patch for you to test on Monday Mark, it will do the same thing that I did in the e1000_82540.c, basically change the read_mac function back to the older way of doing it. Regards, Jack On Sat, Jun 27, 2009 at 10:36 PM, Mark Atkinson wrote: > > > ________________________________ > >From: Jack Vogel > >Oh, hmmm, so this card is completely broken with the new driver then? > > Completely, unfortunately (they don't show up in ifconfig, only in > dmesg/pciconf). > > >What was the last working version you used? > > I was running a kernel from -current May 27th, 2009. I don't recall > any significant em updates between then and when the new driver went > in. > > On Fri, Jun 26, 2009 at 11:36 AM, Mark Atkinson > wrote: > Jack Vogel wrote: > > I'm willing to bet that its in fact the same problem that VMWare is > > having. Our method of getting the mac address changed, and the emulations > > seem to be unprepared for it. > > > > This was done for a real customer requirement to allow support of > > alternate mac addressing in firmware. What happens now is a warm reset of > > the hardware is done, followed by reading the RAR[0] register. In a real > > Intel NIC the mac > > address will be valid in that register, but in VMWare, and I'm willing to > > bet in > > VirtualBox as well, its 0. > > > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > > you tell me when you pick e1000 what real adapter it claims to emulate? > > > > I am considering options for this problem. The one I lean toward right > now > > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > > Express > > hardware, it will be frozen as it were, the idea is that with no new work > > on it > > it will not suffer from any regression type failures. If I do this, there > > are some > > strategy issues, and its those I'm thinking about. > > > > In any case, I intend to have this problem resolved for 8's release. Stay > > tuned. > > Just FYI. this is a real machine with real cards. Older fiber cards. > > em0: mem > 0xdb000000-0xdb01ffff > irq 28 at device 4.0 on pci19 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000 > > em0: Invalid MAC address > device_attach: em0 attach returned 5 > em1: mem > 0xdb020000-0xdb03ffff > irq 29 at device 9.0 on pci19 > em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000 > > em1: Invalid MAC address > device_attach: em1 attach returned 5 > > > $ pciconf -v -l |grep -A4 -e "^em" > em0@pci0:19:4:0: class=0x020000 card=0x10008086 chip=0x10008086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82542 Gigabit Ethernet Controller' > class = network > subclass = ethernet > em1@pci0:19:9:0: class=0x020000 card=0x10008086 chip=0x10008086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82542 Gigabit Ethernet Controller' > class = network > subclass = ethernet > > > > -- > Mark Atkinson > atkin901@yahoo.com > (!wired)?(coffee++):(wired); > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > From mav at FreeBSD.org Sun Jun 28 17:19:16 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jun 28 17:19:23 2009 Subject: Anyone working on RNDIS support? In-Reply-To: <1246202598.00132971.1246192201@10.7.7.3> References: <1246202598.00132971.1246192201@10.7.7.3> Message-ID: <4A4797F9.9040509@FreeBSD.org> Bruce Simpson wrote: > Is anyone out there working on RNDIS driver support for FreeBSD? > > Just interested if anyone is doing it; the only RNDIS device I have is > my cable modem (which already has an Ethernet port), however, we are > seeing more Wi-Fi and DSL devices with USB RNDIS, and it would be great > to have this support. RNDIS is also used by Windows Mobile PDAs for USB connectivity. If somebody wants to work on this, I am ready do be an alpha-tester. Existing BT PAN interface I am using now is cool, but not very power-effective. -- Alexander Motin From weongyo.jeong at gmail.com Mon Jun 29 03:25:26 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Mon Jun 29 03:25:33 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <4A461AF9.7040900@gmx.com> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> Message-ID: <20090629032520.GA1138@weongyo.cdnetworks.kr> On Sat, Jun 27, 2009 at 04:13:29PM +0300, Nikos Vassiliadis wrote: > Weongyo Jeong wrote: > >Could you show me the *full* result after enabling `sysctl debug.ndis=1'? > >Maybe steps would be as follows: > > > > # kldload ndis if_ndis NDIS_module > > # sysctl debug.ndis=1 > > [then plug-in USB stick] > > It goes like this: > > ugen1.2: at usbus1 > ndis0: NDIS API version: 5.1 > attach done. > lock order reversal: > 1st 0xc0edc900 HAL preemption lock (HAL lock) @ > /usr/src/sys/compat/ndis/subr_hal.c:416 > 2nd 0xc23b19ec NDIS USB (network driver) @ > /usr/src/sys/compat/ndis/subr_usbd.c:803 > KDB: stack backtrace: > db_trace_self_wrapper(c0c0f65b,c755e8b8,c08af235,c08a015b,c0c1249e,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c755e914,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c1249e,c23b19ec,c0c3cf54,c2114040,c0c36d8d,...) at > _witness_debugger+0x25 > witness_checkorder(c23b19ec,9,c0c36d8d,323,0,...) at > witness_checkorder+0x839 > _mtx_lock_flags(c23b19ec,0,c0c36d8d,323,c2692400,...) at > _mtx_lock_flags+0xc4 > usbd_irpcancel(c24f1400,c2692400,c755ea28,c755ea74,c0acfe2a,...) at > usbd_irpcancel+0x5c > end(c2692400,c2976b80,c26ea000,c26ea000,c755ea5c,...) at 0xc220c2e1 > end(c26ea000,0,0,c26ea294,c755ea78,...) at 0xc22036e1 > ndis_wg111v3_sys_drv_data_start(c26ea000,0,c26ea000,c26ea000,0,...) at > ndis_wg111v3_sys_drv_data_start+0x5cac > ndis_wg111v3_sys_drv_data_start(c26ea000,c2202000,c26ea000,0,c755eaa8,...) > at ndis_wg111v3_sys_drv_data_start+0x5fec > ndis_wg111v3_sys_drv_data_start(c26ea000,c755eab4,c755eacc,c26b206a,c755eae4,...) > at ndis_wg111v3_sys_drv_data_start+0x603f > ndis_wg111v3_sys_drv_data_start(c26ea000,c23b186c,c26ea000,c0ac7429,c26b206a,...) > at ndis_wg111v3_sys_drv_data_start+0x611f > x86_stdcall_call(c23b1800,c755eb0e,c755eb14,c755eb18,c2aa60e4,...) at > x86_stdcall_call+0x1e > ndis_attach(c23d6b80,c23d6b80,c0bb64fd,0,c238da24,...) at ndis_attach+0xf71 > ndisusb_attach(c23d6b80,c221885c,c0cef938,c0bfc63d,80000000,...) at > ndisusb_attach+0xdb > device_attach(c23d6b80,4,c0c0ed75,9f1) at device_attach+0x36f > device_probe_and_attach(c23d6b80,c755ec1c,ffffffff,c2275800,0,...) at > device_probe_and_attach+0x4e > usb_probe_and_attach_sub(c2275800,0,c0bf354f,4c4,0,...) at > usb_probe_and_attach_sub+0xde > usb_probe_and_attach(c2275800,ff,c2399800,1,0,...) at > usb_probe_and_attach+0x1b3 > uhub_explore(c2399800,0,c0bf1fec,cd,c229ed34,...) at uhub_explore+0x766 > usb_bus_explore(c229ed34,c229edac,c0bfb560,51,c0d5fec0,...) at > usb_bus_explore+0xbb > usb_process(c229ecd4,c755ed38,c0c079d2,334,c21a7d48,...) at usb_process+0xde > fork_exit(c07a6de0,c229ecd4,c755ed38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc755ed70, ebp = 0 --- > > > # ifconfig wlan0 create wlandev ndis0 > > # ifconfig wlan0 ssid blah up > > lab# ifconfig wlan0 ssid blah up > load: 0.06 cmd: ifconfig 1245 [-] 1.92r 0.02u 0.12s 0% 1568k > load: 0.06 cmd: ifconfig 1245 [-] 2.25r 0.02u 0.12s 0% 1568k > > lab# ifconfig ndis0 up > load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.27r 0.00u 0.01s 0% 1568k > load: 0.06 cmd: ifconfig 1254 [KeWFS] 1.66r 0.00u 0.01s 0% 1568k > > > lab# ifconfig ndis0 > ndis0: flags=8803 metric 0 mtu 2290 > ether 00:1b:2f:be:78:aa > media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > status: associated > lab# ifconfig wlan0 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:1b:2f:be:78:aa > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid blah channel 1 (2412 Mhz 11b) > country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 > bintval 0 > lab# ifconfig wlan0 scan > lab# ifconfig wlan0 list scan > lab# > > Any ideas? OK. A last steps you can try is as follows and could you show me the result? # kldload ndis if_ndis NDIS_module # sysctl debug.ndis=1 # sysctl hw.ndisusb.halt=0 [then plug-in USB stick] # ifconfig wlan0 create wlandev ndis0 # ifconfig wlan0 ssid blah up regards, Weongyo Jeong From nvass9573 at gmx.com Mon Jun 29 08:53:23 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Mon Jun 29 08:53:30 2009 Subject: ndis and USB wirelless ethernet In-Reply-To: <20090629032520.GA1138@weongyo.cdnetworks.kr> References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> <20090629032520.GA1138@weongyo.cdnetworks.kr> Message-ID: <4A4880EF.5010206@gmx.com> Weongyo Jeong wrote: > OK. A last steps you can try is as follows and could you show me the > result? > > > # kldload ndis if_ndis NDIS_module > # sysctl debug.ndis=1 > # sysctl hw.ndisusb.halt=0 > [then plug-in USB stick] > # ifconfig wlan0 create wlandev ndis0 > # ifconfig wlan0 ssid blah up > It seems to work, but at the moment I have no access point I can associate to. I will have one by tomorrow or the day after tomorrow. I can see though several of the neighbourhood's access points. I'll get back to you in a few days Weongyo, thanks a lot for you help. Nikos From bugmaster at FreeBSD.org Mon Jun 29 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 29 11:08:57 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200906291107.n5TB73CM046428@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/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/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp 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 o kern/132984 net [netgraph] swi1: net 100% cpu usage 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/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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 305 problems total. From swun2010 at gmail.com Mon Jun 29 11:22:58 2009 From: swun2010 at gmail.com (Sam Wun) Date: Mon Jun 29 11:23:04 2009 Subject: Can't login Jailed system Message-ID: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> Hi, With FreeBSD 7.2Stable, I have done this many times before. After about a month left the "jail" behind, now when I done a "/etc/rc.d/jail start" and ssh into it, I ended up login to the host system. Here is the network configuraiton of the host system and the jail system: # ifconfig rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:00:21:ef:27:f7 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8802 metric 0 mtu 1500 options=8 ether 00:50:fc:65:78:c0 media: Ethernet autoselect status: no carrier fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:13:20:65:a9:be inet 192.168.1.246 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.1.245 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.1.235 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.1.242 netmask 0xffffffff broadcast 192.168.1.242 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 enc0: flags=0<> metric 0 mtu 1536 pflog0: flags=141 metric 0 mtu 33204 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 twp1:# jls JID IP Address Hostname Path 5 192.168.1.242 twp5.ip6.com.au /usr/jail2/twp5 192.168.1.242 is the jailed system, twp1 is the host system. After I login 192.168.1.242, I ended up logged in twp1 which is my host system. Now I am stuck. I don't know how I logged in the jailed system a month ago. Can anyone shred some lights on me? Thanks Sam From bzeeb-lists at lists.zabbadoz.net Mon Jun 29 11:30:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Jun 29 11:30:15 2009 Subject: Can't login Jailed system In-Reply-To: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> Message-ID: <20090629112655.R22887@maildrop.int.zabbadoz.net> On Mon, 29 Jun 2009, Sam Wun wrote: Hi, we've got a freebsd-jail list that I am Cc:ing. > With FreeBSD 7.2Stable, > I have done this many times before. > After about a month left the "jail" behind, now when I done a > "/etc/rc.d/jail start" and ssh into it, I ended up login to the host > system. > Here is the network configuraiton of the host system and the jail system: > > # ifconfig > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:00:21:ef:27:f7 > media: Ethernet autoselect (100baseTX ) > status: active > rl1: flags=8802 metric 0 mtu 1500 > options=8 > ether 00:50:fc:65:78:c0 > media: Ethernet autoselect > status: no carrier > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:13:20:65:a9:be > inet 192.168.1.246 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.245 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.235 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.242 netmask 0xffffffff broadcast 192.168.1.242 > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=108810 metric 0 mtu 1500 > enc0: flags=0<> metric 0 mtu 1536 > pflog0: flags=141 metric 0 mtu 33204 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > twp1:# jls > JID IP Address Hostname Path > 5 192.168.1.242 twp5.ip6.com.au /usr/jail2/twp5 > > 192.168.1.242 is the jailed system, > twp1 is the host system. > > After I login 192.168.1.242, I ended up logged in twp1 which is my host system. > Now I am stuck. I don't know how I logged in the jailed system a month ago. > > Can anyone shred some lights on me? Try to jexec 5 /bin/sh (5 is the jailID from the jls output) and check with ps if sshd is running inside the jail, and check the usual things are up and there. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From freebsdusb at bindone.de Mon Jun 29 11:30:12 2009 From: freebsdusb at bindone.de (Michael Gmelin) Date: Mon Jun 29 11:30:28 2009 Subject: Can't login Jailed system In-Reply-To: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> Message-ID: <4A48A5BA.3080709@bindone.de> Sam Wun wrote: > Hi, > > With FreeBSD 7.2Stable, > I have done this many times before. > After about a month left the "jail" behind, now when I done a > "/etc/rc.d/jail start" and ssh into it, I ended up login to the host > system. > Here is the network configuraiton of the host system and the jail system: > > # ifconfig > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:00:21:ef:27:f7 > media: Ethernet autoselect (100baseTX ) > status: active > rl1: flags=8802 metric 0 mtu 1500 > options=8 > ether 00:50:fc:65:78:c0 > media: Ethernet autoselect > status: no carrier > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:13:20:65:a9:be > inet 192.168.1.246 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.245 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.235 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.242 netmask 0xffffffff broadcast 192.168.1.242 > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=108810 metric 0 mtu 1500 > enc0: flags=0<> metric 0 mtu 1536 > pflog0: flags=141 metric 0 mtu 33204 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > twp1:# jls > JID IP Address Hostname Path > 5 192.168.1.242 twp5.ip6.com.au /usr/jail2/twp5 > > 192.168.1.242 is the jailed system, > twp1 is the host system. > > After I login 192.168.1.242, I ended up logged in twp1 which is my host system. > Now I am stuck. I don't know how I logged in the jailed system a month ago. > > Can anyone shred some lights on me? > > Thanks > Sam > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" What does: netstat -an | grep LISTEN Did you check /etc/ssh/sshd_config on the host system and check if ssh only listens to a specific IP address (to me it seemslike it's listening to *:22). From swun2010 at gmail.com Mon Jun 29 11:40:37 2009 From: swun2010 at gmail.com (Sam Wun) Date: Mon Jun 29 11:40:46 2009 Subject: Can't login Jailed system In-Reply-To: <4A48A5BA.3080709@bindone.de> References: <736c47cb0906290422y756a6a74i9029b4d27d2ade34@mail.gmail.com> <4A48A5BA.3080709@bindone.de> Message-ID: <736c47cb0906290440t29873631ge04aed6cdcc1136f@mail.gmail.com> On Mon, Jun 29, 2009 at 9:30 PM, Michael Gmelin wrote: > Sam Wun wrote: >> Hi, >> >> With FreeBSD 7.2Stable, >> I have done this many times before. >> After about a month left the "jail" behind, now when I done a >> "/etc/rc.d/jail start" and ssh into it, I ended up login to the host >> system. >> Here is the network configuraiton of the host system and the jail system: >> >> ?# ifconfig >> rl0: flags=8843 metric 0 mtu 1500 >> ? ? ? ? options=8 >> ? ? ? ? ether 00:00:21:ef:27:f7 >> ? ? ? ? media: Ethernet autoselect (100baseTX ) >> ? ? ? ? status: active >> rl1: flags=8802 metric 0 mtu 1500 >> ? ? ? ? options=8 >> ? ? ? ? ether 00:50:fc:65:78:c0 >> ? ? ? ? media: Ethernet autoselect >> ? ? ? ? status: no carrier >> fxp0: flags=8843 metric 0 mtu 1500 >> ? ? ? ? options=8 >> ? ? ? ? ether 00:13:20:65:a9:be >> ? ? ? ? inet 192.168.1.246 netmask 0xffffff00 broadcast 192.168.1.255 >> ? ? ? ? inet 192.168.1.245 netmask 0xffffff00 broadcast 192.168.1.255 >> ? ? ? ? inet 192.168.1.235 netmask 0xffffff00 broadcast 192.168.1.255 >> ? ? ? ? inet 192.168.1.242 netmask 0xffffffff broadcast 192.168.1.242 >> ? ? ? ? media: Ethernet autoselect (100baseTX ) >> ? ? ? ? status: active >> plip0: flags=108810 metric 0 mtu 1500 >> enc0: flags=0<> metric 0 mtu 1536 >> pflog0: flags=141 metric 0 mtu 33204 >> pfsync0: flags=0<> metric 0 mtu 1460 >> ? ? ? ? syncpeer: 224.0.0.240 maxupd: 128 >> lo0: flags=8049 metric 0 mtu 16384 >> ? ? ? ? inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 >> ? ? ? ? inet6 ::1 prefixlen 128 >> ? ? ? ? inet 127.0.0.1 netmask 0xff000000 >> twp1:# jls >> ? ?JID ?IP Address ? ? ?Hostname ? ? ? ? ? ? ? ? ? ? ?Path >> ? ? ?5 ?192.168.1.242 ? twp5.ip6.com.au ? ? ? ? ? ? ? /usr/jail2/twp5 >> >> 192.168.1.242 is the jailed system, >> twp1 is the host system. >> >> After I login 192.168.1.242, I ended up logged in twp1 which is my host system. >> Now I am stuck. I don't know how I logged in the jailed system a month ago. >> >> Can anyone shred some lights on me? >> >> Thanks >> Sam >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > What does: > > netstat -an | grep LISTEN > > Did you check /etc/ssh/sshd_config on the host system and check if ssh > only listens to a specific IP address (to me it seemslike it's listening > to *:22). > OK, I changed the host sshd_config setting, now I can ssh into the jailed system. Here is what I've done: twp1:~ # !jexec jexec 5 /bin/sh # top kvm_open: /boot/kernel/kernel: No such file or directory # cd etc # cat rc.conf network_interfaces="" rpcbind_enable="NO" sshd_enable="YES" syslogd_flags="-ss" mysql_enable="yes" mysql_limits="yes" mysql_dbdir="/usr/local/var/db/mysql" # hostname twp5 # twp5 is the jailed system. Strange, I remember last time I can still have sshd and mysql running in the jailed system. Thanks > > > From rwatson at FreeBSD.org Mon Jun 29 12:03:22 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 29 12:03:29 2009 Subject: in_pcb crash on 7.2 RELEASE 64bits In-Reply-To: <86068e730906221718o7b37660ei640fe85085624e06@mail.gmail.com> References: <86068e730906221718o7b37660ei640fe85085624e06@mail.gmail.com> Message-ID: On Mon, 22 Jun 2009, Jerry Toung wrote: > may be someone has seen this? already before I dig into the issue myself. A > consistent crash with the following trace. ? ? ? Unread portion of the > kernel message buffer: This is a NULL pointer dereference -- could you tell me what specific version of in_pcb.c ($FreeBSD$) you're running with? This seems like an unlikely panic to me, as the code in in_pcb.c is fairly careful about walking off the ends of address lists. However, we have a fairly large number of changes in 8.x (and even slightly later 7.x) to address known race conditions in address list management, so that could be related. Robert N M Watson Computer Laboratory University of Cambridge > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address?? = 0x164 > fault code????????????? = supervisor read data, page not present > instruction pointer???? = 0x8:0xffffffff806016c8 > stack pointer?????????? = 0x10:0xfffffffefc079840 > frame pointer?????????? = 0x10:0xc0000000 > code segment??????????? = base 0x0, limit 0xfffff, type 0x1b > ??????????????????????? = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags??????? = interrupt enabled, resume, IOPL = 0 > current process???????? = 1352 (gated) > trap number???????????? = 12 > panic: page fault > cpuid = 4 > Uptime: 5m37s > Dumping 4093 MB (4 chunks) > ? chunk 0: 1MB (156 pages) ... ok > ? chunk 1: 3326MB (851284 pages) 3310 3294 3278 3262 3246 3230 3214 3198 > 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 > 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 > 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 > 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 > 2222 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 > 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 > 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 > 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 > 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 > 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 > 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 > 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 > 126 110 94 78 62 46 30 14 ... ok > ? chunk 2: 1MB (1 pages) ... ok > ? chunk 3: 768MB (196607 pages) 753 737 721 705 689 673 657 641 625 609 593 > 577 561 545 529 513 497 481 465 449 433 417 401 385 369 353 337 321 305 289 > 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 > #0? doadump () at pcpu.h:195 > 195???? pcpu.h: No such file or directory. > ??????? in pcpu.h > (kgdb) bt > #0? doadump () at pcpu.h:195 > #1? 0x0000000000000004 in ?? () > #2? 0xffffffff80521d59 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #3? 0xffffffff80522162 in panic (fmt=0x104
) > ??? at /usr/src/sys/kern/kern_shutdown.c:574 > #4? 0xffffffff807e6a93 in trap_fatal (frame=0xffffff00038a06e0, eva=Variable > "eva" is not available. > ) > ??? at /usr/src/sys/amd64/amd64/trap.c:757 > #5? 0xffffffff807e6e65 in trap_pfault (frame=0xfffffffefc079790, usermode=0) > ??? at /usr/src/sys/amd64/amd64/trap.c:673 > #6? 0xffffffff807e77a4 in trap (frame=0xfffffffefc079790) > ??? at /usr/src/sys/amd64/amd64/trap.c:444 > #7? 0xffffffff807cb90e in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:209 > #8? 0xffffffff806016c8 in in_pcbconnect_setup (inp=0xffffff001439d6c0, > nam=Variable "nam" is not available. > ) > ??? at /usr/src/sys/netinet/in_pcb.c:833 > #9? 0xffffffff806795a1 in udp_send (so=Variable "so" is not available. > ) at /usr/src/sys/netinet/udp_usrreq.c:961 > #10 0xffffffff8057d1a1 in sosend_dgram (so=0xffffff00143442d0, > addr=0xffffff0003b6e530, uio=Variable "uio" is not available. > ) > ??? at /usr/src/sys/kern/uipc_socket.c:1059 > #11 0xffffffff80581d77 in kern_sendit (td=0xffffff00038a06e0, s=22, > mp=0xfffffffefc079af0, > ??? flags=4, control=0x0, segflg=Variable "segflg" is not available. > ) at /usr/src/sys/kern/uipc_syscalls.c:805 > #12 0xffffffff80584d4f in sendit (td=0xffffff00038a06e0, s=22, > mp=0xfffffffefc079af0, flags=4) > ??? at /usr/src/sys/kern/uipc_syscalls.c:742 > #13 0xffffffff80584de9 in sendmsg (td=0xffffff00038a06e0, > uap=0xfffffffefc079bf0) > ??? at /usr/src/sys/kern/uipc_syscalls.c:938 > #14 0xffffffff807e70e7 in syscall (frame=0xfffffffefc079c80) > ??? at /usr/src/sys/amd64/amd64/trap.c:900 > #15 0xffffffff807cbb1b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:330 > #16 0x0000000801c1a00c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 8 > #8? 0xffffffff806016c8 in in_pcbconnect_setup (inp=0xffffff001439d6c0, > nam=Variable "nam" is not available. > ) > ??? at /usr/src/sys/netinet/in_pcb.c:833 > 833???? /usr/src/sys/netinet/in_pcb.c: No such file or directory. > ??????? in /usr/src/sys/netinet/in_pcb.c > (kgdb) p *ia > Cannot access memory at address 0x0 > (kgdb) i loc > ia = (struct in_ifaddr *) 0x0 > oinp = Variable "oinp" is not available. > (kgdb) > ? > ? > thanks, > Jerry > > From linimon at FreeBSD.org Mon Jun 29 20:47:13 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Jun 29 20:47:21 2009 Subject: kern/136168: [em] em driver initialization fails on Intel 5000PSL motherboard Message-ID: <200906292047.n5TKlDSM097213@freefall.freebsd.org> Old Synopsis: em driver initialization fails on Intel 5000PSL motherboard New Synopsis: [em] em driver initialization fails on Intel 5000PSL motherboard Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 29 20:47:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136168 From lab at gta.com Tue Jun 30 18:27:12 2009 From: lab at gta.com (Larry Baird) Date: Tue Jun 30 18:27:19 2009 Subject: Polling and kern.polling.idle_poll Message-ID: <20090630180029.GA8847@gta.com> A while back I upgraded some old gateways from FreeBSD 4.x to FreeBSD 6.x. I thought the upgrade had went smoothly, but a while later I started having users complaining about throughput. Luckly I still had a backup of the FreebSD 4.x install. Did some throughput tests with iperf. Low and behold 4.x appeared to have twice the throughput. After lots of experimenting I determined that turning off polling fixed the issue. So I started digging through the kernel code to see what had changed in the polling logic. Finally arived at the fact that "kern.polling.idle_poll" defaults to 1 in 4.x and 0 in 6.x and above. Turning polling back on with idle-poll enabled fixed the performance issue. The man page for polling states: kern.polling.idle_poll Controls if polling is enabled in the idle loop. There are no reasons (other than power saving or bugs in the scheduler's han- dling of idle priority kernel threads) to disable this. So why is it now disabled by default? Looking back through cvs the change was made by Luigi way back in August of 2002. -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From to.my.trociny at gmail.com Tue Jun 30 19:33:20 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Jun 30 19:33:27 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem In-Reply-To: <200906101720.n5AHK3pr036971@freefall.freebsd.org> (Roar Pettersen's message of "Wed\, 10 Jun 2009 17\:20\:03 GMT") References: <200906101720.n5AHK3pr036971@freefall.freebsd.org> Message-ID: <86ocs5zfd3.fsf@kopusha.onet> Unfortunately, the problem was introduced by this commit :-) ---------- Author: mav Date: Sat Jan 31 12:48:09 2009 UTC (4 months, 4 weeks ago) Log Message: MFC rev. 187495 Check for infinite recursion possible on some broken PPTP/L2TP/... VPN setups. Mark packets with mbuf_tag on first interface passage and drop on second. PR: ports/129625, ports/125303 ---------- If a packet goes through two or more ng interfaces, "while" loop in the tag checking code can run infinitely. The attached patch should fix this. -- Mikolaj Golub -------------- next part -------------- A non-text attachment was scrubbed... Name: ng_iface.c.patch Type: text/x-diff Size: 481 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090630/fba6e1ca/ng_iface.c.bin From to.my.trociny at gmail.com Tue Jun 30 19:40:02 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Jun 30 19:40:09 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200906301940.n5UJe2l3096572@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Mikolaj Golub To: bug-followup@FreeBSD.org Cc: freebsd-net@FreeBSD.org, Sergei Cherveni , Alexander Motin Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Tue, 30 Jun 2009 22:33:12 +0300 --=-=-= Unfortunately, the problem was introduced by this commit :-) ---------- Author: mav Date: Sat Jan 31 12:48:09 2009 UTC (4 months, 4 weeks ago) Log Message: MFC rev. 187495 Check for infinite recursion possible on some broken PPTP/L2TP/... VPN setups. Mark packets with mbuf_tag on first interface passage and drop on second. PR: ports/129625, ports/125303 ---------- If a packet goes through two or more ng interfaces, "while" loop in the tag checking code can run infinitely. The attached patch should fix this. -- Mikolaj Golub --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=ng_iface.c.patch --- netgraph/ng_iface.c.orig 2009-06-30 21:47:54.000000000 +0300 +++ netgraph/ng_iface.c 2009-06-30 21:49:29.000000000 +0300 @@ -365,7 +365,8 @@ } /* Protect from deadly infinite recursion. */ - while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, NULL))) { + mtag = NULL; + while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, mtag))) { if (*(struct ifnet **)(mtag + 1) == ifp) { log(LOG_NOTICE, "Loop detected on %s\n", ifp->if_xname); m_freem(m); --=-=-=-- From to.my.trociny at gmail.com Tue Jun 30 20:00:06 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Jun 30 20:00:12 2009 Subject: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system In-Reply-To: <200906090620.n596K6Uu039348@freefall.freebsd.org> (Dennis Melentyev's message of "Tue\, 9 Jun 2009 06\:20\:06 GMT") References: <200906090620.n596K6Uu039348@freefall.freebsd.org> Message-ID: <86fxdhze4f.fsf@kopusha.onet> Could you try the patch from kern/134557? -- Mikolaj Golub From to.my.trociny at gmail.com Tue Jun 30 20:00:14 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Jun 30 20:00:21 2009 Subject: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Message-ID: <200906302000.n5UK0Ega010941@freefall.freebsd.org> The following reply was made to PR kern/133572; it has been noted by GNATS. From: Mikolaj Golub To: Dennis Melentyev Cc: bug-followup@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the system Date: Tue, 30 Jun 2009 23:00:00 +0300 Could you try the patch from kern/134557? -- Mikolaj Golub