From ganbold at micom.mng.net Mon Sep 1 04:12:15 2008 From: ganbold at micom.mng.net (Ganbold) Date: Mon Sep 1 04:12:22 2008 Subject: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c Message-ID: <48BB6B95.4010103@micom.mng.net> Hi, Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). I'm trying to make small changes in ipfw2.c code (RELENG_7), but make fails with following error: v02# make cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c /usr/src/sbin/ipfw/ipfw2.c /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared (first use in this function) /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is reported only once /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) *** Error code 1 IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included in ipfw2.c: #define IPFW_INTERNAL /* Access to protected structures in ip_fw.h. */ ... #include ... I'm trying to read IPFW_TABLES_MAX and print all tables IP in loop. Any idea how to solve this problem? Basically I'm trying to add small feature (list IPs of all tables) to /sbin/ipfw something like: ipfw table all list I know it is possible to write small shell script to display all the tables and IPs in it. However I thought it might be useful to have such small feature in /sbin/ipfw. Correct me if I'm wrong here. thanks, Ganbold -- Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P. D. Ouspensky From pekkas at netcore.fi Mon Sep 1 05:20:28 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Mon Sep 1 05:20:35 2008 Subject: kern/121298: [panic] Fatal trap 12: page fault while in kernel mode (em0 taskq) Message-ID: <200809010520.m815K4sd009466@freefall.freebsd.org> The following reply was made to PR kern/121298; it has been noted by GNATS. From: Pekka Savola To: bug-followup@freebsd.org Cc: Subject: kern/121298: [panic] Fatal trap 12: page fault while in kernel mode (em0 taskq) Date: Mon, 1 Sep 2008 08:14:42 +0300 (EEST) FYI, I got hit by this (at least it seems identical) as well pretty soon after I enabled SMP on this box. With UP kernel, I have not seen such core dumps. This is 7.1-PRERELEASE (Cvsup of RELENG_7 as of Aug 31 2008). Polling is not compiled in the kernel. The device has: options=9b It's either of these (actually I'm not sure which one. probably the former): 02:0c.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 28 Memory at dfdc0000 (64-bit, non-prefetchable) I/O ports at ec80 Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05) Subsystem: Dell Unknown device 016d Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 48 Memory at dfae0000 (32-bit, non-prefetchable) I/O ports at dcc0 Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device ============== Unread portion of the kernel message buffer: <110>ipfw: 20 Deny TCP [2001:0:d5c7:a2ca:2cfe:116b:2b6a:554d]:55056 [2001:0:4137:9e50:2894:3b42:b7b4:d119]:44889 in via stf0 TPTE at 0xbfca027c IS ZERO @ VA 2809f000 pakernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05c17de stack pointer = 0x28:0xe53cea08 frame pointer = 0x28:0xe53cea28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 21 (em2 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 3h59m45s Physical memory: 2039 MB Dumping 174 MB: 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc058cc57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc058cf19 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc073b9bc in trap_fatal (frame=0xe53ce9c8, eva=20) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc073c30f in trap (frame=0xe53ce9c8) at /usr/src/sys/i386/i386/trap.c:320 #5 0xc072204b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #6 0xc05c17de in propagate_priority (td=0xc555fd20) at /usr/src/sys/kern/subr_turnstile.c:272 #7 0xc05c2618 in turnstile_wait (ts=0xc4d0e5a0, owner=0xc555fd20, queue=Variable "queue" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:739 #8 0xc057fe1e in _mtx_lock_sleep (m=0xc080c7bc, tid=3302831200, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:420 #9 0xc0738002 in pmap_enter (pmap=0xc081ade0, va=3369541632, m=0xc1a11728, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:2345 #10 0xc06db888 in kmem_malloc (map=0xc107108c, size=4096, flags=257) at /usr/src/sys/vm/vm_kern.c:416 #11 0xc06d1ba7 in page_alloc (zone=0xc10601e0, bytes=4096, pflag=0xe53ceb5f "\002", wait=257) at /usr/src/sys/vm/uma_core.c:959 #12 0xc06d0e5c in slab_zalloc (zone=0xc10601e0, wait=257) at /usr/src/sys/vm/uma_core.c:822 #13 0xc06d1344 in uma_zone_slab (zone=0xc10601e0, flags=1) at /usr/src/sys/vm/uma_core.c:2014 #14 0xc06d440a in uma_zalloc_arg (zone=0xc10601e0, udata=0xe53cec04, flags=1) at /usr/src/sys/vm/uma_core.c:2115 #15 0xc049781c in em_get_buf (adapter=0xc4dac000, i=122) at mbuf.h:469 #16 0xc049abf9 in em_rxeof (adapter=0xc4dac000, count=99) at /usr/src/sys/dev/e1000/if_em.c:4420 #17 0xc049b717 in em_handle_rxtx (context=0xc4dac000, pending=1) at /usr/src/sys/dev/e1000/if_em.c:1676 #18 0xc05c0185 in taskqueue_run (queue=0xc4dc2a80) at /usr/src/sys/kern/subr_taskqueue.c:282 #19 0xc05c038b in taskqueue_thread_loop (arg=0xc4dac370) at /usr/src/sys/kern/subr_taskqueue.c:401 #20 0xc0569ab9 in fork_exit (callout=0xc05c02d0 , arg=0xc4dac370, frame=0xe53ced38) at /usr/src/sys/kern/kern_fork.c:804 #21 0xc07220c0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) up 17 #17 0xc049b717 in em_handle_rxtx (context=0xc4dac000, pending=1) at /usr/src/sys/dev/e1000/if_em.c:1676 1676 if (em_rxeof(adapter, adapter->rx_process_limit) != 0) (kgdb) up 16 #16 0xc049abf9 in em_rxeof (adapter=0xc4dac000, count=99) at /usr/src/sys/dev/e1000/if_em.c:4420 4420 if (em_get_buf(adapter, i) != 0) { From onemda at gmail.com Mon Sep 1 08:30:09 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Sep 1 08:30:15 2008 Subject: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics Message-ID: <200809010830.m818U8K2051996@freefall.freebsd.org> The following reply was made to PR kern/125181; it has been noted by GNATS. From: "Paul B. Mahol" To: "Andrew Thompson" Cc: "Coleman Kane" , bug-followup@freebsd.org Subject: Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics Date: Mon, 1 Sep 2008 09:57:42 +0200 On 7/17/08, Andrew Thompson wrote: > On Thu, Jul 17, 2008 at 12:09:52PM -0400, Coleman Kane wrote: >> Andrew, >> >> I got directed to this PR by onemda@gmail.com (Paul D. Mahol), who's >> been helping me track down some edge cases in the if_ndis locking >> rewrite. I am not 100% familiar with the locking semantics in play here >> (IEEE80211 and VAPs), so I wanted to run it by you before I determine >> that it seems to be working well for me. > > I dont think ndis should be reaching into the net80211 lock. Now that > ndis uses a regular mutex its a good chance to add mtx_asserts in the > right places and get the locking up to speed. I will try to post a patch > soon unless someone beats be to it. > > Andrew > I got hit by this bug again, my only option is to switch to UP kernel until patch for this bug is finally committed. Subject of bug report is no more relevant, becuase this bug has nothing directly related with WEP. From bu7cher at yandex.ru Mon Sep 1 09:29:41 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon Sep 1 09:29:48 2008 Subject: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c In-Reply-To: <48BB6B95.4010103@micom.mng.net> References: <48BB6B95.4010103@micom.mng.net> Message-ID: <48BBB1F1.2090302@yandex.ru> Ganbold wrote: > Hi, > > Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). > > I'm trying to make small changes in ipfw2.c code (RELENG_7), but make > fails with following error: > > v02# make > cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c > /usr/src/sbin/ipfw/ipfw2.c > /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': > /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared > (first use in this function) > /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is > reported only once > /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) > *** Error code 1 > > IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included > in ipfw2.c: > IPFW_TABLES_MAX protected by _KERNEL macro. This is why you get an error. -- WBR, Andrey V. Elsukov From ganbold at micom.mng.net Mon Sep 1 09:38:58 2008 From: ganbold at micom.mng.net (Ganbold) Date: Mon Sep 1 09:39:05 2008 Subject: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c In-Reply-To: <48BBB1F1.2090302@yandex.ru> References: <48BB6B95.4010103@micom.mng.net> <48BBB1F1.2090302@yandex.ru> Message-ID: <48BBB82C.3050008@micom.mng.net> Andrey V. Elsukov wrote: > Ganbold wrote: >> Hi, >> >> Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). >> >> I'm trying to make small changes in ipfw2.c code (RELENG_7), but make >> fails with following error: >> >> v02# make >> cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c >> /usr/src/sbin/ipfw/ipfw2.c >> /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': >> /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared >> (first use in this function) >> /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is >> reported only once >> /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears >> in.) >> *** Error code 1 >> >> IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included >> in ipfw2.c: >> > > IPFW_TABLES_MAX protected by _KERNEL macro. This is why you get > an error. Yeah, my fault, I was looking around IPFW_INTERNAL and missed _KERNEL macro. I defined new sysctl variable in netinet/ip_fw2.c and now I'm able to get IPFW_TABLES_MAX via sysctl from /sbin/ipfw. Is it the way I should get constant protected by _KERNEL? Also should I PR my patch? Anyway here is the diff against RELENG_7. Please let me know if I'm doing something wrong here. ------------------------------------------------------------------- --- ip_fw2.c.orig 2008-09-01 17:31:57.000000000 +0800 +++ ip_fw2.c 2008-09-01 16:54:30.000000000 +0800 @@ -255,6 +255,8 @@ static u_int32_t dyn_count; /* # of dynamic rules */ static u_int32_t dyn_max = 4096; /* max # of dynamic rules */ +static u_int32_t tables_count = IPFW_TABLES_MAX; /* # of tables */ + SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, &dyn_buckets, 0, "Number of dyn. buckets"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, @@ -265,6 +267,8 @@ &dyn_max, 0, "Max number of dyn. rules"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, static_count, CTLFLAG_RD, &static_count, 0, "Number of static rules"); +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, tables_count, CTLFLAG_RD, + &tables_count, 0, "Number of tables"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW, &dyn_ack_lifetime, 0, "Lifetime of dyn. rules for acks"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW, ------------------------------------------------------------------- --- /usr/src/sbin/ipfw/ipfw2.c 2008-07-31 09:39:59.000000000 +0800 +++ ipfw2.c 2008-09-01 16:46:08.000000000 +0800 @@ -5860,24 +5860,30 @@ * ipfw table N add addr[/masklen] [value] * ipfw table N delete addr[/masklen] * ipfw table N flush - * ipfw table N list + * ipfw table N|all list */ static void table_handler(int ac, char *av[]) { ipfw_table_entry ent; ipfw_table *tbl; - int do_add; + int do_add, is_all = 0; char *p; socklen_t l; - uint32_t a; + uint32_t a, b, c; + size_t len; ac--; av++; if (ac && isdigit(**av)) { ent.tbl = atoi(*av); ac--; av++; + } else if (_substrcmp(*av, "all") == 0) { + ent.tbl = 0; + is_all = 1; + ac--; av++; } else errx(EX_USAGE, "table number required"); + NEED1("table needs command"); if (_substrcmp(*av, "add") == 0 || _substrcmp(*av, "delete") == 0) { @@ -5931,33 +5937,55 @@ if (do_cmd(IP_FW_TABLE_FLUSH, &ent.tbl, sizeof(ent.tbl)) < 0) err(EX_OSERR, "setsockopt(IP_FW_TABLE_FLUSH)"); } else if (_substrcmp(*av, "list") == 0) { - a = ent.tbl; - l = sizeof(a); - if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) - err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); - l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); - tbl = malloc(l); - if (tbl == NULL) - err(EX_OSERR, "malloc"); - tbl->tbl = ent.tbl; - if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) - err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); - for (a = 0; a < tbl->cnt; a++) { - unsigned int tval; - tval = tbl->ent[a].value; - if (do_value_as_ip) { - char tbuf[128]; - strncpy(tbuf, inet_ntoa(*(struct in_addr *) - &tbl->ent[a].addr), 127); - /* inet_ntoa expects network order */ - tval = htonl(tval); - printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, - inet_ntoa(*(struct in_addr *)&tval)); - } else { - printf("%s/%u %u\n", - inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), - tbl->ent[a].masklen, tval); + c = ent.tbl; + + if (is_all) { + len = sizeof(uint32_t); + + /* get IPFW_TABLES_MAX */ + if (sysctlbyname("net.inet.ip.fw.tables_count", + &c, &len, NULL, 0) == -1) + errx(1, "sysctlbyname(\"%s\")", + "net.inet.ip.fw.tables_count"); + + c -= 1; + } + + for (b = ent.tbl; b <= c; b++) { + a = b; + l = sizeof(b); + + if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) + err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); + l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); + tbl = malloc(l); + if (tbl == NULL) + err(EX_OSERR, "malloc"); + tbl->tbl = b; + if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) + err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); + + if (tbl->cnt && is_all) + printf("---table(%d)---\n", b); + + for (a = 0; a < tbl->cnt; a++) { + unsigned int tval; + tval = tbl->ent[a].value; + if (do_value_as_ip) { + char tbuf[128]; + strncpy(tbuf, inet_ntoa(*(struct in_addr *) + &tbl->ent[a].addr), 127); + /* inet_ntoa expects network order */ + tval = htonl(tval); + printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, + inet_ntoa(*(struct in_addr *)&tval)); + } else { + printf("%s/%u %u\n", + inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), + tbl->ent[a].masklen, tval); + } } + free(tbl); } } else errx(EX_USAGE, "invalid table command %s", *av); thanks, Ganbold -- Life is a grand adventure -- or it is nothing. -- Helen Keller From bugmaster at FreeBSD.org Mon Sep 1 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:08:28 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200809011106.m81B6wpt068504@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126945 net [carp] CARP interface destruction with ifconfig destro 105 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection o kern/126695 net rtfree messages and network disruption upon use of if_ o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) 63 problems total. From remko at FreeBSD.org Mon Sep 1 11:42:42 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Sep 1 11:42:48 2008 Subject: kern/126984: [carp][patch] add carp userland notifications via devctl(4) Message-ID: <200809011142.m81BgfGa076227@freefall.freebsd.org> Synopsis: [carp][patch] add carp userland notifications via devctl(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Sep 1 11:42:22 UTC 2008 Responsible-Changed-Why: Carp is something networking related, bring it over. http://www.freebsd.org/cgi/query-pr.cgi?pr=126984 From rwatson at FreeBSD.org Mon Sep 1 12:04:54 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 1 12:05:00 2008 Subject: bug in unix sockets garbage collector In-Reply-To: <48AEDC40.6030901@citrin.ru> References: <48AEDC40.6030901@citrin.ru> Message-ID: On Fri, 22 Aug 2008, Anton Yuzhaninov wrote: > On servers where used unix sockets, sometimes thread taskq start to eat 100% > CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 > > Addition info about this problem - when this occurs > > sysctl net.local.inflight show negative number. > > % sysctl net.local.inflight net.local.inflight: -3 > > And this condition become always true: > > if (local_unp_rights) > taskqueue_enqueue(taskqueue_thread, &unp_gc_task); > > It seems, that unp_rights decremented more often than incremented, or some > race exist. Hi Anton: On reviewing this code, I've identified at least one race condition that could lead to the behavior that you've spotted. It will probably take me a couple of days to produce a patch for you to try. However, could I ask you to file a PR for this problem, with the above and any related diagnostics, and when you receive the e-mail PR receipt, could you forward it to me so that I can take ownership of it? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From debarshi.ray at gmail.com Mon Sep 1 12:39:11 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon Sep 1 12:39:18 2008 Subject: reading routing table Message-ID: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> I am implementing a library/utility which basically encompasses the features of the traditional route utilities and those of newer tools (like ip from iproute2), which are mostly specific to a particular kernel. The overpowering objective is to make the library/utility work uniformly across all different kernels, so that programs like NetworkManager have a portable library/utility to use instead of the Linux-kernel specific ip which is now being used. I was going through the FreeBSD and NetBSD documentation and the FreeBSD sources of netstat and route. I was suprised to see that while NetBSD's route implementation has a 'show' command, FreeBSD does not offer any such thing. Moreover it seems that one can not read the entire routing table using the PF_ROUTE sockets and RTM_GET returns information pertaining to only one destination. This suprised me because one can do such a thing with the Linux kernel's RTNETLINK. Is there a reason why this is so? Or is reading from /dev/kmem the only way to get a dump of the routing tables? Thanks, Debarshi From bms at FreeBSD.org Mon Sep 1 12:54:13 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Sep 1 12:54:19 2008 Subject: reading routing table In-Reply-To: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> Message-ID: <48BBE5F2.4000108@FreeBSD.org> Debarshi Ray wrote: > I am implementing a library/utility which basically encompasses the > features of the traditional route utilities and those of newer tools > (like ip from iproute2), which are mostly specific to a particular > kernel. The overpowering objective is to make the library/utility work > uniformly across all different kernels, so that programs like > NetworkManager have a portable library/utility to use instead of the > Linux-kernel specific ip which is now being used. > Why don't you just use XORP's FEA code? It already does all this under a BSD-type license. cheers BMS From bms at FreeBSD.org Mon Sep 1 13:01:40 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Sep 1 13:01:47 2008 Subject: reading routing table In-Reply-To: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> Message-ID: <48BBE7B2.4050409@FreeBSD.org> Debarshi Ray wrote: > ... > I was going through the FreeBSD and NetBSD documentation and the > FreeBSD sources of netstat and route. I was suprised to see that while > NetBSD's route implementation has a 'show' command, FreeBSD does not > offer any such thing. Moreover it seems that one can not read the > entire routing table using the PF_ROUTE sockets and RTM_GET returns > information pertaining to only one destination. This suprised me > because one can do such a thing with the Linux kernel's RTNETLINK. > > Is there a reason why this is so? Or is reading from /dev/kmem the > only way to get a dump of the routing tables? > You want 'netstat -rn' to dump them, this is a very common command which should be present in a number of online resources on using and administering FreeBSD so I am somewhat surprised that you didn't find it. P.S. Look in the sysctl tree if you need to snapshot the kernel IP forwarding tables. You can use kmem, but it is generally frowned upon unless you're working from core dumps -- kernels can be built without kmem support, or kmem locked down, etc. cheers BMS From debarshi.ray at gmail.com Mon Sep 1 13:19:04 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon Sep 1 13:19:13 2008 Subject: reading routing table In-Reply-To: <48BBE7B2.4050409@FreeBSD.org> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> Message-ID: <3170f42f0809010619i4d95318x7496e45a442c9654@mail.gmail.com> > You want 'netstat -rn' to dump them, this is a very common command which > should be present in a number of online resources on using and administering > FreeBSD so I am somewhat surprised that you didn't find it. I know about netstat. I did mention having gone through its implementation. :-) What I am asking about is related to the implementation of the 'netstat -rn' functionality, which on some non-FreeBSD systems is also provided by 'route [show] -n'. > P.S. Look in the sysctl tree if you need to snapshot the kernel IP > forwarding tables. You can use kmem, but it is generally frowned upon unless > you're working from core dumps -- kernels can be built without kmem support, > or kmem locked down, etc. Ok, I will have a look. Thanks. Happy hacking, Debarshi From debarshi.ray at gmail.com Mon Sep 1 13:29:49 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon Sep 1 13:29:56 2008 Subject: reading routing table In-Reply-To: <48BBE5F2.4000108@FreeBSD.org> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE5F2.4000108@FreeBSD.org> Message-ID: <3170f42f0809010623k1df25c18u7c784d4431e5a8ce@mail.gmail.com> > Why don't you just use XORP's FEA code? > It already does all this under a BSD-type license. I was not aware of it. What does it do? Is it portable across other OSes or is it *BSD specific? Thanks, Debarshi From bms at FreeBSD.org Mon Sep 1 13:34:28 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Sep 1 13:34:34 2008 Subject: reading routing table In-Reply-To: <3170f42f0809010623k1df25c18u7c784d4431e5a8ce@mail.gmail.com> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE5F2.4000108@FreeBSD.org> <3170f42f0809010623k1df25c18u7c784d4431e5a8ce@mail.gmail.com> Message-ID: <48BBEF62.3030000@FreeBSD.org> Debarshi Ray wrote: >> Why don't you just use XORP's FEA code? >> It already does all this under a BSD-type license. >> > > I was not aware of it. What does it do? Is it portable across other > OSes or is it *BSD specific? > XORP's FEA process is responsible for talking to the underlying forwarding plane. It supports *BSD, Linux, MacOS X, and Microsoft Windows. Over the last year there was a refactoring where the forwarding table management got split into plugin-like modules. It is written in C++ although it's likely this split might make integration into other projects easier. Normally that support all goes into a single process, rather than being linked into many. cheers BMS From bms at FreeBSD.org Mon Sep 1 13:37:51 2008 From: bms at FreeBSD.org (bms@FreeBSD.org) Date: Mon Sep 1 13:37:58 2008 Subject: docs/120945: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Message-ID: <200809011337.m81DbpNx086666@freefall.freebsd.org> Synopsis: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Responsible-Changed-From-To: bms->net Responsible-Changed-By: bms Responsible-Changed-When: Mon 1 Sep 2008 13:37:24 UTC Responsible-Changed-Why: Someone else best grab this until I learn how to MFC in Subversion. http://www.freebsd.org/cgi/query-pr.cgi?pr=120945 From debarshi.ray at gmail.com Mon Sep 1 15:15:25 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon Sep 1 15:15:34 2008 Subject: reading routing table In-Reply-To: <48BBE5F2.4000108@FreeBSD.org> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE5F2.4000108@FreeBSD.org> Message-ID: <3170f42f0809010815q77f50bcat39e5bcd6563ecd7@mail.gmail.com> > Why don't you just use XORP's FEA code? > It already does all this under a BSD-type license. Nice stuff. However, it looks like a full blown routing platform. In that case it would be easier to re-write those portions using the relevant set of APIs. Happy hacking, Debarshi From julian at elischer.org Tue Sep 2 07:00:53 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 2 07:00:59 2008 Subject: reading routing table In-Reply-To: <48BBE7B2.4050409@FreeBSD.org> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> Message-ID: <48BCE4AA.6050807@elischer.org> Bruce M. Simpson wrote: > Debarshi Ray wrote: >> ... >> I was going through the FreeBSD and NetBSD documentation and the >> FreeBSD sources of netstat and route. I was suprised to see that while >> NetBSD's route implementation has a 'show' command, FreeBSD does not >> offer any such thing. Moreover it seems that one can not read the >> entire routing table using the PF_ROUTE sockets and RTM_GET returns >> information pertaining to only one destination. This suprised me >> because one can do such a thing with the Linux kernel's RTNETLINK. >> >> Is there a reason why this is so? Or is reading from /dev/kmem the >> only way to get a dump of the routing tables? >> > > You want 'netstat -rn' to dump them, this is a very common command which > should be present in a number of online resources on using and > administering FreeBSD so I am somewhat surprised that you didn't find it. > > P.S. Look in the sysctl tree if you need to snapshot the kernel IP > forwarding tables. You can use kmem, but it is generally frowned upon > unless you're working from core dumps -- kernels can be built without > kmem support, or kmem locked down, etc. unfortunatly netstat -rn uses /dev/kmem we've just never got around to implementing a better interface.. > > cheers > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From debarshi.ray at gmail.com Tue Sep 2 07:17:53 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue Sep 2 07:18:01 2008 Subject: reading routing table In-Reply-To: <48BCE4AA.6050807@elischer.org> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> Message-ID: <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> > unfortunatly netstat -rn uses /dev/kmem Yes. I also found that FreeBSD's route(8) implementation does not have an equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such an option. Any reason for this? Is it because you did not want to muck with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I have not yet gone through NetBSD's route(8) code though. Happy hacking, Debarshi From rwatson at FreeBSD.org Tue Sep 2 09:19:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 2 09:20:11 2008 Subject: reading routing table In-Reply-To: <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Message-ID: On Tue, 2 Sep 2008, Debarshi Ray wrote: >> unfortunatly netstat -rn uses /dev/kmem > > Yes. I also found that FreeBSD's route(8) implementation does not have an > equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such > an option. Any reason for this? Is it because you did not want to muck with > /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I have not > yet gone through NetBSD's route(8) code though. Usually the "reason" for things like this is that no one has written the code to do otherwise :-). PF_ROUTE is probably not a good mechanism for any bulk data transfer due to the constraints of being a datagram socket, although doing it via an interated dump rather than a simple dump operation would probably work. Sysctl is generally a better interface for monitoring for various reasona, although it also has limitations. Maintaining historic kmem support is important, since it is also the code used for interpreting core dumps, and we don't want to lose support for that. Robert N M Watson Computer Laboratory University of Cambridge From rizzo at iet.unipi.it Tue Sep 2 10:48:34 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Sep 2 10:48:47 2008 Subject: how to read dynamic data structures from the kernel (was Re: reading routing table) In-Reply-To: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Message-ID: <20080902105124.GA22832@onelab2.iet.unipi.it> in the (short so far) thread which i am hijacking, the issue came out of what is a good mechanism for reading the route table from the kernel, since FreeBSD currently uses /dev/kmem and this is not always available/easy to use with dynamically changing data structures. The routing table is only one instance of potentially many similar data structures that we might want to fetch - others are the various firewall tables (the output of 'ipfw show'), possibly bridging tables, socket lists and so on. The issue is actually twofold. The interface problem, or how to pull bits from the kernel, is so easy to be almost irrelevant -- getsockopt, sysctl, kmem, or some special file descriptor does the job as long as the underlying chunk of data does not change (or can be locked) during the syscall. The real problem is that these data structures are dynamic and potentially large, so the following approach (used e.g. in ipfw) enter kernel; get shared lock on the structure; navigate through the structure and make a linearized copy; unlock; copyout the linearized copy; is extremely expensive and has the potential to block other activities for a long time. Accessing /dev/kmem and follow pointers there has probably the risk that you cannot lock the kernel data structure while you navigate on it, so you are likely to follow stale pointers. What we'd need is some internal representation of the data structure that could give us individual entries of the data structure on each call, together with extra info (a pointer if we can guarantee that it doesn't get stale, something more if we cannot make the guarantee) to allow the navigation to occur. I believe this is a very old and common problem, so my question is: do you know if any of the *BSD kernels implements some good mechanism to access a dynamic kernel data structure (e.g. the routing tree/trie, or even a list or hash table) without the flaws of the two approaches i indicate above ? cheers luigi [original thread below just for reference, but i believe i made a fair summary above] On Tue, Sep 02, 2008 at 10:19:55AM +0100, Robert Watson wrote: > On Tue, 2 Sep 2008, Debarshi Ray wrote: > > >>unfortunatly netstat -rn uses /dev/kmem > > > >Yes. I also found that FreeBSD's route(8) implementation does not have an > >equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such > >an option. Any reason for this? Is it because you did not want to muck > >with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I > >have not yet gone through NetBSD's route(8) code though. > > Usually the "reason" for things like this is that no one has written the > code to do otherwise :-). PF_ROUTE is probably not a good mechanism for > any bulk data transfer due to the constraints of being a datagram socket, > although doing it via an interated dump rather than a simple dump operation > would probably work. Sysctl is generally a better interface for monitoring > for various reasona, although it also has limitations. Maintaining > historic kmem support is important, since it is also the code used for > interpreting core dumps, and we don't want to lose support for that. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 FreeBSD.org Tue Sep 2 14:55:56 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Sep 2 14:56:03 2008 Subject: how to read dynamic data structures from the kernel (was Re: reading routing table) In-Reply-To: <20080902105124.GA22832@onelab2.iet.unipi.it> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> Message-ID: <48BD53F9.50002@FreeBSD.org> Luigi Rizzo wrote: > do you know if any of the *BSD kernels implements some good mechanism > to access a dynamic kernel data structure (e.g. the routing tree/trie, > or even a list or hash table) without the flaws of the two approaches > i indicate above ? > Hahaha. I ran into an isomorphic problem with Net-SNMP at work last week. There's a need to export the BGP routing table via SNMP. Of course doing this in our framework at work requires some IPC calls which always require a select() (or WaitForMultipleObjects()) based continuation. Net-SNMP doesn't support continuations at the table iterator level, so somehow, we need to implement an iterator which can accomodate our blocking IPC mechanism. [No, we don't use threads, and that would actually create more problems than it solves -- running single-threaded with continuations lets us run lock free, and we rely on the OS's IPC primitives to serialize our code. works just fine for us so far...] So we would end up caching the whole primary key range in the SNMP sub-agent on a table OID access, a technique which would allow us to defer the IPC calls providing we walk the entire range of the iterator and cache the keys -- but even THAT is far too much data for the BGP table, which is a trie with ~250,000 entries. I hate SNMP GETNEXT. Back to the FreeBSD kernel, though. If you look at in_mcast.c, particularly in p4 bms_netdev, this is what happens for the per-socket multicast source filters -- there is the linearization of an RB-tree for setsourcefilter(). This is fine for something with a limit of ~256 entries per socket (why RB for something so small? this is for space vs time -- and also it has to merge into a larger filter list in the IGMPv3 paths.) And the lock granularity is per-socket. However it doesn't do for something as big as a BGP routing table. C++ lends itself well to expressing these kinds of smart-pointer idioms, though. I'm thinking perhaps we need the notion of a sysctl iterator, which allocates a token for walking a shared data structure, and is able to guarantee that the token maps to a valid pointer for the same entry, until its 'advance pointer' operation is called. Question is, who's going to pull the trigger? cheers BMS P.S. I'm REALLY getting fed up with the lack of openness and transparency largely incumbent in doing work in p4. Come one come all -- we shouldn't need accounts for folk to see and contribute what's going on, and the stagnation is getting silly. FreeBSD development should not be a committer or chum-of-committer in-crowd. From jgreco at ns.sol.net Tue Sep 2 16:40:19 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue Sep 2 16:40:27 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 Message-ID: <200809021542.m82Fg9GK087484@aurora.sol.net> Joining this conversation as someone who's been wrestling with this issue for some months: > > This bug was reported around the release of FreeBSD 7, but does not seem > > to have made any progress. > > > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > > > Is this because the sockopt.c.diff patch is correct, which isn't entirely > > clear from the following comments, or is there some other solution to this > > problem? Thanks! > > You should contact with ports/net/quagga maintainer to push > temporary patch into Ports Tree until quagga developers settle with > something working. This always was most productive way for us. I've been doing extremely limited testing on the sockopt.c patch, on a 7.0R box that used to have problems, and it "seems to" work. However, the failures we were noticing seemed most frequent and catastrophic when using a 7.0R box as a router with about a dozen interfaces active (we got instant failures, in many/most/all?? cases). I don't have a lab setup capable of reproducing this at the moment, and am not willing to sacrifice production networks to the "well just try it and see" patch testing god. I believe the question that was asked is not the question you answered. I, too, would like someone who can offer a knowledgeable opinion as to the correctness of the patch. Were someone who has worked on the code, such as Bruce, to tell me that it appeared to be the right solution, I would be willing to risk a test on a 7.0R box known to fall over rapidly with the multicast issue. I am certainly interested in seeing this fixed. Until someone can either test the heck out of this, or offer a definitive opinion of the correctness based on experience with this subsystem, it would seem premature to ask the port maintainer to include a patch of dubious correctness. I have cc:'d bms@ in the hopes of bringing in such an opinion. I am not sure who else is working on the multicast subsystem at this time, but hopefully someone else can input if appropriate. Knowing that the patch was correct would also provide some leverage for those of us with interest in this code to persuade the Quagga developers to do something about this. As it is, we're left here holding a bag of "this patch is supposed to work but we don't really know it is correct." So it would be really useful to have such an opinion. Thanks, ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bms at FreeBSD.org Tue Sep 2 17:03:28 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Sep 2 17:03:35 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 In-Reply-To: <200809021542.m82Fg9GK087484@aurora.sol.net> References: <200809021542.m82Fg9GK087484@aurora.sol.net> Message-ID: <48BD71DD.10707@FreeBSD.org> Joe Greco wrote: > ... > Knowing that the patch was correct would also provide some leverage for > those of us with interest in this code to persuade the Quagga developers > to do something about this. As it is, we're left here holding a bag of > "this patch is supposed to work but we don't really know it is correct." > So it would be really useful to have such an opinion. > I understand that this situation has dragged on for some 18 months since changes went into 7.x. I'm sorry to hear about the problems you're having. I can't speak for Quagga as I haven't worked on it in many years, nor can I speak for the Quagga patch. On the other hand: there's a published RFC for the SSM multicast API, there has been Linux support for this API for quite some time, and at least one major commercial deployment of it (Microsoft Windows). What's the real problem here? cheers BMS From rwatson at FreeBSD.org Tue Sep 2 21:02:12 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 2 21:02:18 2008 Subject: how to read dynamic data structures from the kernel (was Re: reading routing table) In-Reply-To: <20080902105124.GA22832@onelab2.iet.unipi.it> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> Message-ID: On Tue, 2 Sep 2008, Luigi Rizzo wrote: > The real problem is that these data structures are dynamic and potentially > large, so the following approach (used e.g. in ipfw) > > enter kernel; > get shared lock on the structure; > navigate through the structure and make a linearized copy; > unlock; > copyout the linearized copy; > > is extremely expensive and has the potential to block other activities for a > long time. Sockets, sysctl, kmem, etc, are all really just I/O mechanisms, with varying levels of abstraction, for pushing data, and all fundamentally suffer from the problem of a lack of general export abstraction. > What we'd need is some internal representation of the data structure that > could give us individual entries of the data structure on each call, > together with extra info (a pointer if we can guarantee that it doesn't get > stale, something more if we cannot make the guarantee) to allow the > navigation to occur. I think there's necessarily implementation-specific details to all of these steps for any given kernel subsystem -- we have data structures, synchronization models, etc, that are all tuned to their common use requirements, and monitoring is very much an edge case. I don't think this is bad: this is an OS kernel, after all, but it does make things a bit more tricky. Even if we can't share code, sharing approaches across subsystems is a good idea. For an example of what you have in mind, take a look at the sysctl monitoring for UNIX domain sockets. First, we allocate an array of pointers sized to the number of unpcb's we have. Then we walk the list, bumping the references and adding pointers to the array. Then we release the global locks, and proceed lock, externalize, unlock, and copyout each individual entry, using a generation number fo manage staleness. Finally, we walk the list dropping the refcounts and free the array. This voids holding global locks for a long time, as well as the stale data issue. It's unideal in other ways -- long lists, reference count complexity, etc, but as I mentioned, it is very much an edge case, and much of that mechanism (especially refcounts) is something we need anyway for any moderately complex kernel data structure. Robert N M Watson Computer Laboratory University of Cambridge > Accessing /dev/kmem and follow pointers there has probably the risk > that you cannot lock the kernel data structure while you navigate > on it, so you are likely to follow stale pointers. > > I believe this is a very old and common problem, so my question is: > > do you know if any of the *BSD kernels implements some good mechanism > to access a dynamic kernel data structure (e.g. the routing tree/trie, > or even a list or hash table) without the flaws of the two approaches > i indicate above ? > > cheers > luigi > > [original thread below just for reference, but i believe i made a > fair summary above] > > On Tue, Sep 02, 2008 at 10:19:55AM +0100, Robert Watson wrote: >> On Tue, 2 Sep 2008, Debarshi Ray wrote: >> >>>> unfortunatly netstat -rn uses /dev/kmem >>> >>> Yes. I also found that FreeBSD's route(8) implementation does not have an >>> equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such >>> an option. Any reason for this? Is it because you did not want to muck >>> with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I >>> have not yet gone through NetBSD's route(8) code though. >> >> Usually the "reason" for things like this is that no one has written the >> code to do otherwise :-). PF_ROUTE is probably not a good mechanism for >> any bulk data transfer due to the constraints of being a datagram socket, >> although doing it via an interated dump rather than a simple dump operation >> would probably work. Sysctl is generally a better interface for monitoring >> for various reasona, although it also has limitations. Maintaining >> historic kmem support is important, since it is also the code used for >> interpreting core dumps, and we don't want to lose support for that. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From rizzo at iet.unipi.it Tue Sep 2 21:28:27 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Sep 2 21:28:35 2008 Subject: how to read dynamic data structures from the kernel (was Re: reading routing table) In-Reply-To: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> Message-ID: <20080902213118.GB28398@onelab2.iet.unipi.it> On Tue, Sep 02, 2008 at 10:02:10PM +0100, Robert Watson wrote: > > On Tue, 2 Sep 2008, Luigi Rizzo wrote: > > >The real problem is that these data structures are dynamic and potentially > >large, so the following approach (used e.g. in ipfw) > > > > enter kernel; > > get shared lock on the structure; > > navigate through the structure and make a linearized copy; > > unlock; > > copyout the linearized copy; > > > >is extremely expensive and has the potential to block other activities for > >a long time. > > Sockets, sysctl, kmem, etc, are all really just I/O mechanisms, with > varying levels of abstraction, for pushing data, and all fundamentally > suffer from the problem of a lack of general export abstraction. yes, this is why i said we should not bother about which one is used. > >What we'd need is some internal representation of the data structure that > >could give us individual entries of the data structure on each call, > >together with extra info (a pointer if we can guarantee that it doesn't > >get stale, something more if we cannot make the guarantee) to allow the > >navigation to occur. > > I think there's necessarily implementation-specific details to all of these > steps for any given kernel subsystem -- we have data structures, > synchronization models, etc, that are all tuned to their common use > requirements, and monitoring is very much an edge case. I don't think this > is bad: this is an OS kernel, after all, but it does make things a bit more > tricky. Even if we can't share code, sharing approaches across subsystems > is a good idea. > > For an example of what you have in mind, take a look at the sysctl > monitoring for UNIX domain sockets. First, we allocate an array of > pointers sized to the number of unpcb's we have. Then we walk the list, > bumping the references and adding pointers to the array. Then we release > the global locks, and proceed lock, externalize, unlock, and copyout each > individual entry, using a generation number fo manage staleness. Finally, > we walk the list dropping the refcounts and free the array. This voids > holding global locks for a long time, as well as the stale data issue. > It's unideal in other ways -- long lists, reference count complexity, etc, > but as I mentioned, it is very much an edge case, and much of that > mechanism (especially refcounts) is something we need anyway for any > moderately complex kernel data structure. what you describe above is more efficient but not that different from what i described. The thing is, i always forget that in many cases an iterator doesn't care for the order in which elements are generated so you could use a solution like the one below, by just doing a tiny little bit of work while modifying the main data structure (this might well be a known solution, since it is so trivial...) [i already emailed the following to BMS, so apologies for the duplicate] if all you care is iterating the whole data structure, without a particular order, you could manage an additional array of pointers to all the objects in the data structure (the array should be implemented as a sparse, resizable array but that's a separate issue, and probably a relatively trivial one -- i am googling for it...). Navigation and iterators are simple: + When inserting a new element, append an entry to the array, and make it point to the newly added record. Each entry gets a fresh sequence numbers, and one should make sure that seqnumbers are not recycled (64 bit should suffice ?). + when deleting an element, logically remove the entry from the array + the iterator returns a copy of the object, and its sequence number; + getnext returns the existing element following the 'current' one in the sparse array. Complexity for most ops (data insertion, removal, lookup) would be O(1) plus whatever is needed to do housekeeping on the sparse array, and this depends on the usage of the main data structure and how much we worry for expensive 'getnext' ops. Sure you need a read lock on the main struct while you lookup the next element on the sparse array, but the nice thing is that you can release the lock at each step even if you have a poorly implemented sparse array. Makes sense ? cheers luigi From stellan.alm at home.se Tue Sep 2 22:08:14 2008 From: stellan.alm at home.se (stellan alm) Date: Tue Sep 2 22:08:21 2008 Subject: avahi-daemon, Segmentation fault: 11 (core dumped) Message-ID: <1220392380.3934.10.camel@localhost> Hi, Running: FreeBSD black 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Wed Jun 18 07:33:20 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 All the latest ports gnome2 and xfce4, output from gdb analysing the core says: ----------------------8<------------------------- $ gdb -c avahi-daemon.core /usr/local/sbin/avahi-daemon GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `avahi-daemon'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libavahi-common.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-common.so.3 Reading symbols from /usr/local/lib/libavahi-core.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-core.so.5 Reading symbols from /usr/local/lib/libdaemon.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdaemon.so.0 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /lib/libssp.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libssp.so.0 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x280a73f9 in _thr_cancel_enter () from /usr/local/lib/libavahi-common.so.3 [New LWP 100162] (gdb) ----------------------8<------------------------- net/avahi is compiled with: $ less /var/db/ports/avahi/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for avahi-0.6.23 _OPTIONS_READ=avahi-0.6.23 WITH_AUTOIPD=true WITH_GTK=true WITH_LIBDNS=true WITHOUT_MONO=true WITHOUT_QT3=true WITHOUT_QT4=true WITH_PYTHON=true Searching the net doesn't come up with anything... Removed all ports! Reinstalled but without luck. Kind regards, Stellan Alm From julian at elischer.org Tue Sep 2 22:10:19 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 2 22:10:25 2008 Subject: how to read dynamic data structures from the kernel (was Re: reading routing table) In-Reply-To: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> Message-ID: <48BDB9D0.9030108@elischer.org> Robert Watson wrote: > > On Tue, 2 Sep 2008, Luigi Rizzo wrote: > >> The real problem is that these data structures are dynamic and >> potentially large, so the following approach (used e.g. in ipfw) >> >> enter kernel; >> get shared lock on the structure; >> navigate through the structure and make a linearized copy; >> unlock; >> copyout the linearized copy; >> >> is extremely expensive and has the potential to block other activities >> for a long time. > > Sockets, sysctl, kmem, etc, are all really just I/O mechanisms, with > varying levels of abstraction, for pushing data, and all fundamentally > suffer from the problem of a lack of general export abstraction. > >> What we'd need is some internal representation of the data structure >> that could give us individual entries of the data structure on each >> call, together with extra info (a pointer if we can guarantee that it >> doesn't get stale, something more if we cannot make the guarantee) to >> allow the navigation to occur. > In some code I have seen (and some I have written) there is always two levels of storage in some modules.. One that contains the majority of the information and one that contains "changes that occured since the main container was locked".. so for example the routing tables might be locked and if a routing change is requested thereafter, it gets stored in a transactional form on the side structure.. a routing lookup during the period that the structure is locked (if a read lock) simply goes ahead, and at completion checks if there is a better answer in the waiting list. A write request is stored as a transaction request on the waiting list. not saying it works for everything but If we had a kernel written in a high enough level language, such methods could be broadly used.. oh well. using reader-writer locking mitigates a lot of this.. > I think there's necessarily implementation-specific details to all of > these steps for any given kernel subsystem -- we have data structures, > synchronization models, etc, that are all tuned to their common use > requirements, and monitoring is very much an edge case. I don't think > this is bad: this is an OS kernel, after all, but it does make things a > bit more tricky. Even if we can't share code, sharing approaches across > subsystems is a good idea. > > For an example of what you have in mind, take a look at the sysctl > monitoring for UNIX domain sockets. First, we allocate an array of > pointers sized to the number of unpcb's we have. Then we walk the list, > bumping the references and adding pointers to the array. Then we > release the global locks, and proceed lock, externalize, unlock, and > copyout each individual entry, using a generation number fo manage > staleness. Finally, we walk the list dropping the refcounts and free > the array. This voids holding global locks for a long time, as well as > the stale data issue. It's unideal in other ways -- long lists, > reference count complexity, etc, but as I mentioned, it is very much an > edge case, and much of that mechanism (especially refcounts) is > something we need anyway for any moderately complex kernel data structure. refcounts are, unfortunatly a really bad thing for multiprocessors. refcounts, if they are actually incremented now and then are usually out of scope for any given CPU forcing lots of cache flushes and real reads from memory. There are some elaborate MP-refcount schemes we really should look at but most require a lot of memory. > From linimon at FreeBSD.org Tue Sep 2 22:37:44 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 2 22:37:50 2008 Subject: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Message-ID: <200809022237.m82MbhIx099219@freefall.freebsd.org> Old Synopsis: ipv6 does not work on carp interfaces New Synopsis: [carp] ipv6 does not work on carp interfaces [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 2 22:37:07 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127050 From linimon at FreeBSD.org Tue Sep 2 22:46:38 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 2 22:46:50 2008 Subject: kern/127052: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE Message-ID: <200809022246.m82MkcdC099636@freefall.freebsd.org> Old Synopsis: Still bridge issues - with L2 protocols such as PPPoE New Synopsis: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 2 22:46:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127052 From linimon at FreeBSD.org Wed Sep 3 03:19:32 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 3 03:19:38 2008 Subject: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address Message-ID: <200809030319.m833JWQx072059@freefall.freebsd.org> Old Synopsis: Unable to send UDP packet via IPv6 socket to IPv4 mapped address New Synopsis: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 3 03:18:48 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127057 From rea-fbsd at codelabs.ru Wed Sep 3 04:30:04 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Sep 3 04:30:11 2008 Subject: kern/127052: Still bridge issues - with L2 protocols such as PPPoE Message-ID: <200809030430.m834U4DM077859@freefall.freebsd.org> The following reply was made to PR kern/127052; it has been noted by GNATS. From: Eygene Ryabinkin To: Helge Oldach Cc: bug-followup@FreeBSD.org, philip@FreeBSD.org Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE Date: Wed, 3 Sep 2008 08:21:43 +0400 --UNifc18z8z6e1QHx Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Sep 02, 2008 at 11:06:47PM +0200, Helge Oldach wrote: > Eygene supplied a patch that supposedly fixes this issue by introducing > a sysctl that makes the former if_bridge behaviour default, and which > must be turned on to enable MAC inheritance. I have not tested this > patch yet. And here is the patch itself: --- if_bridge-mac_inheritance.patch begins here --- =46rom 545d95995bb1879a6807be28a43d4ee061dda218 Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Tue, 2 Sep 2008 19:49:44 +0400 Subject: [PATCH] Add sysctl net.link.bridge.inherit_mac to control MAC inhe= ritance Philip Paeps enabled bridge to inherit its MAC from the first bridge member. This broke ARP, it was fixed, but then Helge Oldach reported that this also brokes PPPoE when it is done on the bridged interface. I had implemented new sysctl that controls MAC inheritance. It is off by default to enable previous behaviour of bridge until all problems with duplicated MAC addresses will be chased and fixed. Signed-off-by: Eygene Ryabinkin --- sys/net/if_bridge.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c index a84a0ff..aee7c4a 100644 --- a/sys/net/if_bridge.c +++ b/sys/net/if_bridge.c @@ -350,6 +350,7 @@ static int pfil_ipfw_arp =3D 0; /* layer2 filter with= ipfw */ static int pfil_local_phys =3D 0; /* run pfil hooks on the physical interf= ace for locally destined packets */ static int log_stp =3D 0; /* log STP state changes */ +static int bridge_inherit_mac =3D 0; /* share MAC with first bridge memb= er */ SYSCTL_INT(_net_link_bridge, OID_AUTO, pfil_onlyip, CTLFLAG_RW, &pfil_onlyip, 0, "Only pass IP packets when pfil is enabled"); SYSCTL_INT(_net_link_bridge, OID_AUTO, ipfw_arp, CTLFLAG_RW, @@ -363,6 +364,9 @@ SYSCTL_INT(_net_link_bridge, OID_AUTO, pfil_local_phys,= CTLFLAG_RW, "Packet filter on the physical interface for locally destined packets"= ); SYSCTL_INT(_net_link_bridge, OID_AUTO, log_stp, CTLFLAG_RW, &log_stp, 0, "Log STP state changes"); +SYSCTL_INT(_net_link_bridge, OID_AUTO, inherit_mac, CTLFLAG_RW, + &bridge_inherit_mac, 0, + "Inherit MAC address from the first bridge member"); =20 struct bridge_control { int (*bc_func)(struct bridge_softc *, void *); @@ -921,7 +925,8 @@ bridge_delete_member(struct bridge_softc *sc, struct br= idge_iflist *bif, * the mac address of the bridge to the address of the next member, or * to its default address if no members are left. */ - if (!memcmp(IF_LLADDR(sc->sc_ifp), IF_LLADDR(ifs), ETHER_ADDR_LEN)) { + if (bridge_inherit_mac && + !memcmp(IF_LLADDR(sc->sc_ifp), IF_LLADDR(ifs), ETHER_ADDR_LEN)) { if (LIST_EMPTY(&sc->sc_iflist)) bcopy(sc->sc_defaddr, IF_LLADDR(sc->sc_ifp), ETHER_ADDR_LEN); @@ -1028,7 +1033,7 @@ bridge_ioctl_add(struct bridge_softc *sc, void *arg) * member and the MAC address of the bridge has not been changed from * the default randomly generated one. */ - if (LIST_EMPTY(&sc->sc_iflist) && + if (bridge_inherit_mac && LIST_EMPTY(&sc->sc_iflist) && !memcmp(IF_LLADDR(sc->sc_ifp), sc->sc_defaddr, ETHER_ADDR_LEN)) bcopy(IF_LLADDR(ifs), IF_LLADDR(sc->sc_ifp), ETHER_ADDR_LEN); =20 --=20 1.5.6.4 --- if_bridge-mac_inheritance.patch ends here --- > I wonder what the purpose of MAC inheritance is anyway... Multiple > unicast MACs in one segment sounds pretty odd. As was explained to me by Philip Paeps, ----- On 2008-08-15 18:24:29 (+0400), Eygene Ryabinkin wro= te: > I wonder what was the real need of the commit r180140, where you added > preemption of first bridge member MAC address by the bridge itself? There were two reasons: firstly, it makes the bridge more predictable across reboots, particularly in setups using DHCP. Secondly, this is the way the IEEE spec seems to suggest it should work. It is also the way other bridgi= ng implementations I've encountered work -- which suggests my reading of the s= pec is correct. ----- --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --UNifc18z8z6e1QHx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAki+ENcACgkQthUKNsbL7Yi/wgCgpyeZJSj2E5Bx7R8SdLN/gjRl DfMAnR76+UX8D/LtyeN8Upz2FNnufDZ9 =J9Nn -----END PGP SIGNATURE----- --UNifc18z8z6e1QHx-- From dfilter at FreeBSD.ORG Wed Sep 3 08:00:05 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Sep 3 08:00:11 2008 Subject: kern/126561: commit references a PR Message-ID: <200809030800.m838049V058143@freefall.freebsd.org> The following reply was made to PR kern/126561; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126561: commit references a PR Date: Wed, 3 Sep 2008 07:50:20 +0000 (UTC) dfr 2008-09-03 07:49:49 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/nlm nlm_prot_server.c Log: SVN rev 182712 on 2008-09-03 07:49:49Z by dfr MFC: r182153 - fix interoperability issues with Mac OS X. PR: 126561 Submitted by: Richard.Conto sy gmail.com Approved by: re (kensmith) Revision Changes Path 1.2.2.3 +1 -0 src/sys/nlm/nlm_prot_server.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From bms at FreeBSD.org Wed Sep 3 12:36:03 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 3 12:36:09 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 In-Reply-To: <48BD71DD.10707@FreeBSD.org> References: <200809021542.m82Fg9GK087484@aurora.sol.net> <48BD71DD.10707@FreeBSD.org> Message-ID: <48BE84B0.3080603@FreeBSD.org> Bruce M. Simpson wrote: > > I understand that this situation has dragged on for some 18 months > since changes went into 7.x. I'm sorry to hear about the problems > you're having. I can't speak for Quagga as I haven't worked on it in > many years, nor can I speak for the Quagga patch. > I looked at the sockopt.c.diff patch briefly last night on my free time. It is a quick and dirty bandaid by the looks of it which just munges the socket options. It may "work for you", I haven't tested it as I don't run Quagga. BTW: The RFC 1724 hack was never actually documented, so code which relies on it is buggy and needs to be fixed. I published a patch for routed here nearly 18 months ago, which is probably where Quagga picked up the hack from. From mike at sentex.net Wed Sep 3 13:28:53 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Sep 3 13:29:00 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <7.1.0.9.0.20080822120541.1122fba0@sentex.net> References: <7.1.0.9.0.20080822120541.1122fba0@sentex.net> Message-ID: <200809031328.m83DSkfE058566@lava.sentex.ca> At 01:19 PM 8/22/2008, Mike Tancsa wrote: >On one of our sendmail boxes that we are running RELENG_7, we have >noticed an odd issue triggered or noticed by our monitoring system >(bigbrother in this case). The seems to have been happening ever >since we installed it, so its not a recent commit issue. Just following up, I am still seeing this issue on a recent stable from sept 2. (a sendmail box periodically sending an RST after successful 3way handshake) Monitoring host - 199.212.134.2, smtp host 199.212.134.9 From the sendmail host I see 08:19:32.780772 IP 199.212.134.2.64679 > 199.212.134.9.25: S 3568082086:3568082086(0) win 65535 08:19:32.780793 IP 199.212.134.9.25 > 199.212.134.2.64679: S 901330786:901330786(0) ack 3568082087 win 65535 08:19:32.781325 IP 199.212.134.2.64679 > 199.212.134.9.25: . ack 1 win 8326 08:19:32.781332 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 08:19:32.781334 IP 199.212.134.2.64679 > 199.212.134.9.25: P 1:7(6) ack 1 win 8326 08:19:32.781341 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 From the monitoring host 08:19:32.777919 IP 199.212.134.2.64679 > 199.212.134.9.25: S 3568082086:3568082086(0) win 65535 08:19:32.778448 IP 199.212.134.9.25 > 199.212.134.2.64679: S 901330786:901330786(0) ack 3568082087 win 65535 08:19:32.778470 IP 199.212.134.2.64679 > 199.212.134.9.25: . ack 1 win 8326 08:19:32.778479 IP 199.212.134.2.64679 > 199.212.134.9.25: P 1:7(6) ack 1 win 8326 08:19:32.778942 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 08:19:32.778951 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 There is no record of the connection in sendmail itself either and I have the LogLevel set to 11. On a normal connection from the monitoring host, I would see something like Sep 3 08:59:32 smtp2 sm-mta[14042]: NOQUEUE: connect from ns2.sentex.ca [199.212.134.2] Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: Milter (milter-ahead): init success to negotiate Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: Milter (clamav): init success to negotiate Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: Milter: connect to filters Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: ns2.sentex.ca [199.212.134.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA I tried running without pf (or any firewall) as well as disabling syncache but the problem would still happen (again, once or twice a day, sometimes once every 2 days). Does anyone have any other suggestions as to how to track down this issue ? I am a bit reluctant to move my other sendmail severs to RELENG_7 if the monitoring system is going to be tripping false positives like this. I am just running tcpdump on the main interface now to get a sense of how many times this is happening with connections in general and comparing it to the RELENG_6 boxes. ---Mike From rpaulo at FreeBSD.org Wed Sep 3 16:53:32 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Wed Sep 3 16:53:39 2008 Subject: cvs commit: src/sys/contrib/dev/ath COPYRIGHT README ah.h ah_desc.h ah_devid.h ah_soc.h version.h src/sys/contrib/dev/ath/public alpha-elf.hal.o.uu alpha-elf.inc alpha-elf.opt_ah.h ap30.hal.o.uu ap30.inc ap43.hal.o.uu ap43.inc ... In-Reply-To: <1220382480.2493.5.camel@localhost> References: <200808280023.m7S0NN0B078088@repoman.freebsd.org> <1220382480.2493.5.camel@localhost> Message-ID: <20080903165230.GA31289@alpha.local> On Tue, Sep 02, 2008 at 11:08:00PM +0400, Vladimir Grebenschikov wrote: > ? Thu, 28/08/2008 ? 00:22 +0000, Rui Paulo ?????: > > rpaulo 2008-08-28 00:22:59 UTC > > > After that commit my wireless stop work: Can you tell us your ath mac+phy rev? -- Rui Paulo From mike at sentex.net Wed Sep 3 18:01:36 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Sep 3 18:01:43 2008 Subject: strange TCP issue on RELENG_7 (probably solved) In-Reply-To: <200809031328.m83DSkfE058566@lava.sentex.ca> References: <7.1.0.9.0.20080822120541.1122fba0@sentex.net> <200809031328.m83DSkfE058566@lava.sentex.ca> Message-ID: <200809031801.m83I1Xwb059692@lava.sentex.ca> At 09:28 AM 9/3/2008, Mike Tancsa wrote: >At 01:19 PM 8/22/2008, Mike Tancsa wrote: >>On one of our sendmail boxes that we are running RELENG_7, we have >>noticed an odd issue triggered or noticed by our monitoring system >>(bigbrother in this case). The seems to have been happening ever >>since we installed it, so its not a recent commit issue. > > >Just following up, I am still seeing this issue on a recent stable >from sept 2. (a sendmail box periodically sending an RST after >successful 3way handshake) OK, I think we might have found the issue. On the RELENG_7 box, the mc file didnt have define(`confCONNECTION_RATE_THROTTLE', `40')dnl which the other sendmail boxes have! Hopefully thats all it was and if so, sorry for the noise! ---Mike From spawk at acm.poly.edu Thu Sep 4 16:16:39 2008 From: spawk at acm.poly.edu (Boris Kochergin) Date: Thu Sep 4 16:16:46 2008 Subject: if_gif/if_bridge problem In-Reply-To: <47C4FB54.FF2F89EF@kuzbass.ru> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> Message-ID: <48C00372.8030600@acm.poly.edu> Eugene Grosbein wrote: >> Eugene, I take it the fix that applies on Boris's case is the >> M_BCAST|M_MCAST setting on the mbuf? I would like to test/commit this. >> > > I see you have already got it :-) > > >> Also, why to you add support for adding a bridge to a lagg interface? >> > > I needed to force lagg(4) to aggregate two EtherIP tunnels and now > I have it working :-) > > Eugene > _______________________________________________ > 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" > Ahoy. I've been using the patch for a while, and, recently, when the load on the wireless network I needed it for has increased, I've started getting kernel panics that I think the patch is responsible for. The panics are usually foreshadowed by messages in the style of "Sep 3 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" in the kernel buffer. I like to think that I've eliminated the possibility of bad hardware by changing the motherboard, memory, and Ethernet controllers in the machine, and have tried both Eugene's original patchset and the one that was committed to 7-STABLE, with the same ill effects. Any ideas about what might be wrong, or shall I set about getting a backtrace? Thanks. -Boris From eugen at kuzbass.ru Thu Sep 4 16:49:57 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Sep 4 16:50:05 2008 Subject: if_gif/if_bridge problem In-Reply-To: <48C00372.8030600@acm.poly.edu> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> Message-ID: <20080904164949.GA76939@svzserv.kemerovo.su> On Thu, Sep 04, 2008 at 11:49:06AM -0400, Boris Kochergin wrote: > Ahoy. I've been using the patch for a while, and, recently, when the > load on the wireless network I needed it for has increased, I've started > getting kernel panics that I think the patch is responsible for. The > panics are usually foreshadowed by messages in the style of "Sep 3 > 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" > in the kernel buffer. I like to think that I've eliminated the > possibility of bad hardware by changing the motherboard, memory, and > Ethernet controllers in the machine, and have tried both Eugene's > original patchset and the one that was committed to 7-STABLE, with the > same ill effects. Any ideas about what might be wrong, or shall I set > about getting a backtrace? Thanks. Yes, you should. And I think you no more need my patches after Andrew's fixes to gif(4). But if you need my changes to lagg(4), you should now use version corrected to apply to recent RELENG_7: ftp://www.kuzbass.ru/pub/freebsd/lagg-0.2.tgz There were no functional changes, only context changes after Anrew's commit. Eugene Grosbein From thompsa at FreeBSD.org Thu Sep 4 17:00:27 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Thu Sep 4 17:00:34 2008 Subject: if_gif/if_bridge problem In-Reply-To: <20080904164949.GA76939@svzserv.kemerovo.su> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> Message-ID: <20080904170017.GE23667@citylink.fud.org.nz> On Fri, Sep 05, 2008 at 12:49:49AM +0800, Eugene Grosbein wrote: > On Thu, Sep 04, 2008 at 11:49:06AM -0400, Boris Kochergin wrote: > > > Ahoy. I've been using the patch for a while, and, recently, when the > > load on the wireless network I needed it for has increased, I've started > > getting kernel panics that I think the patch is responsible for. The > > panics are usually foreshadowed by messages in the style of "Sep 3 > > 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" > > in the kernel buffer. I like to think that I've eliminated the > > possibility of bad hardware by changing the motherboard, memory, and > > Ethernet controllers in the machine, and have tried both Eugene's > > original patchset and the one that was committed to 7-STABLE, with the > > same ill effects. Any ideas about what might be wrong, or shall I set > > about getting a backtrace? Thanks. > > Yes, you should. And I think you no more need my patches after > Andrew's fixes to gif(4). But if you need my changes to lagg(4), > you should now use version corrected to apply to recent RELENG_7: > ftp://www.kuzbass.ru/pub/freebsd/lagg-0.2.tgz > > There were no functional changes, only context changes after Anrew's commit. Im not too sure about adding media attachments to the bridge. I have long forgotten the network layout you are trying to achieve, can you describe it again. It may be better to allow media-less interfaces to be added to lagg(4). Andrew From eugen at kuzbass.ru Fri Sep 5 02:24:29 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 5 02:24:36 2008 Subject: if_gif/if_bridge problem In-Reply-To: <20080904170017.GE23667@citylink.fud.org.nz> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> <20080904170017.GE23667@citylink.fud.org.nz> Message-ID: <20080905022422.GA89543@svzserv.kemerovo.su> On Thu, Sep 04, 2008 at 10:00:17AM -0700, Andrew Thompson wrote: > Im not too sure about adding media attachments to the bridge. I have > long forgotten the network layout you are trying to achieve, can you > describe it again. Just to aggregate two bridges with lagg(4) > It may be better to allow media-less interfaces to be added to lagg(4). May be. I just desided to gather all changes in bridge code :-) Eugene Grosbein From linimon at FreeBSD.org Fri Sep 5 03:16:48 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Sep 5 03:16:54 2008 Subject: kern/127102: [wpi] Intel 3945ABG low throughput Message-ID: <200809050316.m853GmOf087287@freefall.freebsd.org> Old Synopsis: Intel 3945ABG (wpi) low throughput New Synopsis: [wpi] Intel 3945ABG low throughput Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Sep 5 03:16:19 UTC 2008 Responsible-Changed-Why: Probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=127102 From figyshki at gmail.com Fri Sep 5 04:20:05 2008 From: figyshki at gmail.com (j0 m4m4) Date: Fri Sep 5 04:20:12 2008 Subject: kern/127102: [wpi] Intel 3945ABG low throughput Message-ID: <200809050420.m854K40g092558@freefall.freebsd.org> The following reply was made to PR kern/127102; it has been noted by GNATS. From: "j0 m4m4" To: bug-followup@FreeBSD.org, figyshki@gmail.com Cc: Subject: Re: kern/127102: [wpi] Intel 3945ABG low throughput Date: Thu, 4 Sep 2008 23:43:33 -0400 ------=_Part_14797_25734829.1220586213145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Same hardware has no issues under Windows and OpenSuSe 10.3 (x86_64). ------=_Part_14797_25734829.1220586213145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Same hardware has no issues under Windows and OpenSuSe 10.3 (x86_64).
------=_Part_14797_25734829.1220586213145-- From freebsd-net at dino.sk Fri Sep 5 07:56:15 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Fri Sep 5 07:56:24 2008 Subject: MSI Wind Notebook's network interfaces Message-ID: <200809050945.09276.freebsd-net@dino.sk> Hi, I have new notebook, MSI's Wind, and installed succesfully both FreeBSD-7 and -CURRENT. In 7.0-RELEASE wired network interface did not work, but after upgrading to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just one small uglyness - it's link level address (MAC) is 00:00:00:00:00:00. Needless to say, Windows initializes this to 00:1d:92:59:f5:8b. I can change it with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would rather let the driver to find the correct MAC. While everything works (I am csup'ing sources over its re0, which is a good test in my experience), if anybody have any idea/patch to test, I would like to do it. Some data collected: ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:00:00:00:00:00 inet 192.168.16.235 netmask 0xffffff00 broadcast 192.168.16.255 media: Ethernet autoselect (100baseTX ) status: active pciconf -lcv (part of) re0@pci0:1:0:0: class=0x020000 card=0x01101462 chip=0x813610ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8139/810x Family Fast Ethernet NIC' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 0 cap 11[ac] = MSI-X supports 2 messages in map 0x20 cap 03[cc] = VPD dmesg (part of verbose boot) re0: port 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 re0: MSI count : 1 re0: Chip rev. 0x34800000 re0: MAC rev. 0x00200000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: bpf attached re0: [MPSAFE] re0: [FILTER] When not booting verbose, there is also one line telling re0: turning off MSI enable bit. This netbook has also wireless interface, but this one does not get detected (or I have no driver for it), in dmesg there is only line telling pci2: at device 0.0 (no driver attached) and relevant part of pciconf -lcv is none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec rev=0x22 hdr=0x00 vendor = 'Realtek Semiconductor' class = network cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint While currently I have no urge need for wireless connectivity, in the long run I would like to use it. Currently I can't change card (probably minipci) as netbook is under warranty, with 'warranty sticker - void if tampered' over screw. If anybody had some idea how to fix MAC address initialization for wired interface or what driver to use for wireless interface (I will probably try NDIS, but my experience in this area is limited and previous succesfull try none), I am all ears. Regars, Milan From pyunyh at gmail.com Fri Sep 5 08:23:32 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Sep 5 08:23:38 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809050945.09276.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> Message-ID: <20080905082322.GA66951@cdnetworks.co.kr> On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: > Hi, > I have new notebook, MSI's Wind, and installed succesfully both FreeBSD-7 > and -CURRENT. > > In 7.0-RELEASE wired network interface did not work, but after upgrading to > 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just one small > uglyness - it's link level address (MAC) is 00:00:00:00:00:00. Needless to > say, Windows initializes this to 00:1d:92:59:f5:8b. I can change it > with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would rather let the > driver to find the correct MAC. > > While everything works (I am csup'ing sources over its re0, which is a good > test in my experience), if anybody have any idea/patch to test, I would like > to do it. > > Some data collected: > > ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > > options=389b > ether 00:00:00:00:00:00 > inet 192.168.16.235 netmask 0xffffff00 broadcast 192.168.16.255 > media: Ethernet autoselect (100baseTX ) > status: active > > pciconf -lcv (part of) > re0@pci0:1:0:0: class=0x020000 card=0x01101462 chip=0x813610ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8139/810x Family Fast Ethernet NIC' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > cap 11[ac] = MSI-X supports 2 messages in map 0x20 > cap 03[cc] = VPD > > dmesg (part of verbose boot) > re0: port 0xc000-0xc0ff mem > 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 > re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > re0: MSI count : 1 > re0: Chip rev. 0x34800000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: bpf attached > re0: [MPSAFE] > re0: [FILTER] > > When not booting verbose, there is also one line telling > re0: turning off MSI enable bit. > re(4) cleared MSI enable bit of configuration register as MSI wouldn't be used. You can ignore this. > This netbook has also wireless interface, but this one does not get detected > (or I have no driver for it), in dmesg there is only line telling > pci2: at device 0.0 (no driver attached) > > and relevant part of pciconf -lcv is > none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec > rev=0x22 hdr=0x00 > vendor = 'Realtek Semiconductor' > class = network > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 1 legacy endpoint > > While currently I have no urge need for wireless connectivity, in the long run > I would like to use it. Currently I can't change card (probably minipci) as > netbook is under warranty, with 'warranty sticker - void if tampered' over > screw. > > If anybody had some idea how to fix MAC address initialization for wired Would you try attached patch? > interface or what driver to use for wireless interface (I will probably try > NDIS, but my experience in this area is limited and previous succesfull try > none), I am all ears. > > Regars, > Milan -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/re/if_re.c.orig Wed Aug 13 12:40:08 2008 +++ sys/dev/re/if_re.c Fri Sep 5 17:18:40 2008 @@ -1213,7 +1213,8 @@ case RL_HWREV_8102E: case RL_HWREV_8102EL: sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR | - RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT; + RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 | + RL_FLAG_MACSTAT; break; case RL_HWREV_8168_SPIN1: case RL_HWREV_8168_SPIN2: From freebsd-net at dino.sk Fri Sep 5 14:44:54 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Fri Sep 5 14:45:02 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <20080905082322.GA66951@cdnetworks.co.kr> References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> Message-ID: <200809051643.52950.freebsd-net@dino.sk> On Friday 05 September 2008 10:23:22 Pyun YongHyeon wrote: > On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: [ snip ] > > In 7.0-RELEASE wired network interface did not work, but after upgrading > > to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just > > one small uglyness - it's link level address (MAC) is 00:00:00:00:00:00. > > Needless to say, Windows initializes this to 00:1d:92:59:f5:8b. I can > > change it with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would > > rather let the driver to find the correct MAC. [ snip ] > > dmesg (part of verbose boot) > > re0: port 0xc000-0xc0ff > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > > re0: MSI count : 1 > > re0: Chip rev. 0x34800000 > > re0: MAC rev. 0x00200000 > > miibus0: on re0 > > rlphy0: PHY 1 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re0: bpf attached > > re0: [MPSAFE] > > re0: [FILTER] > > > > When not booting verbose, there is also one line telling > > re0: turning off MSI enable bit. > > re(4) cleared MSI enable bit of configuration register as MSI > wouldn't be used. You can ignore this. > OK, but what surprised me a bit was the fact this line is not present in dmesg when booting verbose. I would expect all lines from normal boot in verbose boot... > > This netbook has also wireless interface, but this one does not get > > detected (or I have no driver for it), in dmesg there is only line > > telling pci2: at device 0.0 (no driver attached) > > > > and relevant part of pciconf -lcv is > > none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec > > rev=0x22 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > class = network > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 10[70] = PCI-Express 1 legacy endpoint > > > > While currently I have no urge need for wireless connectivity, in the > > long run I would like to use it. Currently I can't change card (probably > > minipci) as netbook is under warranty, with 'warranty sticker - void if > > tampered' over screw. > > > > If anybody had some idea how to fix MAC address initialization for wired > > Would you try attached patch? > I tried on freshly csup'ped head and it works. Ethernet link address is now correctly set. Great! It looks like a kind of magic at first glance :) > > interface or what driver to use for wireless interface (I will probably > > try NDIS, but my experience in this area is limited and previous > > succesfull try none), I am all ears. Could anybody comment on wireless interface? Regards, Milan From redchin at gmail.com Fri Sep 5 16:40:59 2008 From: redchin at gmail.com (Kevin Downey) Date: Fri Sep 5 16:41:05 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809051643.52950.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> <200809051643.52950.freebsd-net@dino.sk> Message-ID: <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch wrote: > [ snip ] > Could anybody comment on wireless interface? I could not get the internal wifi to work with ndis wrapper. It appears that using the rtw driver netbsd, openbsd, and dragonflybsd all support this chipset. I found a (polish?) webpage with a very preliminary attempt at porting the rtw driver. The author of the port said it doesn't really work. I just gave up and bought a usb wifi stick. -- The Mafia way is that we pursue larger goals under the guise of personal relationships. Fisheye From milan at dino.sk Fri Sep 5 19:46:37 2008 From: milan at dino.sk (Milan Obuch) Date: Fri Sep 5 19:46:45 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809051643.52950.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> <200809051643.52950.freebsd-net@dino.sk> Message-ID: <200809052135.27899.milan@dino.sk> On Friday 05 September 2008 16:43:51 Milan Obuch wrote: > On Friday 05 September 2008 10:23:22 Pyun YongHyeon wrote: > > On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: > > [ snip ] > > > > In 7.0-RELEASE wired network interface did not work, but after > > > upgrading to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. > > > There is just one small uglyness - it's link level address (MAC) is > > > 00:00:00:00:00:00. Needless to say, Windows initializes this to > > > 00:1d:92:59:f5:8b. I can change it with 'ifconfig re0 ether > > > 00:1d:92:59:f5:8b', but I would rather let the driver to find the > > > correct MAC. [ snip ] > > > If anybody had some idea how to fix MAC address initialization for > > > wired > > > > Would you try attached patch? > > I tried on freshly csup'ped head and it works. Ethernet link address is now > correctly set. Great! It looks like a kind of magic at first glance :) > > > > interface or what driver to use for wireless interface (I will > > > probably try NDIS, but my experience in this area is limited and > > > previous succesfull try none), I am all ears. > > Could anybody comment on wireless interface? > I csup'ped 7.1-PRERELEASE, apply this patch and it work just like in HEAD. Just FYI. Regards, Milan From julian at elischer.org Fri Sep 5 20:24:02 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 5 20:24:09 2008 Subject: rewrite of rt_check() (now rt_check_fib()) Message-ID: <48C19568.807@elischer.org> In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up rewriting it to do what I thought it was trying to do.. this stops the panics some people have seen, but allows the system to stay up long enough to see some other problem.. anyhow this si the patch: comments? -------------- next part -------------- Index: route.c =================================================================== RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.134 diff -u -r1.134 route.c --- route.c 1 Sep 2008 17:15:29 -0000 1.134 +++ route.c 5 Sep 2008 20:23:32 -0000 @@ -1676,16 +1676,18 @@ * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet + * (*lrt0 has not ref held on it so REMREF is not needed ) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. + * Note that rtalloc returns an rtentry with an extra REF that we need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination - * *lrt points to the route to the next hop + * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. */ @@ -1704,49 +1706,56 @@ int error; KASSERT(*lrt0 != NULL, ("rt_check")); - rt = rt0 = *lrt0; + rt0 = *lrt0; + rt = NULL; /* NB: the locking here is tortuous... */ - RT_LOCK(rt); - if ((rt->rt_flags & RTF_UP) == 0) { - RT_UNLOCK(rt); - rt = rtalloc1_fib(dst, 1, 0UL, fibnum); - if (rt != NULL) { - RT_REMREF(rt); + RT_LOCK(rt0); + if ((rt0->rt_flags & RTF_UP) == 0) { + /* Current rt0 is useless, try get a replacement. */ + RT_UNLOCK(rt0); + rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); + if ((rt0 != NULL)/* && (rt0->rt_flags & RTF_UP) */) { + RT_REMREF(rt0); /* XXX what about if change? */ - } else + } else { return (EHOSTUNREACH); - rt0 = rt; + } } + /* XXX BSD/OS checks dst->sa_family != AF_NS */ - if (rt->rt_flags & RTF_GATEWAY) { - if (rt->rt_gwroute == NULL) - goto lookup; - rt = rt->rt_gwroute; - RT_LOCK(rt); /* NB: gwroute */ - if ((rt->rt_flags & RTF_UP) == 0) { - RTFREE_LOCKED(rt); /* unlock gwroute */ - rt = rt0; - rt0->rt_gwroute = NULL; - lookup: + if (rt0->rt_flags & RTF_GATEWAY) { + if ((rt = rt0->rt_gwroute) != NULL) { + RT_LOCK(rt); /* NB: gwroute */ + if ((rt->rt_flags & RTF_UP) == 0) { + /* gw route is dud. ignore/lose it */ + RTFREE_LOCKED(rt); /* unlock gwroute */ + rt = rt0->rt_gwroute = NULL; + } + } + + + if (rt == NULL) { /* NOT AN ELSE CLAUSE */ RT_UNLOCK(rt0); -/* XXX MRT link level looked up in table 0 */ - rt = rtalloc1_fib(rt->rt_gateway, 1, 0UL, 0); + /* XXX MRT link level looked up in table 0 */ + rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); if (rt == rt0) { - RT_REMREF(rt0); - RT_UNLOCK(rt0); + /* the best we can do is not good enough */ + /* XXX does this happen? */ + RT_REMREF(rt); + RT_UNLOCK(rt); return (ENETUNREACH); } RT_LOCK(rt0); - if (rt0->rt_gwroute != NULL) - RTFREE(rt0->rt_gwroute); - rt0->rt_gwroute = rt; if (rt == NULL) { RT_UNLOCK(rt0); return (EHOSTUNREACH); } + rt0->rt_gwroute = rt; } RT_UNLOCK(rt0); + } else { + rt = rt0; } /* XXX why are we inspecting rmx_expire? */ error = (rt->rt_flags & RTF_REJECT) && From julian at elischer.org Fri Sep 5 22:49:18 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 5 22:49:34 2008 Subject: rewrite of rt_check() (now rt_check_fib()) In-Reply-To: <48C19568.807@elischer.org> References: <48C19568.807@elischer.org> Message-ID: <48C1B774.2020405@elischer.org> Julian Elischer wrote: > In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up > rewriting it to do what I thought it was trying to do.. > this stops the panics some people have seen, but allows the system to > stay up long enough to see some other problem.. > anyhow this si the patch: > > comments? > I was thinking about this a bit. rt_check_fib() drops the lock on the given rtentry in order to be able to get a lock on another rtentry that MIGHT be the same rtentry. while it is doing this, another processor could free the original rtentry. The only safw way to get around this is to hold an additional reference on the first rtentry (we don't already have one) while it is unlocked so that we can be sure that it is not actually freed if this happens. to do this safely I'd have to add a couple of new items into route.h: #define RT_TEMP_UNLOCK(_rt) do { \ RT_ADDREF(_rt); \ RT_UNLOCK(_rt); \ } while (0) #define RT_RELOCK(_rt) do { \ RT_LOCK(_rt) \ if ((_rt)->rt_refcnt <= 1) \ rtfree(_rt); \ _rt = 0; /* signal that it went away */ \ else { \ RT_REMREF(_rt); \ RT_UNLOCK(_rt); \ /* note that _rt is still valid */ \ } \ } while (0) the new version of rt_check is attached..... -------------- next part -------------- /* * rt_check() is invoked on each layer 2 output path, prior to * encapsulating outbound packets. * * The function is mostly used to find a routing entry for the gateway, * which in some protocol families could also point to the link-level * address for the gateway itself (the side effect of revalidating the * route to the destination is rather pointless at this stage, we did it * already a moment before in the pr_output() routine to locate the ifp * and gateway to use). * * When we remove the layer-3 to layer-2 mapping tables from the * routing table, this function can be removed. * * === On input === * *dst is the address of the NEXT HOP (which coincides with the * final destination if directly reachable); * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet * (*lrt0 has not ref held on it so REMREF is not needed ) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. * Note that rtalloc returns an rtentry with an extra REF that we need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. * * To follow this you have to remember that: * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) * and an RT_UNLOCK * RTFREE does an RT_LOCK and an RTFREE_LOCKED * The gwroute pointer counts as a reference on the rtentry to which it points. * so when we add it we use the ref that rtalloc gives us and when we lose it * we need to remove the reference. */ int rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) { return (rt_check_fib(lrt, lrt0, dst, 0)); } int rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, u_int fibnum) { struct rtentry *rt; struct rtentry *rt0; int error; KASSERT(*lrt0 != NULL, ("rt_check")); rt0 = *lrt0; rt = NULL; /* NB: the locking here is tortuous... */ RT_LOCK(rt0); retry: if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { /* Current rt0 is useless, try get a replacement. */ RT_UNLOCK(rt0); rt0 = NULL; } if (rt0 == NULL) { rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); if ((rt0 != NULL)/* && (rt0->rt_flags & RTF_UP) */) { RT_REMREF(rt0); /* don't need the reference. */ /* XXX what about interface change? */ } else { return (EHOSTUNREACH); } } /* XXX BSD/OS checks dst->sa_family != AF_NS */ if (rt0->rt_flags & RTF_GATEWAY) { if ((rt = rt0->rt_gwroute) != NULL) { RT_LOCK(rt); /* NB: gwroute */ if ((rt->rt_flags & RTF_UP) == 0) { /* gw route is dud. ignore/lose it */ RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ rt = rt0->rt_gwroute = NULL; } } if (rt == NULL) { /* NOT AN ELSE CLAUSE */ RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ /* XXX MRT link level looked up in table 0 */ rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); if ((rt == rt0) || (rt == NULL)) { /* the best we can do is not good enough */ if (rt) { RT_REMREF(rt); /* assumes ref > 0 */ RT_UNLOCK(rt); } RT_RELOCK(rt0); /* lose the refcount */ if (rt0) RT_UNLOCK(rt0); return (ENETUNREACH); } /* * Relock it and lose the added reference. * All sorts of things could have happenned while we * had no lock on it, so check for them. */ RT_RELOCK(rt0); if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) /* Ru-roh.. what we had is no longer any good */ goto retry; /* * While we were away, someone replaced the gateway. * Since a reference count is involved we can't just * overwrite it. */ if (rt0->rt_gwroute) { if (rt0->rt_gwroute != rt) { RT_FREE_LOCKED(rt); goto retry; } } else { rt0->rt_gwroute = rt; } } else { RT_UNLOCK(rt0); } } else { /* think of rt as having the lock from now on.. */ rt = rt0; } /* XXX why are we inspecting rmx_expire? */ if ((rt->rt_flags & RTF_REJECT) && (rt->rt_rmx.rmx_expire == 0 || time_uptime < rt->rt_rmx.rmx_expire)) { RT_UNLOCK(rt); return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); } *lrt = rt; *lrt0 = rt0; return (0); } From julian at elischer.org Fri Sep 5 22:52:39 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 5 22:52:46 2008 Subject: rewrite of rt_check() (now rt_check_fib()) In-Reply-To: <48C1B774.2020405@elischer.org> References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> Message-ID: <48C1B83C.9000404@elischer.org> Julian Elischer wrote: > Julian Elischer wrote: >> In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up >> rewriting it to do what I thought it was trying to do.. >> this stops the panics some people have seen, but allows the system to >> stay up long enough to see some other problem.. >> anyhow this si the patch: >> >> comments? >> > > I was thinking about this a bit. > > rt_check_fib() drops the lock on the given rtentry in order to be able > to get a lock on another rtentry that MIGHT be the same rtentry. > > while it is doing this, another processor could free the original > rtentry. The only safw way to get around this is to hold an additional > reference on the first rtentry (we don't already have one) while it is > unlocked so that we can be sure that it is not actually freed if this > happens. > > to do this safely I'd have to add a couple of new items into route.h: > > #define RT_TEMP_UNLOCK(_rt) do { \ > RT_ADDREF(_rt); \ > RT_UNLOCK(_rt); \ > } while (0) > > #define RT_RELOCK(_rt) do { \ > RT_LOCK(_rt) \ > if ((_rt)->rt_refcnt <= 1) \ > rtfree(_rt); \ > _rt = 0; /* signal that it went away */ \ > else { \ > RT_REMREF(_rt); \ > RT_UNLOCK(_rt); duh remove that line! \ > /* note that _rt is still valid */ \ > } \ > } while (0) > > > the new version of rt_check is attached..... > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Fri Sep 5 23:13:48 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 5 23:13:55 2008 Subject: rewrite of rt_check() (now rt_check_fib()) In-Reply-To: <48C1B83C.9000404@elischer.org> References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> <48C1B83C.9000404@elischer.org> Message-ID: <48C1BD31.6090804@elischer.org> Julian Elischer wrote: > Julian Elischer wrote: >> Julian Elischer wrote: >>> In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up >>> rewriting it to do what I thought it was trying to do.. >>> this stops the panics some people have seen, but allows the system to >>> stay up long enough to see some other problem.. >>> anyhow this si the patch: >>> >>> comments? >>> >> >> I was thinking about this a bit. >> >> rt_check_fib() drops the lock on the given rtentry in order to be able >> to get a lock on another rtentry that MIGHT be the same rtentry. >> >> while it is doing this, another processor could free the original >> rtentry. The only safw way to get around this is to hold an additional >> reference on the first rtentry (we don't already have one) while it is >> unlocked so that we can be sure that it is not actually freed if this >> happens. >> >> to do this safely I'd have to add a couple of new items into route.h: this time with less (I hope) bugs... new macros... #define RT_TEMP_UNLOCK(_rt) do { \ RT_ADDREF(_rt); \ RT_UNLOCK(_rt); \ } while (0) #define RT_RELOCK(_rt) do { \ RT_LOCK(_rt) \ if ((_rt)->rt_refcnt <= 1) \ rtfree(_rt); \ _rt = 0; /* signal that it went away */ \ else { \ RT_REMREF(_rt); \ /* note that _rt is still valid */ \ } \ } while (0) with (better) code attached: -------------- next part -------------- /* * rt_check() is invoked on each layer 2 output path, prior to * encapsulating outbound packets. * * The function is mostly used to find a routing entry for the gateway, * which in some protocol families could also point to the link-level * address for the gateway itself (the side effect of revalidating the * route to the destination is rather pointless at this stage, we did it * already a moment before in the pr_output() routine to locate the ifp * and gateway to use). * * When we remove the layer-3 to layer-2 mapping tables from the * routing table, this function can be removed. * * === On input === * *dst is the address of the NEXT HOP (which coincides with the * final destination if directly reachable); * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet * (*lrt0 has not ref held on it so REMREF is not needed ) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. * Note that rtalloc returns an rtentry with an extra REF that we need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. * * To follow this you have to remember that: * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) * and an RT_UNLOCK * RTFREE does an RT_LOCK and an RTFREE_LOCKED * The gwroute pointer counts as a reference on the rtentry to which it points. * so when we add it we use the ref that rtalloc gives us and when we lose it * we need to remove the reference. */ int rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) { return (rt_check_fib(lrt, lrt0, dst, 0)); } int rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, u_int fibnum) { struct rtentry *rt; struct rtentry *rt0; int error; KASSERT(*lrt0 != NULL, ("rt_check")); rt0 = *lrt0; rt = NULL; /* NB: the locking here is tortuous... */ RT_LOCK(rt0); retry: if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { /* Current rt0 is useless, try get a replacement. */ RT_UNLOCK(rt0); rt0 = NULL; } if (rt0 == NULL) { rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); if (rt0 == NULL) { return (EHOSTUNREACH); } RT_REMREF(rt0); /* don't need the reference. */ } if (rt0->rt_flags & RTF_GATEWAY) { if ((rt = rt0->rt_gwroute) != NULL) { RT_LOCK(rt); /* NB: gwroute */ if ((rt->rt_flags & RTF_UP) == 0) { /* gw route is dud. ignore/lose it */ RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ rt = rt0->rt_gwroute = NULL; } } if (rt == NULL) { /* NOT AN ELSE CLAUSE */ RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); if ((rt == rt0) || (rt == NULL)) { /* the best we can do is not good enough */ if (rt) { RT_REMREF(rt); /* assumes ref > 0 */ RT_UNLOCK(rt); } RT_FREE(rt0); /* lock, unref, (unlock) */ return (ENETUNREACH); } /* * Relock it and lose the added reference. * All sorts of things could have happenned while we * had no lock on it, so check for them. */ RT_RELOCK(rt0); if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) /* Ru-roh.. what we had is no longer any good */ goto retry; /* * While we were away, someone replaced the gateway. * Since a reference count is involved we can't just * overwrite it. */ if (rt0->rt_gwroute) { if (rt0->rt_gwroute != rt) { RT_FREE_LOCKED(rt); goto retry; } } else { rt0->rt_gwroute = rt; } } RT_LOCK_ASSERT(rt); RT_UNLOCK(rt0); } else { /* think of rt as having the lock from now on.. */ rt = rt0; } /* XXX why are we inspecting rmx_expire? */ if ((rt->rt_flags & RTF_REJECT) && (rt->rt_rmx.rmx_expire == 0 || time_uptime < rt->rt_rmx.rmx_expire)) { RT_UNLOCK(rt); return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); } *lrt = rt; *lrt0 = rt0; return (0); } From pyunyh at gmail.com Sat Sep 6 00:46:40 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Sep 6 00:46:49 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809051643.52950.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> <200809051643.52950.freebsd-net@dino.sk> Message-ID: <20080906004627.GA69867@cdnetworks.co.kr> On Fri, Sep 05, 2008 at 04:43:51PM +0200, Milan Obuch wrote: > On Friday 05 September 2008 10:23:22 Pyun YongHyeon wrote: > > On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: > > [ snip ] > > > > In 7.0-RELEASE wired network interface did not work, but after upgrading > > > to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just > > > one small uglyness - it's link level address (MAC) is 00:00:00:00:00:00. > > > Needless to say, Windows initializes this to 00:1d:92:59:f5:8b. I can > > > change it with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would > > > rather let the driver to find the correct MAC. > > [ snip ] > > > > dmesg (part of verbose boot) > > > re0: port 0xc000-0xc0ff > > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > > > re0: MSI count : 1 > > > re0: Chip rev. 0x34800000 > > > re0: MAC rev. 0x00200000 > > > miibus0: on re0 > > > rlphy0: PHY 1 on miibus0 > > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > re0: bpf attached > > > re0: [MPSAFE] > > > re0: [FILTER] > > > > > > When not booting verbose, there is also one line telling > > > re0: turning off MSI enable bit. > > > > re(4) cleared MSI enable bit of configuration register as MSI > > wouldn't be used. You can ignore this. > > > > OK, but what surprised me a bit was the fact this line is not present in dmesg > when booting verbose. I would expect all lines from normal boot in verbose > boot... > That MSI information is stored in EEPROM. So you wouldn't see the message again if MSI enable bit was already cleard. Since re(4) clears the bit subsequent booting wouldn't touch the MSI enable bit in EEPROM. > > > This netbook has also wireless interface, but this one does not get > > > detected (or I have no driver for it), in dmesg there is only line > > > telling pci2: at device 0.0 (no driver attached) > > > > > > and relevant part of pciconf -lcv is > > > none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec > > > rev=0x22 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > class = network > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 1 legacy endpoint > > > > > > While currently I have no urge need for wireless connectivity, in the > > > long run I would like to use it. Currently I can't change card (probably > > > minipci) as netbook is under warranty, with 'warranty sticker - void if > > > tampered' over screw. > > > > > > If anybody had some idea how to fix MAC address initialization for wired > > > > Would you try attached patch? > > > > I tried on freshly csup'ped head and it works. Ethernet link address is now > correctly set. Great! It looks like a kind of magic at first glance :) > I've commited the patch to HEAD(r182808). Thanks for your testing! -- Regards, Pyun YongHyeon From freebsd-bridge-sep08 at oldach.net Sat Sep 6 06:00:12 2008 From: freebsd-bridge-sep08 at oldach.net (Helge Oldach) Date: Sat Sep 6 06:00:18 2008 Subject: kern/127052: Still bridge issues - with L2 protocols such as PPPoE Message-ID: <200809060600.m8660CUv072986@freefall.freebsd.org> The following reply was made to PR kern/127052; it has been noted by GNATS. From: freebsd-bridge-sep08@oldach.net (Helge Oldach) To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE Date: Sat, 6 Sep 2008 07:43:42 +0200 (CEST) I have tested Eygenes patch and it works as expected on 6-STABLE. However the behaviour is a little bit strange: The sysctl is of by default. When enabling it, nothing happens. The bridge's MAC still is the random MAC chosen upon boot. Even toggling the bridge interface down/up doesn't change it. The bridge's MAC is inherited only when a member interface is added or deleted. Essentially this sysctl must be set at boot time, e.g. in /etc/sysctl.conf to make it work consistently. Further, it is a global sysctl that applies to *all* bridge interfaces identically. It is not possible to have one bridge with inheritance, and another without. Philip explained that the main rationale for MAC inheritance was to make DHCP consistent over reboots. This can be simply achieved by a trivial ifconfig_bridge0="link 66:fc:df:e2:3f:f5 up" (or similar) in /etc/rc.conf. There is no need to change code at all to achieve the desired effect, and we still have full flexibility, even with multiple bridges. (To simplify mass deployment, one can seed the MAC in the above command from a file created upon initial boot.) I would therefore mandate to back out the bridge inheritance stuff completely. Helge From freebsd-net at dino.sk Sat Sep 6 06:04:07 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Sat Sep 6 06:04:16 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <20080906004627.GA69867@cdnetworks.co.kr> References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <20080906004627.GA69867@cdnetworks.co.kr> Message-ID: <200809060803.53293.freebsd-net@dino.sk> On Saturday 06 September 2008 02:46:27 Pyun YongHyeon wrote: [ snip ] > > > > When not booting verbose, there is also one line telling > > > > re0: turning off MSI enable bit. > > > > > > re(4) cleared MSI enable bit of configuration register as MSI > > > wouldn't be used. You can ignore this. > > > > OK, but what surprised me a bit was the fact this line is not present in > > dmesg when booting verbose. I would expect all lines from normal boot in > > verbose boot... > > That MSI information is stored in EEPROM. So you wouldn't see the > message again if MSI enable bit was already cleard. Since re(4) > clears the bit subsequent booting wouldn't touch the MSI enable bit > in EEPROM. > Now that's clear to me. [ snip ] > > > > If anybody had some idea how to fix MAC address initialization for > > > > wired > > > > > > Would you try attached patch? > > > > I tried on freshly csup'ped head and it works. Ethernet link address is > > now correctly set. Great! It looks like a kind of magic at first glance > > :) > > I've commited the patch to HEAD(r182808). > > Thanks for your testing! It was my pleasure and I would like to express my thanks for your great work. If you will need in future some more testing with this hardware, just drop me a line. Just a side note, will this patch be MFS'ed into 7-STABLE in short timeframe? Regards, Milan From freebsd-net at dino.sk Sat Sep 6 06:43:44 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Sat Sep 6 06:43:51 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> Message-ID: <200809060843.35213.freebsd-net@dino.sk> On Friday 05 September 2008 18:13:45 Kevin Downey wrote: > On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch wrote: > > [ snip ] > > Could anybody comment on wireless interface? > > I could not get the internal wifi to work with ndis wrapper. It > appears that using the rtw driver netbsd, openbsd, and dragonflybsd > all support this chipset. I found a (polish?) webpage with a very > preliminary attempt at porting the rtw driver. The author of the port > said it doesn't really work. > > I just gave up and bought a usb wifi stick. Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do not show working wireless interface/no driver attached. How did you try it? Do you have any reference, alternatively? Wireless interface is not top priority for me at a moment, but if it were not too hard, I will try. My notebook is Wind U100 series... is yours similar or perhaps the same? Regards, Milan From bennett at cs.niu.edu Sat Sep 6 11:17:36 2008 From: bennett at cs.niu.edu (Scott Bennett) Date: Sat Sep 6 11:17:43 2008 Subject: TCP connections hanging in FIN_WAIT_1 Message-ID: <200809061018.m86AIje1006135@mp.cs.niu.edu> I'm running FreeBSD 6.3-STABLE, compiled with updates as of 13 Aug. 2008, and I'm seeing TCP connections that have been in FIN_WAIT_1 state for at least eleven *hours*. It has been years since I last read all the specs on TCP close processing, but my recollection is that the entire sequence was limited to only two or three minutes. I couldn't find a bug report, but that proves nothing. Does anyone know of such a bug? Or some weird condition I should look for that might cause TCP connections to get stuck in the closing sequence somehow? The hardware configuration is a Dell Inspiron XPS with a Broadcom BCM5705 A1 adaptor, ASIC rev. 0x3001, (bge driver) for 10/100/1000 Mb/s connected to a Comcast/RCA cable modem at 100 Mb/s. Thanks in advance for any information you may have. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From sam at freebsd.org Sat Sep 6 15:43:50 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Sep 6 15:43:57 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809060843.35213.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> <200809060843.35213.freebsd-net@dino.sk> Message-ID: <48C2A52F.1080705@freebsd.org> Milan Obuch wrote: > On Friday 05 September 2008 18:13:45 Kevin Downey wrote: >> On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch wrote: >>> [ snip ] >>> Could anybody comment on wireless interface? >> I could not get the internal wifi to work with ndis wrapper. It >> appears that using the rtw driver netbsd, openbsd, and dragonflybsd >> all support this chipset. I found a (polish?) webpage with a very >> preliminary attempt at porting the rtw driver. The author of the port >> said it doesn't really work. >> >> I just gave up and bought a usb wifi stick. > > Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do not > show working wireless interface/no driver attached. How did you try it? Do > you have any reference, alternatively? > > Wireless interface is not top priority for me at a moment, but if it were not > too hard, I will try. > > My notebook is Wind U100 series... is yours similar or perhaps the same? rtw supports only an old 11b only part. If you've really got a RealTek wireless part in this laptop then it's not supported by any bsd driver I know of. There's a linux driver of unknown quality that someone can use to build a bsd driver but given how cheap wireless parts are your best bet is to just replace the card. Sam From freebsd-net at dino.sk Sat Sep 6 16:19:08 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Sat Sep 6 16:19:15 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <48C2A52F.1080705@freebsd.org> References: <200809050945.09276.freebsd-net@dino.sk> <200809060843.35213.freebsd-net@dino.sk> <48C2A52F.1080705@freebsd.org> Message-ID: <200809061818.52700.freebsd-net@dino.sk> On Saturday 06 September 2008 17:43:43 Sam Leffler wrote: [ snip ] > > Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do > > not show working wireless interface/no driver attached. How did you try > > it? Do you have any reference, alternatively? > > > > Wireless interface is not top priority for me at a moment, but if it were > > not too hard, I will try. > > > > My notebook is Wind U100 series... is yours similar or perhaps the same? > > rtw supports only an old 11b only part. If you've really got a RealTek > wireless part in this laptop then it's not supported by any bsd driver I > know of. There's a linux driver of unknown quality that someone can use > to build a bsd driver but given how cheap wireless parts are your best > bet is to just replace the card. > Unfortunately, I will not be allowed to do it until warranty expires... but it's not top priority for me. Judging from Windows driver, this card is b/g capable, so no luck now. No trouble, I need other things get working. Regards, Milan From remko at FreeBSD.org Sat Sep 6 23:16:43 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat Sep 6 23:16:54 2008 Subject: kern/127145: [wi]: prism (wi) driver crash at bigger traffic Message-ID: <200809062316.m86NGhDj000637@freefall.freebsd.org> Old Synopsis: prism (wi) driver crash at bigger traffic New Synopsis: [wi]: prism (wi) driver crash at bigger traffic State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Sat Sep 6 23:15:46 UTC 2008 State-Changed-Why: Ask for feedback: Can you report whether 7.x still has this issue? Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Sep 6 23:15:46 UTC 2008 Responsible-Changed-Why: change to -net, wi is a networking driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=127145 From noc at bg.net.ua Sun Sep 7 12:11:48 2008 From: noc at bg.net.ua (Zin'kov Oleg) Date: Sun Sep 7 12:11:56 2008 Subject: Problem with process parallelization Message-ID: <79dc33e3f3737f5beeadce88e96004bc.squirrel@webmail.bg.net.ua> Hello, freebsd-net mailing list. We have server such configurtion: - 2 quadcore AMD Opteron processors; - 4 GB RAM; - NIC Intel Pro/1000 PT, Dual Port Server Adapter. ########################################################### Problem: in some moments of time, at the growth of the network activity, one of the processors is fully loaded at 100%. ########################################################### Kernel configuration: FreeBSD atlantis.bg.net.ua 7.0-STABLE FreeBSD 7.0-STABLE #1: Tue Apr 1 15:06:30 EEST 2008 root@atlantis.bg.net.ua:/usr/obj/usr/src/sys/ATLANTIS amd64 /etc/sysctl.conf: net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.somaxconn=16384 net.inet.ip.fastforwarding=1 net.inet.ip.maxfragpackets=2000 net.inet.ip.intr_queue_maxlen=1000 net.inet.ip.dummynet.hash_size=2048 net.inet.tcp.recvspace=65536 net.inet.udp.recvspace=65536 net.inet.raw.recvspace=32768 net.local.stream.recvspace=32768 net.local.dgram.recvspace=32768 net.local.stream.sendspace=32768 net.inet.tcp.sendspace=65536 net.inet.icmp.icmplim=500 dev.em.0.rx_int_delay=500 dev.em.0.tx_int_delay=500 dev.em.0.rx_abs_int_delay=800 dev.em.0.tx_abs_int_delay=800 dev.em.1.rx_int_delay=500 dev.em.1.tx_int_delay=500 dev.em.1.rx_abs_int_delay=800 dev.em.1.tx_abs_int_delay=800 net.link.ether.inet.max_age=600 /boot/loader.conf: hw.em.rxd=4096 hw.em.txd=4096 /etc/rc.firewall: 82 pipes like theese: pipe 387 ip from any to 193.227.x.x in recv vlan10 pipe 388 ip from 193.227.x.x to any out xmit vlan10 ######################################### Kernel: cpu HAMMER ident ATLANTIS # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Bus support. device acpi device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering # RAID controllers device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc ### COM device sio # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device vlan # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter ## Custom options # NetGraph options NETGRAPH options NETGRAPH_ONE2MANY options NETGRAPH_NETFLOW options NETGRAPH_CISCO options NETGRAPH_ETHER options NETGRAPH_KSOCKET options NETGRAPH_SOCKET options NETGRAPH_TEE options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=1000 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options HZ=1000 options DEVICE_POLLING ##################################################### Interfaces: - em0 - em1 - bge0 - bge1 - vlan (61 virtual interfaces) ##################################################### top -S last pid: 9673; load averages: 1.94, 1.75, 1.57 up 0+19:17:21 19:45:01 77 processes: 11 running, 49 sleeping, 17 waiting CPU states: 0.0% user, 0.0% nice, 22.6% system, 0.3% interrupt, 77.0% idle Mem: 198M Active, 410M Inact, 455M Wired, 228K Cache, 214M Buf, 2874M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K 16K CPU7 7 19.0H 100.00% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 18.9H 100.00% idle: cpu2 17 root 1 171 ki31 0K 16K RUN 1 18.8H 100.00% idle: cpu1 13 root 1 171 ki31 0K 16K CPU5 5 18.8H 100.00% idle: cpu5 18 root 1 171 ki31 0K 16K CPU0 0 916:13 100.00% idle: cpu0 12 root 1 171 ki31 0K 16K CPU6 6 18.8H 99.85% idle: cpu6 35 root 1 -68 - 0K 16K CPU4 4 466:17 96.00% em1 taskq 34 root 1 -68 - 0K 16K CPU3 3 482:01 90.38% em0 taskq 15 root 1 171 ki31 0K 16K RUN 3 655:20 13.38% idle: cpu3 14 root 1 171 ki31 0K 16K RUN 4 671:52 3.08% idle: cpu4 ############################################## 19:45[p0]root@atlantis#~>netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 57381 0 36442155 68726 0 69126050 0 56817 0 37480502 67656 0 66053093 0 57847 0 39532712 68603 0 67037042 0 56908 0 37197022 68924 0 68660108 0 57107 0 37643382 68398 0 68113937 0 56847 0 35944754 68394 0 67896267 0 58754 0 39763361 68966 0 70029090 0 58343 0 38301796 69635 0 69948678 0 ^C 19:46[p0]root@atlantis#~>netstat -w 1 -I em1 input (em1) output packets errs bytes packets errs bytes colls 67944 0 68877031 55376 0 36252905 0 65943 0 66722222 54575 0 37710643 0 64639 0 67149621 53298 0 35423539 0 63988 0 65035759 51787 0 35402337 0 63849 0 65968513 50727 0 31683425 0 64301 0 66684912 50193 0 30917339 0 ################################################################### How can we solve this problem and parallelize em1:taskq kernel processes between all 8 processors? -- ISP BGNet 288-03-53 246-68-98 Zin'kov Oleg System administrator -- ISP BGNet 288-03-53 246-68-98 Zin'kov Oleg System administrator From linimon at FreeBSD.org Mon Sep 8 01:02:14 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 8 01:02:26 2008 Subject: bin/127192: routed(8) removes the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 Message-ID: <200809080102.m8812EjL091506@freefall.freebsd.org> Old Synopsis: Routed remove the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 New Synopsis: routed(8) removes the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 8 01:01:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127192 From bugmaster at FreeBSD.org Mon Sep 8 02:22:24 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:23:43 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200809080222.m882MOqu006751@freefall.freebsd.org> The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/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/127052 net [if_bridge] Still bridge issues - with L2 protocols su o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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 bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] 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/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 175 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From bugmaster at FreeBSD.org Mon Sep 8 02:23:18 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:24:53 2008 Subject: Current problem reports assigned to net@FreeBSD.org Message-ID: <200809080223.m882NHTQ007811@freefall.freebsd.org> 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 -------------------------------------------------------------------------------- p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS 1 problem total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From thompsa at FreeBSD.org Mon Sep 8 03:20:51 2008 From: thompsa at FreeBSD.org (thompsa@FreeBSD.org) Date: Mon Sep 8 03:20:58 2008 Subject: kern/127052: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE Message-ID: <200809080320.m883Kona015379@freefall.freebsd.org> Synopsis: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE State-Changed-From-To: open->closed State-Changed-By: thompsa State-Changed-When: Mon Sep 8 03:19:43 UTC 2008 State-Changed-Why: r180140 has been reverted for 6.4 and 7.1, thanks for testing and reporting the problems. http://www.freebsd.org/cgi/query-pr.cgi?pr=127052 From pyunyh at gmail.com Mon Sep 8 10:29:20 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Sep 8 10:29:27 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809060803.53293.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <20080906004627.GA69867@cdnetworks.co.kr> <200809060803.53293.freebsd-net@dino.sk> Message-ID: <20080908102912.GI77346@cdnetworks.co.kr> On Sat, Sep 06, 2008 at 08:03:52AM +0200, Milan Obuch wrote: [snip] > It was my pleasure and I would like to express my thanks for your great work. > If you will need in future some more testing with this hardware, just drop me > a line. Just a side note, will this patch be MFS'ed into 7-STABLE in short > timeframe? > As soon as I get re's approval I'll commit to 7-stable. -- Regards, Pyun YongHyeon From freebsd-net at dino.sk Mon Sep 8 10:33:00 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Mon Sep 8 10:33:09 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <20080908102912.GI77346@cdnetworks.co.kr> References: <200809050945.09276.freebsd-net@dino.sk> <200809060803.53293.freebsd-net@dino.sk> <20080908102912.GI77346@cdnetworks.co.kr> Message-ID: <200809081232.43213.freebsd-net@dino.sk> On Monday 08 September 2008 12:29:12 Pyun YongHyeon wrote: > On Sat, Sep 06, 2008 at 08:03:52AM +0200, Milan Obuch wrote: > > [snip] > > > It was my pleasure and I would like to express my thanks for your great > > work. If you will need in future some more testing with this hardware, > > just drop me a line. Just a side note, will this patch be MFS'ed into > > 7-STABLE in short timeframe? > > As soon as I get re's approval I'll commit to 7-stable. Thanks, I can wait a bit with this one. Regards, Milan From _pppp at mail.ru Mon Sep 8 12:41:35 2008 From: _pppp at mail.ru (Dmitriy) Date: Mon Sep 8 12:41:42 2008 Subject: Problem with process parallelization In-Reply-To: <79dc33e3f3737f5beeadce88e96004bc.squirrel@webmail.bg.net.ua> References: <79dc33e3f3737f5beeadce88e96004bc.squirrel@webmail.bg.net.ua> Message-ID: > Hello, freebsd-net mailing list. > > We have server such configurtion: > - 2 quadcore AMD Opteron processors; > - 4 GB RAM; > - NIC Intel Pro/1000 PT, Dual Port Server Adapter. > > ########################################################### > > Problem: > > in some moments of time, at the growth of the network activity, one of > the processors is fully loaded at 100%. > > ########################################################### > > Kernel configuration: > > FreeBSD atlantis.bg.net.ua 7.0-STABLE FreeBSD 7.0-STABLE #1: Tue Apr 1 > 15:06:30 EEST 2008 > root@atlantis.bg.net.ua:/usr/obj/usr/src/sys/ATLANTIS amd64 > > /etc/sysctl.conf: > > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > kern.ipc.somaxconn=16384 > net.inet.ip.fastforwarding=1 > net.inet.ip.maxfragpackets=2000 > net.inet.ip.intr_queue_maxlen=1000 > net.inet.ip.dummynet.hash_size=2048 > net.inet.tcp.recvspace=65536 > net.inet.udp.recvspace=65536 > net.inet.raw.recvspace=32768 > net.local.stream.recvspace=32768 > net.local.dgram.recvspace=32768 > net.local.stream.sendspace=32768 > net.inet.tcp.sendspace=65536 > net.inet.icmp.icmplim=500 > dev.em.0.rx_int_delay=500 > dev.em.0.tx_int_delay=500 > dev.em.0.rx_abs_int_delay=800 > dev.em.0.tx_abs_int_delay=800 > dev.em.1.rx_int_delay=500 > dev.em.1.tx_int_delay=500 > dev.em.1.rx_abs_int_delay=800 > dev.em.1.tx_abs_int_delay=800 > net.link.ether.inet.max_age=600 > > /boot/loader.conf: > > hw.em.rxd=4096 > hw.em.txd=4096 > > /etc/rc.firewall: > > 82 pipes like theese: > > pipe 387 ip from any to 193.227.x.x in recv vlan10 > pipe 388 ip from 193.227.x.x to any out xmit vlan10 > > > ######################################### > Kernel: > > > cpu HAMMER > ident ATLANTIS > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for > devices. > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > symbols > > options SCHED_ULE # 4BSD scheduler > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > #options SCTP # Stream Control Transmission > Protocol > options FFS # Berkeley Fast Filesystem options > SOFTUPDATES # Enable FFS soft updates support options > UFS_ACL # Support for access control lists options > UFS_DIRHASH # Improve performance on big directories > options PROCFS # Process filesystem (requires > PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options > COMPAT_FREEBSD5 # Compatible with FreeBSD5 options > COMPAT_FREEBSD6 # Compatible with FreeBSD6 options KTRACE > # ktrace(1) support > options SYSVSHM # SYSV-style shared memory options > SYSVMSG # SYSV-style message queues options > SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options ADAPTIVE_GIANT # Giant mutex is adaptive. options > STOP_NMI # Stop CPUS using NMI instead of IPI > options AUDIT # Security event auditing > > # Make an SMP-capable kernel by default > options SMP # Symmetric MultiProcessor Kernel > > # Bus support. > device acpi > device pci > > # ATA and ATAPI devices > device ata > > device atadisk # ATA disk drives > options ATA_STATIC_ID # Static device numbering > > # RAID controllers > device twe # 3ware ATA RAID > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console device > sc > > ### COM > device sio > > # PCI Ethernet NICs. > device em # Intel PRO/1000 adapter Gigabit Ethernet > Card > > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these > NICs! device miibus # MII bus support > device bge # Broadcom BCM570xx Gigabit Ethernet > device fxp # Intel EtherExpress PRO/100B (82557, > 82558) > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device pty # Pseudo-ttys (telnet etc) > device vlan > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > ## Custom options > # NetGraph > options NETGRAPH > options NETGRAPH_ONE2MANY > options NETGRAPH_NETFLOW > options NETGRAPH_CISCO > options NETGRAPH_ETHER > options NETGRAPH_KSOCKET > options NETGRAPH_SOCKET > options NETGRAPH_TEE > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_FORWARD > options IPFIREWALL_VERBOSE_LIMIT=1000 > options IPFIREWALL_DEFAULT_TO_ACCEPT > options DUMMYNET > options HZ=1000 > options DEVICE_POLLING > ##################################################### > > Interfaces: > - em0 > - em1 > - bge0 > - bge1 > - vlan (61 virtual interfaces) > > ##################################################### > top -S > > last pid: 9673; load averages: 1.94, 1.75, 1.57 > up 0+19:17:21 > 19:45:01 > 77 processes: 11 running, 49 sleeping, 17 waiting > CPU states: 0.0% user, 0.0% nice, 22.6% system, 0.3% interrupt, 77.0% > idle Mem: 198M Active, 410M Inact, 455M Wired, 228K Cache, 214M Buf, 2874M > Free Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 1 171 ki31 0K 16K CPU7 7 19.0H 100.00% idle: > cpu7 > 16 root 1 171 ki31 0K 16K CPU2 2 18.9H 100.00% idle: > cpu2 > 17 root 1 171 ki31 0K 16K RUN 1 18.8H 100.00% idle: > cpu1 > 13 root 1 171 ki31 0K 16K CPU5 5 18.8H 100.00% idle: > cpu5 > 18 root 1 171 ki31 0K 16K CPU0 0 916:13 100.00% idle: > cpu0 > 12 root 1 171 ki31 0K 16K CPU6 6 18.8H 99.85% idle: > cpu6 > 35 root 1 -68 - 0K 16K CPU4 4 466:17 96.00% em1 > taskq > 34 root 1 -68 - 0K 16K CPU3 3 482:01 90.38% em0 > taskq > 15 root 1 171 ki31 0K 16K RUN 3 655:20 13.38% idle: > cpu3 > 14 root 1 171 ki31 0K 16K RUN 4 671:52 3.08% idle: > cpu4 > > > ############################################## > 19:45[p0]root@atlantis#~>netstat -w 1 -I em0 > input (em0) output > packets errs bytes packets errs bytes colls > 57381 0 36442155 68726 0 69126050 0 > 56817 0 37480502 67656 0 66053093 0 > 57847 0 39532712 68603 0 67037042 0 > 56908 0 37197022 68924 0 68660108 0 > 57107 0 37643382 68398 0 68113937 0 > 56847 0 35944754 68394 0 67896267 0 > 58754 0 39763361 68966 0 70029090 0 > 58343 0 38301796 69635 0 69948678 0 > ^C > 19:46[p0]root@atlantis#~>netstat -w 1 -I em1 > input (em1) output > packets errs bytes packets errs bytes colls > 67944 0 68877031 55376 0 36252905 0 > 65943 0 66722222 54575 0 37710643 0 > 64639 0 67149621 53298 0 35423539 0 > 63988 0 65035759 51787 0 35402337 0 > 63849 0 65968513 50727 0 31683425 0 > 64301 0 66684912 50193 0 30917339 0 > > > > ################################################################### > > > How can we solve this problem and parallelize em1:taskq kernel processes > between all 8 processors? # sysctl net.isr.direct=0 would add one more kernel thread to handle your network traffic. Regards, Dmitriy. > > > -- > ISP BGNet > 288-03-53 > 246-68-98 > > Zin'kov Oleg > System administrator > > > > > > > > > > > > > -- > ISP BGNet > 288-03-53 > 246-68-98 > > Zin'kov Oleg > System administrator > > _______________________________________________ > 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 vova at fbsd.ru Mon Sep 8 14:43:45 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Mon Sep 8 14:43:53 2008 Subject: cvs commit: src/sys/contrib/dev/ath COPYRIGHT README ah.h ah_desc.h ah_devid.h ah_soc.h version.h src/sys/contrib/dev/ath/public alpha-elf.hal.o.uu alpha-elf.inc alpha-elf.opt_ah.h ap30.hal.o.uu ap30.inc ap43.hal.o.uu ap43.inc ... In-Reply-To: <20080903165230.GA31289@alpha.local> References: <200808280023.m7S0NN0B078088@repoman.freebsd.org> <1220382480.2493.5.camel@localhost> <20080903165230.GA31289@alpha.local> Message-ID: <1220883546.4169.13.camel@localhost> On Wed, 2008-09-03 at 17:52 +0100, Rui Paulo wrote: > On Tue, Sep 02, 2008 at 11:08:00PM +0400, Vladimir Grebenschikov wrote: > > ? Thu, 28/08/2008 ? 00:22 +0000, Rui Paulo ?????: > > > rpaulo 2008-08-28 00:22:59 UTC > > > > > > After that commit my wireless stop work: > > Can you tell us your ath mac+phy rev? ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 10.3 phy 6.1 radio 10.2 ether 00:19:7d:8c:0b:44 -- Vladimir B. Grebenschikov vova@fbsd.ru From oleg at FreeBSD.org Mon Sep 8 17:55:36 2008 From: oleg at FreeBSD.org (oleg@FreeBSD.org) Date: Mon Sep 8 17:55:43 2008 Subject: kern/122295: [bge] bge Ierr rate increase (since 6.0R) [regression] Message-ID: <200809081755.m88HtabS029431@freefall.freebsd.org> Synopsis: [bge] bge Ierr rate increase (since 6.0R) [regression] Responsible-Changed-From-To: freebsd-net->oleg Responsible-Changed-By: oleg Responsible-Changed-When: Mon Sep 8 17:54:39 UTC 2008 Responsible-Changed-Why: grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=122295 From gleb.kurtsou at gmail.com Mon Sep 8 20:00:20 2008 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Mon Sep 8 20:00:33 2008 Subject: [patch] gsoc project: improving layer2 filtering Message-ID: <20080908193020.GA37900@rybacik> [Max Laier and Brooks Davis CCed as suggested by Andrew Thompson] This summer I was working on improving layer2 filtering (my mentor is Andrew Thompson) as a google summer of code project. The project was successfully completed. I'd like to ask for a public review of the patch attached. To apply patch (against -CURRENT): cd /usr/src; patch -p0 < gk_l2filter.patch Note, that the patch is not so clean: style(9) issues, stale comments, some inaccurate variable names, etc. But is should be just fine for a general review. I'd like to continue working further to improve it, if community is interested and if there is possibility for it to get commited. I would appreciate any comments and suggestions. Some additional details and examples of new functionality can be found on my blog: http://blogs.freebsdish.org/gleb/ Project's perforce repository: http://perforce.freebsd.org/changeList.cgi?CMD=changes&FSPC=//depot/projects/soc2008/gk%5fl2filter/... To sum it up, following project goals were achieved (old todo list): general: * Implement pfil hooks for filtering ethernet packets * Add mtag containing source and destination layer2 addresses to every mbuf * Add per interface flags: l2filter, l2tag ipfw: * Update ipfw layer2 not to touch ip headers, but to use mentioned mtags to do MAC-IP filtering * Add src-ether and dst-ether ipfw options * Support mac addresses in ipfw lookup tables * Stateful filtering by mac addresses * Implement ARP filtering options * Update documentation pf: * Add stateful filtering against mac addresses. Make it part of present layer3 stateful filtering. * Extend pf's tables facility to contain layer2 address apart with layer3 address. * Support in userspace (pf.conf, pfctl). * Update documentation -------------- next part -------------- A non-text attachment was scrubbed... Name: gk_l2filter.patch Type: text/x-diff Size: 104020 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080908/8ffd3e6c/gk_l2filter-0001.bin From max at love2party.net Mon Sep 8 20:13:37 2008 From: max at love2party.net (Max Laier) Date: Mon Sep 8 20:13:45 2008 Subject: [patch] gsoc project: improving layer2 filtering In-Reply-To: <20080908193020.GA37900@rybacik> References: <20080908193020.GA37900@rybacik> Message-ID: <200809082213.34703.max@love2party.net> On Monday 08 September 2008 21:30:21 Gleb Kurtsou wrote: > [Max Laier and Brooks Davis CCed as suggested by Andrew Thompson] > > This summer I was working on improving layer2 filtering (my mentor is > Andrew Thompson) as a google summer of code project. The project was > successfully completed. Wow! That's one large diff ... unfortunately I don't have much time right now. I'll try to look at the pf changes one of these days, but please re-ping if I don't get to it in a timely manner. For the moment all I can say is that your work is very appreciated and that - from a quick glance - it looks like this could be ready(-ish) for inclusion. In any case we should get the releases out the door before dropping this in current. Again, thanks for your work ... I'll look at it as I find time. > I'd like to ask for a public review of the patch attached. > To apply patch (against -CURRENT): > cd /usr/src; patch -p0 < gk_l2filter.patch > > Note, that the patch is not so clean: style(9) issues, stale comments, > some inaccurate variable names, etc. But is should be just fine for a > general review. I'd like to continue working further to improve it, if > community is interested and if there is possibility for it to get > commited. I would appreciate any comments and suggestions. > > Some additional details and examples of new functionality can be found on > my blog: http://blogs.freebsdish.org/gleb/ > > Project's perforce repository: > http://perforce.freebsd.org/changeList.cgi?CMD=changes&FSPC=//depot/project >s/soc2008/gk%5fl2filter/... > > To sum it up, following project goals were achieved (old todo list): > > general: > * Implement pfil hooks for filtering ethernet packets > * Add mtag containing source and destination layer2 addresses to > every mbuf > * Add per interface flags: l2filter, l2tag > > ipfw: > * Update ipfw layer2 not to touch ip headers, but to use mentioned > mtags to do MAC-IP filtering > * Add src-ether and dst-ether ipfw options > * Support mac addresses in ipfw lookup tables > * Stateful filtering by mac addresses > * Implement ARP filtering options > * Update documentation > > pf: > * Add stateful filtering against mac addresses. Make it part of > present layer3 stateful filtering. > * Extend pf's tables facility to contain layer2 address apart with > layer3 address. > * Support in userspace (pf.conf, pfctl). > * Update documentation -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From onuraslan at gmail.com Tue Sep 9 11:25:53 2008 From: onuraslan at gmail.com (Onur Aslan) Date: Tue Sep 9 11:25:59 2008 Subject: Binary mod_php Message-ID: Hi. I am trying to install a web server to my FreeBSD 7.0-RELEASE. I don't want to compile any packages. I installed apache22 and php5 with pkg_add -r. But there is no mod_php for apache. How can I install mod_php for current installed binary programs? Should I build php5 from /usr/ports? Thanks. From wmoran at collaborativefusion.com Tue Sep 9 12:53:51 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Tue Sep 9 12:53:58 2008 Subject: Binary mod_php In-Reply-To: References: Message-ID: <20080909085349.453d630b.wmoran@collaborativefusion.com> In response to "Onur Aslan" : > > I am trying to install a web server to my FreeBSD 7.0-RELEASE. I don't > want to compile any packages. I installed apache22 and php5 with > pkg_add -r. But there is no mod_php for apache. How can I install > mod_php for current installed binary programs? Should I build php5 > from /usr/ports? The port has the option to build PHP with the module or not, and I believe the default is to _not_ build the Apache module. That would seem to indicate that the packages generated by the build cluster will be built without the Apache module. Anyway, I would suggest building PHP from ports. Do a "make config" first and ensure the apache module is selected. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From ermal.luci at gmail.com Tue Sep 9 15:39:09 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Tue Sep 9 15:39:21 2008 Subject: [patch] gsoc project: improving layer2 filtering In-Reply-To: <20080908193020.GA37900@rybacik> References: <20080908193020.GA37900@rybacik> Message-ID: <9a542da30809090839g4e37c3ddt6b5217a7ec180ebe@mail.gmail.com> On Mon, Sep 8, 2008 at 9:30 PM, Gleb Kurtsou wrote: > [Max Laier and Brooks Davis CCed as suggested by Andrew Thompson] > > This summer I was working on improving layer2 filtering (my mentor is > Andrew Thompson) as a google summer of code project. The project was > successfully completed. > > I'd like to ask for a public review of the patch attached. > To apply patch (against -CURRENT): > cd /usr/src; patch -p0 < gk_l2filter.patch > > Note, that the patch is not so clean: style(9) issues, stale comments, > some inaccurate variable names, etc. But is should be just fine for a > general review. I'd like to continue working further to improve it, if > community is interested and if there is possibility for it to get > commited. I would appreciate any comments and suggestions. > > Some additional details and examples of new functionality can be found on > my blog: http://blogs.freebsdish.org/gleb/ > > Project's perforce repository: http://perforce.freebsd.org/changeList.cgi?CMD=changes&FSPC=//depot/projects/soc2008/gk%5fl2filter/... > > To sum it up, following project goals were achieved (old todo list): > > general: > * Implement pfil hooks for filtering ethernet packets > * Add mtag containing source and destination layer2 addresses to > every mbuf > * Add per interface flags: l2filter, l2tag > > ipfw: > * Update ipfw layer2 not to touch ip headers, but to use mentioned > mtags to do MAC-IP filtering > * Add src-ether and dst-ether ipfw options > * Support mac addresses in ipfw lookup tables > * Stateful filtering by mac addresses > * Implement ARP filtering options > * Update documentation > > pf: > * Add stateful filtering against mac addresses. Make it part of > present layer3 stateful filtering. > * Extend pf's tables facility to contain layer2 address apart with > layer3 address. > * Support in userspace (pf.conf, pfctl). > * Update documentation > Have you done any measurment on the overhead of this? Adding tags to every packet passing might buy some overhead taking in consideration that pf(4) already does this means double overhead for each packet is it worth unifying this tags for filter case?! How about adding to the tags even some other parameters like vlan or COS value when present so one can do some tricks on vlan case or at least shape on COS value? Otherwise path seems ok at first glance and am going to try out soon. -- Ermal From zvonimir.krile at gmail.com Tue Sep 9 16:02:38 2008 From: zvonimir.krile at gmail.com (zvonimir krile) Date: Tue Sep 9 16:02:46 2008 Subject: ip forging Message-ID: <5d86fd060809090846t464ac0f5v8761fe32c0bf3fde@mail.gmail.com> I was wondering if anyone can help me find an application for freebsd that allows me to forge ip packets in whole(header and the data) so that i can inject them later. I actually want to forge OSPF packets as an attack scenario on a network and cannot seem to find anything that would do the trick. Thanks in advance zk From rpaulo at FreeBSD.org Tue Sep 9 16:25:24 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Tue Sep 9 16:25:31 2008 Subject: cvs commit: src/sys/contrib/dev/ath COPYRIGHT README ah.h ah_desc.h ah_devid.h ah_soc.h version.h src/sys/contrib/dev/ath/public alpha-elf.hal.o.uu alpha-elf.inc alpha-elf.opt_ah.h ap30.hal.o.uu ap30.inc ap43.hal.o.uu ap43.inc ... In-Reply-To: <1220883546.4169.13.camel@localhost> References: <200808280023.m7S0NN0B078088@repoman.freebsd.org> <1220382480.2493.5.camel@localhost> <20080903165230.GA31289@alpha.local> <1220883546.4169.13.camel@localhost> Message-ID: <20080909162433.GB35538@alpha.local> On Mon, Sep 08, 2008 at 06:19:06PM +0400, Vladimir Grebenschikov wrote: > On Wed, 2008-09-03 at 17:52 +0100, Rui Paulo wrote: > > On Tue, Sep 02, 2008 at 11:08:00PM +0400, Vladimir Grebenschikov wrote: > > > ? Thu, 28/08/2008 ? 00:22 +0000, Rui Paulo ?????: > > > > rpaulo 2008-08-28 00:22:59 UTC > > > > > > > > > After that commit my wireless stop work: > > > > Can you tell us your ath mac+phy rev? > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 10.3 phy 6.1 radio 10.2 I have a 5212 too and the problem is now fixed in HEAD. Please update. Thanks, -- Rui Paulo From bms at FreeBSD.org Tue Sep 9 16:35:03 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Sep 9 16:35:10 2008 Subject: ip forging In-Reply-To: <5d86fd060809090846t464ac0f5v8761fe32c0bf3fde@mail.gmail.com> References: <5d86fd060809090846t464ac0f5v8761fe32c0bf3fde@mail.gmail.com> Message-ID: <48C6A5B4.5080902@FreeBSD.org> zvonimir krile wrote: > I actually want to forge OSPF packets as an attack scenario > on a network and cannot seem to find anything that would do the trick. > Try pcs.sourceforge.net, you will have to add OSPF support yourself though, I am sure your help there will be very welcome. I started on the BGP packet formats but have far too much else to do to finish. cheers BMS From gleb.kurtsou at gmail.com Tue Sep 9 16:44:31 2008 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Tue Sep 9 16:44:38 2008 Subject: [patch] gsoc project: improving layer2 filtering In-Reply-To: <9a542da30809090839g4e37c3ddt6b5217a7ec180ebe@mail.gmail.com> References: <20080908193020.GA37900@rybacik> <9a542da30809090839g4e37c3ddt6b5217a7ec180ebe@mail.gmail.com> Message-ID: <20080909164406.GA32707@rybacik> On (09/09/2008 17:39), Ermal Lu?i wrote: > On Mon, Sep 8, 2008 at 9:30 PM, Gleb Kurtsou wrote: > > This summer I was working on improving layer2 filtering (my mentor is > > Andrew Thompson) as a google summer of code project. The project was > > successfully completed. [...] > Have you done any measurment on the overhead of this? > Adding tags to every packet passing might buy some overhead taking in > consideration that pf(4) already does this means double overhead for > each packet is it worth unifying this tags for filter case?! No real numbers so far. I did some benchmarking on macfw mac-ip firewall I've developed back in 2006 (should be in net@ archives). macfw itself was to hackish and to simple and also allocated mtag for every packet. I did the tests on pentium2 and pentium3 class machines with 64-256 mb of ram used as routers in 700 host ethernet network. CPU never was a bottleneck, but I've lost the results anyway. And because of performance considerations l2tag interface flag was added, so you mtags are allocated only for packets on desired interface. Using mtag is the right way to do it, imho. Considering unification, I think we are trying to solve not the reason of the problem but its consequence -- mbuf allocation should be made cheap, instead of unifying unrelated mtags. Optimization pf did some time ago (not sure it's in FreeBSD tree), by adding pf fields into mbuf header, is not a solution too, components become more tightly coupled. In case there is an idea on how to speed up mtag allocation I'd like to work on it. > How about adding to the tags even some other parameters like vlan or > COS value when present so one can do some tricks on vlan case or at > least shape on COS value? > > Otherwise path seems ok at first glance and am going to try out soon. > > -- > Ermal From figyshki at gmail.com Tue Sep 9 17:20:08 2008 From: figyshki at gmail.com (=?KOI8-R?B?7sUg5MHN09E=?=) Date: Tue Sep 9 17:20:38 2008 Subject: kern/127102: [wpi] Intel 3945ABG low throughput Message-ID: <200809091720.m89HK7cg091754@freefall.freebsd.org> The following reply was made to PR kern/127102; it has been noted by GNATS. From: "=?KOI8-R?B?7sUg5MHN09E=?=" To: bug-followup@freebsd.org Cc: Subject: Re: kern/127102: [wpi] Intel 3945ABG low throughput Date: Tue, 9 Sep 2008 13:15:29 -0400 ------=_Part_24971_5426585.1220980530002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Curious discovery. Similar behavior (slow throughput) is experienced under Windows on battery power, but not on AC power. Under FreeBSD, the behavior is experienced under AC power or battery power. ------=_Part_24971_5426585.1220980530002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Curious discovery. Similar behavior (slow throughput) is experienced under Windows on battery power, but not on AC power. Under FreeBSD, the behavior is experienced under AC power or battery power.
------=_Part_24971_5426585.1220980530002-- From keramida at freebsd.org Tue Sep 9 22:00:19 2008 From: keramida at freebsd.org (Giorgos Keramidas) Date: Tue Sep 9 22:00:25 2008 Subject: rewrite of rt_check() (now rt_check_fib()) In-Reply-To: <48C1BD31.6090804@elischer.org> (Julian Elischer's message of "Fri, 05 Sep 2008 16:13:53 -0700") References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> <48C1B83C.9000404@elischer.org> <48C1BD31.6090804@elischer.org> Message-ID: <87y721go6i.fsf@kobe.laptop> Hi Julian. Has anyone else tested this patch? I'm going to have a bit of time to try reproducing this again in the following days. Is this patch version the last one you have written? Should I patch with this one and give it a try? FWIW, reading through this version of rt_check_fib() is nicer, and I really liked the comment that explains how it works :-) On Fri, 05 Sep 2008 16:13:53 -0700, Julian Elischer wrote: > this time with less (I hope) bugs... > > new macros... > > #define RT_TEMP_UNLOCK(_rt) do { \ > RT_ADDREF(_rt); \ > RT_UNLOCK(_rt); \ > } while (0) > > #define RT_RELOCK(_rt) do { \ > RT_LOCK(_rt) \ > if ((_rt)->rt_refcnt <= 1) \ > rtfree(_rt); \ > _rt = 0; /* signal that it went away */ \ > else { \ > RT_REMREF(_rt); \ > /* note that _rt is still valid */ \ > } \ > } while (0) > > > with (better) code attached: > > /* > * rt_check() is invoked on each layer 2 output path, prior to > * encapsulating outbound packets. > * > * The function is mostly used to find a routing entry for the gateway, > * which in some protocol families could also point to the link-level > * address for the gateway itself (the side effect of revalidating the > * route to the destination is rather pointless at this stage, we did it > * already a moment before in the pr_output() routine to locate the ifp > * and gateway to use). > * > * When we remove the layer-3 to layer-2 mapping tables from the > * routing table, this function can be removed. > * > * === On input === > * *dst is the address of the NEXT HOP (which coincides with the > * final destination if directly reachable); > * *lrt0 points to the cached route to the final destination; > * *lrt is not meaningful; > * fibnum is the index to the correct network fib for this packet > * (*lrt0 has not ref held on it so REMREF is not needed ) > * > * === Operation === > * If the route is marked down try to find a new route. If the route > * to the gateway is gone, try to setup a new route. Otherwise, > * if the route is marked for packets to be rejected, enforce that. > * Note that rtalloc returns an rtentry with an extra REF that we need to lose. > * > * === On return === > * *dst is unchanged; > * *lrt0 points to the (possibly new) route to the final destination > * *lrt points to the route to the next hop [LOCKED] > * > * Their values are meaningful ONLY if no error is returned. > * > * To follow this you have to remember that: > * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) > * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) > * and an RT_UNLOCK > * RTFREE does an RT_LOCK and an RTFREE_LOCKED > * The gwroute pointer counts as a reference on the rtentry to which it points. > * so when we add it we use the ref that rtalloc gives us and when we lose it > * we need to remove the reference. > */ > int > rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) > { > return (rt_check_fib(lrt, lrt0, dst, 0)); > } > > int > rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, > u_int fibnum) > { > struct rtentry *rt; > struct rtentry *rt0; > int error; > > KASSERT(*lrt0 != NULL, ("rt_check")); > rt0 = *lrt0; > rt = NULL; > > /* NB: the locking here is tortuous... */ > RT_LOCK(rt0); > retry: > if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { > /* Current rt0 is useless, try get a replacement. */ > RT_UNLOCK(rt0); > rt0 = NULL; > } > if (rt0 == NULL) { > rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); > if (rt0 == NULL) { > return (EHOSTUNREACH); > } > RT_REMREF(rt0); /* don't need the reference. */ > } > > if (rt0->rt_flags & RTF_GATEWAY) { > if ((rt = rt0->rt_gwroute) != NULL) { > RT_LOCK(rt); /* NB: gwroute */ > if ((rt->rt_flags & RTF_UP) == 0) { > /* gw route is dud. ignore/lose it */ > RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ > rt = rt0->rt_gwroute = NULL; > } > } > > if (rt == NULL) { /* NOT AN ELSE CLAUSE */ > RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ > rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); > if ((rt == rt0) || (rt == NULL)) { > /* the best we can do is not good enough */ > if (rt) { > RT_REMREF(rt); /* assumes ref > 0 */ > RT_UNLOCK(rt); > } > RT_FREE(rt0); /* lock, unref, (unlock) */ > return (ENETUNREACH); > } > /* > * Relock it and lose the added reference. > * All sorts of things could have happenned while we > * had no lock on it, so check for them. > */ > RT_RELOCK(rt0); > if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) > /* Ru-roh.. what we had is no longer any good */ > goto retry; > /* > * While we were away, someone replaced the gateway. > * Since a reference count is involved we can't just > * overwrite it. > */ > if (rt0->rt_gwroute) { > if (rt0->rt_gwroute != rt) { > RT_FREE_LOCKED(rt); > goto retry; > } > } else { > rt0->rt_gwroute = rt; > } > } > RT_LOCK_ASSERT(rt); > RT_UNLOCK(rt0); > } else { > /* think of rt as having the lock from now on.. */ > rt = rt0; > } > /* XXX why are we inspecting rmx_expire? */ > if ((rt->rt_flags & RTF_REJECT) && > (rt->rt_rmx.rmx_expire == 0 || > time_uptime < rt->rt_rmx.rmx_expire)) { > RT_UNLOCK(rt); > return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); > } > > *lrt = rt; > *lrt0 = rt0; > return (0); > } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080909/75f9d603/attachment.pgp From bms at incunabulum.net Tue Sep 9 23:50:54 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue Sep 9 23:51:02 2008 Subject: Problem with IFDATA_DRIVERNAME sysctl Message-ID: <48C70743.1020003@incunabulum.net> Whenever I call this sysctl, I get an errno of EPROGNOTAVAIL from sysctl(): ????????name[0] = CTL_NET; ????????name[1] = PF_LINK; ????????name[2] = NETLINK_GENERIC; ????????name[3] = IFMIB_IFDATA; ????????name[4] = ifindex; ????????name[5] = IFDATA_DRIVERNAME; ????????len = IFNAMSIZ; ????????if (sysctl(name, 6, dname, &len, NULL, 0) == -1) { ????????????????warnc(EX_OSERR, "cannot obtain driver name for ifname %s", ???????????????? ifname); ????????????????return (-1); ????????} The ifindex is valid. "dname" is a pointer to an IFNAMSIZ sized buffer. This problem is happening on a 7.0-RELEASE system. It looks like the switch..case in that path could be fubar'd by the compiler as there are not break statements for each distinct case label, could this be due to gcc friendly fire? cheers BMS From bms at FreeBSD.org Wed Sep 10 00:13:35 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 10 00:13:42 2008 Subject: Problem with IFDATA_DRIVERNAME sysctl In-Reply-To: <48C70743.1020003@incunabulum.net> References: <48C70743.1020003@incunabulum.net> Message-ID: <48C7112D.3070309@FreeBSD.org> Bruce M Simpson wrote: > > It looks like the switch..case in that path could be fubar'd by the > compiler as there are not break statements for each distinct case > label, could this be due to gcc friendly fire? Possibly false alarm or PEBKAC, I wasn't checking return values right in some of my code, although we should probably have "break" there anyway. Patch against RELENG_7_0. -------------- next part -------------- --- if_mib.c.orig 2008-09-10 00:31:25.000000000 +0100 +++ if_mib.c 2008-09-10 00:32:15.000000000 +0100 @@ -90,6 +90,7 @@ switch(name[1]) { default: return ENOENT; + break; case IFDATA_GENERAL: bzero(&ifmd, sizeof(ifmd)); @@ -136,6 +137,7 @@ error = SYSCTL_IN(req, ifp->if_linkmib, ifp->if_linkmiblen); if (error) return error; + break; case IFDATA_DRIVERNAME: /* 20 is enough for 64bit ints */ @@ -152,6 +154,7 @@ error = EPERM; free(dbuf, M_TEMP); return (error); + break; } return 0; } From julian at elischer.org Wed Sep 10 00:25:17 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 10 00:25:24 2008 Subject: rewrite of rt_check() (now rt_check_fib()) In-Reply-To: <87y721go6i.fsf@kobe.laptop> References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> <48C1B83C.9000404@elischer.org> <48C1BD31.6090804@elischer.org> <87y721go6i.fsf@kobe.laptop> Message-ID: <48C713F9.7010500@elischer.org> Giorgos Keramidas wrote: > Hi Julian. > > Has anyone else tested this patch? I'm going to have a bit of time to > try reproducing this again in the following days. Is this patch version > the last one you have written? Should I patch with this one and give it > a try? I think this was the last one. > > FWIW, reading through this version of rt_check_fib() is nicer, and I > really liked the comment that explains how it works :-) > > On Fri, 05 Sep 2008 16:13:53 -0700, Julian Elischer wrote: >> this time with less (I hope) bugs... >> >> new macros... >> >> #define RT_TEMP_UNLOCK(_rt) do { \ >> RT_ADDREF(_rt); \ >> RT_UNLOCK(_rt); \ >> } while (0) >> >> #define RT_RELOCK(_rt) do { \ >> RT_LOCK(_rt) \ >> if ((_rt)->rt_refcnt <= 1) \ >> rtfree(_rt); \ >> _rt = 0; /* signal that it went away */ \ >> else { \ >> RT_REMREF(_rt); \ >> /* note that _rt is still valid */ \ >> } \ >> } while (0) >> >> >> with (better) code attached: >> >> /* >> * rt_check() is invoked on each layer 2 output path, prior to >> * encapsulating outbound packets. >> * >> * The function is mostly used to find a routing entry for the gateway, >> * which in some protocol families could also point to the link-level >> * address for the gateway itself (the side effect of revalidating the >> * route to the destination is rather pointless at this stage, we did it >> * already a moment before in the pr_output() routine to locate the ifp >> * and gateway to use). >> * >> * When we remove the layer-3 to layer-2 mapping tables from the >> * routing table, this function can be removed. >> * >> * === On input === >> * *dst is the address of the NEXT HOP (which coincides with the >> * final destination if directly reachable); >> * *lrt0 points to the cached route to the final destination; >> * *lrt is not meaningful; >> * fibnum is the index to the correct network fib for this packet >> * (*lrt0 has not ref held on it so REMREF is not needed ) >> * >> * === Operation === >> * If the route is marked down try to find a new route. If the route >> * to the gateway is gone, try to setup a new route. Otherwise, >> * if the route is marked for packets to be rejected, enforce that. >> * Note that rtalloc returns an rtentry with an extra REF that we need to lose. >> * >> * === On return === >> * *dst is unchanged; >> * *lrt0 points to the (possibly new) route to the final destination >> * *lrt points to the route to the next hop [LOCKED] >> * >> * Their values are meaningful ONLY if no error is returned. >> * >> * To follow this you have to remember that: >> * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) >> * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) >> * and an RT_UNLOCK >> * RTFREE does an RT_LOCK and an RTFREE_LOCKED >> * The gwroute pointer counts as a reference on the rtentry to which it points. >> * so when we add it we use the ref that rtalloc gives us and when we lose it >> * we need to remove the reference. >> */ >> int >> rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) >> { >> return (rt_check_fib(lrt, lrt0, dst, 0)); >> } >> >> int >> rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, >> u_int fibnum) >> { >> struct rtentry *rt; >> struct rtentry *rt0; >> int error; >> >> KASSERT(*lrt0 != NULL, ("rt_check")); >> rt0 = *lrt0; >> rt = NULL; >> >> /* NB: the locking here is tortuous... */ >> RT_LOCK(rt0); >> retry: >> if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { >> /* Current rt0 is useless, try get a replacement. */ >> RT_UNLOCK(rt0); >> rt0 = NULL; >> } >> if (rt0 == NULL) { >> rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); >> if (rt0 == NULL) { >> return (EHOSTUNREACH); >> } >> RT_REMREF(rt0); /* don't need the reference. */ >> } >> >> if (rt0->rt_flags & RTF_GATEWAY) { >> if ((rt = rt0->rt_gwroute) != NULL) { >> RT_LOCK(rt); /* NB: gwroute */ >> if ((rt->rt_flags & RTF_UP) == 0) { >> /* gw route is dud. ignore/lose it */ >> RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ >> rt = rt0->rt_gwroute = NULL; >> } >> } >> >> if (rt == NULL) { /* NOT AN ELSE CLAUSE */ >> RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ >> rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); >> if ((rt == rt0) || (rt == NULL)) { >> /* the best we can do is not good enough */ >> if (rt) { >> RT_REMREF(rt); /* assumes ref > 0 */ >> RT_UNLOCK(rt); >> } >> RT_FREE(rt0); /* lock, unref, (unlock) */ >> return (ENETUNREACH); >> } >> /* >> * Relock it and lose the added reference. >> * All sorts of things could have happenned while we >> * had no lock on it, so check for them. >> */ >> RT_RELOCK(rt0); >> if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) >> /* Ru-roh.. what we had is no longer any good */ >> goto retry; >> /* >> * While we were away, someone replaced the gateway. >> * Since a reference count is involved we can't just >> * overwrite it. >> */ >> if (rt0->rt_gwroute) { >> if (rt0->rt_gwroute != rt) { >> RT_FREE_LOCKED(rt); >> goto retry; >> } >> } else { >> rt0->rt_gwroute = rt; >> } >> } >> RT_LOCK_ASSERT(rt); >> RT_UNLOCK(rt0); >> } else { >> /* think of rt as having the lock from now on.. */ >> rt = rt0; >> } >> /* XXX why are we inspecting rmx_expire? */ >> if ((rt->rt_flags & RTF_REJECT) && >> (rt->rt_rmx.rmx_expire == 0 || >> time_uptime < rt->rt_rmx.rmx_expire)) { >> RT_UNLOCK(rt); >> return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); >> } >> >> *lrt = rt; >> *lrt0 = rt0; >> return (0); >> } From julian at elischer.org Wed Sep 10 00:27:58 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 10 00:28:04 2008 Subject: rewrite of rt_check() (now rt_check_fib()) In-Reply-To: <87y721go6i.fsf@kobe.laptop> References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> <48C1B83C.9000404@elischer.org> <48C1BD31.6090804@elischer.org> <87y721go6i.fsf@kobe.laptop> Message-ID: <48C7149A.7040304@elischer.org> Giorgos Keramidas wrote: > Hi Julian. > > Has anyone else tested this patch? I'm going to have a bit of time to > try reproducing this again in the following days. Is this patch version > the last one you have written? Should I patch with this one and give it > a try? no one else has.. which seems strange given that several people got hit by the problem. I think that while removing the quick crash, the underlying problem is somewhere else. > > FWIW, reading through this version of rt_check_fib() is nicer, and I > really liked the comment that explains how it works :-) > > On Fri, 05 Sep 2008 16:13:53 -0700, Julian Elischer wrote: >> this time with less (I hope) bugs... >> >> new macros... >> >> #define RT_TEMP_UNLOCK(_rt) do { \ >> RT_ADDREF(_rt); \ >> RT_UNLOCK(_rt); \ >> } while (0) >> >> #define RT_RELOCK(_rt) do { \ >> RT_LOCK(_rt) \ >> if ((_rt)->rt_refcnt <= 1) \ >> rtfree(_rt); \ >> _rt = 0; /* signal that it went away */ \ >> else { \ >> RT_REMREF(_rt); \ >> /* note that _rt is still valid */ \ >> } \ >> } while (0) >> >> >> with (better) code attached: >> >> /* >> * rt_check() is invoked on each layer 2 output path, prior to >> * encapsulating outbound packets. >> * >> * The function is mostly used to find a routing entry for the gateway, >> * which in some protocol families could also point to the link-level >> * address for the gateway itself (the side effect of revalidating the >> * route to the destination is rather pointless at this stage, we did it >> * already a moment before in the pr_output() routine to locate the ifp >> * and gateway to use). >> * >> * When we remove the layer-3 to layer-2 mapping tables from the >> * routing table, this function can be removed. >> * >> * === On input === >> * *dst is the address of the NEXT HOP (which coincides with the >> * final destination if directly reachable); >> * *lrt0 points to the cached route to the final destination; >> * *lrt is not meaningful; >> * fibnum is the index to the correct network fib for this packet >> * (*lrt0 has not ref held on it so REMREF is not needed ) >> * >> * === Operation === >> * If the route is marked down try to find a new route. If the route >> * to the gateway is gone, try to setup a new route. Otherwise, >> * if the route is marked for packets to be rejected, enforce that. >> * Note that rtalloc returns an rtentry with an extra REF that we need to lose. >> * >> * === On return === >> * *dst is unchanged; >> * *lrt0 points to the (possibly new) route to the final destination >> * *lrt points to the route to the next hop [LOCKED] >> * >> * Their values are meaningful ONLY if no error is returned. >> * >> * To follow this you have to remember that: >> * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) >> * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) >> * and an RT_UNLOCK >> * RTFREE does an RT_LOCK and an RTFREE_LOCKED >> * The gwroute pointer counts as a reference on the rtentry to which it points. >> * so when we add it we use the ref that rtalloc gives us and when we lose it >> * we need to remove the reference. >> */ >> int >> rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) >> { >> return (rt_check_fib(lrt, lrt0, dst, 0)); >> } >> >> int >> rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, >> u_int fibnum) >> { >> struct rtentry *rt; >> struct rtentry *rt0; >> int error; >> >> KASSERT(*lrt0 != NULL, ("rt_check")); >> rt0 = *lrt0; >> rt = NULL; >> >> /* NB: the locking here is tortuous... */ >> RT_LOCK(rt0); >> retry: >> if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { >> /* Current rt0 is useless, try get a replacement. */ >> RT_UNLOCK(rt0); >> rt0 = NULL; >> } >> if (rt0 == NULL) { >> rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); >> if (rt0 == NULL) { >> return (EHOSTUNREACH); >> } >> RT_REMREF(rt0); /* don't need the reference. */ >> } >> >> if (rt0->rt_flags & RTF_GATEWAY) { >> if ((rt = rt0->rt_gwroute) != NULL) { >> RT_LOCK(rt); /* NB: gwroute */ >> if ((rt->rt_flags & RTF_UP) == 0) { >> /* gw route is dud. ignore/lose it */ >> RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ >> rt = rt0->rt_gwroute = NULL; >> } >> } >> >> if (rt == NULL) { /* NOT AN ELSE CLAUSE */ >> RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ >> rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); >> if ((rt == rt0) || (rt == NULL)) { >> /* the best we can do is not good enough */ >> if (rt) { >> RT_REMREF(rt); /* assumes ref > 0 */ >> RT_UNLOCK(rt); >> } >> RT_FREE(rt0); /* lock, unref, (unlock) */ >> return (ENETUNREACH); >> } >> /* >> * Relock it and lose the added reference. >> * All sorts of things could have happenned while we >> * had no lock on it, so check for them. >> */ >> RT_RELOCK(rt0); >> if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) >> /* Ru-roh.. what we had is no longer any good */ >> goto retry; >> /* >> * While we were away, someone replaced the gateway. >> * Since a reference count is involved we can't just >> * overwrite it. >> */ >> if (rt0->rt_gwroute) { >> if (rt0->rt_gwroute != rt) { >> RT_FREE_LOCKED(rt); >> goto retry; >> } >> } else { >> rt0->rt_gwroute = rt; >> } >> } >> RT_LOCK_ASSERT(rt); >> RT_UNLOCK(rt0); >> } else { >> /* think of rt as having the lock from now on.. */ >> rt = rt0; >> } >> /* XXX why are we inspecting rmx_expire? */ >> if ((rt->rt_flags & RTF_REJECT) && >> (rt->rt_rmx.rmx_expire == 0 || >> time_uptime < rt->rt_rmx.rmx_expire)) { >> RT_UNLOCK(rt); >> return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); >> } >> >> *lrt = rt; >> *lrt0 = rt0; >> return (0); >> } From brooks at freebsd.org Wed Sep 10 00:35:47 2008 From: brooks at freebsd.org (Brooks Davis) Date: Wed Sep 10 00:35:56 2008 Subject: Problem with IFDATA_DRIVERNAME sysctl In-Reply-To: <48C7112D.3070309@FreeBSD.org> References: <48C70743.1020003@incunabulum.net> <48C7112D.3070309@FreeBSD.org> Message-ID: <20080910003637.GB34060@lor.one-eyed-alien.net> On Wed, Sep 10, 2008 at 01:13:33AM +0100, Bruce M. Simpson wrote: > Bruce M Simpson wrote: >> >> It looks like the switch..case in that path could be fubar'd by the >> compiler as there are not break statements for each distinct case label, >> could this be due to gcc friendly fire? > > Possibly false alarm or PEBKAC, I wasn't checking return values right in > some of my code, although we should probably have "break" there anyway. > > Patch against RELENG_7_0. > --- if_mib.c.orig 2008-09-10 00:31:25.000000000 +0100 > +++ if_mib.c 2008-09-10 00:32:15.000000000 +0100 > @@ -90,6 +90,7 @@ > switch(name[1]) { > default: > return ENOENT; > + break; That's clearly a no-op since it's unreachable. > case IFDATA_GENERAL: > bzero(&ifmd, sizeof(ifmd)); > @@ -136,6 +137,7 @@ > error = SYSCTL_IN(req, ifp->if_linkmib, ifp->if_linkmiblen); > if (error) > return error; > + break; This looks OK, but I haven't checked the context. > > case IFDATA_DRIVERNAME: > /* 20 is enough for 64bit ints */ > @@ -152,6 +154,7 @@ > error = EPERM; > free(dbuf, M_TEMP); > return (error); > + break; This is also a no-op. --Brooks > } > return 0; > } > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080910/8d36f488/attachment.pgp From linimon at FreeBSD.org Wed Sep 10 08:40:58 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Sep 10 08:41:10 2008 Subject: kern/127266: [gif] gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address Message-ID: <200809100840.m8A8eweX007181@freefall.freebsd.org> Old Synopsis: gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address New Synopsis: [gif] gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 10 08:40:35 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127266 From bms at FreeBSD.org Wed Sep 10 12:23:43 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 10 12:23:49 2008 Subject: Problem with IFDATA_DRIVERNAME sysctl In-Reply-To: <20080910003637.GB34060@lor.one-eyed-alien.net> References: <48C70743.1020003@incunabulum.net> <48C7112D.3070309@FreeBSD.org> <20080910003637.GB34060@lor.one-eyed-alien.net> Message-ID: <48C7BC4C.4090106@FreeBSD.org> Brooks Davis wrote: > >> --- if_mib.c.orig 2008-09-10 00:31:25.000000000 +0100 >> +++ if_mib.c 2008-09-10 00:32:15.000000000 +0100 >> @@ -90,6 +90,7 @@ >> switch(name[1]) { >> default: >> return ENOENT; >> + break; >> > > That's clearly a no-op since it's unreachable. > > >> case IFDATA_GENERAL: >> bzero(&ifmd, sizeof(ifmd)); >> @@ -136,6 +137,7 @@ >> error = SYSCTL_IN(req, ifp->if_linkmib, ifp->if_linkmiblen); >> if (error) >> return error; >> + break; >> > > This looks OK, but I haven't checked the context. > It looks like an unintentional fall-through to case IFDATA_DRIVERNAME, so I'll commit that part. From tom at tomjudge.com Wed Sep 10 17:19:45 2008 From: tom at tomjudge.com (Tom Judge) Date: Wed Sep 10 17:19:53 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 In-Reply-To: <48BE84B0.3080603@FreeBSD.org> References: <200809021542.m82Fg9GK087484@aurora.sol.net> <48BD71DD.10707@FreeBSD.org> <48BE84B0.3080603@FreeBSD.org> Message-ID: <48C7FCED.2030108@tomjudge.com> Bruce M. Simpson wrote: > Bruce M. Simpson wrote: >> >> I understand that this situation has dragged on for some 18 months >> since changes went into 7.x. I'm sorry to hear about the problems >> you're having. I can't speak for Quagga as I haven't worked on it in >> many years, nor can I speak for the Quagga patch. >> > > I looked at the sockopt.c.diff patch briefly last night on my free > time. It is a quick and dirty bandaid by the looks of it which just > munges the socket options. It may "work for you", I haven't tested it > as I don't run Quagga. > > BTW: The RFC 1724 hack was never actually documented, so code which > relies on it is buggy and needs to be fixed. I published a patch for > routed here nearly 18 months ago, which is probably where Quagga > picked up the hack from. The patch works for us in production, we currently have 6 routers running the patch with ~30 interfaces each. Tom J From jdw at wheelhouse.org Wed Sep 10 19:30:05 2008 From: jdw at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 10 19:30:12 2008 Subject: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Message-ID: <200809101930.m8AJU5v2063748@freefall.freebsd.org> The following reply was made to PR kern/127050; it has been noted by GNATS. From: Jeff Wheelhouse To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Date: Wed, 10 Sep 2008 15:02:00 -0400 I am experiencing the identical behavior on the following releases: 6.3-RELEASE-p4 6.4-PRERELEASE (as of Sep 6) I have reproduced the problem on both amd64 and i386, on both physical interfaces and VLAN interfaces. The problem is the same: - two machines, both configured correctly - both machines can ping6 each other - carp configures correctly, and announcements are observed on the relevant LAN via tcpdump - one machine goes to MASTER and one goes to BACKUP - an additional machine on the same LAN can ping6 both machines - none of the three machines can ping (or route through) the CARP IPv6 address However, I'm *assuming* these are the CARP announcements (since they are from the right IPv6 addresses and MASTER/BACKUP status seems to work: 11:54:51.818511 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 11:54:52.855924 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 11:54:53.893300 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 11:54:54.930386 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 11:54:55.967965 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 11:54:57.004987 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 11:54:58.042481 IP6 A:B:C:D::1 > ff02::12: ip-proto-112 36 I would be happy to help troubleshoot this problem in any way possible. Thanks, Jeff From julian at elischer.org Thu Sep 11 20:08:19 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 11 20:08:31 2008 Subject: anyone have a netgraph node to do ipfw filtering? Message-ID: <48C97AB3.6040907@elischer.org> I think someone sent me a link to an ng_ipfw_filter node once but I've lost it... (I think it was called ng_ipfw but that name is now taken by the netgraph/ipfw 'ipfw netgraph' packet divert option). Something that lets you do ipfw filtering on packets as they travel across a graph. As I said,I've seen one but lost it... Julian From vova at fbsd.ru Thu Sep 11 21:12:41 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Thu Sep 11 21:12:47 2008 Subject: cvs commit: src/sys/contrib/dev/ath COPYRIGHT README ah.h ah_desc.h ah_devid.h ah_soc.h version.h src/sys/contrib/dev/ath/public alpha-elf.hal.o.uu alpha-elf.inc alpha-elf.opt_ah.h ap30.hal.o.uu ap30.inc ap43.hal.o.uu ap43.inc ... In-Reply-To: <20080909162433.GB35538@alpha.local> References: <200808280023.m7S0NN0B078088@repoman.freebsd.org> <1220382480.2493.5.camel@localhost> <20080903165230.GA31289@alpha.local> <1220883546.4169.13.camel@localhost> <20080909162433.GB35538@alpha.local> Message-ID: <1221167555.2276.17.camel@localhost> On Tue, 2008-09-09 at 17:24 +0100, Rui Paulo wrote: > On Mon, Sep 08, 2008 at 06:19:06PM +0400, Vladimir Grebenschikov wrote: > > On Wed, 2008-09-03 at 17:52 +0100, Rui Paulo wrote: > > > On Tue, Sep 02, 2008 at 11:08:00PM +0400, Vladimir Grebenschikov wrote: > > > > ? Thu, 28/08/2008 ? 00:22 +0000, Rui Paulo ?????: > > > > > rpaulo 2008-08-28 00:22:59 UTC > > > > > > > > > > > > After that commit my wireless stop work: > > > > > > Can you tell us your ath mac+phy rev? > > > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > > RF5413) > > ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > > pci3 > > ath0: [ITHREAD] > > ath0: WARNING: using obsoleted if_watchdog interface > > ath0: mac 10.3 phy 6.1 radio 10.2 > > I have a 5212 too and the problem is now fixed in HEAD. Please update. Yes, it works now, thank you. > Thanks, -- Vladimir B. Grebenschikov vova@fbsd.ru From bzeeb-lists at lists.zabbadoz.net Fri Sep 12 05:50:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Sep 12 05:50:15 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <48C97AB3.6040907@elischer.org> References: <48C97AB3.6040907@elischer.org> Message-ID: <20080912054832.Q65801@maildrop.int.zabbadoz.net> On Thu, 11 Sep 2008, Julian Elischer wrote: Hi, > I think someone sent me a link to an ng_ipfw_filter node once > but I've lost it... > > (I think it was called ng_ipfw but that name is now taken by the > netgraph/ipfw 'ipfw netgraph' packet divert option). > > Something that lets you do ipfw filtering on packets as they > travel across a graph. > > As I said,I've seen one but lost it... I could be wrong but did you mean? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_ipfw.c -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Fri Sep 12 06:12:31 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 12 06:12:37 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912054832.Q65801@maildrop.int.zabbadoz.net> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> Message-ID: <48CA084D.1050406@elischer.org> Bjoern A. Zeeb wrote: > On Thu, 11 Sep 2008, Julian Elischer wrote: > > Hi, > >> I think someone sent me a link to an ng_ipfw_filter node once >> but I've lost it... >> >> (I think it was called ng_ipfw but that name is now taken by the >> netgraph/ipfw 'ipfw netgraph' packet divert option). >> >> Something that lets you do ipfw filtering on packets as they >> travel across a graph. >> >> As I said,I've seen one but lost it... > > I could be wrong but did you mean? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_ipfw.c > no that's the one I refer to in themail wiich is the inverse of what I want that one allows ipfw to send things to netgraph. I want one to allow a netgraph graph to filter things with ipfw... From bzeeb-lists at lists.zabbadoz.net Fri Sep 12 06:15:06 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Sep 12 06:15:13 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912054832.Q65801@maildrop.int.zabbadoz.net> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> Message-ID: <20080912061314.H65801@maildrop.int.zabbadoz.net> On Fri, 12 Sep 2008, Bjoern A. Zeeb wrote: > On Thu, 11 Sep 2008, Julian Elischer wrote: > > Hi, > >> I think someone sent me a link to an ng_ipfw_filter node once >> but I've lost it... >> >> (I think it was called ng_ipfw but that name is now taken by the >> netgraph/ipfw 'ipfw netgraph' packet divert option). >> >> Something that lets you do ipfw filtering on packets as they >> travel across a graph. >> >> As I said,I've seen one but lost it... > > I could be wrong but did you mean? baeh, ignore this... -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From eugen at kuzbass.ru Fri Sep 12 06:16:37 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 12 06:16:44 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <48CA084D.1050406@elischer.org> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> <48CA084D.1050406@elischer.org> Message-ID: <20080912061628.GA46340@svzserv.kemerovo.su> On Thu, Sep 11, 2008 at 11:12:29PM -0700, Julian Elischer wrote: > that one allows ipfw to send things to netgraph. I want one > to allow a netgraph graph to filter things with ipfw... ng_bpf? not exactly ipfw filtering, but filtering :-) Eugene Grosbein From andrew at modulus.org Fri Sep 12 06:17:32 2008 From: andrew at modulus.org (Andrew Snow) Date: Fri Sep 12 06:18:03 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912054832.Q65801@maildrop.int.zabbadoz.net> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> Message-ID: <48CA0952.50804@modulus.org> I think what you ask can be done by: 1. sending the packet through ng_mbuf to tag it 2. sending it to ng_ipfw to be sent through IPFW 3. use IPFW rules to operate on packets with the particular tag you attached in #1 4. as the final IPFW rule, pass the packet back in to netgraph via a 'netgraph' IPFW rule. I have not tried this, no idea if it would work Best of luck! :-) - Andrew From julian at elischer.org Fri Sep 12 06:48:51 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 12 06:48:57 2008 Subject: anyone have a netgraph node to do ipfw filtering? In-Reply-To: <20080912061628.GA46340@svzserv.kemerovo.su> References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> <48CA084D.1050406@elischer.org> <20080912061628.GA46340@svzserv.kemerovo.su> Message-ID: <48CA10D2.4040807@elischer.org> Eugene Grosbein wrote: > On Thu, Sep 11, 2008 at 11:12:29PM -0700, Julian Elischer wrote: > >> that one allows ipfw to send things to netgraph. I want one >> to allow a netgraph graph to filter things with ipfw... > > ng_bpf? not exactly ipfw filtering, but filtering :-) > No it needs to be ifpw for the job I'm doing..there is already a lot of code that manipulate ipfw rules that I want to reuse. (heavy use of tables etc.). From eugen at kuzbass.ru Fri Sep 12 06:56:03 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 12 06:56:10 2008 Subject: anyone have a netgraph node to do ipfw filtering? References: <48C97AB3.6040907@elischer.org> <20080912054832.Q65801@maildrop.int.zabbadoz.net> <48CA084D.1050406@elischer.org> <20080912061628.GA46340@svzserv.kemerovo.su> <48CA10D2.4040807@elischer.org> Message-ID: <48CA127E.9BDA9C22@kuzbass.ru> Julian Elischer wrote: > >> that one allows ipfw to send things to netgraph. I want one > >> to allow a netgraph graph to filter things with ipfw... > > > > ng_bpf? not exactly ipfw filtering, but filtering :-) > > No it needs to be ifpw for the job I'm doing..there is already a lot > of code that manipulate ipfw rules that I want to reuse. > (heavy use of tables etc.). I think there is no such node at present, I did some search recently. From edwin at mavetju.org Fri Sep 12 10:20:06 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Fri Sep 12 10:20:13 2008 Subject: misc/127266: gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address Message-ID: <200809121020.m8CAK6UP051253@freefall.freebsd.org> The following reply was made to PR kern/127266; it has been noted by GNATS. From: Edwin Groothuis To: Serg Livitin Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/127266: gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address Date: Fri, 12 Sep 2008 20:10:50 +1000 On Wed, Sep 10, 2008 at 08:39:35AM +0000, Serg Livitin wrote: > my ifconfig: > sis0: flags=8843 mtu 1500 > options=8 > inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:16:ec:44:e3:a8 > media: Ethernet autoselect (100baseTX ) > status: active > xl0: flags=8843 mtu 1500 > options=9 > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:04:76:a1:97:ef > media: Ethernet autoselect (100baseTX ) > status: active > fxp0: flags=8843 mtu 1500 > options=8 > inet 79.165.217.154 netmask 0xfffff000 broadcast 255.255.255.255 > ether 00:50:8b:5f:f2:4a > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > gif0: flags=8051 mtu 1280 > tunnel inet 79.165.217.154 --> 212.248.60.138 > inet 192.168.0.254 --> 192.168.8.254 netmask 0xffffff00 > gif3: flags=8051 mtu 1280 > tunnel inet 79.165.217.154 --> 81.195.226.74 > inet 192.168.0.254 --> 192.168.2.254 netmask 0xffffff00 > > [Home]gw# ifconfig gif14 create > [Home]gw# ifconfig gif14 tunnel 79.165.217.154 212.248.60.138 > ifconfig: SIOCSIFPHYADDR: Can't assign requested address You already used that address on gif0. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From chris at cretaforce.gr Fri Sep 12 10:45:46 2008 From: chris at cretaforce.gr (Chris) Date: Fri Sep 12 10:45:52 2008 Subject: FreeBSD 7.0 and vr0 Message-ID: <1221215436.13772.15.camel@desktop.lan> Hello, I have a FreeBSD 7.0 server with patch level 3 and no ipv6 services running. SSH / web-server / ftp server / etc stop responding but server responds to ping. A reboot fix this. The logs show nothing. Any idea what may be wrong? Regards, Chris Chatzaras From gaijin.k at gmail.com Sat Sep 13 14:17:09 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sat Sep 13 14:17:16 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <20080828002919.GA54169@alpha.local> References: <20080828002919.GA54169@alpha.local> Message-ID: <1221313811.1305.15.camel@RabbitsDen> On Thu, 2008-08-28 at 01:29 +0100, Rui Paulo wrote: > Hi, > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > If you have an Atheros or Atheros based card, I really wanted you to > test it. We were unable to test this in several Atheros chipsets, so > if you find a regression, please contact me or Sam Leffler > (sam@freebsd.org) ASAP. > So, please give it a try :-) I don't know if it is necessarily useful thing to report, but I have pulled it into RELENG_7 (as of August 29th) and so far I have not seen lookups, which were my regular fare with 0.9.20.3 and powerd. I see a lot of "bogus rix..." and "bogus ndx0..." messages flying by, but since nobody promised that this should work on RELENG_7, I don't think they are worth reporting ;) My hardware is ThinkPad X60: Sep 13 09:30:26 RabbitsDen kernel: ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) Sep 13 09:30:27 RabbitsDen kernel: ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 Sep 13 09:30:27 RabbitsDen kernel: ath0: [ITHREAD] Sep 13 09:30:27 RabbitsDen kernel: ath0: WARNING: using obsoleted if_watchdog interface Sep 13 09:30:27 RabbitsDen kernel: ath0: Ethernet address: xx:xx:xx:xx:xx:xx Sep 13 09:30:27 RabbitsDen kernel: ath0: mac 10.3 phy 6.1 radio 10.2 > > Unfortuntely, this will only make 7.1 if the release date slips. So, > don't expect this to be MFCed any time soon. Those having troubles with 0.9.x.x should be able to pull it in without much difficulty, at least to give it a try. Thank you very much for doing this work! -- Alexandre "Sunny" Kovalenko (????????? ?????????) From rpaulo at FreeBSD.org Sat Sep 13 14:54:27 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sat Sep 13 14:54:44 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <1221313811.1305.15.camel@RabbitsDen> References: <20080828002919.GA54169@alpha.local> <1221313811.1305.15.camel@RabbitsDen> Message-ID: <20080913145145.GA13435@alpha.local> On Sat, Sep 13, 2008 at 09:50:11AM -0400, Alexandre Sunny Kovalenko wrote: > On Thu, 2008-08-28 at 01:29 +0100, Rui Paulo wrote: > > Hi, > > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > > > If you have an Atheros or Atheros based card, I really wanted you to > > test it. We were unable to test this in several Atheros chipsets, so > > if you find a regression, please contact me or Sam Leffler > > (sam@freebsd.org) ASAP. > > So, please give it a try :-) > I don't know if it is necessarily useful thing to report, but I have > pulled it into RELENG_7 (as of August 29th) and so far I have not seen > lookups, which were my regular fare with 0.9.20.3 and powerd. Yes, I think I had them too sometimes. > I see a lot of "bogus rix..." and "bogus ndx0..." messages flying by, > but since nobody promised that this should work on RELENG_7, I don't > think they are worth reporting ;) They happen to me on HEAD too (but I think they are harmless). Regards, -- Rui Paulo From gaijin.k at gmail.com Sat Sep 13 17:26:00 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sat Sep 13 17:26:07 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <20080913150553.GV39652@deviant.kiev.zoral.com.ua> References: <20080828002919.GA54169@alpha.local> <1221313811.1305.15.camel@RabbitsDen> <20080913145145.GA13435@alpha.local> <20080913150553.GV39652@deviant.kiev.zoral.com.ua> Message-ID: <1221326744.1305.28.camel@RabbitsDen> On Sat, 2008-09-13 at 18:05 +0300, Kostik Belousov wrote: > On Sat, Sep 13, 2008 at 03:51:45PM +0100, Rui Paulo wrote: > > On Sat, Sep 13, 2008 at 09:50:11AM -0400, Alexandre Sunny Kovalenko wrote: > > > On Thu, 2008-08-28 at 01:29 +0100, Rui Paulo wrote: > > > > Hi, > > > > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > > > > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > > > > > > > If you have an Atheros or Atheros based card, I really wanted you to > > > > test it. We were unable to test this in several Atheros chipsets, so > > > > if you find a regression, please contact me or Sam Leffler > > > > (sam@freebsd.org) ASAP. > > > > So, please give it a try :-) > > > I don't know if it is necessarily useful thing to report, but I have > > > pulled it into RELENG_7 (as of August 29th) and so far I have not seen > > > lookups, which were my regular fare with 0.9.20.3 and powerd. > > > > Yes, I think I had them too sometimes. > > > > > I see a lot of "bogus rix..." and "bogus ndx0..." messages flying by, > > > but since nobody promised that this should work on RELENG_7, I don't > > > think they are worth reporting ;) > > > > They happen to me on HEAD too (but I think they are harmless). > > Are there estimations for the MFC ? Obviously, after 7.1, but how long ? I think (sm) that if everyone interested in MFC and running RELENG_7 would replace his local copy of /usr/src/sys/contrib/dev/ath with the one from the HEAD, rebuild his kernel, or, as it was the case for me, ath_hal.ko and if_ath.ko, run with it for a while and report success back to this list, we can speed this up dramatically. In my experience, replacing 9.x.x.x HAL that came with RELENG_7 with this one solved at least one persistent and annoying problem, and so far has not shown any regressions. YMMV. But then again, I am not the one who would be doing MFC, so this is just an assumption on my part, not necessarily correct or useful. -- Alexandre "Sunny" Kovalenko (????????? ?????????) From bzeeb-lists at lists.zabbadoz.net Sat Sep 13 17:42:13 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Sep 13 17:42:20 2008 Subject: TCP-MD5 support for IPv6 Message-ID: <20080913173441.F65801@maildrop.int.zabbadoz.net> Hi, I just committed IPv6 TCP-MD5 support for HEAD. This gives one the ability to send the TCP signature but as with IPv4 there is no input path validation and we need to enhance the key management, etc.. But that's another story. For now I have an additional hack that enables sending ... for IPv4 and IPv6: - ACK from timewait - inital RST after socket close (as long as possible) For both changes, one needs to hack up TCP in a very bad way as we lose the "signature flag" on the way down. Multiple TCP exit paths do not help with this either. Nick (thanks!) had tried it and given me tcpdumps and they looked sane. In case you can use it as well, the patch, temporary, is here: http://people.freebsd.org/~bz/20080913-02-tcp-md5-ack-rst.diff This is the "more changes" I mentioned in the commit message. Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ---------- Forwarded message ---------- Date: Sat, 13 Sep 2008 17:26:46 +0000 (UTC) From: Bjoern A. Zeeb To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/netinet tcp_output.c tcp_subr.c tcp_syncache.c bz 2008-09-13 17:26:46 UTC FreeBSD src repository Modified files: sys/netinet tcp_output.c tcp_subr.c tcp_syncache.c Log: SVN rev 183001 on 2008-09-13 17:26:46Z by bz Implement IPv6 support for TCP MD5 Signature Option (RFC 2385) the same way it has been implemented for IPv4. Reviewed by: bms (skimmed) Tested by: Nick Hilliard (nick netability.ie) (with more changes) MFC after: 2 months Revision Changes Path 1.155 +1 -8 src/sys/netinet/tcp_output.c 1.316 +93 -24 src/sys/netinet/tcp_subr.c 1.156 +1 -1 src/sys/netinet/tcp_syncache.c From rpaulo at FreeBSD.org Sat Sep 13 18:27:01 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sat Sep 13 18:27:09 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <1221326744.1305.28.camel@RabbitsDen> References: <20080828002919.GA54169@alpha.local> <1221313811.1305.15.camel@RabbitsDen> <20080913145145.GA13435@alpha.local> <20080913150553.GV39652@deviant.kiev.zoral.com.ua> <1221326744.1305.28.camel@RabbitsDen> Message-ID: <20080913182412.GA6850@alpha.local> On Sat, Sep 13, 2008 at 01:25:44PM -0400, Alexandre Sunny Kovalenko wrote: > Are there estimations for the MFC ? Obviously, after 7.1, but how long ? > I think (sm) that if everyone interested in MFC and running RELENG_7 > would replace his local copy of /usr/src/sys/contrib/dev/ath with the > one from the HEAD, rebuild his kernel, or, as it was the case for me, > ath_hal.ko and if_ath.ko, run with it for a while and report success > back to this list, we can speed this up dramatically. In my experience, > replacing 9.x.x.x HAL that came with RELENG_7 with this one solved at > least one persistent and annoying problem, and so far has not shown any > regressions. YMMV. > > But then again, I am not the one who would be doing MFC, so this is just > an assumption on my part, not necessarily correct or useful. I may do an MFC in medium-to-long time, but there are some changes in the code that I need to clear up with Sam. So, expect this only in 7.2. Regards, -- Rui Paulo From kostikbel at gmail.com Sat Sep 13 19:22:03 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Sep 13 19:22:10 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <20080913145145.GA13435@alpha.local> References: <20080828002919.GA54169@alpha.local> <1221313811.1305.15.camel@RabbitsDen> <20080913145145.GA13435@alpha.local> Message-ID: <20080913150553.GV39652@deviant.kiev.zoral.com.ua> On Sat, Sep 13, 2008 at 03:51:45PM +0100, Rui Paulo wrote: > On Sat, Sep 13, 2008 at 09:50:11AM -0400, Alexandre Sunny Kovalenko wrote: > > On Thu, 2008-08-28 at 01:29 +0100, Rui Paulo wrote: > > > Hi, > > > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > > > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > > > > > If you have an Atheros or Atheros based card, I really wanted you to > > > test it. We were unable to test this in several Atheros chipsets, so > > > if you find a regression, please contact me or Sam Leffler > > > (sam@freebsd.org) ASAP. > > > So, please give it a try :-) > > I don't know if it is necessarily useful thing to report, but I have > > pulled it into RELENG_7 (as of August 29th) and so far I have not seen > > lookups, which were my regular fare with 0.9.20.3 and powerd. > > Yes, I think I had them too sometimes. > > > I see a lot of "bogus rix..." and "bogus ndx0..." messages flying by, > > but since nobody promised that this should work on RELENG_7, I don't > > think they are worth reporting ;) > > They happen to me on HEAD too (but I think they are harmless). Are there estimations for the MFC ? Obviously, after 7.1, but how long ? -------------- 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/20080913/87dd4ca7/attachment.pgp From remko at FreeBSD.org Sat Sep 13 22:36:01 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat Sep 13 22:36:07 2008 Subject: kern/127266: [gif] gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address Message-ID: <200809132235.m8DMZxs0074581@freefall.freebsd.org> Synopsis: [gif] gif tunnel error ifconfig: SIOCSIFPHYADDR: Can't assign requested address State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Sat Sep 13 22:35:59 UTC 2008 State-Changed-Why: Both Edwin (public reply) and I (private reply) mentioned the same problem. Most likely this is the issue. Please reply to one of our emails to get this further if needed. http://www.freebsd.org/cgi/query-pr.cgi?pr=127266 From biancalana at gmail.com Sun Sep 14 17:15:28 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Sun Sep 14 17:15:35 2008 Subject: ECMP Support Message-ID: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> Hi! How's good is our ECMP ? Is someone using in production ? Regards, From bms at FreeBSD.org Sun Sep 14 17:38:28 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Sep 14 17:38:34 2008 Subject: ECMP Support In-Reply-To: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> Message-ID: <48CD4C11.6020104@FreeBSD.org> Alexandre Biancalana wrote: > Hi! > > How's good is our ECMP ? Is someone using in production ? > Doesn't exist yet, care to contribute? There is "multiple routing tables" support but that's not quite the same thing. regards BMS From biancalana at gmail.com Sun Sep 14 17:53:55 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Sun Sep 14 17:54:02 2008 Subject: ECMP Support In-Reply-To: <48CD4C11.6020104@FreeBSD.org> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> Message-ID: <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> On 9/14/08, Bruce M. Simpson wrote: > Alexandre Biancalana wrote: > > > Hi! > > > > How's good is our ECMP ? Is someone using in production ? > > > > > > Doesn't exist yet, care to contribute? > > There is "multiple routing tables" support but that's not quite the same > thing. Doesn't exists ?? So what's this commit message about ? http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html From bms at FreeBSD.org Sun Sep 14 17:57:06 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Sep 14 17:57:12 2008 Subject: ECMP Support In-Reply-To: <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> Message-ID: <48CD506F.8090401@FreeBSD.org> Alexandre Biancalana wrote: >> There is "multiple routing tables" support but that's not quite the same >> thing. >> > > Doesn't exists ?? So what's this commit message about ? > > http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html > Qing Li committed this support to -CURRENT but not RELENG_7. AFAIK there hasn't been management tool support added, so further work is needed before it can be used. cheers BMS From biancalana at gmail.com Sun Sep 14 21:56:53 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Sun Sep 14 21:57:06 2008 Subject: ECMP Support In-Reply-To: <48CD506F.8090401@FreeBSD.org> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> <48CD506F.8090401@FreeBSD.org> Message-ID: <8e10486b0809141456t48e799a0tcd74b605f2ad473f@mail.gmail.com> On 9/14/08, Bruce M. Simpson wrote: > Alexandre Biancalana wrote: > > > > > > There is "multiple routing tables" support but that's not quite the > same > > > thing. > > > > > > > > > > Doesn't exists ?? So what's this commit message about ? > > > > > http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html > > > > > > Qing Li committed this support to -CURRENT but not RELENG_7. Sure! Excuse my misunderstanding.... > AFAIK there > hasn't been management tool support added, so further work is needed before > it can be used. There is any documentation about what have to be done ? Thank you From julian at elischer.org Mon Sep 15 04:18:50 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Sep 15 04:18:56 2008 Subject: ECMP Support In-Reply-To: <8e10486b0809141456t48e799a0tcd74b605f2ad473f@mail.gmail.com> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> <48CD506F.8090401@FreeBSD.org> <8e10486b0809141456t48e799a0tcd74b605f2ad473f@mail.gmail.com> Message-ID: <48CDE229.905@elischer.org> Alexandre Biancalana wrote: > On 9/14/08, Bruce M. Simpson wrote: >> Alexandre Biancalana wrote: >> >>>> There is "multiple routing tables" support but that's not quite the >> same >>>> thing. >>>> >>>> >>> Doesn't exists ?? So what's this commit message about ? >>> >>> >> http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html >>> >> Qing Li committed this support to -CURRENT but not RELENG_7. > > Sure! Excuse my misunderstanding.... > >> AFAIK there >> hasn't been management tool support added, so further work is needed before >> it can be used. > > There is any documentation about what have to be done ? I suggest you talk to Qing. He is probably lurking.. > > Thank you > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From guru at unixarea.de Mon Sep 15 11:20:50 2008 From: guru at unixarea.de (Matthias Apitz) Date: Mon Sep 15 11:21:05 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 Message-ID: <20080915110838.GA5258@rebelion.Sisis.de> Hello, I'm booting my laptop 3 times a day: in the morning at home (WEP area), when I arrive in my office (WPA area) and in the evening at home (again); the sequence is always the same: booting, login into console, startx which launches via ~/.xinitrc the KDE; in about 1 of 2-3 cases and only in the office(!) the system panics when KDE comes up, at the end of the KDE booting and the jingle already played; today it crashed again and again and after switching off the Wifi radio on the laptop it came finally up fine; I did this (Wifi off) because I'm assuming somehow a relation with http://www.freebsd.org/cgi/query-pr.cgi?pr=122331 where my laptop as well only panic'ed in WPA mode (i.e. in the office) and with 'bgscan' active; which I now have deactivated; all these panics look in the debugger more or less like this one: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0788b98 stack pointer = 0x28:0xe6960acc frame pointer = 0x28:0xe6960c50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1426 (kdeinit) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m36s Physical memory: 1009 MB Dumping 129 MB: 114 98 82 66 50 34 18 2 #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 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe6960a8c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) at /usr/src/sys/kern/sys_generic.c:663 #9 0xc0a49635 in syscall (frame=0xe6960d38) at /usr/src/sys/i386/i386/trap.c:1035 #10 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) the 'current process' (kdeinit in the above crash) changes, but is always one of the KDE parts; of course the problem is not KDE related, it is just that the system comes under heavy usage in that moment; I already run 'memtest 128' for some hours without any noted problem in memory; test are just passing fine; the same problem is with 7.0-RELEASE as with RELENG_7; what can I do to nail this down? it sucks somehow seeing it crashing on startup in the morning in the office :-(( thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From hpcharles at gmail.com Mon Sep 15 14:31:44 2008 From: hpcharles at gmail.com (Henri-Pierre Charles) Date: Mon Sep 15 14:31:51 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <20080828002919.GA54169@alpha.local> References: <20080828002919.GA54169@alpha.local> Message-ID: <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> Hi, On Thu, Aug 28, 2008 at 2:29 AM, Rui Paulo wrote: > We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of > new chips, namely those on the Asus Eee PC, MacBooks and other laptops. It's included into 8.0-CURRENT-200809-i386 snapshot if I understand correctly. > If you have an Atheros or Atheros based card, I really wanted you to > test it. We were unable to test this in several Atheros chipsets, so > if you find a regression, please contact me or Sam Leffler > (sam@freebsd.org) ASAP. I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. The corresponding dmesg can be found here : * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-7.1-BETA.txt * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-8.0-200809.txt The 8.0-CURRENT-200809-i386 contain ath_hal 0.10.5.10 but I was unable to use the interface. "dhclient ath0" never give up. Let me know if I can try something. In the past I had success with 7.0 code base + madwifi-ng-r2756+ar5007.hal I was able to use ath with dhclient and wpa_supplicant. And what about the rj45 interface for eee 701 ? Any chance to be supported in a near future ? -- HPC From bugmaster at FreeBSD.org Mon Sep 15 15:18:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:20:25 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200809151518.m8FFIqRg018966@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/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/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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 bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 173 problems total. From bugmaster at FreeBSD.org Mon Sep 15 15:19:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:21:47 2008 Subject: Current problem reports assigned to net@FreeBSD.org Message-ID: <200809151519.m8FFJpfC020036@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 -------------------------------------------------------------------------------- p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS 1 problem total. From julian at elischer.org Mon Sep 15 16:27:33 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Sep 15 16:27:40 2008 Subject: ECMP Support In-Reply-To: <48CD4C11.6020104@FreeBSD.org> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> Message-ID: <48CE8CF3.6060802@elischer.org> Bruce M. Simpson wrote: > Alexandre Biancalana wrote: >> Hi! >> >> How's good is our ECMP ? Is someone using in production ? >> > > Doesn't exist yet, care to contribute? > > There is "multiple routing tables" support but that's not quite the same > thing. > > regards > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From qing.li at bluecoat.com Mon Sep 15 17:42:09 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Sep 15 17:42:19 2008 Subject: ECMP Support In-Reply-To: <48CDE229.905@elischer.org> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> <48CD506F.8090401@FreeBSD.org><8e10486b0809141456t48e799a0tcd74b605f2ad473f@mail.gmail.com> <48CDE229.905@elischer.org> Message-ID: I can't tell you if the current ECMP support is good enough for you without knowing what your requirements are. We are using the code in production environments (along with other pieces of supporting infrastructure to perform our enhanced features). I know Barrett Lyon from BitGravity has been testing the code. I developed the code on FreeBSD 5.4 originally and I integrated the changes into -current, so I can't imagine it would be that hard to get it working in the 7.x branch if that is what you need. The main issue of running the ECMP code in any release later than the 5.4 release, is the lack of "inp_route" field that caches the route. In a system where the routing table changes frequently, the symptom would be packets of a flow could be spread across multiple paths, which could have serious impact on TCP performance. The "inp_route" field was removed in 5.4 release if I remembered correctly. I reintroduced this field in our custom releases. The "route" and "netstat" commands work with ECMP. There isn't much documentation but I do intend to update the manpages soon. Please indicate if there is any other command that you need. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Julian Elischer > Sent: Sunday, September 14, 2008 9:19 PM > To: Alexandre Biancalana > Cc: freebsd-net@freebsd.org; Qing Li > Subject: Re: ECMP Support > > Alexandre Biancalana wrote: > > On 9/14/08, Bruce M. Simpson wrote: > >> Alexandre Biancalana wrote: > >> > >>>> There is "multiple routing tables" support but that's not quite > >>>> the > >> same > >>>> thing. > >>>> > >>>> > >>> Doesn't exists ?? So what's this commit message about ? > >>> > >>> > >> http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html > >>> > >> Qing Li committed this support to -CURRENT but not RELENG_7. > > > > Sure! Excuse my misunderstanding.... > > > >> AFAIK there > >> hasn't been management tool support added, so further work > is needed > >> before it can be used. > > > > There is any documentation about what have to be done ? > > I suggest you talk to Qing. He is probably lurking.. > > > > Thank you > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > 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 swordqiu at gmail.com Mon Sep 15 17:44:23 2008 From: swordqiu at gmail.com (Jian Qiu) Date: Mon Sep 15 17:44:55 2008 Subject: What's the status of parallel netisr? Message-ID: I noticed there was a project trying to parallelize netisr in SMP. But I cannot find the relevant codes in either stable 7 or current 8. I'm wondering what's the current status of this project? When will it be merged into FreeBSD source tree? Many thanks. Best regards, Jian From jhb at freebsd.org Mon Sep 15 19:28:55 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 19:29:07 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <20080915110838.GA5258@rebelion.Sisis.de> References: <20080915110838.GA5258@rebelion.Sisis.de> Message-ID: <200809151448.06105.jhb@freebsd.org> On Monday 15 September 2008 07:08:38 am Matthias Apitz wrote: > > Hello, > > I'm booting my laptop 3 times a day: in the morning at home (WEP area), > when I arrive in my office (WPA area) and in the evening at home > (again); > > the sequence is always the same: booting, login into console, startx > which launches via ~/.xinitrc the KDE; > > in about 1 of 2-3 cases and only in the office(!) the system panics when > KDE comes up, at the end of the KDE booting and the jingle already > played; today it crashed again and again and after switching off the > Wifi radio on the laptop it came finally up fine; > > I did this (Wifi off) because I'm assuming somehow a relation with > http://www.freebsd.org/cgi/query-pr.cgi?pr=122331 > where my laptop as well only panic'ed in WPA mode (i.e. in the office) > and with 'bgscan' active; which I now have deactivated; > > all these panics look in the debugger more or less like this one: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0788b98 > stack pointer = 0x28:0xe6960acc > frame pointer = 0x28:0xe6960c50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1426 (kdeinit) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1m36s > Physical memory: 1009 MB > Dumping 129 MB: 114 98 82 66 50 34 18 2 > > #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 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) > at /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a49c8c in trap (frame=0xe6960a8c) at /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, > fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) at /usr/src/sys/kern/sys_generic.c:663 > #9 0xc0a49635 in syscall (frame=0xe6960d38) at /usr/src/sys/i386/i386/trap.c:1035 > #10 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > the 'current process' (kdeinit in the above crash) changes, but is > always one of the KDE parts; of course the problem is not KDE related, > it is just that the system comes under heavy usage in that moment; > > I already run 'memtest 128' for some hours without any noted problem in > memory; test are just passing fine; > > the same problem is with 7.0-RELEASE as with RELENG_7; > > what can I do to nail this down? it sucks somehow seeing it crashing on > startup in the morning in the office :-(( Can you go to frame 7 in kgdb and 'p *fdp'? -- John Baldwin From guru at unixarea.de Mon Sep 15 19:55:22 2008 From: guru at unixarea.de (Matthias Apitz) Date: Mon Sep 15 19:55:52 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <200809151448.06105.jhb@freebsd.org> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151448.06105.jhb@freebsd.org> Message-ID: <20080915194853.GA8365@rebelion.Sisis.de> El d?a Monday, September 15, 2008 a las 02:48:05PM -0400, John Baldwin escribi?: > > #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 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) > at /usr/src/sys/kern/kern_shutdown.c:563 > > #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) > at /usr/src/sys/i386/i386/trap.c:899 > > #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) > > at /usr/src/sys/i386/i386/trap.c:812 > > #5 0xc0a49c8c in trap (frame=0xe6960a8c) > at /usr/src/sys/i386/i386/trap.c:490 > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > fd_ou=0x298ad9c4, > > fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) > at /usr/src/sys/kern/sys_generic.c:663 > > #9 0xc0a49635 in syscall (frame=0xe6960d38) > at /usr/src/sys/i386/i386/trap.c:1035 > > #10 0xc0a2fc70 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:196 > > #11 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > ... > Can you go to frame 7 in kgdb and 'p *fdp'? (kgdb) frame 7 #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); (kgdb) p *fdp Variable "fdp" is not available. (kgdb) perhaps I do something wrong? matthias From biancalana at gmail.com Mon Sep 15 20:02:45 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Mon Sep 15 20:02:52 2008 Subject: ECMP Support In-Reply-To: References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> <48CD506F.8090401@FreeBSD.org> <8e10486b0809141456t48e799a0tcd74b605f2ad473f@mail.gmail.com> <48CDE229.905@elischer.org> Message-ID: <8e10486b0809151302l5a1c9433j5e44b54198409cd8@mail.gmail.com> On 9/15/08, Li, Qing wrote: > > I can't tell you if the current ECMP support is good enough for > you without knowing what your requirements are. We are using > the code in production environments (along with other pieces of > supporting infrastructure to perform our enhanced features). > I know Barrett Lyon from BitGravity has been testing the code. Hi Qing ! Thank you for your answer ! My idea is use ECMP on 7.x branch to balance 100Mbit Lan-2-Lan links between our enterprise network and IDC network. > > I developed the code on FreeBSD 5.4 originally and I integrated > the changes into -current, so I can't imagine it would be that > hard > to get it working in the 7.x branch if that is what you need. > > The main issue of running the ECMP code in any release later > than > the 5.4 release, is the lack of "inp_route" field that caches > the route. In a system where the routing table changes > frequently, > the symptom would be packets of a flow could be spread across > multiple paths, which could have serious impact on TCP > performance. In this case the route table only change when a link goes down, so I will remove this from routing table until this goes up again. This is a problem with current ECMP implementation ? > The "inp_route" field was removed in 5.4 release if I remembered > correctly. I reintroduced this field in our custom releases. > > The "route" and "netstat" commands work with ECMP. There isn't > much documentation but I do intend to update the manpages soon. > Please indicate if there is any other command that you need. I think this is enough for me. Regards, Alexandre > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org > > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Julian Elischer > > Sent: Sunday, September 14, 2008 9:19 PM > > To: Alexandre Biancalana > > Cc: freebsd-net@freebsd.org; Qing Li > > Subject: Re: ECMP Support > > > > Alexandre Biancalana wrote: > > > On 9/14/08, Bruce M. Simpson wrote: > > >> Alexandre Biancalana wrote: > > >> > > >>>> There is "multiple routing tables" support but that's not quite > > >>>> the > > >> same > > >>>> thing. > > >>>> > > >>>> > > >>> Doesn't exists ?? So what's this commit message about ? > > >>> > > >>> > > >> http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html > > >>> > > >> Qing Li committed this support to -CURRENT but not RELENG_7. > > > > > > Sure! Excuse my misunderstanding.... > > > > > >> AFAIK there > > >> hasn't been management tool support added, so further work > > is needed > > >> before it can be used. > > > > > > There is any documentation about what have to be done ? > > > > I suggest you talk to Qing. He is probably lurking.. > > > > > > Thank you > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > > 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 jhb at freebsd.org Mon Sep 15 20:49:49 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 20:50:06 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <20080915194853.GA8365@rebelion.Sisis.de> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151448.06105.jhb@freebsd.org> <20080915194853.GA8365@rebelion.Sisis.de> Message-ID: <200809151608.06738.jhb@freebsd.org> On Monday 15 September 2008 03:48:53 pm Matthias Apitz wrote: > El d?a Monday, September 15, 2008 a las 02:48:05PM -0400, John Baldwin escribi?: > > > > #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 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > > > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) > > at /usr/src/sys/kern/kern_shutdown.c:563 > > > #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) > > at /usr/src/sys/i386/i386/trap.c:899 > > > #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) > > > at /usr/src/sys/i386/i386/trap.c:812 > > > #5 0xc0a49c8c in trap (frame=0xe6960a8c) > > at /usr/src/sys/i386/i386/trap.c:490 > > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > > fd_ou=0x298ad9c4, > > > fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > > #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) > > at /usr/src/sys/kern/sys_generic.c:663 > > > #9 0xc0a49635 in syscall (frame=0xe6960d38) > > at /usr/src/sys/i386/i386/trap.c:1035 > > > #10 0xc0a2fc70 in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:196 > > > #11 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > (kgdb) > > > > ... > > Can you go to frame 7 in kgdb and 'p *fdp'? > > (kgdb) frame 7 > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); > (kgdb) p *fdp > Variable "fdp" is not available. > (kgdb) If 'td' is available then you can do 'p *td->td_proc->p_fd' -- John Baldwin From guru at unixarea.de Mon Sep 15 22:24:37 2008 From: guru at unixarea.de (Matthias Apitz) Date: Mon Sep 15 22:24:44 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <200809151608.06738.jhb@freebsd.org> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151448.06105.jhb@freebsd.org> <20080915194853.GA8365@rebelion.Sisis.de> <200809151608.06738.jhb@freebsd.org> Message-ID: <20080915222414.GA12474@rebelion.Sisis.de> El d?a Monday, September 15, 2008 a las 04:08:06PM -0400, John Baldwin escribi?: > > > Can you go to frame 7 in kgdb and 'p *fdp'? > > > > (kgdb) frame 7 > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); > > (kgdb) p *fdp > > Variable "fdp" is not available. > > (kgdb) > > If 'td' is available then you can do 'p *td->td_proc->p_fd' (kgdb) frame 7 #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 136 return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); (kgdb) p td $7 = (struct thread *) 0xc49d5630 (kgdb) p *td->td_proc->p_fd $8 = {fd_ofiles = 0x0, fd_ofileflags = 0x0, fd_cdir = 0x0, fd_rdir = 0xc42f3a00, fd_jdir = 0x0, fd_nfiles = 20, fd_map = 0xc49db8b4, fd_lastfile = 9, fd_freefile = 10, fd_cmask = 18, fd_refcnt = 1, fd_holdcnt = 1, fd_sx = {lock_object = { lo_name = 0xc0ad3cbe "filedesc structure", lo_type = 0xc0ad3cbe "filedesc structure", lo_flags = 37421056, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 17, sx_recurse = 0}, fd_kqlist = {slh_first = 0x0}, fd_holdleaderscount = 0, fd_holdleaderswakeup = 0} (kgdb) matthias From qing.li at bluecoat.com Tue Sep 16 00:10:26 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Tue Sep 16 00:10:32 2008 Subject: ECMP Support In-Reply-To: <8e10486b0809151302l5a1c9433j5e44b54198409cd8@mail.gmail.com> References: <8e10486b0809140950h6200dfdco5950f59d23718866@mail.gmail.com> <48CD4C11.6020104@FreeBSD.org> <8e10486b0809141053i69f9c4b5raffdad187ecd16eb@mail.gmail.com> <48CD506F.8090401@FreeBSD.org> <8e10486b0809141456t48e799a0tcd74b605f2ad473f@mail.gmail.com> <48CDE229.905@elischer.org> <8e10486b0809151302l5a1c9433j5e44b54198409cd8@mail.gmail.com> Message-ID: > > My idea is use ECMP on 7.x branch to balance 100Mbit > Lan-2-Lan links between our enterprise network and IDC network. > I can merge those changes into 7.x. Frankly I have lost track of the release schedule so I do need to talk to the FreeBSD release team to figure out where and when I should integrate the code. > > In this case the route table only change when a link goes > down, so I will remove this from routing table until this > goes up again. This is a problem with current ECMP implementation ? > The route selection uses a hash and because the number of route entries changes when you remove that route from the routing table, and depending on the hash key, you may get a different route entry. In earlier 5.x releases when "inp_route" is present (route is sticky), tcp_output() provides that value and route lookup is bypassed. This is something we are working on for a fix in -current. > > > > The "route" and "netstat" commands work with ECMP. > > There isn't much documentation but I do intend to update the > > manpages soon. > > Please indicate if there is any other command that you need. > > I think this is enough for me. > Okay. -- Qing From pyunyh at gmail.com Tue Sep 16 03:52:40 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Sep 16 03:52:47 2008 Subject: FreeBSD 7.0 and vr0 In-Reply-To: <1221215436.13772.15.camel@desktop.lan> References: <1221215436.13772.15.camel@desktop.lan> Message-ID: <20080916034947.GB1301@cdnetworks.co.kr> On Fri, Sep 12, 2008 at 01:30:36PM +0300, Chris wrote: > Hello, > > I have a FreeBSD 7.0 server with patch level 3 and no ipv6 services > running. > > SSH / web-server / ftp server / etc stop responding but server responds > to ping. > > A reboot fix this. > > The logs show nothing. > > Any idea what may be wrong? > vr(4) had a couple of bugs in link state handling and a lot of changes made to fix all known issue since 7.0-RELEASE. Would you try 7.1-BETA? -- Regards, Pyun YongHyeon From chris at cretaforce.gr Tue Sep 16 05:11:26 2008 From: chris at cretaforce.gr (Chris) Date: Tue Sep 16 05:11:38 2008 Subject: FreeBSD 7.0 and vr0 In-Reply-To: <20080916034947.GB1301@cdnetworks.co.kr> References: <1221215436.13772.15.camel@desktop.lan> <20080916034947.GB1301@cdnetworks.co.kr> Message-ID: <1221541951.15672.1.camel@desktop.lan> I upgrade to 7.1-PRERELEASE and I will see how it goes. Also today I had similar problem with nfe card (another server). The hangs are not related to the network hard, but with something else. > vr(4) had a couple of bugs in link state handling and a lot of > changes made to fix all known issue since 7.0-RELEASE. > Would you try 7.1-BETA? > From kris at FreeBSD.org Tue Sep 16 07:46:16 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Sep 16 07:46:22 2008 Subject: What's the status of parallel netisr? In-Reply-To: References: Message-ID: <48CF6450.6020909@FreeBSD.org> Jian Qiu wrote: > I noticed there was a project trying to parallelize netisr in SMP. > > But I cannot find the relevant codes in either stable 7 or current 8. > > I'm wondering what's the current status of this project? > > When will it be merged into FreeBSD source tree? It's available in a perforce branch owned by rwatson (sorry, I don't have the branch name handy), but in my tests it either produced no benefits, or actually reduced performance. This is surprising and the reasons for this are still unknown. Kris From bz at FreeBSD.org Tue Sep 16 09:08:24 2008 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Tue Sep 16 09:08:36 2008 Subject: docs/120945: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Message-ID: <200809160908.m8G98OkG070513@freefall.freebsd.org> Synopsis: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Responsible-Changed-From-To: net->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Tue Sep 16 09:07:33 UTC 2008 Responsible-Changed-Why: Change Resp. to not get an extra GNATS spam every week. http://www.freebsd.org/cgi/query-pr.cgi?pr=120945 From bz at FreeBSD.org Tue Sep 16 09:08:24 2008 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Tue Sep 16 09:08:36 2008 Subject: docs/120945: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Message-ID: <200809160908.m8G98OkG070513@freefall.freebsd.org> Synopsis: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Responsible-Changed-From-To: net->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Tue Sep 16 09:07:33 UTC 2008 Responsible-Changed-Why: Change Resp. to not get an extra GNATS spam every week. http://www.freebsd.org/cgi/query-pr.cgi?pr=120945 From hpcharles at gmail.com Tue Sep 16 09:23:31 2008 From: hpcharles at gmail.com (Henri-Pierre Charles) Date: Tue Sep 16 09:23:37 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> Message-ID: <4734a3ed0809160223p6ddc6fd5pacb901ea9dfccfe3@mail.gmail.com> Hello, (I reply to myself) On Mon, Sep 15, 2008 at 3:59 PM, Henri-Pierre Charles wrote: > Hi, > > On Thu, Aug 28, 2008 at 2:29 AM, Rui Paulo wrote: >> We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of >> new chips, namely those on the Asus Eee PC, MacBooks and other laptops. > > It's included into 8.0-CURRENT-200809-i386 snapshot if I understand correctly. > I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > > 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. > The corresponding dmesg can be found here : > > * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-7.1-BETA.txt > * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-8.0-200809.txt > > The 8.0-CURRENT-200809-i386 contain ath_hal 0.10.5.10 but I was unable > to use the interface. "dhclient ath0" never give up. Let me know if I > can try something. I discover a "new" way to configure network interface, with wlan I have tried to put in my rc.conf: wlans_ath0=wlan0 ifconfig_wlan0="WPA DHCP" And .. it works, with a WPA2 configuration and also with only DHCP. Conclusion 8-0-CURRENT-200809 work out of the box for the eeepc 701. The only documentation I have found is http://people.freebsd.org/~sam/BSDCan2005.pdf . Is there something more substantial ? > And what about the rj45 interface for eee 701 ? Any chance to be supported > in a near future ? Any tips ? H-P -- HPC From vince at unsane.co.uk Tue Sep 16 09:52:19 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Tue Sep 16 09:52:29 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <4734a3ed0809160223p6ddc6fd5pacb901ea9dfccfe3@mail.gmail.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <4734a3ed0809160223p6ddc6fd5pacb901ea9dfccfe3@mail.gmail.com> Message-ID: <48CF81CE.2070608@unsane.co.uk> Henri-Pierre Charles wrote: > Hello, (I reply to myself) > > On Mon, Sep 15, 2008 at 3:59 PM, Henri-Pierre Charles > wrote: > >> Hi, >> >> On Thu, Aug 28, 2008 at 2:29 AM, Rui Paulo wrote: >> >>> We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of >>> new chips, namely those on the Asus Eee PC, MacBooks and other laptops. >>> >> It's included into 8.0-CURRENT-200809-i386 snapshot if I understand correctly. >> I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 >> >> 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. >> The corresponding dmesg can be found here : >> >> * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-7.1-BETA.txt >> * http://www.prism.uvsq.fr/~hpc/pmwiki/uploads/Data/dmesg-8.0-200809.txt >> >> The 8.0-CURRENT-200809-i386 contain ath_hal 0.10.5.10 but I was unable >> to use the interface. "dhclient ath0" never give up. Let me know if I >> can try something. >> > > I discover a "new" way to configure network interface, with wlan > I have tried to put in my rc.conf: > wlans_ath0=wlan0 > ifconfig_wlan0="WPA DHCP" > > And .. it works, with a WPA2 configuration and also with only DHCP. > Conclusion 8-0-CURRENT-200809 work out of the box for the eeepc 701. > > The only documentation I have found is > http://people.freebsd.org/~sam/BSDCan2005.pdf . Is there something > more substantial ? > > /usr/src/UPDATING check the 20080420 entry. Always check this when updating your sources unless you read every mail on the current@ mailing list and even then its worth checking it. Vince >> And what about the rj45 interface for eee 701 ? Any chance to be supported >> in a near future ? >> > > Any tips ? > > H-P > > From jespasac at minibofh.org Tue Sep 16 11:22:49 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Tue Sep 16 11:25:53 2008 Subject: Change netmask with /etc/rc.d/network restart or reboot the machine? Message-ID: <48CF930B.4020704@minibofh.org> Hi all, I've a lot of boxes in production with a lot of associated services (http, ftp, ssh, smtp, mysql...). Because of internal administration reasons I need to ampliate my internal IPs range from /24 to /16; so I need to change my internal NIC settings. The last goal is make the change with _security_. I prefer a reboot with thier 2/4 minutes downtime than a odd miss-function in several production services. I tend to think that the use of ifconfig(8) will be enough; of course, I'll also modify /etc/rc.conf 'ifconfig_' record for posterior reboots. Or maybe I has more sense to modify directly the /etc/rc.conf record and next use the '/etc/rc.d/netif restart'; or maybe make the change in /etc/rc.conf and reboot the machines. ?What do you tink about? -- Thanks, Jordi Espasa Clofent From nacho319 at gmail.com Tue Sep 16 11:23:11 2008 From: nacho319 at gmail.com (Chris Inacio) Date: Tue Sep 16 11:25:53 2008 Subject: help with code to determine external IP address on FreeBSD gateway machine Message-ID: <900019150809160401v316682fdt4cf8a95bfcb48dc2@mail.gmail.com> Hello, I'm writing a tiny bit of code to do NAT-PMP and I need code that can determine what the external facing IP address is on a machine with presumably multiple interfaces. I think I have a method in mind which would involve getting the default route, and then figuring out which interface is reachable by that default route. There are always all the other methods of going out to a web site which will reflect my IP address back to me on a web site - and while reliable, that seems sort of hackish. So the thing is, I'm not super familiar with the necessary ioctl calls, or routing socket calls, or...? Can somebody save me a ton of time and just point me in the right direction as to how to get this done? I was looking through the code of src/net/route.c, but decided a lot of context was needed to understand what I was reading. Any help would be very much appreciated. Thanks, Chris From glen.j.barber at gmail.com Tue Sep 16 11:31:30 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Tue Sep 16 11:34:09 2008 Subject: Change netmask with /etc/rc.d/network restart or reboot the machine? In-Reply-To: <48CF930B.4020704@minibofh.org> References: <48CF930B.4020704@minibofh.org> Message-ID: <4ad871310809160431j4adfc578g71afc242e8ead3b3@mail.gmail.com> You could change the interface settings in rc.conf, and /etc/rc.d/netif restart. I've added/removed aliased interfaces in a similar fashion, and haven't experienced hiccups. You should, however, double check your service applications that listen on particular IP addresses to make sure they are going to behave after netif restarts, as well as after a reboot. Certain changes, for example apache, require the service to be restarted as well. Regards. -- Glen Barber From debarshi.ray at gmail.com Tue Sep 16 11:33:56 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue Sep 16 11:34:21 2008 Subject: help with code to determine external IP address on FreeBSD gateway machine In-Reply-To: <900019150809160401v316682fdt4cf8a95bfcb48dc2@mail.gmail.com> References: <900019150809160401v316682fdt4cf8a95bfcb48dc2@mail.gmail.com> Message-ID: <3170f42f0809160433x78d6637odc58da304cf3e19e@mail.gmail.com> I have some PF_ROUTE based code, which shows the routing table of a FreeBSD system. If you are interested, I can show it to you once I get back home tonight. Happy hacking, Debarshi From edwin at mavetju.org Tue Sep 16 11:51:12 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Tue Sep 16 11:53:57 2008 Subject: Change netmask with /etc/rc.d/network restart or reboot the machine? In-Reply-To: <48CF930B.4020704@minibofh.org> References: <48CF930B.4020704@minibofh.org> Message-ID: <20080916113455.GA83338@k7.mavetju> On Tue, Sep 16, 2008 at 01:05:47PM +0200, Jordi Espasa Clofent wrote: > I've a lot of boxes in production with a lot of associated services > (http, ftp, ssh, smtp, mysql...). > Because of internal administration reasons I need to ampliate my > internal IPs range from /24 to /16; so I need to change my internal NIC > settings. The last goal is make the change with _security_. I prefer a > reboot with thier 2/4 minutes downtime than a odd miss-function in > several production services. > > I tend to think that the use of ifconfig(8) will be enough; of course, > I'll also modify /etc/rc.conf 'ifconfig_' record for posterior > reboots. Or maybe I has more sense to modify directly the /etc/rc.conf > record and next use the '/etc/rc.d/netif restart'; or maybe make the > change in /etc/rc.conf and reboot the machines. > > ?What do you tink about? Like you said, ifconfig is the simplest way to do it. Just make sure your default gateway doesn't need a change neither. Foolproof should be: - Modify /etc/rc.conf - "shutdown -r +3" - "ifconfig nic0 1.2.3.4 netmask 255.255.0.0" - "killall -TERM shutdown" That way even if the ifconfig goes wrong for some reason (it will happen if you do 700 machines) the machine will come back after the reboot. Don't forget about possible ipfw rule changes! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From swordqiu at gmail.com Tue Sep 16 14:43:27 2008 From: swordqiu at gmail.com (Jian Qiu) Date: Tue Sep 16 14:44:38 2008 Subject: What's the status of parallel netisr? In-Reply-To: <48CF6450.6020909@FreeBSD.org> References: <48CF6450.6020909@FreeBSD.org> Message-ID: Interesting. I did a test on local UDP throughput. I was surprised to find out the performance with a SMP kernel was worse than UP. (~74MB/s v.s. 96 MB/s). I had though parallel netisr might be a solution. Anyway, thanks for the info. On Tue, Sep 16, 2008 at 3:46 PM, Kris Kennaway wrote: > Jian Qiu wrote: >> >> I noticed there was a project trying to parallelize netisr in SMP. >> >> But I cannot find the relevant codes in either stable 7 or current 8. >> >> I'm wondering what's the current status of this project? >> >> When will it be merged into FreeBSD source tree? > > It's available in a perforce branch owned by rwatson (sorry, I don't have > the branch name handy), but in my tests it either produced no benefits, or > actually reduced performance. This is surprising and the reasons for this > are still unknown. > > Kris > From nacho319 at gmail.com Tue Sep 16 15:29:34 2008 From: nacho319 at gmail.com (Chris Inacio) Date: Tue Sep 16 15:29:44 2008 Subject: help with code to determine external IP address on FreeBSD gateway machine In-Reply-To: <3170f42f0809160433x78d6637odc58da304cf3e19e@mail.gmail.com> References: <900019150809160401v316682fdt4cf8a95bfcb48dc2@mail.gmail.com> <3170f42f0809160433x78d6637odc58da304cf3e19e@mail.gmail.com> Message-ID: <900019150809160829n7bf785ddn9ee2a86f11174885@mail.gmail.com> Debarshi, Yes, I would be interested in seeing the code. I would hope that this task isn't too complicated, but I have my suspicions that it will be a fair number of steps. Thanks, Chris On Tue, Sep 16, 2008 at 7:33 AM, Debarshi Ray wrote: > I have some PF_ROUTE based code, which shows the routing table of a > FreeBSD system. If you are interested, I can show it to you once I get > back home tonight. > > Happy hacking, > Debarshi > From debarshi.ray at gmail.com Tue Sep 16 18:39:39 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue Sep 16 18:42:05 2008 Subject: help with code to determine external IP address on FreeBSD gateway machine In-Reply-To: <900019150809160829n7bf785ddn9ee2a86f11174885@mail.gmail.com> References: <900019150809160401v316682fdt4cf8a95bfcb48dc2@mail.gmail.com> <3170f42f0809160433x78d6637odc58da304cf3e19e@mail.gmail.com> <900019150809160829n7bf785ddn9ee2a86f11174885@mail.gmail.com> Message-ID: <3170f42f0809161139k44b67895id412832aafe0568f@mail.gmail.com> Here is the code: http://rishi.fedorapeople.org/gnu/inetutils-1.5.tar.gz You will be interested in route/bsd_show.c and the function in that file named bsd_show. It uses a combination of sysctl and PF_ROUTE to retrieve the information. Please ask if you encounter any problem. :-) Happy hacking, Debarshi From oberman at es.net Tue Sep 16 18:46:39 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Sep 16 18:49:00 2008 Subject: What's the status of parallel netisr? In-Reply-To: Your message of "Tue, 16 Sep 2008 22:43:25 +0800." Message-ID: <20080916183559.949004500F@ptavv.es.net> > Date: Tue, 16 Sep 2008 22:43:25 +0800 > From: "Jian Qiu" > Sender: owner-freebsd-net@freebsd.org > > Interesting. > > I did a test on local UDP throughput. > > I was surprised to find out the performance with a SMP kernel was > worse than UP. (~74MB/s v.s. 96 MB/s). Look at CPU affinity. I have seen significant jumps in performance when things switch between CPUs. It's best to lock the UDP cannon to a single CPU and that the CPU not be CPU0. (This applies to both BSD and Linux systems that I have worked with.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080916/b31c0e27/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Tue Sep 16 18:55:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Sep 16 18:55:54 2008 Subject: [CFT/R] IPv4 source address selection In-Reply-To: <20080824111925.X66593@maildrop.int.zabbadoz.net> References: <20080824111925.X66593@maildrop.int.zabbadoz.net> Message-ID: <20080916183952.A65801@maildrop.int.zabbadoz.net> On Sun, 24 Aug 2008, Bjoern A. Zeeb wrote: Hi, > I have a patch, that was inspired by work from Y!, to do porper > IPv4 source address selection for unbound sockets (with multi-IP > jails). > > You can temporary find it here: > http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff > > People running my latest jail patches have been ``testing'' this > without really knowing the last weeks. > > In case you wonder why, in the jail case, I loop over the ifa first > before simply falling back to the primary jail IP (which is the only > jail IP as in HEAD) -- this is because with the upcoming jail patches > I have to check if any of possibly lots of IPs match any IP on an > interface and only if none matches I have to fall back to the 'primary' > jail IP. > So the code has been prepared for upcoming changes already. > > > Feel free to test it and report problems or unexpected behavior. > Unless someone is going to cry it'll hit HEAD in a few days. Okay, there was close to zero feedback:( I had Kris test it performance wise and he found a performance regression and I talked to Robert about the general code a bit more then decided that I can simplify it. After that I re-ran some performance tests myself and found that passing in pointers improves things and now we are at the following with unbound udp sockets: x cvs-plain2 + bz-laddr +------------------------------------------------------------+ |+ + + + x x x + x| | |______________________A_____M________|_______|_A________|| +------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 498932.16 500399.34 499727.93 499724.08 668.35243 + 5 496178.62 500190.01 498391.13 497996.98 1649.8572 No difference proven at 95.0% confidence x cvs-plain2-jailed + bz-laddr-jailed +------------------------------------------------------------+ |x + * + xx + x +| | ||_________________M_AA______M____________|| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 493049.99 499015.59 497250.89 496364.37 2305.2757 + 5 493335.46 499712.52 496067.19 496411.24 2431.479 No difference proven at 95.0% confidence For jails this already has the loops, though I was still trying with a single (extra) IP only. So the latest patch is here: http://people.freebsd.org/~bz/20080831-01-in_pcbladdr.diff I'd really like some review before this goes in especially as it changes the semantics for jails a bit more. I'll probably time out by Sunday (UTC) or so; in case you want to look at it but need more time, let me know and I'll wait. /bz PS: I'll also post an updated jail patch for HEAD with this change in case people want to try that with multi-IP jails. > PS: in case you review this properly (not only glance at it or test > it) let me know so I can punish you in the Reviewed by: line;-) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From kris at FreeBSD.org Tue Sep 16 19:27:12 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Sep 16 19:30:34 2008 Subject: What's the status of parallel netisr? In-Reply-To: References: <48CF6450.6020909@FreeBSD.org> Message-ID: <48D00899.4070908@FreeBSD.org> Jian Qiu wrote: > Interesting. > > I did a test on local UDP throughput. > > I was surprised to find out the performance with a SMP kernel was > worse than UP. (~74MB/s v.s. 96 MB/s). > > I had though parallel netisr might be a solution. Make sure you are testing with either 8.0 or 7.1 (or late 7.0-STABLE), i.e. after the fixes to improve UDP performance on SMP systems. Kris From jhb at freebsd.org Tue Sep 16 19:49:22 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 16 19:52:21 2008 Subject: kern/122331: panic's on KDE-launches (but only in WPA Wifi area) In-Reply-To: <20080915222414.GA12474@rebelion.Sisis.de> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151608.06738.jhb@freebsd.org> <20080915222414.GA12474@rebelion.Sisis.de> Message-ID: <200809161125.45034.jhb@freebsd.org> On Monday 15 September 2008 06:24:14 pm Matthias Apitz wrote: > El d?a Monday, September 15, 2008 a las 04:08:06PM -0400, John Baldwin escribi?: > > > > > Can you go to frame 7 in kgdb and 'p *fdp'? > > > > > > (kgdb) frame 7 > > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > > > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > > return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); > > > (kgdb) p *fdp > > > Variable "fdp" is not available. > > > (kgdb) > > > > If 'td' is available then you can do 'p *td->td_proc->p_fd' > > (kgdb) frame 7 > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > 136 return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : > fdp->fd_ofiles[fd]); > (kgdb) p td > $7 = (struct thread *) 0xc49d5630 > (kgdb) p *td->td_proc->p_fd > $8 = {fd_ofiles = 0x0, fd_ofileflags = 0x0, fd_cdir = 0x0, Well, fd_ofiles being NULL here is really odd. It's also odd that you have no current directory. Because fd_nfiles is 20, fd_ofiles should be pointing to the static file descriptor array. Off the top of my head I don't see how this is happening. It might help if you can narrow down exactly what WPA operation you are doing that causes the panic. -- John Baldwin From julian at elischer.org Wed Sep 17 01:12:26 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 17 01:12:34 2008 Subject: [CFT/R] IPv4 source address selection In-Reply-To: <20080916183952.A65801@maildrop.int.zabbadoz.net> References: <20080824111925.X66593@maildrop.int.zabbadoz.net> <20080916183952.A65801@maildrop.int.zabbadoz.net> Message-ID: <48D05972.3060509@elischer.org> Bjoern A. Zeeb wrote: > On Sun, 24 Aug 2008, Bjoern A. Zeeb wrote: > > Hi, > >> I have a patch, that was inspired by work from Y!, to do porper >> IPv4 source address selection for unbound sockets (with multi-IP >> jails). >> >> You can temporary find it here: >> http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff >> >> People running my latest jail patches have been ``testing'' this >> without really knowing the last weeks. >> >> In case you wonder why, in the jail case, I loop over the ifa first >> before simply falling back to the primary jail IP (which is the only >> jail IP as in HEAD) -- this is because with the upcoming jail patches >> I have to check if any of possibly lots of IPs match any IP on an >> interface and only if none matches I have to fall back to the 'primary' >> jail IP. >> So the code has been prepared for upcoming changes already. >> >> >> Feel free to test it and report problems or unexpected behavior. >> Unless someone is going to cry it'll hit HEAD in a few days. > > Okay, there was close to zero feedback:( sorry I'm flat out, but very interested.. > > I had Kris test it performance wise and he found a performance regression > and I talked to Robert about the general code a bit more then decided > that I can simplify it. After that I re-ran some performance tests > myself and found that passing in pointers improves things and now we are > at the following with unbound udp sockets: > > x cvs-plain2 > + bz-laddr > +------------------------------------------------------------+ > |+ + + + x x x + x| > | |______________________A_____M________|_______|_A________|| > +------------------------------------------------------------+ > N Min Max Median Avg > Stddev > x 5 498932.16 500399.34 499727.93 499724.08 668.35243 > + 5 496178.62 500190.01 498391.13 497996.98 1649.8572 > No difference proven at 95.0% confidence > > x cvs-plain2-jailed > + bz-laddr-jailed > +------------------------------------------------------------+ > |x + * + xx + x +| > | ||_________________M_AA______M____________|| | > +------------------------------------------------------------+ > N Min Max Median Avg > Stddev > x 5 493049.99 499015.59 497250.89 496364.37 2305.2757 > + 5 493335.46 499712.52 496067.19 496411.24 2431.479 > No difference proven at 95.0% confidence > > > For jails this already has the loops, though I was still trying > with a single (extra) IP only. > > So the latest patch is here: > http://people.freebsd.org/~bz/20080831-01-in_pcbladdr.diff > > I'd really like some review before this goes in especially as it > changes the semantics for jails a bit more. I'll probably time out > by Sunday (UTC) or so; in case you want to look at it but need more > time, let me know and I'll wait. > > /bz > > > PS: I'll also post an updated jail patch for HEAD with this change in case > people want to try that with multi-IP jails. > > >> PS: in case you review this properly (not only glance at it or test >> it) let me know so I can punish you in the Reviewed by: line;-) > From guru at unixarea.de Wed Sep 17 07:28:03 2008 From: guru at unixarea.de (Matthias Apitz) Date: Wed Sep 17 07:28:14 2008 Subject: kern/122331: panic's on KDE-launches (but only in WPA Wifi area) In-Reply-To: <200809161125.45034.jhb@freebsd.org> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151608.06738.jhb@freebsd.org> <20080915222414.GA12474@rebelion.Sisis.de> <200809161125.45034.jhb@freebsd.org> Message-ID: <20080917072747.GA2738@rebelion.Sisis.de> El d?a Tuesday, September 16, 2008 a las 11:25:44AM -0400, John Baldwin escribi?: > Well, fd_ofiles being NULL here is really odd. It's also odd that you have no > current directory. Because fd_nfiles is 20, fd_ofiles should be pointing to > the static file descriptor array. Off the top of my head I don't see how > this is happening. It might help if you can narrow down exactly what WPA > operation you are doing that causes the panic. I'm doing nothing by my own with WPA; the wpa_supplicant is launched at boot time via /etc/rc.conf entry as: ifconfig_iwi0="WPA" i.e. in the moment when I launch the X11+KDE with 'startx' is already running, iwi0 is associated with the AP and IP/routing is up in the interface (I've checked this always with 'ifconfig iwi0'); the difference between my home and the office is WEP (at home where I don't face that problem) and WPA in the office; yesterday and today morning KDE booted fine without causing this panic; could the reason be some inconsistency in the file system? but in this case as well I don't know where this could come from; I have always clean shutdowns before moving from my home to the office: matthias -- Matthias Apitz A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From dchagin at freebsd.org Wed Sep 17 19:02:49 2008 From: dchagin at freebsd.org (Chagin Dmitry) Date: Wed Sep 17 19:02:56 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080917183801.GA2714@dchagin.dialup.corbina.ru> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> Message-ID: <20080917190230.GA2947@dchagin.dialup.corbina.ru> On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote: > > Please review, any comment will be helpful. > thnx! > ups... I have lost a new file, the previous patch is incorrect. sorry. diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h index 8940289..9439900 100644 --- a/src/sys/amd64/linux32/linux.h +++ b/src/sys/amd64/linux32/linux.h @@ -685,6 +685,7 @@ union l_semun { #define LINUX_SO_NO_CHECK 11 #define LINUX_SO_PRIORITY 12 #define LINUX_SO_LINGER 13 +#define LINUX_SO_PASSCRED 16 #define LINUX_SO_PEERCRED 17 #define LINUX_SO_RCVLOWAT 18 #define LINUX_SO_SNDLOWAT 19 @@ -709,6 +710,28 @@ struct l_sockaddr { char sa_data[14]; } __packed; +struct l_msghdr { + l_uintptr_t msg_name; + l_int msg_namelen; + l_uintptr_t msg_iov; + l_size_t msg_iovlen; + l_uintptr_t msg_control; + l_size_t msg_controllen; + l_uint msg_flags; +} __packed; + +struct l_cmsghdr { + l_size_t cmsg_len; + l_int cmsg_level; + l_int cmsg_type; +} __packed; + +struct l_ucred { + uint32_t pid; + uint32_t uid; + uint32_t gid; +} __packed; + struct l_ifmap { l_ulong mem_start; l_ulong mem_end; diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h new file mode 100644 index 0000000..c1a9f1c --- /dev/null +++ b/src/sys/amd64/linux32/linux32_io.h @@ -0,0 +1,47 @@ +/*- + * Copyright (c) 2004 Tim J. Robbins + * Copyright (c) 2001 Doug Rabson + * Copyright (c) 1994-1996 S?ren Schmidt + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _AMD64_LINUX32_IO_H_ +#define _AMD64_LINUX32_IO_H_ + + +struct iovec32 { + u_int32_t iov_base; + int iov_len; +}; + +CTASSERT(sizeof(struct iovec32) == 8); + +int linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp, + int error); + +#endif /* !_AMD64_LINUX32_IO_H_ */ diff --git a/src/sys/amd64/linux32/linux32_machdep.c b/src/sys/amd64/linux32/linux32_machdep.c index 32cbe0b..26459c9 100644 --- a/src/sys/amd64/linux32/linux32_machdep.c +++ b/src/sys/amd64/linux32/linux32_machdep.c @@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v 1.49 2008/09/08 09 #include #include +#include #include #include #include @@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args *args) return (error); } -struct iovec32 { - u_int32_t iov_base; - int iov_len; -}; - -CTASSERT(sizeof(struct iovec32) == 8); - static int linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop) { @@ -281,6 +275,34 @@ linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop) } int +linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp, + int error) +{ + struct iovec32 iov32; + struct iovec *iov; + u_int iovlen; + int i; + + *iovp = NULL; + if (iovcnt > UIO_MAXIOV) + return (error); + iovlen = iovcnt * sizeof(struct iovec); + iov = malloc(iovlen, M_IOV, M_WAITOK); + for (i = 0; i < iovcnt; i++) { + error = copyin(&iovp32[i], &iov32, sizeof(struct iovec32)); + if (error) { + free(iov, M_IOV); + return (error); + } + iov[i].iov_base = PTRIN(iov32.iov_base); + iov[i].iov_len = iov32.iov_len; + } + *iovp = iov; + return(0); + +} + +int linux_readv(struct thread *td, struct linux_readv_args *uap) { struct uio *auio; diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c index f97aa23..34e25dc 100644 --- a/src/sys/compat/linux/linux_socket.c +++ b/src/sys/compat/linux/linux_socket.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: src/sys/compat/linux/linux_socket.c,v 1.76 2008/09/09 13:01: #ifdef COMPAT_LINUX32 #include +#include #include #else #include @@ -294,6 +295,8 @@ linux_to_bsd_so_sockopt(int opt) return (SO_OOBINLINE); case LINUX_SO_LINGER: return (SO_LINGER); + case LINUX_SO_PASSCRED: + return (LOCAL_CREDS); case LINUX_SO_PEERCRED: return (LOCAL_PEERCRED); case LINUX_SO_RCVLOWAT: @@ -421,6 +424,63 @@ linux_sa_put(struct osockaddr *osa) } static int +linux_to_bsd_cmsg_type(int cmsg_type) +{ + + switch (cmsg_type) { + case LINUX_SCM_RIGHTS: + return (SCM_RIGHTS); + case LINUX_SCM_CREDENTIALS: + return (SCM_CREDS); + } + return (cmsg_type); +} + +static int +bsd_to_linux_cmsg_type(int cmsg_type) +{ + + switch (cmsg_type) { + case SCM_RIGHTS: + return (LINUX_SCM_RIGHTS); + case SCM_CREDS: + return (LINUX_SCM_CREDENTIALS); + } + return (cmsg_type); +} + + + +static int +linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr) +{ + if (lhdr->msg_controllen > INT_MAX) + return (ENOBUFS); + + bhdr->msg_name = PTRIN(lhdr->msg_name); + bhdr->msg_namelen = lhdr->msg_namelen; + bhdr->msg_iov = PTRIN(lhdr->msg_iov); + bhdr->msg_iovlen = lhdr->msg_iovlen; + bhdr->msg_control = PTRIN(lhdr->msg_control); + bhdr->msg_controllen = lhdr->msg_controllen; + bhdr->msg_flags = linux_to_bsd_msg_flags(lhdr->msg_flags); + return (0); +} + +static int +bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr) +{ + lhdr->msg_name = PTROUT(bhdr->msg_name); + lhdr->msg_namelen = bhdr->msg_namelen; + lhdr->msg_iov = PTROUT(bhdr->msg_iov); + lhdr->msg_iovlen = bhdr->msg_iovlen; + lhdr->msg_control = PTROUT(bhdr->msg_control); + lhdr->msg_controllen = bhdr->msg_controllen; + /* msg_flags skipped */ + return (0); +} + +static int linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags, enum uio_seg segflg) { @@ -437,25 +497,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags, to = NULL; if (mp->msg_control != NULL) { + struct l_cmsghdr *ptr_cmsg; + struct l_cmsghdr linux_cmsg; struct cmsghdr *cmsg; - - if (mp->msg_controllen < sizeof(struct cmsghdr)) { - error = EINVAL; - goto bad; - } - error = sockargs(&control, mp->msg_control, - mp->msg_controllen, MT_CONTROL); - if (error) - goto bad; - - cmsg = mtod(control, struct cmsghdr *); - cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level); + void *data; + socklen_t datalen; + + cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); + control = m_get(M_WAIT, MT_CONTROL); + ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp); + + do { + error = copyin(ptr_cmsg, &linux_cmsg, + sizeof(struct l_cmsghdr)); + if (error) + goto bad; + if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) || + linux_cmsg.cmsg_len > INT_MAX) { + error = EINVAL; + goto bad; + } + + switch (linux_cmsg.cmsg_type) { + case LINUX_SCM_RIGHTS: + cmsg->cmsg_type = + linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type); + break; + default: + error = EINVAL; + goto bad; + } + cmsg->cmsg_level = + linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level); + + datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ; + cmsg->cmsg_len = CMSG_LEN(datalen); + data = LINUX_CMSG_DATA(ptr_cmsg); + + error = ENOBUFS; + if (!m_append(control, CMSG_HDRSZ, (c_caddr_t) cmsg)) + goto bad; + if (!m_append(control, datalen, (c_caddr_t) data)) + goto bad; + + } while ((ptr_cmsg = LINUX_CMSG_NXTHDR(mp, ptr_cmsg))); + + free(cmsg, M_TEMP); } else control = NULL; error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control, segflg); - bad: if (to) FREE(to, M_SONAME); @@ -960,12 +1052,14 @@ static int linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) { struct msghdr msg; + struct l_msghdr linux_msg; struct iovec *iov; int error; - /* XXXTJR sendmsg is broken on amd64 */ - - error = copyin(PTRIN(args->msg), &msg, sizeof(msg)); + error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); + if (error) + return (error); + error = linux_to_bsd_msghdr(&msg, &linux_msg); if (error) return (error); @@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) */ if (msg.msg_control != NULL && msg.msg_controllen == 0) msg.msg_control = NULL; + +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); - if (error) - return (error); +#endif msg.msg_iov = iov; msg.msg_flags = 0; error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE); @@ -997,44 +1095,168 @@ struct linux_recvmsg_args { static int linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args) { - struct recvmsg_args /* { - int s; - struct msghdr *msg; - int flags; - } */ bsd_args; struct msghdr msg; - struct cmsghdr *cmsg; + struct l_msghdr linux_msg; + struct l_cmsghdr *linux_cmsg = NULL; + struct iovec *iov, *uiov; + struct mbuf *control = NULL; + struct mbuf **controlp; int error; - /* XXXTJR recvmsg is broken on amd64 */ + error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); + if (error) + return (error); - if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg)))) + error = linux_to_bsd_msghdr(&msg, &linux_msg); + if (error) return (error); - bsd_args.s = args->s; - bsd_args.msg = PTRIN(args->msg); - bsd_args.flags = linux_to_bsd_msg_flags(args->flags); - if (msg.msg_name) { - linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name, - msg.msg_namelen); - error = recvmsg(td, &bsd_args); - bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name); - } else - error = recvmsg(td, &bsd_args); +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else + error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); +#endif if (error) return (error); - if (bsd_args.msg->msg_control != NULL && - bsd_args.msg->msg_controllen > 0) { - cmsg = (struct cmsghdr*)bsd_args.msg->msg_control; - cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level); + if (msg.msg_name) { + error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name, + msg.msg_namelen); + if (error) + goto bad; } - error = copyin(PTRIN(args->msg), &msg, sizeof(msg)); + uiov = msg.msg_iov; + msg.msg_iov = iov; + controlp = (msg.msg_control != NULL) ? &control : NULL; + error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp); + msg.msg_iov = uiov; if (error) - return (error); - if (msg.msg_name && msg.msg_namelen > 2) - error = linux_sa_put(msg.msg_name); + goto bad; + + error = bsd_to_linux_msghdr(&msg, &linux_msg); + if (error) + goto bad; + + if (linux_msg.msg_name) { + error = bsd_to_linux_sockaddr((struct sockaddr *) + PTRIN(linux_msg.msg_name)); + if (error) + goto bad; + } + if (linux_msg.msg_name && linux_msg.msg_namelen > 2) { + error = linux_sa_put(PTRIN(linux_msg.msg_name)); + if (error) + goto bad; + } + + if (control) { + caddr_t outbuf; + struct cmsghdr *cm; + socklen_t datalen, outlen; + socklen_t clen; + void *data; + struct sockcred *scred; + struct l_ucred lcred; + + linux_cmsg = malloc(L_CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); + outbuf = PTRIN(linux_msg.msg_control); + cm = mtod(control, struct cmsghdr *); + outlen = 0; + clen = control->m_len; + + while (cm != NULL) { + + switch (cm->cmsg_type) { + case SCM_CREDS: + + scred = (struct sockcred *)CMSG_DATA(cm); + datalen = (caddr_t)cm + cm->cmsg_len - + (caddr_t)scred; + + if (outlen + LINUX_CMSG_LEN(sizeof(lcred)) > + linux_msg.msg_controllen) { + linux_msg.msg_flags |= LINUX_MSG_CTRUNC; + goto out; + } + + lcred.pid = -1; + lcred.uid = scred->sc_uid; + lcred.gid = scred->sc_gid; + + linux_cmsg->cmsg_len = + LINUX_CMSG_LEN(sizeof(lcred)); + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + + error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); + if (error) + goto bad; + outbuf += L_CMSG_HDRSZ; + + error = copyout(&lcred, outbuf, sizeof(lcred)); + if (error) + goto bad; + + outbuf += LINUX_CMSG_ALIGN(sizeof(lcred)); + outlen += LINUX_CMSG_LEN(sizeof(lcred)); + linux_msg.msg_controllen = outlen; + break; + + default: + + data = CMSG_DATA(cm); + datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data; + + if (outlen + LINUX_CMSG_LEN(datalen) > + linux_msg.msg_controllen) { + linux_msg.msg_flags |= LINUX_MSG_CTRUNC; + goto out; + } + + linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen); + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + + error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); + if (error) + goto bad; + outbuf += L_CMSG_HDRSZ; + + error = copyout(data, outbuf, datalen); + if (error) + goto bad; + + outbuf += LINUX_CMSG_ALIGN(datalen); + outlen += LINUX_CMSG_LEN(datalen); + linux_msg.msg_controllen = outlen; + break; + } + + if (CMSG_SPACE(datalen) < clen) { + clen -= CMSG_SPACE(datalen); + cm = (struct cmsghdr *) + ((caddr_t)cm + CMSG_SPACE(datalen)); + } else + cm = NULL; + } + } + +out: + error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg)); + +bad: + free(iov, M_IOV); + if (control != NULL) + m_freem(control); + if (linux_cmsg != NULL) + free(linux_cmsg, M_TEMP); + return (error); } @@ -1081,6 +1303,12 @@ linux_setsockopt(struct thread *td, struct linux_setsockopt_args *args) switch (bsd_args.level) { case SOL_SOCKET: name = linux_to_bsd_so_sockopt(args->optname); + switch (args->optname) { + case LINUX_SO_PASSCRED: + /* FreeBSD bug? socket level opts at non socket level */ + bsd_args.level = 0; + break; + } break; case IPPROTO_IP: name = linux_to_bsd_ip_sockopt(args->optname); @@ -1136,6 +1364,11 @@ linux_getsockopt(struct thread *td, struct linux_getsockopt_args *args) switch (bsd_args.level) { case SOL_SOCKET: name = linux_to_bsd_so_sockopt(args->optname); + switch (args->optname) { + case LINUX_SO_PASSCRED: + bsd_args.level = 0; + break; + } break; case IPPROTO_IP: name = linux_to_bsd_ip_sockopt(args->optname); diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h index 074e8e0..e8c2ec8 100644 --- a/src/sys/compat/linux/linux_socket.h +++ b/src/sys/compat/linux/linux_socket.h @@ -49,4 +49,36 @@ #define LINUX_MSG_ERRQUEUE 0x2000 #define LINUX_MSG_NOSIGNAL 0x4000 +/* Socket-level control message types */ + +#define LINUX_SCM_RIGHTS 0x01 +#define LINUX_SCM_CREDENTIALS 0x02 + +/* Ancilliary data object information macros */ + +#define LINUX_CMSG_ALIGN(len) (((len) + sizeof(l_long)-1) & ~(sizeof(l_long)-1)) +#define LINUX_CMSG_DATA(cmsg) ((void *)((char *)(cmsg) + \ + LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)))) +#define LINUX_CMSG_SPACE(len) (LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \ + LINUX_CMSG_ALIGN(len)) +#define LINUX_CMSG_LEN(len) (LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \ + (len)) +#define LINUX_CMSG_FIRSTHDR(msg) \ + ((msg)->msg_controllen >= \ + sizeof(struct l_cmsghdr) ? \ + (struct l_cmsghdr *)((msg)->msg_control) : \ + (struct l_cmsghdr *)(NULL)) +#define LINUX_CMSG_NXTHDR(msg, cmsg) \ + ((((char *)(cmsg) + \ + LINUX_CMSG_ALIGN((cmsg)->cmsg_len) + \ + sizeof(*(cmsg))) > \ + (((char *)(msg)->msg_control) + \ + (msg)->msg_controllen)) ? \ + (struct l_cmsghdr *) NULL : \ + (struct l_cmsghdr *)((char *)(cmsg) + \ + LINUX_CMSG_ALIGN((cmsg)->cmsg_len))) + +#define CMSG_HDRSZ CMSG_LEN(0) +#define L_CMSG_HDRSZ LINUX_CMSG_LEN(0) + #endif /* _LINUX_SOCKET_H_ */ diff --git a/src/sys/i386/linux/linux.h b/src/sys/i386/linux/linux.h index 1c3627d..28655fe 100644 --- a/src/sys/i386/linux/linux.h +++ b/src/sys/i386/linux/linux.h @@ -656,6 +656,7 @@ union l_semun { #define LINUX_SO_NO_CHECK 11 #define LINUX_SO_PRIORITY 12 #define LINUX_SO_LINGER 13 +#define LINUX_SO_PASSCRED 16 #define LINUX_SO_PEERCRED 17 #define LINUX_SO_RCVLOWAT 18 #define LINUX_SO_SNDLOWAT 19 @@ -680,6 +681,28 @@ struct l_sockaddr { char sa_data[14]; }; +struct l_msghdr { + l_uintptr_t msg_name; + l_int msg_namelen; + l_uintptr_t msg_iov; + l_size_t msg_iovlen; + l_uintptr_t msg_control; + l_size_t msg_controllen; + l_uint msg_flags; +}; + +struct l_cmsghdr { + l_size_t cmsg_len; + l_int cmsg_level; + l_int cmsg_type; +}; + +struct l_ucred { + uint32_t pid; + uint32_t uid; + uint32_t gid; +}; + struct l_ifmap { l_ulong mem_start; l_ulong mem_end; -- Have fun! chd From dchagin at freebsd.org Wed Sep 17 19:08:23 2008 From: dchagin at freebsd.org (Chagin Dmitry) Date: Wed Sep 17 19:08:30 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080902085623.GA12395@freebsd.org> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> Message-ID: <20080917183801.GA2714@dchagin.dialup.corbina.ru> On Tue, Sep 02, 2008 at 10:56:23AM +0200, Roman Divacky wrote: > On Sun, Aug 31, 2008 at 03:06:10PM +0400, Chagin Dmitry wrote: > > On Fri, Aug 22, 2008 at 01:29:46PM +0200, Roman Divacky wrote: > > > On Fri, Aug 22, 2008 at 01:29:27PM +0200, Ed Schouten wrote: > > > > Hello Emulation folks, > > > > > > > > I just wanted to send you all a message to say one of the things I tried > > > > to improve in the MPSAFE TTY branch was support for PTY's for Linux > > > > binaries. > > > > > > > > At home I've got a FreeBSD Jail running Debian Etch. Unfortunately, > > > > Linux sendmsg() is a little broken on FreeBSD/amd64, but so far I've > > > > been able to at least get OpenSSH (as root) and GNU Screen working. > > > > > > I believe dmitry has a patch for this.. > > > > the patch is bellow, I tested a patch only on LTP tests (with little changes), > > it's necessary to test on real apps, it will be good if Ed will test.. > > this should be reviewed by someone with a knowledge of how networking works in > FreeBSD. Any volunteer? Dmitry, can you send a mail to net@ describing the changes > in the patch and ask for a review there? > Hi, So, a patch bellow. The patch corrects sendmsg() recvmsg() in our linuxulator, also adds SO_PASSCRED option to linuxulator setsockopt() getsockopt() it's necessary for implementing Linux analogue of FreeBSD SCM_CREDS control message. I have tested it on i386 && ia32@amd64 linuxulators, it works for me now. Please review, any comment will be helpful. thnx! diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h index 8940289..9439900 100644 --- a/src/sys/amd64/linux32/linux.h +++ b/src/sys/amd64/linux32/linux.h @@ -685,6 +685,7 @@ union l_semun { #define LINUX_SO_NO_CHECK 11 #define LINUX_SO_PRIORITY 12 #define LINUX_SO_LINGER 13 +#define LINUX_SO_PASSCRED 16 #define LINUX_SO_PEERCRED 17 #define LINUX_SO_RCVLOWAT 18 #define LINUX_SO_SNDLOWAT 19 @@ -709,6 +710,28 @@ struct l_sockaddr { char sa_data[14]; } __packed; +struct l_msghdr { + l_uintptr_t msg_name; + l_int msg_namelen; + l_uintptr_t msg_iov; + l_size_t msg_iovlen; + l_uintptr_t msg_control; + l_size_t msg_controllen; + l_uint msg_flags; +} __packed; + +struct l_cmsghdr { + l_size_t cmsg_len; + l_int cmsg_level; + l_int cmsg_type; +} __packed; + +struct l_ucred { + uint32_t pid; + uint32_t uid; + uint32_t gid; +} __packed; + struct l_ifmap { l_ulong mem_start; l_ulong mem_end; diff --git a/src/sys/amd64/linux32/linux32_machdep.c b/src/sys/amd64/linux32/linux32_machdep.c index 32cbe0b..26459c9 100644 --- a/src/sys/amd64/linux32/linux32_machdep.c +++ b/src/sys/amd64/linux32/linux32_machdep.c @@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v 1.49 2008/09/08 09 #include #include +#include #include #include #include @@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args *args) return (error); } -struct iovec32 { - u_int32_t iov_base; - int iov_len; -}; - -CTASSERT(sizeof(struct iovec32) == 8); - static int linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop) { @@ -281,6 +275,34 @@ linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop) } int +linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp, + int error) +{ + struct iovec32 iov32; + struct iovec *iov; + u_int iovlen; + int i; + + *iovp = NULL; + if (iovcnt > UIO_MAXIOV) + return (error); + iovlen = iovcnt * sizeof(struct iovec); + iov = malloc(iovlen, M_IOV, M_WAITOK); + for (i = 0; i < iovcnt; i++) { + error = copyin(&iovp32[i], &iov32, sizeof(struct iovec32)); + if (error) { + free(iov, M_IOV); + return (error); + } + iov[i].iov_base = PTRIN(iov32.iov_base); + iov[i].iov_len = iov32.iov_len; + } + *iovp = iov; + return(0); + +} + +int linux_readv(struct thread *td, struct linux_readv_args *uap) { struct uio *auio; diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c index f97aa23..34e25dc 100644 --- a/src/sys/compat/linux/linux_socket.c +++ b/src/sys/compat/linux/linux_socket.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: src/sys/compat/linux/linux_socket.c,v 1.76 2008/09/09 13:01: #ifdef COMPAT_LINUX32 #include +#include #include #else #include @@ -294,6 +295,8 @@ linux_to_bsd_so_sockopt(int opt) return (SO_OOBINLINE); case LINUX_SO_LINGER: return (SO_LINGER); + case LINUX_SO_PASSCRED: + return (LOCAL_CREDS); case LINUX_SO_PEERCRED: return (LOCAL_PEERCRED); case LINUX_SO_RCVLOWAT: @@ -421,6 +424,63 @@ linux_sa_put(struct osockaddr *osa) } static int +linux_to_bsd_cmsg_type(int cmsg_type) +{ + + switch (cmsg_type) { + case LINUX_SCM_RIGHTS: + return (SCM_RIGHTS); + case LINUX_SCM_CREDENTIALS: + return (SCM_CREDS); + } + return (cmsg_type); +} + +static int +bsd_to_linux_cmsg_type(int cmsg_type) +{ + + switch (cmsg_type) { + case SCM_RIGHTS: + return (LINUX_SCM_RIGHTS); + case SCM_CREDS: + return (LINUX_SCM_CREDENTIALS); + } + return (cmsg_type); +} + + + +static int +linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr) +{ + if (lhdr->msg_controllen > INT_MAX) + return (ENOBUFS); + + bhdr->msg_name = PTRIN(lhdr->msg_name); + bhdr->msg_namelen = lhdr->msg_namelen; + bhdr->msg_iov = PTRIN(lhdr->msg_iov); + bhdr->msg_iovlen = lhdr->msg_iovlen; + bhdr->msg_control = PTRIN(lhdr->msg_control); + bhdr->msg_controllen = lhdr->msg_controllen; + bhdr->msg_flags = linux_to_bsd_msg_flags(lhdr->msg_flags); + return (0); +} + +static int +bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr) +{ + lhdr->msg_name = PTROUT(bhdr->msg_name); + lhdr->msg_namelen = bhdr->msg_namelen; + lhdr->msg_iov = PTROUT(bhdr->msg_iov); + lhdr->msg_iovlen = bhdr->msg_iovlen; + lhdr->msg_control = PTROUT(bhdr->msg_control); + lhdr->msg_controllen = bhdr->msg_controllen; + /* msg_flags skipped */ + return (0); +} + +static int linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags, enum uio_seg segflg) { @@ -437,25 +497,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags, to = NULL; if (mp->msg_control != NULL) { + struct l_cmsghdr *ptr_cmsg; + struct l_cmsghdr linux_cmsg; struct cmsghdr *cmsg; - - if (mp->msg_controllen < sizeof(struct cmsghdr)) { - error = EINVAL; - goto bad; - } - error = sockargs(&control, mp->msg_control, - mp->msg_controllen, MT_CONTROL); - if (error) - goto bad; - - cmsg = mtod(control, struct cmsghdr *); - cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level); + void *data; + socklen_t datalen; + + cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); + control = m_get(M_WAIT, MT_CONTROL); + ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp); + + do { + error = copyin(ptr_cmsg, &linux_cmsg, + sizeof(struct l_cmsghdr)); + if (error) + goto bad; + if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) || + linux_cmsg.cmsg_len > INT_MAX) { + error = EINVAL; + goto bad; + } + + switch (linux_cmsg.cmsg_type) { + case LINUX_SCM_RIGHTS: + cmsg->cmsg_type = + linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type); + break; + default: + error = EINVAL; + goto bad; + } + cmsg->cmsg_level = + linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level); + + datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ; + cmsg->cmsg_len = CMSG_LEN(datalen); + data = LINUX_CMSG_DATA(ptr_cmsg); + + error = ENOBUFS; + if (!m_append(control, CMSG_HDRSZ, (c_caddr_t) cmsg)) + goto bad; + if (!m_append(control, datalen, (c_caddr_t) data)) + goto bad; + + } while ((ptr_cmsg = LINUX_CMSG_NXTHDR(mp, ptr_cmsg))); + + free(cmsg, M_TEMP); } else control = NULL; error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control, segflg); - bad: if (to) FREE(to, M_SONAME); @@ -960,12 +1052,14 @@ static int linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) { struct msghdr msg; + struct l_msghdr linux_msg; struct iovec *iov; int error; - /* XXXTJR sendmsg is broken on amd64 */ - - error = copyin(PTRIN(args->msg), &msg, sizeof(msg)); + error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); + if (error) + return (error); + error = linux_to_bsd_msghdr(&msg, &linux_msg); if (error) return (error); @@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) */ if (msg.msg_control != NULL && msg.msg_controllen == 0) msg.msg_control = NULL; + +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); - if (error) - return (error); +#endif msg.msg_iov = iov; msg.msg_flags = 0; error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE); @@ -997,44 +1095,168 @@ struct linux_recvmsg_args { static int linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args) { - struct recvmsg_args /* { - int s; - struct msghdr *msg; - int flags; - } */ bsd_args; struct msghdr msg; - struct cmsghdr *cmsg; + struct l_msghdr linux_msg; + struct l_cmsghdr *linux_cmsg = NULL; + struct iovec *iov, *uiov; + struct mbuf *control = NULL; + struct mbuf **controlp; int error; - /* XXXTJR recvmsg is broken on amd64 */ + error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); + if (error) + return (error); - if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg)))) + error = linux_to_bsd_msghdr(&msg, &linux_msg); + if (error) return (error); - bsd_args.s = args->s; - bsd_args.msg = PTRIN(args->msg); - bsd_args.flags = linux_to_bsd_msg_flags(args->flags); - if (msg.msg_name) { - linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name, - msg.msg_namelen); - error = recvmsg(td, &bsd_args); - bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name); - } else - error = recvmsg(td, &bsd_args); +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else + error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); +#endif if (error) return (error); - if (bsd_args.msg->msg_control != NULL && - bsd_args.msg->msg_controllen > 0) { - cmsg = (struct cmsghdr*)bsd_args.msg->msg_control; - cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level); + if (msg.msg_name) { + error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name, + msg.msg_namelen); + if (error) + goto bad; } - error = copyin(PTRIN(args->msg), &msg, sizeof(msg)); + uiov = msg.msg_iov; + msg.msg_iov = iov; + controlp = (msg.msg_control != NULL) ? &control : NULL; + error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp); + msg.msg_iov = uiov; if (error) - return (error); - if (msg.msg_name && msg.msg_namelen > 2) - error = linux_sa_put(msg.msg_name); + goto bad; + + error = bsd_to_linux_msghdr(&msg, &linux_msg); + if (error) + goto bad; + + if (linux_msg.msg_name) { + error = bsd_to_linux_sockaddr((struct sockaddr *) + PTRIN(linux_msg.msg_name)); + if (error) + goto bad; + } + if (linux_msg.msg_name && linux_msg.msg_namelen > 2) { + error = linux_sa_put(PTRIN(linux_msg.msg_name)); + if (error) + goto bad; + } + + if (control) { + caddr_t outbuf; + struct cmsghdr *cm; + socklen_t datalen, outlen; + socklen_t clen; + void *data; + struct sockcred *scred; + struct l_ucred lcred; + + linux_cmsg = malloc(L_CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); + outbuf = PTRIN(linux_msg.msg_control); + cm = mtod(control, struct cmsghdr *); + outlen = 0; + clen = control->m_len; + + while (cm != NULL) { + + switch (cm->cmsg_type) { + case SCM_CREDS: + + scred = (struct sockcred *)CMSG_DATA(cm); + datalen = (caddr_t)cm + cm->cmsg_len - + (caddr_t)scred; + + if (outlen + LINUX_CMSG_LEN(sizeof(lcred)) > + linux_msg.msg_controllen) { + linux_msg.msg_flags |= LINUX_MSG_CTRUNC; + goto out; + } + + lcred.pid = -1; + lcred.uid = scred->sc_uid; + lcred.gid = scred->sc_gid; + + linux_cmsg->cmsg_len = + LINUX_CMSG_LEN(sizeof(lcred)); + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + + error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); + if (error) + goto bad; + outbuf += L_CMSG_HDRSZ; + + error = copyout(&lcred, outbuf, sizeof(lcred)); + if (error) + goto bad; + + outbuf += LINUX_CMSG_ALIGN(sizeof(lcred)); + outlen += LINUX_CMSG_LEN(sizeof(lcred)); + linux_msg.msg_controllen = outlen; + break; + + default: + + data = CMSG_DATA(cm); + datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data; + + if (outlen + LINUX_CMSG_LEN(datalen) > + linux_msg.msg_controllen) { + linux_msg.msg_flags |= LINUX_MSG_CTRUNC; + goto out; + } + + linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen); + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + + error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); + if (error) + goto bad; + outbuf += L_CMSG_HDRSZ; + + error = copyout(data, outbuf, datalen); + if (error) + goto bad; + + outbuf += LINUX_CMSG_ALIGN(datalen); + outlen += LINUX_CMSG_LEN(datalen); + linux_msg.msg_controllen = outlen; + break; + } + + if (CMSG_SPACE(datalen) < clen) { + clen -= CMSG_SPACE(datalen); + cm = (struct cmsghdr *) + ((caddr_t)cm + CMSG_SPACE(datalen)); + } else + cm = NULL; + } + } + +out: + error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg)); + +bad: + free(iov, M_IOV); + if (control != NULL) + m_freem(control); + if (linux_cmsg != NULL) + free(linux_cmsg, M_TEMP); + return (error); } @@ -1081,6 +1303,12 @@ linux_setsockopt(struct thread *td, struct linux_setsockopt_args *args) switch (bsd_args.level) { case SOL_SOCKET: name = linux_to_bsd_so_sockopt(args->optname); + switch (args->optname) { + case LINUX_SO_PASSCRED: + /* FreeBSD bug? socket level opts at non socket level */ + bsd_args.level = 0; + break; + } break; case IPPROTO_IP: name = linux_to_bsd_ip_sockopt(args->optname); @@ -1136,6 +1364,11 @@ linux_getsockopt(struct thread *td, struct linux_getsockopt_args *args) switch (bsd_args.level) { case SOL_SOCKET: name = linux_to_bsd_so_sockopt(args->optname); + switch (args->optname) { + case LINUX_SO_PASSCRED: + bsd_args.level = 0; + break; + } break; case IPPROTO_IP: name = linux_to_bsd_ip_sockopt(args->optname); diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h index 074e8e0..e8c2ec8 100644 --- a/src/sys/compat/linux/linux_socket.h +++ b/src/sys/compat/linux/linux_socket.h @@ -49,4 +49,36 @@ #define LINUX_MSG_ERRQUEUE 0x2000 #define LINUX_MSG_NOSIGNAL 0x4000 +/* Socket-level control message types */ + +#define LINUX_SCM_RIGHTS 0x01 +#define LINUX_SCM_CREDENTIALS 0x02 + +/* Ancilliary data object information macros */ + +#define LINUX_CMSG_ALIGN(len) (((len) + sizeof(l_long)-1) & ~(sizeof(l_long)-1)) +#define LINUX_CMSG_DATA(cmsg) ((void *)((char *)(cmsg) + \ + LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)))) +#define LINUX_CMSG_SPACE(len) (LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \ + LINUX_CMSG_ALIGN(len)) +#define LINUX_CMSG_LEN(len) (LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \ + (len)) +#define LINUX_CMSG_FIRSTHDR(msg) \ + ((msg)->msg_controllen >= \ + sizeof(struct l_cmsghdr) ? \ + (struct l_cmsghdr *)((msg)->msg_control) : \ + (struct l_cmsghdr *)(NULL)) +#define LINUX_CMSG_NXTHDR(msg, cmsg) \ + ((((char *)(cmsg) + \ + LINUX_CMSG_ALIGN((cmsg)->cmsg_len) + \ + sizeof(*(cmsg))) > \ + (((char *)(msg)->msg_control) + \ + (msg)->msg_controllen)) ? \ + (struct l_cmsghdr *) NULL : \ + (struct l_cmsghdr *)((char *)(cmsg) + \ + LINUX_CMSG_ALIGN((cmsg)->cmsg_len))) + +#define CMSG_HDRSZ CMSG_LEN(0) +#define L_CMSG_HDRSZ LINUX_CMSG_LEN(0) + #endif /* _LINUX_SOCKET_H_ */ diff --git a/src/sys/i386/linux/linux.h b/src/sys/i386/linux/linux.h index 1c3627d..28655fe 100644 --- a/src/sys/i386/linux/linux.h +++ b/src/sys/i386/linux/linux.h @@ -656,6 +656,7 @@ union l_semun { #define LINUX_SO_NO_CHECK 11 #define LINUX_SO_PRIORITY 12 #define LINUX_SO_LINGER 13 +#define LINUX_SO_PASSCRED 16 #define LINUX_SO_PEERCRED 17 #define LINUX_SO_RCVLOWAT 18 #define LINUX_SO_SNDLOWAT 19 @@ -680,6 +681,28 @@ struct l_sockaddr { char sa_data[14]; }; +struct l_msghdr { + l_uintptr_t msg_name; + l_int msg_namelen; + l_uintptr_t msg_iov; + l_size_t msg_iovlen; + l_uintptr_t msg_control; + l_size_t msg_controllen; + l_uint msg_flags; +}; + +struct l_cmsghdr { + l_size_t cmsg_len; + l_int cmsg_level; + l_int cmsg_type; +}; + +struct l_ucred { + uint32_t pid; + uint32_t uid; + uint32_t gid; +}; + struct l_ifmap { l_ulong mem_start; l_ulong mem_end; -- Have fun! chd From =?koi8-r?Q?=EC=CF=D4=C3_=E1=CE=D4=CF=CE_?= Thu Sep 18 04:00:12 2008 From: =?koi8-r?Q?=EC=CF=D4=C3_=E1=CE=D4=CF=CE_?= (=?koi8-r?Q?=EC=CF=D4=C3_=E1=CE=D4=CF=CE_?=) Date: Thu Sep 18 04:00:18 2008 Subject: kern/122794: [lagg] Kernel panic after brings lagg(8) up if NICs are not bringed up before Message-ID: <200809180400.m8I40BbM049536@freefall.freebsd.org> The following reply was made to PR kern/122794; it has been noted by GNATS. From: =?koi8-r?Q?=EC=CF=D4=C3_=E1=CE=D4=CF=CE_?= =?koi8-r?Q?=F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE?= To: bug-followup@FreeBSD.org, robhass@gmail.com Cc: Subject: Re: kern/122794: [lagg] Kernel panic after brings lagg(8) up if NICs are not bringed up before Date: Thu, 18 Sep 2008 09:08:56 +0600 --=-pYK/Vjp63XwXQm/bEEhQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello I have found similar problem: kernel panic occurs if you try to use lagg interface without any laggport configured. Is this the same problem? There are at least two way to reproduce problem: 1. Boot to single-user mode and issue commands ifconfig lagg0 create ifconfig lagg0 laggproto loadbalance # does it really need to crash? ifconfig lagg0 inet 10.10.10.10 netmask 255.255.255.0 Kernel panic follows (possible need to send a packet) Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x80441f38 stack pointer = 0x28:0xec046988 frame pointer = 0x28:0xec04699c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 57 (ifconfig) trap number = 18 panic: integer divide fault cpuid = 0 Uptime: 3m5s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort 2. Boot to any network-enabled mode and remove all laggport from the lagg interface. Kernel panic follows (possible need to send a packet). ifconfig lagg0 -laggport bce0 ping 10.10.10.11 Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x80441f38 stack pointer = 0x28:0xec0a19ec frame pointer = 0x28:0xec0a1a00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 52383 (ping) trap number = 18 panic: integer divide fault cpuid = 0 Uptime: 13m53s Physical memory: 4086 MB Dumping 128 MB: 113 97 81 65 49 33 17 1 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Possible solution could be following: *** if_lagg.c-orig Thu Sep 18 08:29:25 2008 --- if_lagg.c Thu Sep 18 08:32:39 2008 *************** *** 1403,1408 **** --- 1403,1412 ---- uint32_t p; p = atomic_fetchadd_32(&sc->sc_seq, 1); + if (sc->sc_count == 0) { + m_freem(m); + return (ENOENT); + } p %= sc->sc_count; lp = SLIST_FIRST(&sc->sc_ports); while (p--) *************** *** 1580,1585 **** --- 1584,1593 ---- int idx; p = lagg_hashmbuf(m, lb->lb_key); + if (sc->sc_count == 0) { + m_freem(m); + return (ENOENT); + } if ((idx = p % sc->sc_count) >= LAGG_MAX_PORTS) { m_freem(m); return (EINVAL); I'm not a qualified kernel-hacker so please provide a better solution. Regards -- Anton Lotts --=-pYK/Vjp63XwXQm/bEEhQ Content-Disposition: attachment; filename=lagg.patch Content-Type: text/x-patch; name=lagg.patch; charset=utf-8 Content-Transfer-Encoding: 7bit *** if_lagg.c-orig Thu Sep 18 08:29:25 2008 --- if_lagg.c Thu Sep 18 08:32:39 2008 *************** *** 1403,1408 **** --- 1403,1412 ---- uint32_t p; p = atomic_fetchadd_32(&sc->sc_seq, 1); + if (sc->sc_count == 0) { + m_freem(m); + return (ENOENT); + } p %= sc->sc_count; lp = SLIST_FIRST(&sc->sc_ports); while (p--) *************** *** 1580,1585 **** --- 1584,1593 ---- int idx; p = lagg_hashmbuf(m, lb->lb_key); + if (sc->sc_count == 0) { + m_freem(m); + return (ENOENT); + } if ((idx = p % sc->sc_count) >= LAGG_MAX_PORTS) { m_freem(m); return (EINVAL); --=-pYK/Vjp63XwXQm/bEEhQ-- From thompsa at FreeBSD.org Thu Sep 18 04:15:52 2008 From: thompsa at FreeBSD.org (thompsa@FreeBSD.org) Date: Thu Sep 18 04:15:58 2008 Subject: kern/122794: [lagg] Kernel panic after brings lagg(8) up if NICs are not bringed up before Message-ID: <200809180415.m8I4FpdM051442@freefall.freebsd.org> Synopsis: [lagg] Kernel panic after brings lagg(8) up if NICs are not bringed up before State-Changed-From-To: feedback->patched State-Changed-By: thompsa State-Changed-When: Thu Sep 18 04:14:56 UTC 2008 State-Changed-Why: This has been fixed in r183135, please update. I missed this PR, sorry for the delay. http://www.freebsd.org/cgi/query-pr.cgi?pr=122794 From dfilter at FreeBSD.ORG Thu Sep 18 04:20:04 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Thu Sep 18 04:20:10 2008 Subject: kern/122794: commit references a PR Message-ID: <200809180420.m8I4K4sZ051546@freefall.freebsd.org> The following reply was made to PR kern/122794; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/122794: commit references a PR Date: Thu, 18 Sep 2008 04:14:43 +0000 (UTC) thompsa 2008-09-18 04:14:28 UTC FreeBSD src repository Modified files: sys/net if_lagg.c Log: SVN rev 183135 on 2008-09-18 04:14:28Z by thompsa Make sure there is at least one port to avoid divide by zero when choosing the tx port. PR: kern/122794 MFC after: 3 days Revision Changes Path 1.29 +2 -1 src/sys/net/if_lagg.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From Alexander at Leidinger.net Thu Sep 18 07:56:12 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Sep 18 07:56:19 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080917190230.GA2947@dchagin.dialup.corbina.ru> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> <20080917190230.GA2947@dchagin.dialup.corbina.ru> Message-ID: <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> Quoting "Chagin Dmitry" (from Wed, 17 Sep 2008 23:02:30 +0400): > On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote: >> >> Please review, any comment will be helpful. I did just a very quick look... > @@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct > linux_sendmsg_args *args) > */ > if (msg.msg_control != NULL && msg.msg_controllen == 0) > msg.msg_control = NULL; > + > +#if defined(__amd64__) && defined(COMPAT_LINUX32) > + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, > + &iov, EMSGSIZE); > +#else > error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); > - if (error) > - return (error); > +#endif > msg.msg_iov = iov; > msg.msg_flags = 0; > error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE); You've lost the error handling in the conditional. Bye, Alexander. -- BOFH excuse #266: All of the packets are empty http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From debarshi.ray at gmail.com Thu Sep 18 08:01:47 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu Sep 18 08:01:54 2008 Subject: reading routing table In-Reply-To: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Message-ID: <3170f42f0809180101w57e1d4c1m1bfcef00200e6b52@mail.gmail.com> So I got something working for FreeBSD now: http://rishi.fedorapeople.org/gnu/inetutils-1.5.tar.gz I have been using a combination of sysctl and PF_ROUTE to retrieve the routing table, much like the approach taken by the NetBSD implementation. Support for modifying the routing table is yet to be implemented. Thanks for all your comments. By the way, would you want someone to implement 'show' support for FreeBSD's route implementation? I can give it a go now. :-) Happy hacking, Debarshi From dchagin at freebsd.org Thu Sep 18 13:57:45 2008 From: dchagin at freebsd.org (Chagin Dmitry) Date: Thu Sep 18 13:57:53 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> <20080917190230.GA2947@dchagin.dialup.corbina.ru> <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> Message-ID: <20080918135736.GA2218@dchagin.dialup.corbina.ru> On Thu, Sep 18, 2008 at 09:38:31AM +0200, Alexander Leidinger wrote: > Quoting "Chagin Dmitry" (from Wed, 17 Sep 2008 > 23:02:30 +0400): > > >On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote: > >> > >>Please review, any comment will be helpful. > > I did just a very quick look... > > >@@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct > >linux_sendmsg_args *args) > > */ > > if (msg.msg_control != NULL && msg.msg_controllen == 0) > > msg.msg_control = NULL; > >+ > >+#if defined(__amd64__) && defined(COMPAT_LINUX32) > >+ error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, > >+ &iov, EMSGSIZE); > >+#else > > error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); > >- if (error) > >- return (error); > >+#endif > > msg.msg_iov = iov; > > msg.msg_flags = 0; > > error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE); > > You've lost the error handling in the conditional. > It's accepted, thnx! diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h index 8940289..9439900 100644 --- a/src/sys/amd64/linux32/linux.h +++ b/src/sys/amd64/linux32/linux.h @@ -685,6 +685,7 @@ union l_semun { #define LINUX_SO_NO_CHECK 11 #define LINUX_SO_PRIORITY 12 #define LINUX_SO_LINGER 13 +#define LINUX_SO_PASSCRED 16 #define LINUX_SO_PEERCRED 17 #define LINUX_SO_RCVLOWAT 18 #define LINUX_SO_SNDLOWAT 19 @@ -709,6 +710,28 @@ struct l_sockaddr { char sa_data[14]; } __packed; +struct l_msghdr { + l_uintptr_t msg_name; + l_int msg_namelen; + l_uintptr_t msg_iov; + l_size_t msg_iovlen; + l_uintptr_t msg_control; + l_size_t msg_controllen; + l_uint msg_flags; +} __packed; + +struct l_cmsghdr { + l_size_t cmsg_len; + l_int cmsg_level; + l_int cmsg_type; +} __packed; + +struct l_ucred { + uint32_t pid; + uint32_t uid; + uint32_t gid; +} __packed; + struct l_ifmap { l_ulong mem_start; l_ulong mem_end; diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h new file mode 100644 index 0000000..c1a9f1c --- /dev/null +++ b/src/sys/amd64/linux32/linux32_io.h @@ -0,0 +1,47 @@ +/*- + * Copyright (c) 2004 Tim J. Robbins + * Copyright (c) 2001 Doug Rabson + * Copyright (c) 1994-1996 S?ren Schmidt + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _AMD64_LINUX32_IO_H_ +#define _AMD64_LINUX32_IO_H_ + + +struct iovec32 { + u_int32_t iov_base; + int iov_len; +}; + +CTASSERT(sizeof(struct iovec32) == 8); + +int linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp, + int error); + +#endif /* !_AMD64_LINUX32_IO_H_ */ diff --git a/src/sys/amd64/linux32/linux32_machdep.c b/src/sys/amd64/linux32/linux32_machdep.c index 32cbe0b..26459c9 100644 --- a/src/sys/amd64/linux32/linux32_machdep.c +++ b/src/sys/amd64/linux32/linux32_machdep.c @@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v 1.49 2008/09/08 09 #include #include +#include #include #include #include @@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args *args) return (error); } -struct iovec32 { - u_int32_t iov_base; - int iov_len; -}; - -CTASSERT(sizeof(struct iovec32) == 8); - static int linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop) { @@ -281,6 +275,34 @@ linux32_copyinuio(struct iovec32 *iovp, u_int iovcnt, struct uio **uiop) } int +linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec **iovp, + int error) +{ + struct iovec32 iov32; + struct iovec *iov; + u_int iovlen; + int i; + + *iovp = NULL; + if (iovcnt > UIO_MAXIOV) + return (error); + iovlen = iovcnt * sizeof(struct iovec); + iov = malloc(iovlen, M_IOV, M_WAITOK); + for (i = 0; i < iovcnt; i++) { + error = copyin(&iovp32[i], &iov32, sizeof(struct iovec32)); + if (error) { + free(iov, M_IOV); + return (error); + } + iov[i].iov_base = PTRIN(iov32.iov_base); + iov[i].iov_len = iov32.iov_len; + } + *iovp = iov; + return(0); + +} + +int linux_readv(struct thread *td, struct linux_readv_args *uap) { struct uio *auio; diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c index f97aa23..634389d 100644 --- a/src/sys/compat/linux/linux_socket.c +++ b/src/sys/compat/linux/linux_socket.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: src/sys/compat/linux/linux_socket.c,v 1.76 2008/09/09 13:01: #ifdef COMPAT_LINUX32 #include +#include #include #else #include @@ -294,6 +295,8 @@ linux_to_bsd_so_sockopt(int opt) return (SO_OOBINLINE); case LINUX_SO_LINGER: return (SO_LINGER); + case LINUX_SO_PASSCRED: + return (LOCAL_CREDS); case LINUX_SO_PEERCRED: return (LOCAL_PEERCRED); case LINUX_SO_RCVLOWAT: @@ -414,9 +417,64 @@ linux_sa_put(struct osockaddr *osa) sa.sa_family = bdom; error = copyout(&sa, osa, sizeof(sa.sa_family)); - if (error) - return (error); + return (error); +} + +static int +linux_to_bsd_cmsg_type(int cmsg_type) +{ + + switch (cmsg_type) { + case LINUX_SCM_RIGHTS: + return (SCM_RIGHTS); + case LINUX_SCM_CREDENTIALS: + return (SCM_CREDS); + } + return (cmsg_type); +} + +static int +bsd_to_linux_cmsg_type(int cmsg_type) +{ + + switch (cmsg_type) { + case SCM_RIGHTS: + return (LINUX_SCM_RIGHTS); + case SCM_CREDS: + return (LINUX_SCM_CREDENTIALS); + } + return (cmsg_type); +} + + + +static int +linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr) +{ + if (lhdr->msg_controllen > INT_MAX) + return (ENOBUFS); + + bhdr->msg_name = PTRIN(lhdr->msg_name); + bhdr->msg_namelen = lhdr->msg_namelen; + bhdr->msg_iov = PTRIN(lhdr->msg_iov); + bhdr->msg_iovlen = lhdr->msg_iovlen; + bhdr->msg_control = PTRIN(lhdr->msg_control); + bhdr->msg_controllen = lhdr->msg_controllen; + bhdr->msg_flags = linux_to_bsd_msg_flags(lhdr->msg_flags); + return (0); +} + +static int +bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr) +{ + lhdr->msg_name = PTROUT(bhdr->msg_name); + lhdr->msg_namelen = bhdr->msg_namelen; + lhdr->msg_iov = PTROUT(bhdr->msg_iov); + lhdr->msg_iovlen = bhdr->msg_iovlen; + lhdr->msg_control = PTROUT(bhdr->msg_control); + lhdr->msg_controllen = bhdr->msg_controllen; + /* msg_flags skipped */ return (0); } @@ -437,25 +495,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags, to = NULL; if (mp->msg_control != NULL) { + struct l_cmsghdr *ptr_cmsg; + struct l_cmsghdr linux_cmsg; struct cmsghdr *cmsg; - - if (mp->msg_controllen < sizeof(struct cmsghdr)) { - error = EINVAL; - goto bad; - } - error = sockargs(&control, mp->msg_control, - mp->msg_controllen, MT_CONTROL); - if (error) - goto bad; - - cmsg = mtod(control, struct cmsghdr *); - cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level); + void *data; + socklen_t datalen; + + cmsg = malloc(CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); + control = m_get(M_WAIT, MT_CONTROL); + ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp); + + do { + error = copyin(ptr_cmsg, &linux_cmsg, + sizeof(struct l_cmsghdr)); + if (error) + goto bad; + if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) || + linux_cmsg.cmsg_len > INT_MAX) { + error = EINVAL; + goto bad; + } + + switch (linux_cmsg.cmsg_type) { + case LINUX_SCM_RIGHTS: + cmsg->cmsg_type = + linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type); + break; + default: + error = EINVAL; + goto bad; + } + cmsg->cmsg_level = + linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level); + + datalen = linux_cmsg.cmsg_len - L_CMSG_HDRSZ; + cmsg->cmsg_len = CMSG_LEN(datalen); + data = LINUX_CMSG_DATA(ptr_cmsg); + + error = ENOBUFS; + if (!m_append(control, CMSG_HDRSZ, (c_caddr_t) cmsg)) + goto bad; + if (!m_append(control, datalen, (c_caddr_t) data)) + goto bad; + + } while ((ptr_cmsg = LINUX_CMSG_NXTHDR(mp, ptr_cmsg))); + + free(cmsg, M_TEMP); } else control = NULL; error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control, segflg); - bad: if (to) FREE(to, M_SONAME); @@ -960,12 +1050,14 @@ static int linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) { struct msghdr msg; + struct l_msghdr linux_msg; struct iovec *iov; int error; - /* XXXTJR sendmsg is broken on amd64 */ - - error = copyin(PTRIN(args->msg), &msg, sizeof(msg)); + error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); + if (error) + return (error); + error = linux_to_bsd_msghdr(&msg, &linux_msg); if (error) return (error); @@ -978,7 +1070,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) */ if (msg.msg_control != NULL && msg.msg_controllen == 0) msg.msg_control = NULL; + +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); +#endif if (error) return (error); msg.msg_iov = iov; @@ -997,44 +1095,168 @@ struct linux_recvmsg_args { static int linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args) { - struct recvmsg_args /* { - int s; - struct msghdr *msg; - int flags; - } */ bsd_args; struct msghdr msg; - struct cmsghdr *cmsg; + struct l_msghdr linux_msg; + struct l_cmsghdr *linux_cmsg = NULL; + struct iovec *iov, *uiov; + struct mbuf *control = NULL; + struct mbuf **controlp; int error; - /* XXXTJR recvmsg is broken on amd64 */ + error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg)); + if (error) + return (error); - if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg)))) + error = linux_to_bsd_msghdr(&msg, &linux_msg); + if (error) return (error); - bsd_args.s = args->s; - bsd_args.msg = PTRIN(args->msg); - bsd_args.flags = linux_to_bsd_msg_flags(args->flags); - if (msg.msg_name) { - linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name, - msg.msg_namelen); - error = recvmsg(td, &bsd_args); - bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name); - } else - error = recvmsg(td, &bsd_args); +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else + error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); +#endif if (error) return (error); - if (bsd_args.msg->msg_control != NULL && - bsd_args.msg->msg_controllen > 0) { - cmsg = (struct cmsghdr*)bsd_args.msg->msg_control; - cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level); + if (msg.msg_name) { + error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name, + msg.msg_namelen); + if (error) + goto bad; } - error = copyin(PTRIN(args->msg), &msg, sizeof(msg)); + uiov = msg.msg_iov; + msg.msg_iov = iov; + controlp = (msg.msg_control != NULL) ? &control : NULL; + error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp); + msg.msg_iov = uiov; if (error) - return (error); - if (msg.msg_name && msg.msg_namelen > 2) - error = linux_sa_put(msg.msg_name); + goto bad; + + error = bsd_to_linux_msghdr(&msg, &linux_msg); + if (error) + goto bad; + + if (linux_msg.msg_name) { + error = bsd_to_linux_sockaddr((struct sockaddr *) + PTRIN(linux_msg.msg_name)); + if (error) + goto bad; + } + if (linux_msg.msg_name && linux_msg.msg_namelen > 2) { + error = linux_sa_put(PTRIN(linux_msg.msg_name)); + if (error) + goto bad; + } + + if (control) { + caddr_t outbuf; + struct cmsghdr *cm; + socklen_t datalen, outlen; + socklen_t clen; + void *data; + struct sockcred *scred; + struct l_ucred lcred; + + linux_cmsg = malloc(L_CMSG_HDRSZ, M_TEMP, M_WAITOK | M_ZERO); + outbuf = PTRIN(linux_msg.msg_control); + cm = mtod(control, struct cmsghdr *); + outlen = 0; + clen = control->m_len; + + while (cm != NULL) { + + switch (cm->cmsg_type) { + case SCM_CREDS: + + scred = (struct sockcred *)CMSG_DATA(cm); + datalen = (caddr_t)cm + cm->cmsg_len - + (caddr_t)scred; + + if (outlen + LINUX_CMSG_LEN(sizeof(lcred)) > + linux_msg.msg_controllen) { + linux_msg.msg_flags |= LINUX_MSG_CTRUNC; + goto out; + } + + lcred.pid = -1; + lcred.uid = scred->sc_uid; + lcred.gid = scred->sc_gid; + + linux_cmsg->cmsg_len = + LINUX_CMSG_LEN(sizeof(lcred)); + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + + error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); + if (error) + goto bad; + outbuf += L_CMSG_HDRSZ; + + error = copyout(&lcred, outbuf, sizeof(lcred)); + if (error) + goto bad; + + outbuf += LINUX_CMSG_ALIGN(sizeof(lcred)); + outlen += LINUX_CMSG_LEN(sizeof(lcred)); + linux_msg.msg_controllen = outlen; + break; + + default: + + data = CMSG_DATA(cm); + datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data; + + if (outlen + LINUX_CMSG_LEN(datalen) > + linux_msg.msg_controllen) { + linux_msg.msg_flags |= LINUX_MSG_CTRUNC; + goto out; + } + + linux_cmsg->cmsg_len = LINUX_CMSG_LEN(datalen); + linux_cmsg->cmsg_type = + bsd_to_linux_cmsg_type(cm->cmsg_type); + linux_cmsg->cmsg_level = + bsd_to_linux_sockopt_level(cm->cmsg_level); + + error = copyout(linux_cmsg, outbuf, L_CMSG_HDRSZ); + if (error) + goto bad; + outbuf += L_CMSG_HDRSZ; + + error = copyout(data, outbuf, datalen); + if (error) + goto bad; + + outbuf += LINUX_CMSG_ALIGN(datalen); + outlen += LINUX_CMSG_LEN(datalen); + linux_msg.msg_controllen = outlen; + break; + } + + if (CMSG_SPACE(datalen) < clen) { + clen -= CMSG_SPACE(datalen); + cm = (struct cmsghdr *) + ((caddr_t)cm + CMSG_SPACE(datalen)); + } else + cm = NULL; + } + } + +out: + error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg)); + +bad: + free(iov, M_IOV); + if (control != NULL) + m_freem(control); + if (linux_cmsg != NULL) + free(linux_cmsg, M_TEMP); + return (error); } @@ -1081,6 +1303,12 @@ linux_setsockopt(struct thread *td, struct linux_setsockopt_args *args) switch (bsd_args.level) { case SOL_SOCKET: name = linux_to_bsd_so_sockopt(args->optname); + switch (args->optname) { + case LINUX_SO_PASSCRED: + /* FreeBSD bug? socket level opts at non socket level */ + bsd_args.level = 0; + break; + } break; case IPPROTO_IP: name = linux_to_bsd_ip_sockopt(args->optname); @@ -1136,6 +1364,11 @@ linux_getsockopt(struct thread *td, struct linux_getsockopt_args *args) switch (bsd_args.level) { case SOL_SOCKET: name = linux_to_bsd_so_sockopt(args->optname); + switch (args->optname) { + case LINUX_SO_PASSCRED: + bsd_args.level = 0; + break; + } break; case IPPROTO_IP: name = linux_to_bsd_ip_sockopt(args->optname); diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h index 074e8e0..e8c2ec8 100644 --- a/src/sys/compat/linux/linux_socket.h +++ b/src/sys/compat/linux/linux_socket.h @@ -49,4 +49,36 @@ #define LINUX_MSG_ERRQUEUE 0x2000 #define LINUX_MSG_NOSIGNAL 0x4000 +/* Socket-level control message types */ + +#define LINUX_SCM_RIGHTS 0x01 +#define LINUX_SCM_CREDENTIALS 0x02 + +/* Ancilliary data object information macros */ + +#define LINUX_CMSG_ALIGN(len) (((len) + sizeof(l_long)-1) & ~(sizeof(l_long)-1)) +#define LINUX_CMSG_DATA(cmsg) ((void *)((char *)(cmsg) + \ + LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)))) +#define LINUX_CMSG_SPACE(len) (LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \ + LINUX_CMSG_ALIGN(len)) +#define LINUX_CMSG_LEN(len) (LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \ + (len)) +#define LINUX_CMSG_FIRSTHDR(msg) \ + ((msg)->msg_controllen >= \ + sizeof(struct l_cmsghdr) ? \ + (struct l_cmsghdr *)((msg)->msg_control) : \ + (struct l_cmsghdr *)(NULL)) +#define LINUX_CMSG_NXTHDR(msg, cmsg) \ + ((((char *)(cmsg) + \ + LINUX_CMSG_ALIGN((cmsg)->cmsg_len) + \ + sizeof(*(cmsg))) > \ + (((char *)(msg)->msg_control) + \ + (msg)->msg_controllen)) ? \ + (struct l_cmsghdr *) NULL : \ + (struct l_cmsghdr *)((char *)(cmsg) + \ + LINUX_CMSG_ALIGN((cmsg)->cmsg_len))) + +#define CMSG_HDRSZ CMSG_LEN(0) +#define L_CMSG_HDRSZ LINUX_CMSG_LEN(0) + #endif /* _LINUX_SOCKET_H_ */ diff --git a/src/sys/i386/linux/linux.h b/src/sys/i386/linux/linux.h index 1c3627d..28655fe 100644 --- a/src/sys/i386/linux/linux.h +++ b/src/sys/i386/linux/linux.h @@ -656,6 +656,7 @@ union l_semun { #define LINUX_SO_NO_CHECK 11 #define LINUX_SO_PRIORITY 12 #define LINUX_SO_LINGER 13 +#define LINUX_SO_PASSCRED 16 #define LINUX_SO_PEERCRED 17 #define LINUX_SO_RCVLOWAT 18 #define LINUX_SO_SNDLOWAT 19 @@ -680,6 +681,28 @@ struct l_sockaddr { char sa_data[14]; }; +struct l_msghdr { + l_uintptr_t msg_name; + l_int msg_namelen; + l_uintptr_t msg_iov; + l_size_t msg_iovlen; + l_uintptr_t msg_control; + l_size_t msg_controllen; + l_uint msg_flags; +}; + +struct l_cmsghdr { + l_size_t cmsg_len; + l_int cmsg_level; + l_int cmsg_type; +}; + +struct l_ucred { + uint32_t pid; + uint32_t uid; + uint32_t gid; +}; + struct l_ifmap { l_ulong mem_start; l_ulong mem_end; -- Have fun! chd From kostikbel at gmail.com Thu Sep 18 14:25:08 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Sep 18 14:25:20 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080918135736.GA2218@dchagin.dialup.corbina.ru> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> <20080917190230.GA2947@dchagin.dialup.corbina.ru> <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> <20080918135736.GA2218@dchagin.dialup.corbina.ru> Message-ID: <20080918142454.GK39652@deviant.kiev.zoral.com.ua> On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h > new file mode 100644 > index 0000000..c1a9f1c > --- /dev/null > +++ b/src/sys/amd64/linux32/linux32_io.h > @@ -0,0 +1,47 @@ > +/*- > + * Copyright (c) 2004 Tim J. Robbins > + * Copyright (c) 2001 Doug Rabson > + * Copyright (c) 1994-1996 S?ren Schmidt > + * All rights reserved. ^^^^^^^^^^ Is this true ? Coloring this further, do we need a new include file for one structure and one function ? P.S. Your MUA sets Mail-Followup-To: to the full list of the recipients _except_ you. Is this intentional ? -------------- 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/20080918/8d58bc8e/attachment.pgp From swordqiu at gmail.com Thu Sep 18 14:50:12 2008 From: swordqiu at gmail.com (Jian Qiu) Date: Thu Sep 18 14:50:19 2008 Subject: What's the status of parallel netisr? In-Reply-To: <48D00899.4070908@FreeBSD.org> References: <48CF6450.6020909@FreeBSD.org> <48D00899.4070908@FreeBSD.org> Message-ID: Thanks again for the info. As you suggested, I did test on the most recent 7.0-stable-200807 kernel. The SMP throughout on the new kernel was improved to around 90MB/s. However, SMP kernel still had no advantage over UP, at least for this kind of single threaded applications. I further did the same test on Linux with both SMP and UP. I did observe the same trend. The throughput on UP (~210MB/ecs) was also much better than SMP (~170MB/sec). However, I was surprised again that the local UDP throughput on Linux was more than double of FreeBSD. Since all these tests were performed on the same machine, it must be because of the kernel that made such big differences. I'm curious what is the major performance bottleneck in FreeBSD network stack?? Is there any plan in community to address these issues? Many thanks. Jian On Wed, Sep 17, 2008 at 3:27 AM, Kris Kennaway wrote: > Jian Qiu wrote: >> >> Interesting. >> >> I did a test on local UDP throughput. >> >> I was surprised to find out the performance with a SMP kernel was >> worse than UP. (~74MB/s v.s. 96 MB/s). >> >> I had though parallel netisr might be a solution. > > Make sure you are testing with either 8.0 or 7.1 (or late 7.0-STABLE), i.e. > after the fixes to improve UDP performance on SMP systems. > > Kris > > From dchagin at freebsd.org Thu Sep 18 15:08:07 2008 From: dchagin at freebsd.org (Chagin Dmitry) Date: Thu Sep 18 15:08:24 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080918142454.GK39652@deviant.kiev.zoral.com.ua> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> <20080917190230.GA2947@dchagin.dialup.corbina.ru> <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> <20080918135736.GA2218@dchagin.dialup.corbina.ru> <20080918142454.GK39652@deviant.kiev.zoral.com.ua> Message-ID: <20080918150759.GA2898@dchagin.dialup.corbina.ru> On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote: > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h > > new file mode 100644 > > index 0000000..c1a9f1c > > --- /dev/null > > +++ b/src/sys/amd64/linux32/linux32_io.h > > @@ -0,0 +1,47 @@ > > +/*- > > + * Copyright (c) 2004 Tim J. Robbins > > + * Copyright (c) 2001 Doug Rabson > > + * Copyright (c) 1994-1996 S?ren Schmidt > > + * All rights reserved. > ^^^^^^^^^^ Is this true ? > I have copied it from linux.h, can I remove it? > Coloring this further, do we need a new include file for one structure > and one function ? > You suggest to transfer it to linux.h? I can do it, but then it is necessary to insert #include into all files which include linux.h thnx! -- Have fun! chd From kostikbel at gmail.com Thu Sep 18 15:31:17 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Sep 18 15:31:28 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080918150759.GA2898@dchagin.dialup.corbina.ru> References: <20080822112927.GZ99951@hoeg.nl> <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> <20080917190230.GA2947@dchagin.dialup.corbina.ru> <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> <20080918135736.GA2218@dchagin.dialup.corbina.ru> <20080918142454.GK39652@deviant.kiev.zoral.com.ua> <20080918150759.GA2898@dchagin.dialup.corbina.ru> Message-ID: <20080918153111.GL39652@deviant.kiev.zoral.com.ua> On Thu, Sep 18, 2008 at 07:07:59PM +0400, Chagin Dmitry wrote: I still cannot answer to you, so be it. > On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote: > > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > > > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h > > > new file mode 100644 > > > index 0000000..c1a9f1c > > > --- /dev/null > > > +++ b/src/sys/amd64/linux32/linux32_io.h > > > @@ -0,0 +1,47 @@ > > > +/*- > > > + * Copyright (c) 2004 Tim J. Robbins > > > + * Copyright (c) 2001 Doug Rabson > > > + * Copyright (c) 1994-1996 S?ren Schmidt > > > + * All rights reserved. > > ^^^^^^^^^^ Is this true ? > > > > I have copied it from linux.h, can I remove it? No, you should specify yourself as the copyright holder. > > > Coloring this further, do we need a new include file for one structure > > and one function ? > > > > You suggest to transfer it to linux.h? > I can do it, but then it is necessary to insert #include > into all files which include linux.h This may be a trouble. Is there any other compat/linux include that requires uio ? -------------- 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/20080918/eaea9f0d/attachment.pgp From dchagin at freebsd.org Thu Sep 18 15:56:34 2008 From: dchagin at freebsd.org (Chagin Dmitry) Date: Thu Sep 18 15:56:40 2008 Subject: [PATCH] recvmsg() sendmsg() linux emulation In-Reply-To: <20080918153111.GL39652@deviant.kiev.zoral.com.ua> References: <20080822112946.GA97526@freebsd.org> <20080831110610.GA2380@dchagin.dialup.corbina.ru> <20080902085623.GA12395@freebsd.org> <20080917183801.GA2714@dchagin.dialup.corbina.ru> <20080917190230.GA2947@dchagin.dialup.corbina.ru> <20080918093831.89545e2iu5zjgjgg@webmail.leidinger.net> <20080918135736.GA2218@dchagin.dialup.corbina.ru> <20080918142454.GK39652@deviant.kiev.zoral.com.ua> <20080918150759.GA2898@dchagin.dialup.corbina.ru> <20080918153111.GL39652@deviant.kiev.zoral.com.ua> Message-ID: <20080918155626.GA3299@dchagin.dialup.corbina.ru> On Thu, Sep 18, 2008 at 06:31:11PM +0300, Kostik Belousov wrote: > On Thu, Sep 18, 2008 at 07:07:59PM +0400, Chagin Dmitry wrote: > > I still cannot answer to you, so be it. > > > On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote: > > > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > > > > diff --git a/src/sys/amd64/linux32/linux32_io.h b/src/sys/amd64/linux32/linux32_io.h > > > > new file mode 100644 > > > > index 0000000..c1a9f1c > > > > --- /dev/null > > > > +++ b/src/sys/amd64/linux32/linux32_io.h > > > > @@ -0,0 +1,47 @@ > > > > +/*- > > > > + * Copyright (c) 2004 Tim J. Robbins > > > > + * Copyright (c) 2001 Doug Rabson > > > > + * Copyright (c) 1994-1996 S?ren Schmidt > > > > + * All rights reserved. > > > ^^^^^^^^^^ Is this true ? > > > > > > > I have copied it from linux.h, can I remove it? > > No, you should specify yourself as the copyright holder. > ok > > > > > Coloring this further, do we need a new include file for one structure > > > and one function ? > > > > > > > You suggest to transfer it to linux.h? > > I can do it, but then it is necessary to insert #include > > into all files which include linux.h > > This may be a trouble. Is there any other compat/linux include that > requires uio ? yes, linux_util.h include uio now, but iovec32 stuff specific only for ia32@amd64 emulation. -- Have fun! chd From oberman at es.net Thu Sep 18 18:58:31 2008 From: oberman at es.net (Kevin Oberman) Date: Thu Sep 18 18:58:38 2008 Subject: What's the status of parallel netisr? In-Reply-To: Your message of "Thu, 18 Sep 2008 22:50:10 +0800." Message-ID: <20080918185827.E05DA45047@ptavv.es.net> > Date: Thu, 18 Sep 2008 22:50:10 +0800 > From: "Jian Qiu" > Sender: owner-freebsd-net@freebsd.org > > Thanks again for the info. > > As you suggested, I did test on the most recent 7.0-stable-200807 kernel. > > The SMP throughout on the new kernel was improved to around 90MB/s. > > However, SMP kernel still had no advantage over UP, at least for this > kind of single threaded applications. > > I further did the same test on Linux with both SMP and UP. > > I did observe the same trend. > > The throughput on UP (~210MB/ecs) was also much better than SMP (~170MB/sec). > > However, I was surprised again that the local UDP throughput on Linux > was more than double of FreeBSD. > > Since all these tests were performed on the same machine, it must be > because of the kernel that made such big differences. > > I'm curious what is the major performance bottleneck in FreeBSD network stack?? > > Is there any plan in community to address these issues? Did you try locking down the CPUs used with cpuset (FreeBSD) or taskset (Linux)? This can make a very substantial difference. Something like a UDP canon will run far more efficiently if locked to a single CPU and will run best if that CPU is not processing the interrupts. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080918/73160578/attachment.pgp From kris at FreeBSD.org Thu Sep 18 19:27:20 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Sep 18 19:27:28 2008 Subject: What's the status of parallel netisr? In-Reply-To: References: <48CF6450.6020909@FreeBSD.org> <48D00899.4070908@FreeBSD.org> Message-ID: <48D2ABA2.8010703@FreeBSD.org> Jian Qiu wrote: > Thanks again for the info. > > As you suggested, I did test on the most recent 7.0-stable-200807 kernel. > > The SMP throughout on the new kernel was improved to around 90MB/s. > > However, SMP kernel still had no advantage over UP, at least for this > kind of single threaded applications. > > I further did the same test on Linux with both SMP and UP. > > I did observe the same trend. > > The throughput on UP (~210MB/ecs) was also much better than SMP (~170MB/sec). > > However, I was surprised again that the local UDP throughput on Linux > was more than double of FreeBSD. > > Since all these tests were performed on the same machine, it must be > because of the kernel that made such big differences. > > I'm curious what is the major performance bottleneck in FreeBSD network stack?? > > Is there any plan in community to address these issues? In our application-level tests FreeBSD significantly out-performs Linux, so either you have found a different workload, or something is not configured equally. One important thing I can think of off the top of my head is that Linux has a larger socket buffer size by default, so try tuning that on FreeBSD or confirm they are equal. If that still fails, can you provide test code? Kris From bms at FreeBSD.org Thu Sep 18 22:00:09 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 18 22:00:15 2008 Subject: reading routing table In-Reply-To: <3170f42f0809180101w57e1d4c1m1bfcef00200e6b52@mail.gmail.com> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <3170f42f0809180101w57e1d4c1m1bfcef00200e6b52@mail.gmail.com> Message-ID: <48D2CF66.8080608@FreeBSD.org> Debarshi Ray wrote: > ... > By the way, would you want someone to implement 'show' support for > FreeBSD's route implementation? I can give it a go now. :-) > For sure, we'd be very happy to see a patch like that. Many thanks BMS From julian at elischer.org Thu Sep 18 23:57:33 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 18 23:57:39 2008 Subject: reading routing table In-Reply-To: <48D2CF66.8080608@FreeBSD.org> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <3170f42f0809180101w57e1d4c1m1bfcef00200e6b52@mail.gmail.com> <48D2CF66.8080608@FreeBSD.org> Message-ID: <48D2EAEC.1020902@elischer.org> Bruce M. Simpson wrote: > Debarshi Ray wrote: >> ... >> By the way, would you want someone to implement 'show' support for >> FreeBSD's route implementation? I can give it a go now. :-) >> > > For sure, we'd be very happy to see a patch like that. > > Many thanks > BMS and don't forget the same patch for netsta\t so that it doesn't need /dev/kmem for netstat -r :-) BUT, don't forget about multiple routing tables.. From kungfujesus06 at gmail.com Fri Sep 19 00:15:03 2008 From: kungfujesus06 at gmail.com (Adam Stylinski) Date: Fri Sep 19 00:15:10 2008 Subject: Question regarding NFS Message-ID: <96af083b0809181644o6136af1fybf0110f227f04f3b@mail.gmail.com> Hello, I am running an IPCop firewall for my entire network. I have a wireless network device on the blue subnet which must access a freebsd NFS server. In order to do this, I need to open a DMZ pinhole on a few select ports. It's my understanding that NFS chooses random ports and I was wondering if there was a way I could fix this. There is a good reason that the subnet for the wireless is separate from the wired and I'd rather not configure this thing over a VPN. The client connecting to the NFS server is a voyage computer (pretty much a small debian). Also, if at all possible, I'd like to keep performance reasonably high when large volumes of clients are connecting to the NFS server, I'm not sure if binding to one port may or may not make this impossible. I apologize for my stupidity and lack of understanding when it comes to NFS. Any help would be gladly appreciated, guys. From jbut at swin.edu.au Fri Sep 19 03:07:08 2008 From: jbut at swin.edu.au (Jason But) Date: Fri Sep 19 03:07:15 2008 Subject: Code release of ipfw NAT support for SCTP in FreeBSD-8 Message-ID: <48D3142C.1060901@swin.edu.au> The Centre for Advanced Internet Architectures (CAIA http://caia.swin.edu.au) is proud to announce the release of alias_sctp version 0.2, an SCTP NAT patch to FreeBSD 8.x. Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/libalias suite. Alias_sctp version 0.2 is a fully functional NAT for SCTP. It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata). The code has been intentionally kept as separate as possible from the base modules to aid testing and debugging, and make it easier to port to other systems. We welcome and value feedback and comments. Please forward feedback to dahayes@swin.edu.au and jbut@swin.edu.au Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html Features of alias_sctp version 0.2: - Support for global multi-homing - Support for multi-homed privately addressed hosts using ASCONF modifications from the Internet Draft (R. Stewart and M. Tuexen, "Stream control transmission protocol (SCTP) network address translation", draft-stewart-behave-sctpnat-04, Jul. 2008) - Support for forwarding of T-flagged packets - Generation and delivery of AbortM/ErrorM packets upon detection of NAT collisions - Per-port forwarding rules - Dynamic configuration (via sysctl interface) of: o Logging and statistic gathering o Timer management o Hash Table sizes o Global address storage and other processing limits - Configuration via use of the "ipfw nat ... config" - Stateful SCTP association management. This project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Jason -- ---------- Dr. Jason But Lecturer Telecommunications Engineering Academic Group Faculty of Information and Communication Technologies Swinburne University of Technology http://www.swinburne.edu.au/ict/telecommshome.htm From pyunyh at gmail.com Fri Sep 19 03:38:56 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Sep 19 03:39:03 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <200809081232.43213.freebsd-net@dino.sk> References: <200809050945.09276.freebsd-net@dino.sk> <200809060803.53293.freebsd-net@dino.sk> <20080908102912.GI77346@cdnetworks.co.kr> <200809081232.43213.freebsd-net@dino.sk> Message-ID: <20080919033650.GA14593@cdnetworks.co.kr> On Mon, Sep 08, 2008 at 12:32:42PM +0200, Milan Obuch wrote: > On Monday 08 September 2008 12:29:12 Pyun YongHyeon wrote: > > On Sat, Sep 06, 2008 at 08:03:52AM +0200, Milan Obuch wrote: > > > > [snip] > > > > > It was my pleasure and I would like to express my thanks for your great > > > work. If you will need in future some more testing with this hardware, > > > just drop me a line. Just a side note, will this patch be MFS'ed into > > > 7-STABLE in short timeframe? > > > > As soon as I get re's approval I'll commit to 7-stable. > > Thanks, I can wait a bit with this one. FYI: I've MFCed the fix to 7-stable(svn r183171). -- Regards, Pyun YongHyeon From pjd at FreeBSD.org Fri Sep 19 08:28:22 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Sep 19 08:28:29 2008 Subject: Firewall redirect doesn't work any more... Message-ID: <20080919075633.GA4333@garage.freebsd.pl> ...or am I missing something? I've a box running: FreeBSD whiplash.wheel.pl 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 23 11:41:31 CEST 2008 root@puppet.wheel.pl:/usr/obj/usr/src/sys/WHIPLASH i386 I'm also running PF in there with the following rule: rdr on fxp0 proto tcp from 10.0.1.9 to 10.0.0.2 port 88 -> 10.0.5.123 port 88 When I connect from 10.0.1.9 to 10.0.0.2:88 I can see redirected packet leaving the box: IP 10.0.1.9.43210 > 10.0.0.2.88: S [...] IP 10.0.1.9.43210 > 10.0.5.123.88: S [...] Ok. Now I've a box running: FreeBSD bridge.wheel.pl 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Sep 11 13:59:06 CEST 2008 root@bridge.wheel.pl:/usr/obj/usr/src/sys/BRIDGE i386 And the following PF rule: rdr on fxp0 proto tcp from 10.0.0.2 to 10.0.5.123 port 88 -> 10.0.1.9 port 88 When I connect from 10.0.0.2 to 10.0.5.123:88 I no longer see redirected packet leaving the box: IP 10.0.0.2.60806 > 10.0.5.123.88: S [...] I tried to redirect packet on the second box with IPFW, but also failed (yes IPFIREWALL_FORWARD was compiled in). Does something got broken or am I missing some configuration hint? -- 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/20080919/9e5776b2/attachment.pgp From freebsd-net at dino.sk Fri Sep 19 09:35:49 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Fri Sep 19 09:35:56 2008 Subject: MSI Wind Notebook's network interfaces In-Reply-To: <20080919033650.GA14593@cdnetworks.co.kr> References: <200809050945.09276.freebsd-net@dino.sk> <200809081232.43213.freebsd-net@dino.sk> <20080919033650.GA14593@cdnetworks.co.kr> Message-ID: <200809191134.43531.freebsd-net@dino.sk> On Friday 19 September 2008 05:36:50 Pyun YongHyeon wrote: > On Mon, Sep 08, 2008 at 12:32:42PM +0200, Milan Obuch wrote: > > On Monday 08 September 2008 12:29:12 Pyun YongHyeon wrote: > > > On Sat, Sep 06, 2008 at 08:03:52AM +0200, Milan Obuch wrote: > > > > > > [snip] > > > > > > > It was my pleasure and I would like to express my thanks for your > > > > great work. If you will need in future some more testing with this > > > > hardware, just drop me a line. Just a side note, will this patch be > > > > MFS'ed into 7-STABLE in short timeframe? > > > > > > As soon as I get re's approval I'll commit to 7-stable. > > > > Thanks, I can wait a bit with this one. > > FYI: I've MFCed the fix to 7-stable(svn r183171). Thanks for reminder. Tried csup'ping, rebuild my 7.1-PRERELEASE and it works the expected way. As expected, I can now work with no patches with this system again. Until I find another problem/bug, possibly in totally different part of system... Regards, Milan From randall at lakerest.net Fri Sep 19 10:25:38 2008 From: randall at lakerest.net (Randy Stewart) Date: Fri Sep 19 10:25:45 2008 Subject: Code release of ipfw NAT support for SCTP in FreeBSD-8 In-Reply-To: <486765C7.1010409@swin.edu.au> References: <486765C7.1010409@swin.edu.au> Message-ID: <24300CD2-275A-42BA-930A-9D347C15435F@lakerest.net> Jason: Do you know if anyone will shepard this in to FreeBSD? If not I will volunteer... I need to actually fix the stack to be able to generate the right things for this anyway ;-) Let me know if you have someone already out there doing this :-) Thanks R On Jun 29, 2008, at 6:36 AM, Jason But wrote: > The Centre for Advanced Internet Architectures (CAIA - http://caia.swin.edu.au > ) > is proud to announce the release of alias_sctp version 0.1, a SCTP > NAT patch to > FreeBSD 8.x. > > > Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/ > libalias suite. > It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata > ). > The code has been intentionally kept as separate as possible from > the base > modules to aid testing and debugging, and make it easier to port to > other > systems. > > This project has been made possible in part by a grant from the Cisco > University Research Program Fund at Community Foundation Silicon > Valley. > > > We welcome and value feedback and comments. > Please forward feedback to dahayes@swin.edu.au and jbut@swin.edu.au > > Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html > > Features of alias_sctp version 0.1: > > - Basic configuration through "ipfw nat ... config" commands. > > - Forwarding of incoming SCTP associations through > "ipfw nat ... redirect_addr ..." commands. > > - A variety of log levels (currently #define, but sysctl in version > 0.2). > > - Stateful SCTP association management. > > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > - Tested on single-homed hosts, but should work when the multi-homed > host is on > the global side of the NAT (same mechanism for address translation). > > - Dynamic hash table size allocation (currently #define, but sysctl in > version 0.2). > > - Initial testing has been for up to 10000 concurrent flows arriving > and leaving > at about 2000/second. Tested for periods of up to 72 hours. > > > Features in the pipline for further releases: > > - Sysctl interface for logging, timeouts, hash table size. > Status - mostly complete. > > - Port forwarding and load sharing. > Status - mostly complete. > > - Support for, soon to be specified, enhancements of SCTP to aid > interworking > with NATs. > > - New AddIP ASCONF chunks. > Status - preliminary coding and investigation. > (Requires finalised standards to be completed) > > - AbortM and ErrorM NAT originated messages. > Status - preliminary coding, with work starting on the ipfw send > interface > > - IPv6 support. > Status - preliminary investigation. > > - Global IP address tracing. > Status - preliminary investigation. > > > Other tasks: > > - Exaustive testing of the various configurations and scenarios. > > - Stress and load testing. > > - Performance analysis. > > Jason > -- > > ---------- > Dr. Jason But > Lecturer > Telecommunications Engineering Academic Group > Faculty of Information and Communication Technologies > Swinburne University of Technology > http://www.swinburne.edu.au/ict/telecommshome.htm > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ----- Randall Stewart randall@lakerest.net From pjd at FreeBSD.org Fri Sep 19 12:16:01 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Sep 19 12:16:04 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080919075633.GA4333@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> Message-ID: <20080919121602.GC4333@garage.freebsd.pl> On Fri, Sep 19, 2008 at 09:56:33AM +0200, Pawel Jakub Dawidek wrote: > ...or am I missing something? > > I've a box running: > > FreeBSD whiplash.wheel.pl 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 23 11:41:31 CEST 2008 root@puppet.wheel.pl:/usr/obj/usr/src/sys/WHIPLASH i386 > > I'm also running PF in there with the following rule: > > rdr on fxp0 proto tcp from 10.0.1.9 to 10.0.0.2 port 88 -> 10.0.5.123 port 88 > > When I connect from 10.0.1.9 to 10.0.0.2:88 I can see redirected packet > leaving the box: > > IP 10.0.1.9.43210 > 10.0.0.2.88: S [...] > IP 10.0.1.9.43210 > 10.0.5.123.88: S [...] > > Ok. Now I've a box running: > > FreeBSD bridge.wheel.pl 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Sep 11 13:59:06 CEST 2008 root@bridge.wheel.pl:/usr/obj/usr/src/sys/BRIDGE i386 > > And the following PF rule: > > rdr on fxp0 proto tcp from 10.0.0.2 to 10.0.5.123 port 88 -> 10.0.1.9 port 88 > > When I connect from 10.0.0.2 to 10.0.5.123:88 I no longer see redirected > packet leaving the box: > > IP 10.0.0.2.60806 > 10.0.5.123.88: S [...] > > I tried to redirect packet on the second box with IPFW, but also failed > (yes IPFIREWALL_FORWARD was compiled in). > > Does something got broken or am I missing some configuration hint? I downgraded to 7.0-RELEASE and the problem was still there, but I found a work-around - one needs to set net.inet.ip.forwarding to 1, even though packet is not forwarded between interfaces (everything is related to fxp0 only). -- 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/20080919/e9e3fbe1/attachment.pgp From max at love2party.net Fri Sep 19 13:38:07 2008 From: max at love2party.net (Max Laier) Date: Fri Sep 19 13:38:11 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080919121602.GC4333@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> Message-ID: <200809191538.02698.max@love2party.net> On Friday 19 September 2008 14:16:02 Pawel Jakub Dawidek wrote: > On Fri, Sep 19, 2008 at 09:56:33AM +0200, Pawel Jakub Dawidek wrote: > > ...or am I missing something? > > > > I've a box running: > > > > FreeBSD whiplash.wheel.pl 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 23 > > 11:41:31 CEST 2008 root@puppet.wheel.pl:/usr/obj/usr/src/sys/WHIPLASH > > i386 > > > > I'm also running PF in there with the following rule: > > > > rdr on fxp0 proto tcp from 10.0.1.9 to 10.0.0.2 port 88 -> 10.0.5.123 > > port 88 > > > > When I connect from 10.0.1.9 to 10.0.0.2:88 I can see redirected packet > > leaving the box: > > > > IP 10.0.1.9.43210 > 10.0.0.2.88: S [...] > > IP 10.0.1.9.43210 > 10.0.5.123.88: S [...] > > > > Ok. Now I've a box running: > > > > FreeBSD bridge.wheel.pl 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Sep > > 11 13:59:06 CEST 2008 root@bridge.wheel.pl:/usr/obj/usr/src/sys/BRIDGE > > i386 > > > > And the following PF rule: > > > > rdr on fxp0 proto tcp from 10.0.0.2 to 10.0.5.123 port 88 -> 10.0.1.9 > > port 88 > > > > When I connect from 10.0.0.2 to 10.0.5.123:88 I no longer see redirected > > packet leaving the box: > > > > IP 10.0.0.2.60806 > 10.0.5.123.88: S [...] > > > > I tried to redirect packet on the second box with IPFW, but also failed > > (yes IPFIREWALL_FORWARD was compiled in). > > > > Does something got broken or am I missing some configuration hint? > > I downgraded to 7.0-RELEASE and the problem was still there, but I found > a work-around - one needs to set net.inet.ip.forwarding to 1, even > though packet is not forwarded between interfaces (everything is related > to fxp0 only). I might be wrong, but I don't think we ever supported rdr without net.inet.ip.forwarding enabled. Maybe to a different local address, but even then you'd need net.inet.ip.check_interface=0. Looking at the code, I don't see where IPFW forwarding fails (as it has its own ip_forward() call), though. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From renaud at vmware.com Fri Sep 19 18:51:39 2008 From: renaud at vmware.com (Renaud Lienhart) Date: Fri Sep 19 18:51:43 2008 Subject: Unnecessary check in mb_zinit_pack()? Message-ID: <20080919113157.2ac9fe9e@renaud-dev1.eng.vmware.com> It seems there is a redundant check in mb_zinit_pack(): if (uma_zalloc_arg(zone_clust, m, how) == NULL || m->m_ext.ext_buf == NULL) return (ENOMEM); If uma_zalloc_arg() successfully allocates a cluster then shouldn't m->m_ext.ext_buf be guaranteed not to be NULL? I can't find any rationale for the second check; I removed it from my private tree, moved it into a KASSERT() and didn't run into any problem so far. Am I missing something? Thanks, Renaud Lienhart From 0ac5 at packet-pushers.com Fri Sep 19 23:21:01 2008 From: 0ac5 at packet-pushers.com (Duane Wessels) Date: Fri Sep 19 23:21:10 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> Message-ID: <20080919155900.P29264@life-gone-hazy.com> On Mon, 15 Sep 2008, Henri-Pierre Charles said: > I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > > 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. For the record, the same is true for my Acer Aspire One. After updating sys/contrib/dev/ath to HEAD I now have a working ath0. hooray! Duane W. From frank at exit.com Sat Sep 20 00:21:26 2008 From: frank at exit.com (Frank Mayhar) Date: Sat Sep 20 00:21:30 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <20080919155900.P29264@life-gone-hazy.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <20080919155900.P29264@life-gone-hazy.com> Message-ID: <1221868355.63110.2.camel@jill.exit.com> On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: > > On Mon, 15 Sep 2008, Henri-Pierre Charles said: > > > I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > > > > 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. > > For the record, the same is true for my Acer Aspire One. After > updating sys/contrib/dev/ath to HEAD I now have a working ath0. > hooray! On the other hand, mine doesn't. I have a brand new Lifebook E8420 and I believe the Atheros wireless chipset is an a/g/n chipset. It lists as: none0@pci0:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 I read somewhere that this chipset is supported by the new ath9k Linux driver but, of course, I run FreeBSD. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From sam at freebsd.org Sat Sep 20 00:57:36 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Sep 20 00:57:43 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <1221868355.63110.2.camel@jill.exit.com> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <20080919155900.P29264@life-gone-hazy.com> <1221868355.63110.2.camel@jill.exit.com> Message-ID: <48D44A6F.1020408@freebsd.org> Frank Mayhar wrote: > On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: > >> On Mon, 15 Sep 2008, Henri-Pierre Charles said: >> >> >>> I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 >>> >>> 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. >>> >> For the record, the same is true for my Acer Aspire One. After >> updating sys/contrib/dev/ath to HEAD I now have a working ath0. >> hooray! >> > > On the other hand, mine doesn't. I have a brand new Lifebook E8420 and > I believe the Atheros wireless chipset is an a/g/n chipset. It lists > as: > > none0@pci0:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 > > I read somewhere that this chipset is supported by the new ath9k Linux > driver but, of course, I run FreeBSD. > That's a merlin part (aka 9280); I've got untested changes to support it. Unfortunately I don't have a card so it may take a while to get something out. Unfortunately it's not feasible for me to send out test code to try until I can actually work w/ a card. Sam From frank at exit.com Sat Sep 20 05:12:14 2008 From: frank at exit.com (Frank Mayhar) Date: Sat Sep 20 05:12:22 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST In-Reply-To: <48D44A6F.1020408@freebsd.org> References: <20080828002919.GA54169@alpha.local> <4734a3ed0809150659n438a5b20r59278908f4032a45@mail.gmail.com> <20080919155900.P29264@life-gone-hazy.com> <1221868355.63110.2.camel@jill.exit.com> <48D44A6F.1020408@freebsd.org> Message-ID: <1221887499.64423.1.camel@jill.exit.com> On Fri, 2008-09-19 at 17:57 -0700, Sam Leffler wrote: > Frank Mayhar wrote: > > On Fri, 2008-09-19 at 16:02 -0700, Duane Wessels wrote: > > > >> On Mon, 15 Sep 2008, Henri-Pierre Charles said: > >> > >> > >>> I've tried 7.1-BETA and 8.0-CURRENT-200809 on my eeepc model 701 > >>> > >>> 7.1 does not recognize ath0, as expected, but 8.0-CURRENT does. > >>> > >> For the record, the same is true for my Acer Aspire One. After > >> updating sys/contrib/dev/ath to HEAD I now have a working ath0. > >> hooray! > >> > > > > On the other hand, mine doesn't. I have a brand new Lifebook E8420 and > > I believe the Atheros wireless chipset is an a/g/n chipset. It lists > > as: > > > > none0@pci0:32:0:0: class=0x028000 card=0x147c10cf chip=0x002a168c rev=0x01 hdr=0x00 > > > > I read somewhere that this chipset is supported by the new ath9k Linux > > driver but, of course, I run FreeBSD. > > > That's a merlin part (aka 9280); I've got untested changes to support > it. Unfortunately I don't have a card so it may take a while to get > something out. Unfortunately it's not feasible for me to send out test > code to try until I can actually work w/ a card. I would happily pay for a card if that would help. Just pick out the one you want and let me know. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From swordqiu at gmail.com Sat Sep 20 15:36:42 2008 From: swordqiu at gmail.com (Jian Qiu) Date: Sat Sep 20 15:36:45 2008 Subject: What's the status of parallel netisr? In-Reply-To: <20080918185827.E05DA45047@ptavv.es.net> References: <20080918185827.E05DA45047@ptavv.es.net> Message-ID: Hi, Kevin, > > Did you try locking down the CPUs used with cpuset (FreeBSD) or taskset > (Linux)? This can make a very substantial difference. Something like a > UDP canon will run far more efficiently if locked to a single CPU and > will run best if that CPU is not processing the interrupts. As far as I know, on the sending path, a UDP packet will be directly put on the sending queue of the relevant NIC. The UDP stack codes are executed on the CPU where the sending application is running. On the receiving path, iIf the packet is received from a loopback interface, the UDP stack codes are executed in the context of netisr softirq. Did you mean I should bind the sending application to one CPU and netsir softirq to another CPU? Thanks. Jian From swordqiu at gmail.com Sat Sep 20 16:04:02 2008 From: swordqiu at gmail.com (Jian Qiu) Date: Sat Sep 20 16:04:04 2008 Subject: What's the status of parallel netisr? In-Reply-To: <48D2ABA2.8010703@FreeBSD.org> References: <48CF6450.6020909@FreeBSD.org> <48D00899.4070908@FreeBSD.org> <48D2ABA2.8010703@FreeBSD.org> Message-ID: Hi, Kris, > In our application-level tests FreeBSD significantly out-performs Linux, so > either you have found a different workload, or something is not configured > equally. One important thing I can think of off the top of my head is that > Linux has a larger socket buffer size by default, so try tuning that on > FreeBSD or confirm they are equal. > > If that still fails, can you provide test code? > > Kris > I tried but larger socket buffer seem not helpful. I also tried netperf and iperf. Both applications achieve better throughput on Linux. So I feel the result is not specific to my test code. My code is very simple. Basically, a client process called sendto in a loop while a server called recvfrom in a loop. Besides these, some additional lines get the throughput statistics. If necessary, I will post the code here. BTW, I did the tests on Linux 2.26.5. Which linux kernel did you use? Could you please provide some more information on your test. Many thanks. Jian From wahjava at gmail.com Sat Sep 20 21:56:01 2008 From: wahjava at gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IOCktg==?= =?utf-8?B?4KWB4KSV4KWN4KSy?=) Date: Sat Sep 20 21:56:05 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? Message-ID: <87ej3e32iz.fsf@chateau.d.lf> Hi all, Is there anyone, who is porting NetworkManager[1] to FreeBSD ? If yes, I would like to be a tester or contributor to the effort. References: [1] - http://www.gnome.org/projects/NetworkManager/ Thanks Ashish Shukla -- ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080920/62baf4e7/attachment.pgp From marcus at marcuscom.com Sun Sep 21 03:38:58 2008 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Sun Sep 21 03:39:03 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? In-Reply-To: <87ej3e32iz.fsf@chateau.d.lf> References: <87ej3e32iz.fsf@chateau.d.lf> Message-ID: <1221968342.74421.4.camel@shumai.marcuscom.com> On Sun, 2008-09-21 at 03:26 +0530, Ashish Shukla ???? ????? wrote: > Hi all, > > Is there anyone, who is porting NetworkManager[1] to FreeBSD ? If yes, I > would like to be a tester or contributor to the effort. It's been on our ideas list for a while, and I think someone mentioned they were working on it a few months ago (check the archives). I held a desktop discussion at the last BSDCan, and Kris Moore of PC-BSD suggested it may be easier to port their network manager (http://svn.pcbsd.org/browser/pcbsd/trunk/NetworkManager) from KDE to GTK+/GNOME In the meantime, I did a GNOME PBI for PC-BSD, and added hooks to make use of some of PC-BSD's admin tools. The result was positive. However, it would be great to have working GTK+/GNOME native tools. Joe > > References: > [1] - http://www.gnome.org/projects/NetworkManager/ > > Thanks > Ashish Shukla -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080921/2c9a7072/attachment.pgp From kris at FreeBSD.org Sun Sep 21 09:57:48 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Sep 21 09:57:50 2008 Subject: What's the status of parallel netisr? In-Reply-To: References: <48CF6450.6020909@FreeBSD.org> <48D00899.4070908@FreeBSD.org> <48D2ABA2.8010703@FreeBSD.org> Message-ID: <48D61AA9.5080208@FreeBSD.org> Jian Qiu wrote: > Hi, Kris, > >> In our application-level tests FreeBSD significantly out-performs Linux, so >> either you have found a different workload, or something is not configured >> equally. One important thing I can think of off the top of my head is that >> Linux has a larger socket buffer size by default, so try tuning that on >> FreeBSD or confirm they are equal. >> >> If that still fails, can you provide test code? >> >> Kris >> > > I tried but larger socket buffer seem not helpful. > > I also tried netperf and iperf. Both applications achieve better > throughput on Linux. > > So I feel the result is not specific to my test code. > > My code is very simple. Basically, a client process called sendto in a > loop while a server called recvfrom in a loop. > Besides these, some additional lines get the throughput statistics. If > necessary, I will post the code here. > > BTW, I did the tests on Linux 2.26.5. Which linux kernel did you use? > > Could you please provide some more information on your test. The ones I have in mind were application level benchmarks of things like DNS and memcached. I tested on 2.6.25, which is perhaps what you meant to say too. Try to keep looking for other factors that might still be in play, like hardware or driver differences. Kris From alcazoid at gmail.com Sun Sep 21 18:25:34 2008 From: alcazoid at gmail.com (Mikhail Gorbulev) Date: Sun Sep 21 18:25:36 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? In-Reply-To: <1221968342.74421.4.camel@shumai.marcuscom.com> References: <87ej3e32iz.fsf@chateau.d.lf> <1221968342.74421.4.camel@shumai.marcuscom.com> Message-ID: I was thinking about porting it, because I really need this thing on my laptop and to have some programming experience. I just wanted to have a companion, because I'm not sure I can handle this by myself and because I'm pretty lazy these days, so I need to feel responsibility :) Anyone interested? 2008/9/21 Joe Marcus Clarke : > On Sun, 2008-09-21 at 03:26 +0530, Ashish Shukla ???? ????? wrote: >> Hi all, >> >> Is there anyone, who is porting NetworkManager[1] to FreeBSD ? If yes, I >> would like to be a tester or contributor to the effort. > > It's been on our ideas list for a while, and I think someone mentioned > they were working on it a few months ago (check the archives). I held a > desktop discussion at the last BSDCan, and Kris Moore of PC-BSD > suggested it may be easier to port their network manager > (http://svn.pcbsd.org/browser/pcbsd/trunk/NetworkManager) from KDE to > GTK+/GNOME > > In the meantime, I did a GNOME PBI for PC-BSD, and added hooks to make > use of some of PC-BSD's admin tools. The result was positive. However, > it would be great to have working GTK+/GNOME native tools. > > Joe > >> >> References: >> [1] - http://www.gnome.org/projects/NetworkManager/ >> >> Thanks >> Ashish Shukla > -- > PGP Key : http://www.marcuscom.com/pgp.asc > -- Best wishes, me. From gavin at FreeBSD.org Sun Sep 21 18:28:40 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sun Sep 21 18:28:45 2008 Subject: Backporting iwn(4): WPA auth hangs... Help! Message-ID: <20080921183530.V31429@ury.york.ac.uk> Hi all, I'm attempting to backport the iwn(4) driver for the Intel 4965 driver from -HEAD to RELENG_7 and am getting stuck with it at one particular point: WPA authentication times out. I've so far tried to both take the -HEAD driver and de-vapify etc. it, and also to take a pre-vap version of the driver and bring in required changes. Both fail in exactly the same way, with authentication timing out. I have verified that the laptop can successfully connect to the same network with -HEAD and the same wpa_supplicant.conf file. I've attached the log file from wpa_supplicant. Code can be found at http://people.freebsd.org/~gavin/iwn/ - I'm currently working with the updated-from-pre-vap version so that's the one that generated the log file and is probably the best to look at. Sadly I don't have the infrastructure at the moment to test if the driver works with WEP. Any help or pointers would be greatfully received, Thanks! Gavin -------------- next part -------------- Initializing interface 'iwn0' conf '/root/wpa_supplicant.conf' driver 'default' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/root/wpa_supplicant.conf' -> '/root/wpa_supplicant.conf' Reading configuration file '/root/wpa_supplicant.conf' ctrl_interface='/var/run/wpa_supplicant' Priority group 0 id=0 ssid='sdkfjw' Initializing interface (2) 'iwn0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:1f:3b:24:ed:ed wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Added interface iwn0 State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=6): 73 64 6b 66 6a 77 sdkfjw Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (3 BSSes) Scan results: 3 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:19:4b:97:84:cd ssid='com77' wpa_ie_len=26 rsn_ie_len=0 caps=0x11 skip - SSID mismatch 1: 00:1f:33:7a:5f:be ssid='SKY04014' wpa_ie_len=26 rsn_ie_len=0 caps=0x71 skip - SSID mismatch 2: 00:13:49:c0:3c:e1 ssid='sdkfjw' wpa_ie_len=0 rsn_ie_len=22 caps=0x11 selected based on RSN IE selected WPA AP 00:13:49:c0:3c:e1 ssid='sdkfjw' Try to find non-WPA AP Trying to associate with 00:13:49:c0:3c:e1 (SSID='sdkfjw' freq=2472 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'sdkfjw' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag Authentication with 00:13:49:c0:3c:e1 timed out. Added BSSID 00:13:49:c0:3c:e1 into blacklist No keys have been configured - skip key clearing State: ASSOCIATING -> DISCONNECTED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - EAP success=0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=6): 73 64 6b 66 6a 77 sdkfjw Received 0 bytes of scan results (3 BSSes) Scan results: 3 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:19:4b:97:84:cd ssid='com77' wpa_ie_len=26 rsn_ie_len=0 caps=0x11 skip - SSID mismatch 1: 00:1f:33:7a:5f:be ssid='SKY04014' wpa_ie_len=26 rsn_ie_len=0 caps=0x71 skip - SSID mismatch 2: 00:13:49:c0:3c:e1 ssid='sdkfjw' wpa_ie_len=0 rsn_ie_len=22 caps=0x11 selected based on RSN IE selected WPA AP 00:13:49:c0:3c:e1 ssid='sdkfjw' Try to find non-WPA AP Trying to associate with 00:13:49:c0:3c:e1 (SSID='sdkfjw' freq=2472 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'sdkfjw' wpa ie len 22 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: External notification - EAP fail=0 EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag CTRL-EVENT-TERMINATING - signal 2 received Removing interface iwn0 State: ASSOCIATING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing Removed BSSID 00:13:49:c0:3c:e1 from blacklist (clear) Cancelling scan request Cancelling authentication timeout wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 From remko at FreeBSD.org Sun Sep 21 21:03:57 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sun Sep 21 21:03:59 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200809212103.m8LL3v61012961@freefall.freebsd.org> Old Synopsis: icmp socket receives icmp replies not owned by the process. New Synopsis: [icmp]: icmp socket receives icmp replies not owned by the process. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Sep 21 21:03:41 UTC 2008 Responsible-Changed-Why: Reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=127528 From rik at inse.ru Sun Sep 21 21:12:30 2008 From: rik at inse.ru (Roman Kurakin) Date: Sun Sep 21 21:12:34 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080919075633.GA4333@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> Message-ID: <48D6B6D3.7000306@localhost.inse.ru> Pawel Jakub Dawidek wrote: > ...or am I missing something? > > I've a box running: > > FreeBSD whiplash.wheel.pl 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 23 11:41:31 CEST 2008 root@puppet.wheel.pl:/usr/obj/usr/src/sys/WHIPLASH i386 > > I'm also running PF in there with the following rule: > > rdr on fxp0 proto tcp from 10.0.1.9 to 10.0.0.2 port 88 -> 10.0.5.123 port 88 > > When I connect from 10.0.1.9 to 10.0.0.2:88 I can see redirected packet > leaving the box: > > IP 10.0.1.9.43210 > 10.0.0.2.88: S [...] > IP 10.0.1.9.43210 > 10.0.5.123.88: S [...] > > Ok. Now I've a box running: > > FreeBSD bridge.wheel.pl 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Sep 11 13:59:06 CEST 2008 root@bridge.wheel.pl:/usr/obj/usr/src/sys/BRIDGE i386 > > And the following PF rule: > > rdr on fxp0 proto tcp from 10.0.0.2 to 10.0.5.123 port 88 -> 10.0.1.9 port 88 > > When I connect from 10.0.0.2 to 10.0.5.123:88 I no longer see redirected > packet leaving the box: > > IP 10.0.0.2.60806 > 10.0.5.123.88: S [...] > > I tried to redirect packet on the second box with IPFW, but also failed > (yes IPFIREWALL_FORWARD was compiled in). > > Does something got broken or am I missing some configuration hint? > Could it be that the box you are trying to connect from is the 10.0.0.2? If this is the case, then the problem is that the rule rdr is works only for packet which hits the interface from outside, eq interface should be incoming for packets not outgoing on which the rule is set . rik From onemda at gmail.com Sun Sep 21 22:01:43 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Sep 21 22:01:47 2008 Subject: Backporting iwn(4): WPA auth hangs... Help! In-Reply-To: <20080921183530.V31429@ury.york.ac.uk> References: <20080921183530.V31429@ury.york.ac.uk> Message-ID: <3a142e750809211436v7bb5c7beqd55c7fe55ed6f449@mail.gmail.com> On 9/21/08, Gavin Atkinson wrote: > > Hi all, > > I'm attempting to backport the iwn(4) driver for the Intel 4965 driver > from -HEAD to RELENG_7 and am getting stuck with it at one particular > point: WPA authentication times out. > > I've so far tried to both take the -HEAD driver and de-vapify etc. it, and > also to take a pre-vap version of the driver and bring in required > changes. Both fail in exactly the same way, with authentication timing > out. I have verified that the laptop can successfully connect to the same > network with -HEAD and the same wpa_supplicant.conf file. I've attached > the log file from wpa_supplicant. Code can be found at > http://people.freebsd.org/~gavin/iwn/ - I'm currently working with the > updated-from-pre-vap version so that's the one that generated the log file > and is probably the best to look at. > > Sadly I don't have the infrastructure at the moment to test if the > driver works with WEP. > > Any help or pointers would be greatfully received, > > Thanks! > > Gavin I can't understand why is IEEE80211_C_STA removed in both versions. From sam at freebsd.org Sun Sep 21 22:04:03 2008 From: sam at freebsd.org (Sam Leffler) Date: Sun Sep 21 22:04:06 2008 Subject: Backporting iwn(4): WPA auth hangs... Help! In-Reply-To: <3a142e750809211436v7bb5c7beqd55c7fe55ed6f449@mail.gmail.com> References: <20080921183530.V31429@ury.york.ac.uk> <3a142e750809211436v7bb5c7beqd55c7fe55ed6f449@mail.gmail.com> Message-ID: <48D6C4D1.7030301@freebsd.org> Paul B. Mahol wrote: > On 9/21/08, Gavin Atkinson wrote: > >> Hi all, >> >> I'm attempting to backport the iwn(4) driver for the Intel 4965 driver >> from -HEAD to RELENG_7 and am getting stuck with it at one particular >> point: WPA authentication times out. >> >> I've so far tried to both take the -HEAD driver and de-vapify etc. it, and >> also to take a pre-vap version of the driver and bring in required >> changes. Both fail in exactly the same way, with authentication timing >> out. I have verified that the laptop can successfully connect to the same >> network with -HEAD and the same wpa_supplicant.conf file. I've attached >> the log file from wpa_supplicant. Code can be found at >> http://people.freebsd.org/~gavin/iwn/ - I'm currently working with the >> updated-from-pre-vap version so that's the one that generated the log file >> and is probably the best to look at. >> >> Sadly I don't have the infrastructure at the moment to test if the >> driver works with WEP. >> >> Any help or pointers would be greatfully received, >> >> Thanks! >> >> Gavin >> > > I can't understand why is IEEE80211_C_STA removed in both versions. > _______________________________________________ > There is no explicit STA capability in RELENG_7; it only exists in HEAD. Sam From bms at FreeBSD.org Sun Sep 21 22:12:34 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Sep 21 22:12:39 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. In-Reply-To: <200809212103.m8LL3v61012961@freefall.freebsd.org> References: <200809212103.m8LL3v61012961@freefall.freebsd.org> Message-ID: <48D6C6CE.3060404@FreeBSD.org> remko@FreeBSD.org wrote: > Old Synopsis: icmp socket receives icmp replies not owned by the process. > New Synopsis: [icmp]: icmp socket receives icmp replies not owned by the process. > This PR is bogus because: ICMP has no concept of datagrams being "owned" by a process. There is no field in the ICMP protocol which differentiates ICMP "sessions" on a per-process basis, and this is because ICMP has no concept of "sessions" -- ICMP messages are directed at IP endpoints. The networking stack will only selectively dispatch ICMP traffic based on two conditions: 1. ip_proto number (raw sockets may selectively bind to a protocol) and 2. multicast group membership (not applicable in this instance). > It also shows that both echo requests have different identifiers in the id field which should keep the icmp streams seperated. There is absolutely no requirement for the kernel code to look at the ID field, beyond reporting it to consumers of the SOCK_RAW interface. This PR can be closed, the submitter should consult the pfSense maintainers. thanks BMS From bms at FreeBSD.org Sun Sep 21 22:20:04 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Sep 21 22:20:06 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200809212220.m8LMK4QZ019761@freefall.freebsd.org> The following reply was made to PR kern/127528; it has been noted by GNATS. From: "Bruce M. Simpson" To: remko@FreeBSD.org Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Sun, 21 Sep 2008 23:12:30 +0100 remko@FreeBSD.org wrote: > Old Synopsis: icmp socket receives icmp replies not owned by the process. > New Synopsis: [icmp]: icmp socket receives icmp replies not owned by the process. > This PR is bogus because: ICMP has no concept of datagrams being "owned" by a process. There is no field in the ICMP protocol which differentiates ICMP "sessions" on a per-process basis, and this is because ICMP has no concept of "sessions" -- ICMP messages are directed at IP endpoints. The networking stack will only selectively dispatch ICMP traffic based on two conditions: 1. ip_proto number (raw sockets may selectively bind to a protocol) and 2. multicast group membership (not applicable in this instance). > It also shows that both echo requests have different identifiers in the id field which should keep the icmp streams seperated. There is absolutely no requirement for the kernel code to look at the ID field, beyond reporting it to consumers of the SOCK_RAW interface. This PR can be closed, the submitter should consult the pfSense maintainers. thanks BMS _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From gavin at freebsd.org Sun Sep 21 22:42:09 2008 From: gavin at freebsd.org (Gavin Atkinson) Date: Sun Sep 21 22:42:13 2008 Subject: Backporting iwn(4): WPA auth hangs... Help! In-Reply-To: <20080921183530.V31429@ury.york.ac.uk> References: <20080921183530.V31429@ury.york.ac.uk> Message-ID: <20080921233855.P31429@ury.york.ac.uk> On Sun, 21 Sep 2008, Gavin Atkinson wrote: > I'm attempting to backport the iwn(4) driver for the Intel 4965 driver from > -HEAD to RELENG_7 and am getting stuck with it at one particular point: WPA > authentication times out. I've includewd the output with all options within wlandebug enabled at http://people.freebsd.org/~gavin/iwn/ (net.wlan.0.debug: 0x5fff1fe0) Tomorrow, I'll see what I can see by sniffing the wire. Thanks, Gavin From cmb at pfsense.org Sun Sep 21 23:39:28 2008 From: cmb at pfsense.org (Chris Buechler) Date: Sun Sep 21 23:39:33 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. In-Reply-To: <48D6C6CE.3060404@FreeBSD.org> References: <200809212103.m8LL3v61012961@freefall.freebsd.org> <48D6C6CE.3060404@FreeBSD.org> Message-ID: <48D6D489.5070506@pfsense.org> Bruce M. Simpson wrote: > remko@FreeBSD.org wrote: >> Old Synopsis: icmp socket receives icmp replies not owned by the >> process. >> New Synopsis: [icmp]: icmp socket receives icmp replies not owned by >> the process. >> > > This PR is bogus because: > ICMP has no concept of datagrams being "owned" by a process. There is > no field in the ICMP protocol which differentiates ICMP "sessions" on > a per-process basis, and this is because ICMP has no concept of > "sessions" -- ICMP messages are directed at IP endpoints. ICMP echo and echo replies do have "sessions" of sorts, at least unique identifying fields - identifier and sequence number. This was opened by a pfSense maintainer because it's a change in behavior from 6.x releases where this was never an issue, and is something we feel is a regression. Ideally you don't want to be pinging the same host from two different processes, but it's difficult to avoid in some circumstances and it's something that always worked fine prior to FreeBSD 7.0. Thanks, Chris From cmb at pfsense.org Sun Sep 21 23:50:04 2008 From: cmb at pfsense.org (Chris Buechler) Date: Sun Sep 21 23:50:07 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200809212350.m8LNo4vw026668@freefall.freebsd.org> The following reply was made to PR kern/127528; it has been noted by GNATS. From: Chris Buechler To: "Bruce M. Simpson" Cc: freebsd-net@FreeBSD.org, remko@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Sun, 21 Sep 2008 19:11:05 -0400 Bruce M. Simpson wrote: > remko@FreeBSD.org wrote: >> Old Synopsis: icmp socket receives icmp replies not owned by the >> process. >> New Synopsis: [icmp]: icmp socket receives icmp replies not owned by >> the process. >> > > This PR is bogus because: > ICMP has no concept of datagrams being "owned" by a process. There is > no field in the ICMP protocol which differentiates ICMP "sessions" on > a per-process basis, and this is because ICMP has no concept of > "sessions" -- ICMP messages are directed at IP endpoints. ICMP echo and echo replies do have "sessions" of sorts, at least unique identifying fields - identifier and sequence number. This was opened by a pfSense maintainer because it's a change in behavior from 6.x releases where this was never an issue, and is something we feel is a regression. Ideally you don't want to be pinging the same host from two different processes, but it's difficult to avoid in some circumstances and it's something that always worked fine prior to FreeBSD 7.0. Thanks, Chris _______________________________________________ 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 linimon at FreeBSD.org Mon Sep 22 04:25:30 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 22 04:25:33 2008 Subject: kern/127529: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update Message-ID: <200809220425.m8M4PUlk047466@freefall.freebsd.org> Old Synopsis: Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update New Synopsis: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 22 04:24:43 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127529 From wahjava.ml at gmail.com Mon Sep 22 05:52:21 2008 From: wahjava.ml at gmail.com (Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IA==?= =?utf-8?B?4KS24KWB4KSV4KWN4KSy?=) Date: Mon Sep 22 05:52:29 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? In-Reply-To: <1221968342.74421.4.camel@shumai.marcuscom.com> (Joe Marcus Clarke's message of "Sat\, 20 Sep 2008 23\:39\:02 -0400") References: <87ej3e32iz.fsf@chateau.d.lf> <1221968342.74421.4.camel@shumai.marcuscom.com> Message-ID: <87prmw682t.fsf@chateau.d.lf> Joe Marcus Clarke writes: > On Sun, 2008-09-21 at 03:26 +0530, Ashish Shukla ???? ????? wrote: >> Hi all, >> >> Is there anyone, who is porting NetworkManager[1] to FreeBSD ? If yes, I >> would like to be a tester or contributor to the effort. > It's been on our ideas list for a while, and I think someone mentioned > they were working on it a few months ago (check the archives). I held a > desktop discussion at the last BSDCan, and Kris Moore of PC-BSD > suggested it may be easier to port their network manager > (http://svn.pcbsd.org/browser/pcbsd/trunk/NetworkManager) from KDE to > GTK+/GNOME > In the meantime, I did a GNOME PBI for PC-BSD, and added hooks to make > use of some of PC-BSD's admin tools. The result was positive. However, > it would be great to have working GTK+/GNOME native tools. Thanks for the reply. But, that looks like a static network configuration tool. Ashish -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- % dig +short cname cdac.in @::1 microsoft.gov.in -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080922/e852acb9/attachment.pgp From yongari at FreeBSD.org Mon Sep 22 06:27:19 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Mon Sep 22 06:27:22 2008 Subject: kern/127529: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update Message-ID: <200809220627.m8M6RJ8o062822@freefall.freebsd.org> Synopsis: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Sep 22 06:25:38 UTC 2008 State-Changed-Why: Would you try patch at the followng URL? http://people.freebsd.org/~yongari/nfe/nfe.mcp77_79.patch Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Sep 22 06:25:38 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=127529 From rwatson at FreeBSD.org Mon Sep 22 08:56:46 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 22 08:56:54 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. In-Reply-To: <48D6D489.5070506@pfsense.org> References: <200809212103.m8LL3v61012961@freefall.freebsd.org> <48D6C6CE.3060404@FreeBSD.org> <48D6D489.5070506@pfsense.org> Message-ID: On Sun, 21 Sep 2008, Chris Buechler wrote: >> This PR is bogus because: ICMP has no concept of datagrams being "owned" by >> a process. There is no field in the ICMP protocol which differentiates ICMP >> "sessions" on a per-process basis, and this is because ICMP has no concept >> of "sessions" -- ICMP messages are directed at IP endpoints. > > ICMP echo and echo replies do have "sessions" of sorts, at least unique > identifying fields - identifier and sequence number. > > This was opened by a pfSense maintainer because it's a change in behavior > from 6.x releases where this was never an issue, and is something we feel is > a regression. > > Ideally you don't want to be pinging the same host from two different > processes, but it's difficult to avoid in some circumstances and it's > something that always worked fine prior to FreeBSD 7.0. As far as I'm aware, IP raw sockets have never supported using the ID field to identify sessions or direct packets to specific sockets. This means that a kernel regression in that session semantic is unlikely. However, it could be that you're seeing the impact of another regression relating to other behavior for restricting ICMP received on the raw socket. The kernel code in question is in raw_ip.c:rip_input(), which performs the following checks for each raw IP socket it considers a candidate for delivery: - If a non-zero 'protocol' argument was specified in the socket() call, is the protocol of the packet the same as the protocol on the socket? - If a local address is bound on the raw socket, is it the same as the destination address on the packet? - If a forieng address is bound on the raw socket, is it the same as the source address on the packet? - If the socket was created by a process in a jail, is the jail IP the same as the destination address on the packet? With these in mind, I'd look for one of two things that might have lead to the symptoms you're seeing: a change in the way your application is written or run such that the address limits on packets received are no longer requested or may now be ambiguous, or a change in the way our system works such that it's no longer implementing the above checks correctly. Ping applications are, btw, supposed to select unique identifiers (typically the pid is used) and then ignore replies with a different identifier, and last I checked ping(8) did that. Could it be that your application is not doing that? Robert N M Watson Computer Laboratory University of Cambridge From pjd at FreeBSD.org Mon Sep 22 10:22:08 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Sep 22 10:22:12 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <200809191538.02698.max@love2party.net> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> Message-ID: <20080922102209.GB2468@garage.freebsd.pl> On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote: > I might be wrong, but I don't think we ever supported rdr without > net.inet.ip.forwarding enabled. Maybe to a different local address, but even > then you'd need net.inet.ip.check_interface=0. Looking at the code, I don't > see where IPFW forwarding fails (as it has its own ip_forward() call), though. Ok, I did some more tests. I'm running bridge in there and trying to redirect packets that goes through my bridge to a local daemon. UDP redirect seems to work with PF: rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 -> 10.0.5.123 port 12345 Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can even send packets back and they are send with source address set to 10.0.0.2 - this is exactly what I'm looking for. Unfortunately it doesn't work for TCP. I see packets beeing redirected to 10.0.5.123, but my local daemon never accepts the connection and nc client keeps resending SYN packets. I also see weird messages in the logs: TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored (Both tcps_badrst and tcps_sc_dropped are increased on every connection attempt.) Any ideas how to make it work with TCP? PS. The same functionality doesn't work at all with ipfw(8) (because of if_bridge(4)?). -- 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/20080922/16cc6b2d/attachment.pgp From rwatson at FreeBSD.org Mon Sep 22 11:00:13 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 22 11:00:15 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200809221100.m8MB0CwT014166@freefall.freebsd.org> The following reply was made to PR kern/127528; it has been noted by GNATS. From: Robert Watson To: Chris Buechler Cc: freebsd-net@FreeBSD.org, remko@FreeBSD.org, "Bruce M. Simpson" , freebsd-bugs@FreeBSD.org Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Mon, 22 Sep 2008 09:56:45 +0100 (BST) On Sun, 21 Sep 2008, Chris Buechler wrote: >> This PR is bogus because: ICMP has no concept of datagrams being "owned" by >> a process. There is no field in the ICMP protocol which differentiates ICMP >> "sessions" on a per-process basis, and this is because ICMP has no concept >> of "sessions" -- ICMP messages are directed at IP endpoints. > > ICMP echo and echo replies do have "sessions" of sorts, at least unique > identifying fields - identifier and sequence number. > > This was opened by a pfSense maintainer because it's a change in behavior > from 6.x releases where this was never an issue, and is something we feel is > a regression. > > Ideally you don't want to be pinging the same host from two different > processes, but it's difficult to avoid in some circumstances and it's > something that always worked fine prior to FreeBSD 7.0. As far as I'm aware, IP raw sockets have never supported using the ID field to identify sessions or direct packets to specific sockets. This means that a kernel regression in that session semantic is unlikely. However, it could be that you're seeing the impact of another regression relating to other behavior for restricting ICMP received on the raw socket. The kernel code in question is in raw_ip.c:rip_input(), which performs the following checks for each raw IP socket it considers a candidate for delivery: - If a non-zero 'protocol' argument was specified in the socket() call, is the protocol of the packet the same as the protocol on the socket? - If a local address is bound on the raw socket, is it the same as the destination address on the packet? - If a forieng address is bound on the raw socket, is it the same as the source address on the packet? - If the socket was created by a process in a jail, is the jail IP the same as the destination address on the packet? With these in mind, I'd look for one of two things that might have lead to the symptoms you're seeing: a change in the way your application is written or run such that the address limits on packets received are no longer requested or may now be ambiguous, or a change in the way our system works such that it's no longer implementing the above checks correctly. Ping applications are, btw, supposed to select unique identifiers (typically the pid is used) and then ignore replies with a different identifier, and last I checked ping(8) did that. Could it be that your application is not doing that? Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Sep 22 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:30 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200809221106.m8MB6wbL015444@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/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/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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 bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 175 problems total. From bms at FreeBSD.org Mon Sep 22 13:04:21 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Sep 22 13:04:26 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. In-Reply-To: <48D6D489.5070506@pfsense.org> References: <200809212103.m8LL3v61012961@freefall.freebsd.org> <48D6C6CE.3060404@FreeBSD.org> <48D6D489.5070506@pfsense.org> Message-ID: <48D797D1.1080403@FreeBSD.org> Chris Buechler wrote: >> >> This PR is bogus because: >> ICMP has no concept of datagrams being "owned" by a process. There is >> no field in the ICMP protocol which differentiates ICMP "sessions" on >> a per-process basis, and this is because ICMP has no concept of >> "sessions" -- ICMP messages are directed at IP endpoints. > > ICMP echo and echo replies do have "sessions" of sorts, at least > unique identifying fields - identifier and sequence number. These fields do exist in ICMP, and as you point out, they are sometimes used to implement session-like behaviour. Many NAT implementations use them in this way. However there is no way of specifying them in a bind() call -- ICMP can only be received on a raw socket, and raw sockets will not filter these things on behalf of a user process, nor have they ever done to the best of my knowledge. They are not part of the address structures for a raw socket (SOCK_RAW, PF_INET, * or IPPROTO_ICMP). > > This was opened by a pfSense maintainer because it's a change in > behavior from 6.x releases where this was never an issue, and is > something we feel is a regression. Robert has replied outlining a few situations where the behaviour might have changed. Raw sockets do support binding laddr/faddr, there is the possibility this could have changed, however there is no notion of processes "owning" streams of ICMP messages, this has never been part of the ICMP protocol and to think in these terms is misleading. It sounds to me as though the application is relying on a form of filtering which isn't happening, and the way to track this down is to carefully note what, if anything, changed in the expected behaviour between releases. For example, does the application bind() to any given host addresses? This is the only form of filtering, apart from multicast SSM, that raw sockets would support, and SSM ain't in the tree [yet]. thanks BMS From rik at inse.ru Mon Sep 22 13:31:08 2008 From: rik at inse.ru (Roman Kurakin) Date: Mon Sep 22 13:31:12 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080922102209.GB2468@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl> Message-ID: <48D79E1C.3060003@inse.ru> Hi, Pawel Jakub Dawidek wrote: > On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote: > >> I might be wrong, but I don't think we ever supported rdr without >> net.inet.ip.forwarding enabled. Maybe to a different local address, but even >> then you'd need net.inet.ip.check_interface=0. Looking at the code, I don't >> see where IPFW forwarding fails (as it has its own ip_forward() call), though. >> > > Ok, I did some more tests. I'm running bridge in there and trying to > redirect packets that goes through my bridge to a local daemon. > UDP redirect seems to work with PF: > > rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 -> 10.0.5.123 port 12345 > > Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I > call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on > 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can > even send packets back and they are send with source address set to > 10.0.0.2 - this is exactly what I'm looking for. > > Unfortunately it doesn't work for TCP. I see packets beeing redirected to > 10.0.5.123, but my local daemon never accepts the connection and nc client > keeps resending SYN packets. > > I also see weird messages in the logs: > > TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > (Both tcps_badrst and tcps_sc_dropped are increased on every connection > attempt.) > > Any ideas how to make it work with TCP? > > PS. The same functionality doesn't work at all with ipfw(8) (because of > if_bridge(4)?). > I use ipfw(8) fwd for tcp with bridge and it works (more or less) fine for me. The network scheme in my setup is: if0 - bridge0 - vlanX lo0 connected jails with private IPs. forwarding enabled, also net.link.bridge.pfil_local_phys=1 to get more control on traffic, but this should not affect the result. I do not use pf since it have problems with ftp+nat. All packets from vlanX to any 80 are redirected to a squid-jail, and there is no problems. (Mostly no, since I have some instability and I get connection timeouts and need to press reload time to time in my browser window. Can't say what is the reason since IIRC the squid version was of the last but no-stable version and it was the first time I've used jail for squid and also jail are behind the natd. I just didn't have a time to dig this problem.) But once again it works. So, could you draw you connections and related firewall rules. And the one you are trying to setup. I will also try to update the machine to the most recent 7 to see if my setup will stop working. Currently machine runs early September checkout. PS. Also check the mac address issue that was discussed here (case where the brdige0 and the first bridge member share the same MAC). rik From pjd at FreeBSD.org Mon Sep 22 13:48:33 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Sep 22 13:48:40 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <48D79E1C.3060003@inse.ru> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl> <48D79E1C.3060003@inse.ru> Message-ID: <20080922134830.GA6797@garage.freebsd.pl> On Mon, Sep 22, 2008 at 05:31:08PM +0400, Roman Kurakin wrote: > So, could you draw you connections and related firewall rules. And the > one you > are trying to setup. I will also try to update the machine to the most > recent 7 to > see if my setup will stop working. Currently machine runs early > September checkout. client (10.0.1.1) -----> bridge (10.0.5.123) -----> server (10.0.0.2) ifnet = "bridge0" rdr on $ifnet proto tcp from any to any port 12345 -> 10.0.5.123 port 12345 rdr on $ifnet proto udp from any to any port 12345 -> 10.0.5.123 port 12345 net.inet.ip.forwarding=1 To test my redirection I run: server# nc -u -l 12345 client# nc -u 10.0.0.2 12345 For UDP it works, for TCP it doesn't: server# nc -l 12345 client# nc 10.0.0.2 12345 Although it works even with bridge0 and TCP connections, but when bridge machine is treated as gateway, eg. server# nc -l 12345 client# route add 1.0.0.0/24 10.0.5.123 client# nc 10.0.0.2 12345 > PS. Also check the mac address issue that was discussed here (case where the > brdige0 and the first bridge member share the same MAC). That's not the case on my test machines. -- 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/20080922/4276b3d9/attachment.pgp From gavin at freebsd.org Mon Sep 22 14:06:58 2008 From: gavin at freebsd.org (Gavin Atkinson) Date: Mon Sep 22 14:07:00 2008 Subject: Backporting iwn(4): Success! In-Reply-To: <20080921183530.V31429@ury.york.ac.uk> References: <20080921183530.V31429@ury.york.ac.uk> Message-ID: <20080922150424.O6681@ury.york.ac.uk> On Sun, 21 Sep 2008, Gavin Atkinson wrote: > I'm attempting to backport the iwn(4) driver for the Intel 4965 driver from > -HEAD to RELENG_7 and am getting stuck with it at one particular point: WPA > authentication times out. As a followup to this, with a bit of help from Sam Leffler, I've now succeeded in getting this working. If you're interested in using this driver under RELENG_7 plese see my post to freebsd-stable@: http://docs.FreeBSD.org/cgi/mid.cgi?1222090773.43647.16.camel Gavin From rik at inse.ru Mon Sep 22 14:11:34 2008 From: rik at inse.ru (Roman Kurakin) Date: Mon Sep 22 14:11:37 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080922134830.GA6797@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl> <48D79E1C.3060003@inse.ru> <20080922134830.GA6797@garage.freebsd.pl> Message-ID: <48D7A797.6070009@inse.ru> Pawel Jakub Dawidek wrote: > On Mon, Sep 22, 2008 at 05:31:08PM +0400, Roman Kurakin wrote: > >> So, could you draw you connections and related firewall rules. And the >> one you >> are trying to setup. I will also try to update the machine to the most >> recent 7 to >> see if my setup will stop working. Currently machine runs early >> September checkout. >> > > client (10.0.1.1) -----> bridge (10.0.5.123) -----> server (10.0.0.2) > > ifnet = "bridge0" > rdr on $ifnet proto tcp from any to any port 12345 -> 10.0.5.123 port 12345 > rdr on $ifnet proto udp from any to any port 12345 -> 10.0.5.123 port 12345 > Try also to play with stateful switches for pf. By the way do you have any global that affects defaults? > net.inet.ip.forwarding=1 > > To test my redirection I run: > > server# nc -u -l 12345 > client# nc -u 10.0.0.2 12345 > > For UDP it works, for TCP it doesn't: > > server# nc -l 12345 > client# nc 10.0.0.2 12345 > > Although it works even with bridge0 and TCP connections, but when bridge > machine is treated as gateway, eg. > > server# nc -l 12345 > client# route add 1.0.0.0/24 10.0.5.123 > client# nc 10.0.0.2 12345 > And what about ipfw variant? rik >> PS. Also check the mac address issue that was discussed here (case where the >> brdige0 and the first bridge member share the same MAC). >> > > That's not the case on my test machines. > > From psychosensor at gmail.com Mon Sep 22 14:23:14 2008 From: psychosensor at gmail.com (Sergey Listopad) Date: Mon Sep 22 14:23:17 2008 Subject: bridged tap interfaces with stp Message-ID: Hi! I am playing with bridge(4) stp feature. there are 2 boxes with 7.0-RELEASE-p4. rt1 rt2 ___________ ___________ | ____| |____ | | |tap1| ------------------------|tap1| | | | | | | |tap2|-------------------------|tap2| | |___________| |___________| rt1 connected to rt2 with 2 openvpn L2 links (tap). tap1 bridged with tap2 on both routers. rt1# ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xffffff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap2 flags=143 member: tap1 flags=143 rt2# ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xffffff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 16384 ifcost 0 port 0 member: tap2 flags=143 member: tap1 flags=143 rt1# ping 3.3.3.2 PING 3.3.3.2 (3.3.3.2): 56 data bytes 64 bytes from 3.3.3.2: icmp_seq=0 ttl=64 time=8.144 ms 64 bytes from 3.3.3.2: icmp_seq=1 ttl=64 time=4.313 ms 64 bytes from 3.3.3.2: icmp_seq=2 ttl=64 time=4.421 ms ... all works while broadcast Then I'd try to enable stp on bridge0 interfaces for automatic disable one of redundant links (tap1/tap2). rt1# ifconfig bridge0 stp tap1 stp tap2 rt1# ifconfig bridge0 bridge0: flags=8943 metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xffffff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:b9 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:b9 priority 32768 ifcost 0 port 0 member: tap2 flags=147 port 12 priority 128 path cost 2000000 proto rstp role disabled state discarding member: tap1 flags=147 port 16 priority 128 path cost 2000000 proto rstp role disabled state discarding rt2# ifconfig bridge0 stp tap1 stp tap2 rt2# ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xffffff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:ad priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:ad priority 16384 ifcost 0 port 0 member: tap2 flags=147 port 9 priority 128 path cost 2000000 proto rstp role disabled state discarding member: tap1 flags=147 port 8 priority 128 path cost 2000000 proto rstp role disabled state discarding But when stp is enabled, it blocks all bridge members, and bridge stop working. May be I am misunderstand something with stp? At all it is possible to use bridge(4) stp with tap(4)? Even when bridge0 on both router has only 1 member, ports stay in disabled state. rt1# ifconfig bridge0 deletem tap1 deletem tap2 rt1# ifconfig bridge0 bridge0: flags=8943 metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xffffff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 rt2# ifconfig bridge0 deletem tap1 deletem tap2 rt2# ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xffffff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 16384 ifcost 0 port 0 rt1# ifconfig bridge0 addm tap1 stp tap1 rt1# ifconfig bridge0 bridge0: flags=8943 metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xffffff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:b9 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:b9 priority 32768 ifcost 0 port 0 member: tap1 flags=147 port 16 priority 128 path cost 2000000 proto rstp role disabled state discarding rt2# ifconfig bridge0 addm tap1 stp tap1 rt2# ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xffffff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:ad priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:ad priority 16384 ifcost 0 port 0 member: tap1 flags=147 port 8 priority 128 path cost 2000000 proto rstp role disabled state discarding -- S.Listopad From rwatson at FreeBSD.org Mon Sep 22 14:24:14 2008 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Sep 22 14:24:15 2008 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200809221424.m8MEODPn034463@freefall.freebsd.org> Synopsis: [icmp]: icmp socket receives icmp replies not owned by the process. State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Sep 22 14:22:16 UTC 2008 State-Changed-Why: Request feedback based on correspondence to date -- the delivery of ICMP messages to multiple raw sockets is historical behavior from the original BSD network stack, and not considered a bug. However, clearly something has changed in the software configuration leading to the reported symptoms, and a FreeBSD kernel bug is not precluded as perhaps some other portion of raw IP socket input processing has changed and/or been broken. Please let us know what further investigation reveals about the source of the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=127528 From pjd at FreeBSD.org Mon Sep 22 14:24:53 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Sep 22 14:24:58 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <48D7A797.6070009@inse.ru> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl> <48D79E1C.3060003@inse.ru> <20080922134830.GA6797@garage.freebsd.pl> <48D7A797.6070009@inse.ru> Message-ID: <20080922142452.GC6797@garage.freebsd.pl> On Mon, Sep 22, 2008 at 06:11:35PM +0400, Roman Kurakin wrote: > Pawel Jakub Dawidek wrote: > >On Mon, Sep 22, 2008 at 05:31:08PM +0400, Roman Kurakin wrote: > > > >>So, could you draw you connections and related firewall rules. And the > >>one you > >>are trying to setup. I will also try to update the machine to the most > >>recent 7 to > >>see if my setup will stop working. Currently machine runs early > >>September checkout. > >> > > > >client (10.0.1.1) -----> bridge (10.0.5.123) -----> server (10.0.0.2) > > > >ifnet = "bridge0" > >rdr on $ifnet proto tcp from any to any port 12345 -> 10.0.5.123 port 12345 > >rdr on $ifnet proto udp from any to any port 12345 -> 10.0.5.123 port 12345 > > > Try also to play with stateful switches for pf. [...] Adding the following made even UDP non-working: pass in on $ifnet proto udp from any to any keep state For TCP there was no difference. > [...] By the way do you have > any global that affects > defaults? Besides net.inet.ip.forwarding=1, no, although I tried various settings for net.link.bridge.*. > >Although it works even with bridge0 and TCP connections, but when bridge > >machine is treated as gateway, eg. > > > >server# nc -l 12345 > >client# route add 1.0.0.0/24 10.0.5.123 > >client# nc 10.0.0.2 12345 > > > And what about ipfw variant? For the first (bridge) case ipfw didn't work at all. No packets were redirected. I haven't tried for the gateway case, because pf works there. -- 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/20080922/6d40e826/attachment.pgp From thompsa at FreeBSD.org Mon Sep 22 15:43:09 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Sep 22 15:43:15 2008 Subject: bridged tap interfaces with stp In-Reply-To: References: Message-ID: <20080922154301.GC76768@citylink.fud.org.nz> On Mon, Sep 22, 2008 at 05:00:59PM +0300, Sergey Listopad wrote: > Hi! > > I am playing with bridge(4) stp feature. > > there are 2 boxes with 7.0-RELEASE-p4. > > rt1 rt2 > ___________ ___________ > | ____| |____ | > | |tap1| ------------------------|tap1| | > | | | | > | |tap2|-------------------------|tap2| | > |___________| |___________| > > rt1 connected to rt2 with 2 openvpn L2 links (tap). > > tap1 bridged with tap2 on both routers. > > rt1# ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu 1500 > ether 56:8d:35:75:ee:3f > inet 3.3.3.1 netmask 0xffffff00 broadcast 3.3.3.255 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap2 flags=143 > member: tap1 flags=143 > > rt2# ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu 1500 > ether 3a:af:9d:0f:c1:b9 > inet 3.3.3.2 netmask 0xffffff00 broadcast 3.3.3.255 > id 00:00:00:00:00:00 priority 16384 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 16384 ifcost 0 port 0 > member: tap2 flags=143 > member: tap1 flags=143 > > rt1# ping 3.3.3.2 > PING 3.3.3.2 (3.3.3.2): 56 data bytes > 64 bytes from 3.3.3.2: icmp_seq=0 ttl=64 time=8.144 ms > 64 bytes from 3.3.3.2: icmp_seq=1 ttl=64 time=4.313 ms > 64 bytes from 3.3.3.2: icmp_seq=2 ttl=64 time=4.421 ms > ... > all works while broadcast > > Then I'd try to enable stp on bridge0 interfaces for automatic disable > one of redundant links (tap1/tap2). > rt1# ifconfig bridge0 stp tap1 stp tap2 > rt1# ifconfig bridge0 > bridge0: flags=8943 > metric 0 mtu 1500 > ether 56:8d:35:75:ee:3f > inet 3.3.3.1 netmask 0xffffff00 broadcast 3.3.3.255 > id 00:1c:c0:39:d6:b9 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:1c:c0:39:d6:b9 priority 32768 ifcost 0 port 0 > member: tap2 flags=147 > port 12 priority 128 path cost 2000000 proto rstp > role disabled state discarding > member: tap1 flags=147 > port 16 priority 128 path cost 2000000 proto rstp > role disabled state discarding > > rt2# ifconfig bridge0 stp tap1 stp tap2 > rt2# ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu 1500 > ether 3a:af:9d:0f:c1:b9 > inet 3.3.3.2 netmask 0xffffff00 broadcast 3.3.3.255 > id 00:1c:c0:39:d6:ad priority 16384 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:1c:c0:39:d6:ad priority 16384 ifcost 0 port 0 > member: tap2 flags=147 > port 9 priority 128 path cost 2000000 proto rstp > role disabled state discarding > member: tap1 flags=147 > port 8 priority 128 path cost 2000000 proto rstp > role disabled state discarding > > But when stp is enabled, it blocks all bridge members, and bridge stop working. > > May be I am misunderstand something with stp? > At all it is possible to use bridge(4) stp with tap(4)? This is because tap(4) does not have a media attachment, the spanning tree code uses this to check if there is a link and obtain the duplex (see bstp_ifupdstatus). Im not sure what the answer is, maybe ignore this for pseudo interfaces. Andrew From julian at elischer.org Mon Sep 22 17:26:43 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Sep 22 17:26:46 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080922142452.GC6797@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> <20080919121602.GC4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl> <48D79E1C.3060003@inse.ru> <20080922134830.GA6797@garage.freebsd.pl> <48D7A797.6070009@inse.ru> <20080922142452.GC6797@garage.freebsd.pl> Message-ID: <48D7D54A.1020709@elischer.org> Pawel Jakub Dawidek wrote: >> And what about ipfw variant? > > For the first (bridge) case ipfw didn't work at all. No packets were > redirected. I haven't tried for the gateway case, because pf works > there. ipfw forwarding is disabled for bridge and L2 cases. (I think the man page says so.) At Ironport we added some small patche sto allow this to occur. it is relatively simple.. (less than 10 lines) When ipfw returns that a packet to the bridge, that has been marked as 'redirected', then you accept it to the IP stack as if it was addressed to the local machine. You then make sure that in L3 ipfe processing, you hit the same fwd rule, and this time it is sent to the right place. It does require that ipfw see the packet twice, but it works. A further hack would be to add code in the IP stack so that a packet tagged as redirected from the bridge would skip ipfw in the IP stack and go direct to the redirection. (but that may open security issues). From max at love2party.net Mon Sep 22 18:13:31 2008 From: max at love2party.net (Max Laier) Date: Mon Sep 22 18:13:35 2008 Subject: Firewall redirect doesn't work any more... In-Reply-To: <20080922102209.GB2468@garage.freebsd.pl> References: <20080919075633.GA4333@garage.freebsd.pl> <200809191538.02698.max@love2party.net> <20080922102209.GB2468@garage.freebsd.pl> Message-ID: <200809222013.27553.max@love2party.net> On Monday 22 September 2008 12:22:09 Pawel Jakub Dawidek wrote: > On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote: > > I might be wrong, but I don't think we ever supported rdr without > > net.inet.ip.forwarding enabled. Maybe to a different local address, but > > even then you'd need net.inet.ip.check_interface=0. Looking at the code, > > I don't see where IPFW forwarding fails (as it has its own ip_forward() > > call), though. > > Ok, I did some more tests. I'm running bridge in there and trying to > redirect packets that goes through my bridge to a local daemon. > UDP redirect seems to work with PF: > > rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 -> 10.0.5.123 > port 12345 > > Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I > call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on > 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can > even send packets back and they are send with source address set to > 10.0.0.2 - this is exactly what I'm looking for. > > Unfortunately it doesn't work for TCP. I see packets beeing redirected to > 10.0.5.123, but my local daemon never accepts the connection and nc client > keeps resending SYN packets. > > I also see weird messages in the logs: > > TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored (Both tcps_badrst and tcps_sc_dropped are > increased on every connection attempt.) > > Any ideas how to make it work with TCP? > > PS. The same functionality doesn't work at all with ipfw(8) (because of > if_bridge(4)?). The problem is that the packet is still subject to bridge's L2 processing and thus will make it's way to the original MAC receiver that will bark on it. What you could try is a pf route-to rule to lo0 and 127.0.0.1 and then rdr on lo0. In contrast to rdr, a route-to rule will consume the packet and reinject it into the IP-processing path. This way it won't be forwarded by the bridge and there should not be problems. That being said, it's rather difficult to write firewall rules for a bridge as there is no clear concept of direction (in/out). In scenarios like this I usually suggest filtering on the member interfaces only: net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 0 -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From marcus at marcuscom.com Mon Sep 22 21:40:39 2008 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Mon Sep 22 21:40:42 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? In-Reply-To: <87prmw682t.fsf@chateau.d.lf> References: <87ej3e32iz.fsf@chateau.d.lf> <1221968342.74421.4.camel@shumai.marcuscom.com> <87prmw682t.fsf@chateau.d.lf> Message-ID: <1222119643.52357.88.camel@shumai.marcuscom.com> On Mon, 2008-09-22 at 11:22 +0530, Ashish Shukla ???? ????? wrote: > Joe Marcus Clarke writes: > > On Sun, 2008-09-21 at 03:26 +0530, Ashish Shukla ???? ????? wrote: > >> Hi all, > >> > >> Is there anyone, who is porting NetworkManager[1] to FreeBSD ? If yes, I > >> would like to be a tester or contributor to the effort. > > > It's been on our ideas list for a while, and I think someone mentioned > > they were working on it a few months ago (check the archives). I held a > > desktop discussion at the last BSDCan, and Kris Moore of PC-BSD > > suggested it may be easier to port their network manager > > (http://svn.pcbsd.org/browser/pcbsd/trunk/NetworkManager) from KDE to > > GTK+/GNOME > > > In the meantime, I did a GNOME PBI for PC-BSD, and added hooks to make > > use of some of PC-BSD's admin tools. The result was positive. However, > > it would be great to have working GTK+/GNOME native tools. > > Thanks for the reply. > > But, that looks like a static network configuration tool. Sorry, wrong link. There are a few network admin tools in PC-BSD (including a task tray application). Here is their wireless config app: http://svn.pcbsd.org/browser/pcbsd/trunk/wificonfi . The advantage of using the PC-BSD code is that the FreeBSD internal stuff is done already. That could could be used as a model for creating a GTK+/GNOME frontend. On the other hand, porting NM would require adapting it to your net80211 stack. Joe > > Ashish -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080922/a668f9f7/attachment.pgp From igor4ml at gmail.com Tue Sep 23 06:22:36 2008 From: igor4ml at gmail.com (Igor R) Date: Tue Sep 23 06:22:39 2008 Subject: Multiple routing tables (setfib) trouble Message-ID: Hello! I'm using FreeBSD 7.0-STABLE (Jul 25) and I have two Internet connections. Both are ethernet based, but one requires PPTP (2) while another is direct with external IP address. Trouble is that provider (1) of connection with external address is limiting number of outgoing TCP connections (this was reason I got another provider). So now my setup is 1) On boot I have default route to provider (1) 2) After MPD (PPTP) is up I replace default route with route to provider (2) 3) I use "route-to" and "reply-to" in /etc/pf.rules to route incoming SSH and HTTP and outgoing HTTP via provider (1), also I use these rules to provide routing to internal network of this provider 4) All other traffic (BitTorrent :-) ) is going via provider (2) via ng0 (PPTP) interface All works fine, but ... Provider with PPTP is less reliable and when PPTP connection fails I have trouble connecting to my SSH server (because DNS stops working) So, after FreeBSD got multiple routing tables I tried this: 1) On boot I have default route to provider (1) 2) After MPD (PPTP) is up I do 2a) setfib 1 route add default PPTP_DEFAULT_GATEWAY 2b) setfib 1 /usr/local/etc/rc.d/tranmission restart And here are problems: 1) All outgoing traffic with fib==1 goes through provider (2) as expected, answers are received 2) BUT ... incoming traffic looks strange: answers are sent through default gateway with fib==0 I made simple test: setfib 1 netcat -l 8000 and then from outside: telnet my_ip 8000 I see (with tcpdump) incoming packets on ng0 (PPTP) inteface, but no answers. If I start tcpdump on other provider interface I see packets with answers. But if I try setfib 1 traceroute some_host then routing works via correct gateway So, is it possible to have bittorrent daemon with FIB=1 :-)? From julian at elischer.org Tue Sep 23 07:42:32 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 23 07:42:34 2008 Subject: Multiple routing tables (setfib) trouble In-Reply-To: References: Message-ID: <48D89DE6.6090606@elischer.org> Igor R wrote: > Hello! > > I'm using FreeBSD 7.0-STABLE (Jul 25) and I have two Internet > connections. Both are ethernet based, but one requires PPTP (2) while > another is direct with external IP address. > Trouble is that provider (1) of connection with external address is > limiting number of outgoing TCP connections (this was reason I got > another provider). So now my setup is > 1) On boot I have default route to provider (1) > 2) After MPD (PPTP) is up I replace default route with route to provider (2) > 3) I use "route-to" and "reply-to" in /etc/pf.rules to route incoming > SSH and HTTP and outgoing HTTP via provider (1), also I use these > rules to provide routing to internal network of this provider > 4) All other traffic (BitTorrent :-) ) is going via provider (2) via > ng0 (PPTP) interface > All works fine, but ... Provider with PPTP is less reliable and when > PPTP connection fails I have trouble connecting to my SSH server > (because DNS stops working) > > So, after FreeBSD got multiple routing tables I tried this: > > 1) On boot I have default route to provider (1) > 2) After MPD (PPTP) is up I do > 2a) setfib 1 route add default PPTP_DEFAULT_GATEWAY > 2b) setfib 1 /usr/local/etc/rc.d/tranmission restart > > And here are problems: > 1) All outgoing traffic with fib==1 goes through provider (2) as > expected, answers are received > 2) BUT ... incoming traffic looks strange: answers are sent through > default gateway with fib==0 > > I made simple test: > > setfib 1 netcat -l 8000 > and then from outside: > telnet my_ip 8000 > I see (with tcpdump) incoming packets on ng0 (PPTP) inteface, but no > answers. If I start tcpdump on other provider interface I see packets > with answers. But if I try > setfib 1 traceroute some_host > then routing works via correct gateway > > So, is it possible to have bittorrent daemon with FIB=1 :-)? can you sendme teh output of: setfib -0 netstat -rn setfib -1 netstat -rn > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Tue Sep 23 07:49:25 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 23 07:49:26 2008 Subject: Multiple routing tables (setfib) trouble In-Reply-To: References: Message-ID: <48D89F83.9020002@elischer.org> Igor R wrote: > Hello! > > I'm using FreeBSD 7.0-STABLE (Jul 25) and I have two Internet > connections. Both are ethernet based, but one requires PPTP (2) while > another is direct with external IP address. > Trouble is that provider (1) of connection with external address is > limiting number of outgoing TCP connections (this was reason I got > another provider). So now my setup is > 1) On boot I have default route to provider (1) > 2) After MPD (PPTP) is up I replace default route with route to provider (2) > 3) I use "route-to" and "reply-to" in /etc/pf.rules to route incoming > SSH and HTTP and outgoing HTTP via provider (1), also I use these > rules to provide routing to internal network of this provider > 4) All other traffic (BitTorrent :-) ) is going via provider (2) via > ng0 (PPTP) interface > All works fine, but ... Provider with PPTP is less reliable and when > PPTP connection fails I have trouble connecting to my SSH server > (because DNS stops working) > > So, after FreeBSD got multiple routing tables I tried this: > > 1) On boot I have default route to provider (1) > 2) After MPD (PPTP) is up I do > 2a) setfib 1 route add default PPTP_DEFAULT_GATEWAY > 2b) setfib 1 /usr/local/etc/rc.d/tranmission restart > > And here are problems: > 1) All outgoing traffic with fib==1 goes through provider (2) as > expected, answers are received > 2) BUT ... incoming traffic looks strange: answers are sent through > default gateway with fib==0 > > I made simple test: > > setfib 1 netcat -l 8000 > and then from outside: > telnet my_ip 8000 > I see (with tcpdump) incoming packets on ng0 (PPTP) inteface, but no > answers. which address is the source address for the outgoing packets? is it possible the socket has been bound to the address of the other interface? hmm now THEORETICALLY you can figure out which packets have which fib by using the 'fib' qualifier in ipfw.. i.e. ipfw add 100 count log ip from any to any fib 1 to > If I start tcpdump on other provider interface I see packets > with answers. But if I try > setfib 1 traceroute some_host > then routing works via correct gateway > > So, is it possible to have bittorrent daemon with FIB=1 :-)? > _______________________________________________ > 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 auryn at zirakzigil.org Tue Sep 23 08:17:08 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Tue Sep 23 08:17:11 2008 Subject: lost routes Message-ID: <48D8A232.600@zirakzigil.org> I think this is a very old freebsd problem, dating back to freebsd5 or even before. Every now and again static routes are lost by freebsd. In my fw/router/vpn box (average traffic about 10Mb/s) with a lot of interfaces, physical, vlan and virtual, once every x weeks (x very variable) one of the routes get lost. Just yesterday night I updated the system with the last 7 stable (amd64). This morning one of the route has disappeared. Since I believe I'm not the only one to experience this, can the network developers report on the status of this bug? Thanks. From rea-fbsd at codelabs.ru Tue Sep 23 08:52:51 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Sep 23 08:52:54 2008 Subject: lost routes In-Reply-To: <48D8A232.600@zirakzigil.org> References: <48D8A232.600@zirakzigil.org> Message-ID: Giulio, good day. Tue, Sep 23, 2008 at 10:00:50AM +0200, Giulio Ferro wrote: > Every now and again static routes are lost by freebsd. > In my fw/router/vpn box (average traffic about 10Mb/s) with a lot > of interfaces, physical, vlan and virtual, once every x weeks (x very > variable) one of the routes get lost. > > Just yesterday night I updated the system with the last 7 stable > (amd64). This morning one of the route has disappeared. > > Since I believe I'm not the only one to experience this, can the > network developers report on the status of this bug? Was the problem described in some PR? Can it be so that the interface goes down and then it is resurrected by the sequence that is more-or-less identical to /etc/rc.d/netif restart? This can lead to the route loss. Do you have some kernel messages that are related to the interface on which routes are lost? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- 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/20080923/dcfcba37/attachment.pgp From auryn at zirakzigil.org Tue Sep 23 08:57:58 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Tue Sep 23 08:58:00 2008 Subject: lost routes In-Reply-To: References: <48D8A232.600@zirakzigil.org> Message-ID: <48D8AF8E.6080507@zirakzigil.org> Eygene Ryabinkin wrote: > Giulio, good day. > > Good day to you. > Was the problem described in some PR? > I don't know, really. I heard about it in the past (some years ago) from another guy, and it has happened to me for at least 2-3 years. This is just the first time I've decided to report it (my bad)... > Can it be so that the interface goes down and then it is resurrected by > the sequence that is more-or-less identical to /etc/rc.d/netif restart? > This can lead to the route loss. Do you have some kernel messages that > are related to the interface on which routes are lost? > Nope. There are no messages in the logs, and no interface has been touched. Anyway, since there are a lot of routes and only one gets deleted I don't think it depends on interface changing (it would delete them all, wouldn't it?) Interestingly enough, one of the routes that is erased has the same gateway as several others which aren't deleted. Hope it rings some bell... Bye. From michal at myserver.cz Tue Sep 23 09:04:14 2008 From: michal at myserver.cz (Michal Sviba) Date: Tue Sep 23 09:04:17 2008 Subject: lost routes In-Reply-To: <48D8A232.600@zirakzigil.org> References: <48D8A232.600@zirakzigil.org> Message-ID: <1222159049.5256.34.camel@michal-desktop> Hi, i've seen a bit similar problem with routes. I have two interfaces (em0, iwi0) on laptop. Problem is, after this command # ifconfig em0 down I expected, that every routes to this interface should be deleted (included default gw). But route "dest: default netif: em0" is stil present in # netstat -f inet -r I have 7.1-PRERELEASE, but same case is on 7.0. Michal Giulio Ferro p??e v ?t 23. 09. 2008 v 10:00 +0200: > I think this is a very old freebsd problem, dating back to freebsd5 > or even before. > > Every now and again static routes are lost by freebsd. > In my fw/router/vpn box (average traffic about 10Mb/s) with a lot > of interfaces, physical, vlan and virtual, once every x weeks (x very > variable) one of the routes get lost. > > Just yesterday night I updated the system with the last 7 stable > (amd64). This morning one of the route has disappeared. > > Since I believe I'm not the only one to experience this, can the > network developers report on the status of this bug? > > 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" -- Michal Sviba -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080923/00143727/attachment.pgp From rea-fbsd at codelabs.ru Tue Sep 23 10:35:06 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Sep 23 10:35:09 2008 Subject: lost routes In-Reply-To: <48D8AF8E.6080507@zirakzigil.org> References: <48D8A232.600@zirakzigil.org> <48D8AF8E.6080507@zirakzigil.org> Message-ID: Giulio, Tue, Sep 23, 2008 at 10:57:50AM +0200, Giulio Ferro wrote: > > Was the problem described in some PR? > > > I don't know, really. I heard about it in the past (some years ago) > from another guy, and it has happened to me for at least 2-3 years. > > This is just the first time I've decided to report it (my bad)... Then it will be good to open PR about this: it will allow other people to see this issue and may be this won't be lost in the mailing lists. It will be rather hard to do something with this issue if it won't be reproducible, so it will be great if you (or other people who sees the simular problems) will find a way to reproduce the problem in some setup. > > Can it be so that the interface goes down and then it is resurrected by > > the sequence that is more-or-less identical to /etc/rc.d/netif restart? > > This can lead to the route loss. Do you have some kernel messages that > > are related to the interface on which routes are lost? > > > > Nope. > There are no messages in the logs, and no interface has been > touched. Anyway, since there are a lot of routes and only one > gets deleted I don't think it depends on interface changing > (it would delete them all, wouldn't it?) Yes, in theory, it should delete all routes having this interface. > Interestingly enough, one of the routes that is erased has the > same gateway as several others which aren't deleted. Hope it > rings some bell... OK, so, please, file PR, provide as many details as possible, try to find a way to reproduce this problem (but even if you'll not be able to do it "just now", post PR anyway) and post a link to the PR here. May be Someone (tm) will be able to help you. My $0.02. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- 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/20080923/113c8fd9/attachment.pgp From gnn at freebsd.org Tue Sep 23 19:30:01 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Sep 23 19:30:03 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... Message-ID: Hi, It turns out that the last time anyone looked at this constant was before 1994 and it's very likely time to turn it into a kernel tunable. On hosts that have a high rate of packet transmission packets can be dropped at the interface queue because this value is too small. Rather than make a sweeping code change I propose the following change to the macro and updating a couple of places in the IP and IPv6 stacks that were using this macro to set their own global variables. I have tested this in my test lab at work, it is not as yet in production at my day job, but will be soon. Best, George Index: netinet/ip_input.c =================================================================== --- netinet/ip_input.c (revision 183299) +++ netinet/ip_input.c (working copy) @@ -133,7 +133,6 @@ struct pfil_head inet_pfil_hook; /* Packet filter hooks */ static struct ifqueue ipintrq; -static int ipqmaxlen = IFQ_MAXLEN; extern struct domain inetdomain; extern struct protosw inetsw[]; @@ -265,7 +264,7 @@ /* Initialize various other remaining things. */ ip_id = time_second & 0xffff; - ipintrq.ifq_maxlen = ipqmaxlen; + ipintrq.ifq_maxlen = IFQ_MAXLEN; mtx_init(&ipintrq.ifq_mtx, "ip_inq", NULL, MTX_DEF); netisr_register(NETISR_IP, ip_input, &ipintrq, NETISR_MPSAFE); } Index: net/if.c =================================================================== --- net/if.c (revision 183299) +++ net/if.c (working copy) @@ -135,7 +135,14 @@ #endif int if_index = 0; -int ifqmaxlen = IFQ_MAXLEN; + +int ifqmaxlen = 50; +TUNABLE_INT("net.ifqmaxlen", &ifqmaxlen); + +SYSCTL_INT(_net, OID_AUTO, ifqmaxlen, CTLFLAG_RD, + &ifqmaxlen, 0, + "interface queue length"); + struct ifnethead ifnet; /* depend on static init XXX */ struct ifgrouphead ifg_head; struct mtx ifnet_lock; Index: net/if.h =================================================================== --- net/if.h (revision 183299) +++ net/if.h (working copy) @@ -221,7 +221,7 @@ #define IFCAP_WOL (IFCAP_WOL_UCAST | IFCAP_WOL_MCAST | IFCAP_WOL_MAGIC) #define IFCAP_TOE (IFCAP_TOE4 | IFCAP_TOE6) -#define IFQ_MAXLEN 50 +#define IFQ_MAXLEN ifqmaxlen #define IFNET_SLOWHZ 1 /* granularity is 1 second */ /* Index: netinet6/ip6_input.c =================================================================== --- netinet6/ip6_input.c (revision 183299) +++ netinet6/ip6_input.c (working copy) @@ -115,7 +115,6 @@ u_char ip6_protox[IPPROTO_MAX]; static struct ifqueue ip6intrq; -static int ip6qmaxlen = IFQ_MAXLEN; struct in6_ifaddr *in6_ifaddr; extern struct callout in6_tmpaddrtimer_ch; @@ -178,7 +177,7 @@ printf("%s: WARNING: unable to register pfil hook, " "error %d\n", __func__, i); - ip6intrq.ifq_maxlen = ip6qmaxlen; + ip6intrq.ifq_maxlen = IFQ_MAXLEN; mtx_init(&ip6intrq.ifq_mtx, "ip6_inq", NULL, MTX_DEF); netisr_register(NETISR_IPV6, ip6_input, &ip6intrq, 0); scope6_init(); From ru at FreeBSD.org Tue Sep 23 21:00:20 2008 From: ru at FreeBSD.org (Ruslan Ermilov) Date: Tue Sep 23 21:00:22 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: References: Message-ID: <20080923201718.GA88008@edoofus.dev.vega.ru> Hi, On Tue, Sep 23, 2008 at 03:29:06PM -0400, gnn@freebsd.org wrote: > It turns out that the last time anyone looked at this constant was > before 1994 and it's very likely time to turn it into a kernel > tunable. On hosts that have a high rate of packet transmission > packets can be dropped at the interface queue because this value is > too small. Rather than make a sweeping code change I propose the > following change to the macro and updating a couple of places in the > IP and IPv6 stacks that were using this macro to set their own global > variables. > > I have tested this in my test lab at work, it is not as yet in > production at my day job, but will be soon. > It's not that bad -- most modern Ethernet drivers initialize interface input queues themselves, and don't depend on IFQ_MAXLEN. The IPv4 input queue is tunable via net.inet.ip.intr_queue_maxlen. The IPv6 queue can similarly be made tunable. I agree that ifqmaxlen can be made tunable because there's still a lot of (mostly for old hardware) drivers that use ifqmaxlen and IFQ_MAXLEN, but I'm against changing the definition of IFQ_MAXLEN. Imagine some code like this: void *x[IFQ_MAXLEN]; // here it's 50 And some function that does: for (i = 0; i < IFQ_MAXLEN; i++) { // not necessarily 50 x[i] = NULL; } Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From 20080111.freebsd.org at ab.ote.we.lv Tue Sep 23 21:08:51 2008 From: 20080111.freebsd.org at ab.ote.we.lv (Eugene M. Kim) Date: Tue Sep 23 21:08:53 2008 Subject: Request for review - PR bin/127951: spurious warning against DNAME RRs Message-ID: <48D95AD7.2070604@ab.ote.we.lv> Greetings, I just submitted a very simple PR/patch - http://www.freebsd.org/cgi/query-pr.cgi?pr=127591 - which fixes spurious but annoying warnings against DNAME RRs (annoying because they spam syslog at auth.notice level). The patch should not cause any regression, because it just suppresses the warning without altering any other control flow, but I am not entirely sure if there is a valid case where DNAMEs should trigger a strong security warning just as they currently do. Could someone please review and/or take care of this PR? Cheers, Eugene P.S. A bit of background information, for those who are not familiar with the subject: DNAME RRs, as defined in RFC 2672, provides a useful mechanism for mapping/aliasing an entire DNS tree. For (a real) example, given a primary domain "the-7.net" and a number of secondary domains such as the-7.com, the-7.org, the-seven.net and so on, instead of having to add CNAMEs for "www", "mail" and other subdomains to every single secondary domain, one can simply add "IN DNAME the-7.net." to the zone apex of those secondary domains, and the DNS server will take care of all possible - current /and/ future - subdomains automatically, by returning a synthesized CNAME: $ dig www.the-7.com IN A +noall +answer ; <<>> DiG 9.4.2-P1 <<>> www.the-7.com IN A +noall +answer ;; global options: printcmd the-7.com. 300 IN DNAME the-7.net. www.the-7.com. 0 IN CNAME www.the-7.net. www.the-7.net. 300 IN CNAME purple.the-7.net. purple.the-7.net. 300 IN A 64.71.156.34 $ From peterjeremy at optushome.com.au Tue Sep 23 21:38:49 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Sep 23 21:38:52 2008 Subject: lost routes In-Reply-To: <48D8A232.600@zirakzigil.org> References: <48D8A232.600@zirakzigil.org> Message-ID: <20080923091559.GJ15376@server.vk2pj.dyndns.org> On 2008-Sep-23 10:00:50 +0200, Giulio Ferro wrote: >I think this is a very old freebsd problem, dating back to freebsd5 >or even before. I don't recall seeing it, or previous references to this problem, so all I can offer is more questions. I presume you aren't running any sort of routing daemon or DHCP client. >Every now and again static routes are lost by freebsd. >In my fw/router/vpn box (average traffic about 10Mb/s) with a lot >of interfaces, physical, vlan and virtual, once every x weeks (x very >variable) one of the routes get lost. Is it a random route, or is it always the same route being lost? If it's different routes, is there anything in common between the routes that are lost? Are all your interfaces on disjoint subnets? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- 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/20080923/2b9e0d7a/attachment.pgp From linimon at FreeBSD.org Tue Sep 23 22:09:21 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 23 22:09:24 2008 Subject: kern/127587: [if_bge] [request] if_bge(4) doesn't support BCM576X family Message-ID: <200809232209.m8NM9LOI003876@freefall.freebsd.org> Old Synopsis: if_bge(4) doesn't support BCM576X family New Synopsis: [if_bge] [request] if_bge(4) doesn't support BCM576X family State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Tue Sep 23 22:08:30 UTC 2008 State-Changed-Why: Awaiting someone to implement the code. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 23 22:08:30 UTC 2008 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=127587 From rumuru at gmail.com Tue Sep 23 22:42:02 2008 From: rumuru at gmail.com (Mungyung Ryu) Date: Tue Sep 23 22:42:05 2008 Subject: ACE on FreeBSD? Message-ID: Hi freeBSD users, I've developed couple of server applications on Windows platform with ACE Proactor and it worked quite well. But, because of the expensive Windows Server, I wanna move to Linux or freeBSD. Recently, I'm considering to build a server application on freeBSD but the important issue is whether the freeBSD supports ACE Proactor framework. I googled about it and Linux doesn't support it well because Linux doesn't support AIO (asynchronous I/O) on socket. Moreover, most of the ACE professionals recommend to use Reactor framework on Linux. My questions is.. 1. freeBSD supports AIO on socket? 2. I can use ACE Proactor framework on freeBSD 7.0 without any problem? Is it stable? -- ****************************************************************************** Mungyung Ryu Ph.D. Student. College of Computing Georgia Institute of Technology, Atlanta ****************************************************************************** From julian at elischer.org Tue Sep 23 23:06:41 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 23 23:06:44 2008 Subject: Request for review - PR bin/127951: spurious warning against DNAME RRs In-Reply-To: <48D95AD7.2070604@ab.ote.we.lv> References: <48D95AD7.2070604@ab.ote.we.lv> Message-ID: <48D9767F.2080207@elischer.org> Eugene M. Kim wrote: > Greetings, > > I just submitted a very simple PR/patch - > http://www.freebsd.org/cgi/query-pr.cgi?pr=127591 - which fixes spurious > but annoying warnings against DNAME RRs (annoying because they spam > syslog at auth.notice level). > > The patch should not cause any regression, because it just suppresses > the warning without altering any other control flow, but I am not > entirely sure if there is a valid case where DNAMEs should trigger a > strong security warning just as they currently do. > > Could someone please review and/or take care of this PR? > > Cheers, > Eugene > > P.S. A bit of background information, for those who are not familiar > with the subject: > > DNAME RRs, as defined in RFC 2672, provides a useful mechanism for > mapping/aliasing an entire DNS tree. For (a real) example, given a > primary domain "the-7.net" and a number of secondary domains such as > the-7.com, the-7.org, the-seven.net and so on, instead of having to add > CNAMEs for "www", "mail" and other subdomains to every single secondary > domain, one can simply add "IN DNAME the-7.net." to the zone apex of > those secondary domains, and the DNS server will take care of all > possible - current /and/ future - subdomains automatically, by returning > a synthesized CNAME: > > $ dig www.the-7.com IN A +noall +answer sigh, another DNS RR I have to add support for at $WORK.. > > ; <<>> DiG 9.4.2-P1 <<>> www.the-7.com IN A +noall +answer > ;; global options: printcmd > the-7.com. 300 IN DNAME the-7.net. > www.the-7.com. 0 IN CNAME www.the-7.net. > www.the-7.net. 300 IN CNAME purple.the-7.net. > purple.the-7.net. 300 IN A 64.71.156.34 > $ > > _______________________________________________ > 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 gnn at FreeBSD.org Wed Sep 24 03:37:07 2008 From: gnn at FreeBSD.org (gnn@FreeBSD.org) Date: Wed Sep 24 03:37:10 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: <20080923201718.GA88008@edoofus.dev.vega.ru> References: <20080923201718.GA88008@edoofus.dev.vega.ru> Message-ID: At Wed, 24 Sep 2008 00:17:18 +0400, Ruslan Ermilov wrote: > > Hi, > > On Tue, Sep 23, 2008 at 03:29:06PM -0400, gnn@freebsd.org wrote: > > It turns out that the last time anyone looked at this constant was > > before 1994 and it's very likely time to turn it into a kernel > > tunable. On hosts that have a high rate of packet transmission > > packets can be dropped at the interface queue because this value is > > too small. Rather than make a sweeping code change I propose the > > following change to the macro and updating a couple of places in the > > IP and IPv6 stacks that were using this macro to set their own global > > variables. > > > > I have tested this in my test lab at work, it is not as yet in > > production at my day job, but will be soon. > > > It's not that bad -- most modern Ethernet drivers initialize interface > input queues themselves, and don't depend on IFQ_MAXLEN. The IPv4 > input queue is tunable via net.inet.ip.intr_queue_maxlen. The IPv6 > queue can similarly be made tunable. I agree that ifqmaxlen can be > made tunable because there's still a lot of (mostly for old hardware) > drivers that use ifqmaxlen and IFQ_MAXLEN, but I'm against changing > the definition of IFQ_MAXLEN. Imagine some code like this: > Sorry, this is about the output queue, not the input queue. Though there are both input and output queues that depend on this. > void *x[IFQ_MAXLEN]; // here it's 50 > > And some function that does: > > for (i = 0; i < IFQ_MAXLEN; i++) { // not necessarily 50 > x[i] = NULL; > } > I found no occurrences of the above in our code base. I used cscope to search all of src/sys. Are you aware of any occurrences of this? Best, George From ganbold at micom.mng.net Wed Sep 24 10:50:17 2008 From: ganbold at micom.mng.net (Ganbold) Date: Wed Sep 24 10:50:20 2008 Subject: ipfw port lookup table patch for review Message-ID: <48DA1B65.8030106@micom.mng.net> Hi, I thought it might be useful to have port lookup table similar to existing IP lookup table in ipfw and I have made patch for that. The downside of the patch so far I'm seeing is the port entries are in linked list (no limitation yet, memory overhead), not sorted and it uses linear search to match (could be slow when lot of entries). Just after I've made the patch I saw http://www.freebsd.org/cgi/query-pr.cgi?pr=121807&cat= . :( I agree with PR's reply however for small number of port entries I thought this functionality is quite useful. It gives benefit like no need to modify existing rule, adding/deleting port entries is easy. I did some small tests and it seems like working. Patches are at: http://people.freebsd.org/~ganbold/ipfw_port_table/ The output of some usage samples is at: http://people.freebsd.org/~ganbold/ipfw_port_table/ipfw_port_table_usage_sample.txt Patches can be successfully applied to CURRENT. Didn't test RELENG_7 due to no RELENG_7 PC :) Please let me know your thoughts. I'm happy to discuss to improve the patch. Correct me if I'm doing something wrong here. thanks, Ganbold From kfl at xiplink.com Wed Sep 24 14:27:20 2008 From: kfl at xiplink.com (Karim Fodil-Lemelin) Date: Wed Sep 24 14:27:30 2008 Subject: ACE on FreeBSD? In-Reply-To: References: Message-ID: <48DA4AE3.7060907@xiplink.com> Mungyung Ryu wrote: > Hi freeBSD users, > > I've developed couple of server applications on Windows platform with ACE > Proactor > and it worked quite well. But, because of the expensive Windows Server, > I wanna move to Linux or freeBSD. > > Recently, I'm considering to build a server application on freeBSD but the > important issue > is whether the freeBSD supports ACE Proactor framework. > I googled about it and Linux doesn't support it well because Linux doesn't > support AIO (asynchronous I/O) on socket. > Moreover, most of the ACE professionals recommend to use Reactor framework > on Linux. > > My questions is.. > > 1. freeBSD supports AIO on socket? > Yes > 2. I can use ACE Proactor framework on freeBSD 7.0 without any problem? Is > it stable? > It works, although the same Linux recommendation stands for FreeBSD. Reactor had much more love then the Proactor on Unices. From bms at FreeBSD.org Wed Sep 24 14:43:20 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 24 14:43:31 2008 Subject: ACE on FreeBSD? In-Reply-To: References: Message-ID: <48DA5204.3030803@FreeBSD.org> Hi, I looked at ACE years and years ago (~1997) when Doug Schmidt was first promoting the ideas behind it. The whole Reactor/Proactor split pretty much hangs on the event dispatch which your particular OS supports. The key observation is whether your target OS implements events in an edge-triggered or level-triggered way; I am borrowing definitions from electronic engineering here. You could do a straight port with Proactor, but performance will probably suck, because both FreeBSD (and Linux, I believe) need to emulate POSIX asynchronous I/O operations. Reactor will generally "fare better" on UNIX derived systems such as FreeBSD and Linux, because its event handling primitives are geared towards the level-triggered facilities provided by select(). In Windows, Winsock events use asynchronous notifications which may be tied to Win32 EVENT objects, and the usual Kernel32.DLL thread primitives are used around this. This makes Proactor more appropriate in that environment. XORP does some similar stuff to ACE under the hood to support the native socket facilities of both Windows and FreeBSD/Linux. It's hybridized but it behaves more like Reactor because we run in a single thread, and you have to force Winsock's helper thread to run, by preempting you, using some file handle and socket tricks. I don't currently know about stability of ACE on FreeBSD. cheers BMS From bms at FreeBSD.org Wed Sep 24 14:50:34 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 24 14:50:44 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: References: Message-ID: <48DA53B8.3030407@FreeBSD.org> Hi, I agree with the intent of the change that IPv4 and IPv6 input queues should have a tunable queue length. However, the change provided is going to make the definition of IFQ_MAXLEN global and dependent upon a variable. gnn@freebsd.org wrote: > Hi, > > It turns out that the last time anyone looked at this constant was > before 1994 and it's very likely time to turn it into a kernel > tunable. On hosts that have a high rate of packet transmission > packets can be dropped at the interface queue because this value is > too small. Rather than make a sweeping code change I propose the > following change to the macro and updating a couple of places in the > IP and IPv6 stacks that were using this macro to set their own global > variables. > This isn't appropriate for many uses of ifq's which might be internal to a given driver or subsystem, and which may use IFQ_MAXLEN for convenience, as Ruslan has pointed out. I have code elsewhere which does this. Can you please do this on a per-protocol stack basis? i.e. give IPv4 and IPv6 their own TUNABLE queue length. thanks BMS From bms at FreeBSD.org Wed Sep 24 14:52:53 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 24 14:53:23 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: References: <20080923201718.GA88008@edoofus.dev.vega.ru> Message-ID: <48DA5443.3070903@FreeBSD.org> gnn@FreeBSD.org wrote: > ... > I found no occurrences of the above in our code base. I used cscope > to search all of src/sys. Are you aware of any occurrences of this? > I have been using IFQ_MAXLEN to size buffer queues internal to some IGMPv3 stuff. I don't feel comfortable with a change which sizes the queues for both IPv4 and IPv6 stacks, from a variable which is obscured by a macro. thanks BMS From bms at FreeBSD.org Wed Sep 24 14:55:25 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Wed Sep 24 14:55:30 2008 Subject: lost routes In-Reply-To: <48D8AF8E.6080507@zirakzigil.org> References: <48D8A232.600@zirakzigil.org> <48D8AF8E.6080507@zirakzigil.org> Message-ID: <48DA54DA.8070102@FreeBSD.org> Giulio Ferro wrote: > > There are no messages in the logs, and no interface has been > touched. Anyway, since there are a lot of routes and only one > gets deleted I don't think it depends on interface changing > (it would delete them all, wouldn't it?) Normally static routes only get touched if the state of the underlying ifp/ifa changes. There are paths in netinet which will cause routes to be deleted in this situation. Occasionally the idea of a floating static re-surfaces... look in the PR database with this term for possibly related reports. cheers BMS From gnn at FreeBSD.org Wed Sep 24 19:45:57 2008 From: gnn at FreeBSD.org (gnn@FreeBSD.org) Date: Wed Sep 24 19:46:00 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: <48DA53B8.3030407@FreeBSD.org> References: <48DA53B8.3030407@FreeBSD.org> Message-ID: At Wed, 24 Sep 2008 15:50:32 +0100, Bruce M. Simpson wrote: > > Hi, > > I agree with the intent of the change that IPv4 and IPv6 input queues > should have a tunable queue length. However, the change provided is > going to make the definition of IFQ_MAXLEN global and dependent upon a > variable. > > gnn@freebsd.org wrote: > > Hi, > > > > It turns out that the last time anyone looked at this constant was > > before 1994 and it's very likely time to turn it into a kernel > > tunable. On hosts that have a high rate of packet transmission > > packets can be dropped at the interface queue because this value is > > too small. Rather than make a sweeping code change I propose the > > following change to the macro and updating a couple of places in the > > IP and IPv6 stacks that were using this macro to set their own global > > variables. > > > > This isn't appropriate for many uses of ifq's which might be internal to > a given driver or subsystem, and which may use IFQ_MAXLEN for > convenience, as Ruslan has pointed out. I have code elsewhere which does > this. > > Can you please do this on a per-protocol stack basis? i.e. give IPv4 and > IPv6 their own TUNABLE queue length. > Actually what we'd need is N of these, since my target is actually the send queue, not the input queue. Let me look at this some more. Best, George From jmg at funkthat.com Wed Sep 24 20:15:42 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Wed Sep 24 20:15:44 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: References: Message-ID: <20080924195331.GQ783@funkthat.com> George V. Neville-Neil wrote this message on Tue, Sep 23, 2008 at 15:29 -0400: > It turns out that the last time anyone looked at this constant was > before 1994 and it's very likely time to turn it into a kernel > tunable. On hosts that have a high rate of packet transmission > packets can be dropped at the interface queue because this value is > too small. Rather than make a sweeping code change I propose the > following change to the macro and updating a couple of places in the > IP and IPv6 stacks that were using this macro to set their own global > variables. The better solution is to resurrect rwatson's patch that eliminates the interface queue, and does direct dispatch to the ethernet driver.. Usually the driver has a queue of 512 or more packets already, so putting them into a second queue doesn't provide much benefit besides increasing the amount of locking necessary to deliver packets... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From julian at elischer.org Wed Sep 24 20:36:11 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 24 20:36:18 2008 Subject: ACE on FreeBSD? In-Reply-To: <48DA5204.3030803@FreeBSD.org> References: <48DA5204.3030803@FreeBSD.org> Message-ID: <48DAA4BB.7080907@elischer.org> Bruce M. Simpson wrote: > Hi, > > I looked at ACE years and years ago (~1997) when Doug Schmidt was first > promoting the ideas behind it. The whole Reactor/Proactor split pretty > much hangs on the event dispatch which your particular OS supports. > > The key observation is whether your target OS implements events in an > edge-triggered or level-triggered way; I am borrowing definitions from > electronic engineering here. > > You could do a straight port with Proactor, but performance will > probably suck, because both FreeBSD (and Linux, I believe) need to > emulate POSIX asynchronous I/O operations. > > Reactor will generally "fare better" on UNIX derived systems such as > FreeBSD and Linux, because its event handling primitives are geared > towards the level-triggered facilities provided by select(). A true FreeBSD port would use kevent with AIO. At Cisco/ironport we use AIO with the build in kevent trigering to great effect. Certainly for sockets it works VERY well. > > In Windows, Winsock events use asynchronous notifications which may be > tied to Win32 EVENT objects, and the usual Kernel32.DLL thread > primitives are used around this. This makes Proactor more appropriate in > that environment. > > XORP does some similar stuff to ACE under the hood to support the native > socket facilities of both Windows and FreeBSD/Linux. It's hybridized but > it behaves more like Reactor because we run in a single thread, and you > have to force Winsock's helper thread to run, by preempting you, using > some file handle and socket tricks. > > I don't currently know about stability of ACE on FreeBSD. > > cheers > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Wed Sep 24 20:38:12 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 24 20:38:19 2008 Subject: ACE on FreeBSD? In-Reply-To: <48DAA4BB.7080907@elischer.org> References: <48DA5204.3030803@FreeBSD.org> <48DAA4BB.7080907@elischer.org> Message-ID: <48DAA533.3080607@elischer.org> Julian Elischer wrote: > Bruce M. Simpson wrote: >> Hi, >> >> I looked at ACE years and years ago (~1997) when Doug Schmidt was >> first promoting the ideas behind it. The whole Reactor/Proactor split >> pretty much hangs on the event dispatch which your particular OS >> supports. >> >> The key observation is whether your target OS implements events in an >> edge-triggered or level-triggered way; I am borrowing definitions from >> electronic engineering here. >> >> You could do a straight port with Proactor, but performance will >> probably suck, because both FreeBSD (and Linux, I believe) need to >> emulate POSIX asynchronous I/O operations. >> >> Reactor will generally "fare better" on UNIX derived systems such as >> FreeBSD and Linux, because its event handling primitives are geared >> towards the level-triggered facilities provided by select(). > > A true FreeBSD port would use kevent with AIO. > At Cisco/ironport we use AIO with the build in kevent trigering to > great effect. Certainly for sockets it works VERY well. sorry I meant for sockets and raw devices.. (what we use them for) sockets don't need AIO to work well with kevent but raw devices do. Luckily it works as advertised. > >> >> In Windows, Winsock events use asynchronous notifications which may be >> tied to Win32 EVENT objects, and the usual Kernel32.DLL thread >> primitives are used around this. This makes Proactor more appropriate >> in that environment. >> >> XORP does some similar stuff to ACE under the hood to support the >> native socket facilities of both Windows and FreeBSD/Linux. It's >> hybridized but it behaves more like Reactor because we run in a single >> thread, and you have to force Winsock's helper thread to run, by >> preempting you, using some file handle and socket tricks. >> >> I don't currently know about stability of ACE on FreeBSD. >> >> cheers >> BMS >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > 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 debarshi.ray at gmail.com Wed Sep 24 20:42:37 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed Sep 24 20:42:44 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? In-Reply-To: References: <87ej3e32iz.fsf@chateau.d.lf> <1221968342.74421.4.camel@shumai.marcuscom.com> Message-ID: <3170f42f0809241342q422439b7oe72f60cf45ba53f8@mail.gmail.com> > I was thinking about porting it, because I really need this thing on > my laptop and to have some programming experience. I just wanted to > have a companion, because I'm not sure I can handle this by myself and > because I'm pretty lazy these days, so I need to feel responsibility Myself and Ashish are working on a library (libroute) that basically abstracts out the various interfaces offered by different kernels to interact with routing tables, etc.. Currently NetworkManager uses libnl [1], which is a wrapper over the Linux kernel's PF_NETLINK socket interface, but its entirely Linux specific. So libroute will have a backend for PF_NETLINK (using libnl), one for PF_ROUTE, and so on. Once we have the required functionality, we intend to modify NetworkManager so that it calls libroute instead of libnl. The initial code is available here: git://bombadil.infradead.org/~rishi/inetutils.git (see libroute/ and route/) I must say that libroute is still in the initial stages of developement. :-) Interested? Happy hacking, Debarshi [1] http://people.suug.ch/~tgr/libnl From debarshi.ray at gmail.com Wed Sep 24 20:49:34 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed Sep 24 20:49:45 2008 Subject: [X-POST] Anyone porting NetworkManager to FreeBSD ? In-Reply-To: References: <87ej3e32iz.fsf@chateau.d.lf> <1221968342.74421.4.camel@shumai.marcuscom.com> <3170f42f0809241342q422439b7oe72f60cf45ba53f8@mail.gmail.com> Message-ID: <3170f42f0809241349v13700daeme5ca5f0618b17f0b@mail.gmail.com> > Yep, I'm interested. :) Awesome. Clone the Git tree start hacking. Ashish is working on a patch to add IPv6 support to BSD's show function (see bsd_show.c), while I am reworking the Linux backend to use libnl instead of mucking with PF_NETLINK directly. The immediate TODO items are to implement 'add' and 'delete' support for BSD. Happy hacking, Debarshi From gnn at freebsd.org Wed Sep 24 22:04:51 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Wed Sep 24 22:05:02 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: <20080924195331.GQ783@funkthat.com> References: <20080924195331.GQ783@funkthat.com> Message-ID: At Wed, 24 Sep 2008 12:53:31 -0700, John-Mark Gurney wrote: > > George V. Neville-Neil wrote this message on Tue, Sep 23, 2008 at 15:29 -0400: > > It turns out that the last time anyone looked at this constant was > > before 1994 and it's very likely time to turn it into a kernel > > tunable. On hosts that have a high rate of packet transmission > > packets can be dropped at the interface queue because this value is > > too small. Rather than make a sweeping code change I propose the > > following change to the macro and updating a couple of places in the > > IP and IPv6 stacks that were using this macro to set their own global > > variables. > > The better solution is to resurrect rwatson's patch that eliminates the > interface queue, and does direct dispatch to the ethernet driver.. > Usually the driver has a queue of 512 or more packets already, so putting > them into a second queue doesn't provide much benefit besides increasing > the amount of locking necessary to deliver packets... Actually I am making this change because I found on 10G hardware the queue is too small. Also, there are many systems where you might want to up this, usually ones that are highly biased towards transmit only, like a multicast repeater of some sort. Best, George From emax at FreeBSD.org Wed Sep 24 23:45:54 2008 From: emax at FreeBSD.org (emax@FreeBSD.org) Date: Wed Sep 24 23:45:59 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Message-ID: <200809242345.m8ONjrDO068751@freefall.freebsd.org> Synopsis: [panic] kernel panic when sending file via ng_ubt(4) Responsible-Changed-From-To: freebsd-net->emax Responsible-Changed-By: emax Responsible-Changed-When: Wed Sep 24 23:45:40 UTC 2008 Responsible-Changed-Why: over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=126742 From alfred at freebsd.org Thu Sep 25 00:47:15 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Thu Sep 25 00:47:22 2008 Subject: Question regarding NFS In-Reply-To: <96af083b0809181644o6136af1fybf0110f227f04f3b@mail.gmail.com> References: <96af083b0809181644o6136af1fybf0110f227f04f3b@mail.gmail.com> Message-ID: <20080925003146.GI36572@elvis.mu.org> * Adam Stylinski [080918 17:15] wrote: > Hello, > I am running an IPCop firewall for my entire network. I have a > wireless network device on the blue subnet which must access a freebsd NFS > server. In order to do this, I need to open a DMZ pinhole on a few select > ports. It's my understanding that NFS chooses random ports and I was > wondering if there was a way I could fix this. There is a good reason that > the subnet for the wireless is separate from the wired and I'd rather not > configure this thing over a VPN. The client connecting to the NFS server is > a voyage computer (pretty much a small debian). Also, if at all possible, > I'd like to keep performance reasonably high when large volumes of clients > are connecting to the NFS server, I'm not sure if binding to one port may or > may not make this impossible. I apologize for my stupidity and lack of > understanding when it comes to NFS. Any help would be gladly appreciated, > guys. _usually_ NFS uses port 2049 on the server side. I think the client may bind to a random low port, this would be annoying to change, but could be done with a kernel hack relatively easily. Look at the code in src/sys/nfsclient/nfs_socket.c, there's some code that that deals with binding sockets that you can play with. -- - Alfred Perlstein From julian at elischer.org Thu Sep 25 04:05:41 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 25 04:05:47 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: References: <20080924195331.GQ783@funkthat.com> Message-ID: <48DB0E14.6030607@elischer.org> gnn@freebsd.org wrote: > At Wed, 24 Sep 2008 12:53:31 -0700, > John-Mark Gurney wrote: >> George V. Neville-Neil wrote this message on Tue, Sep 23, 2008 at 15:29 -0400: >>> It turns out that the last time anyone looked at this constant was >>> before 1994 and it's very likely time to turn it into a kernel >>> tunable. On hosts that have a high rate of packet transmission >>> packets can be dropped at the interface queue because this value is >>> too small. Rather than make a sweeping code change I propose the >>> following change to the macro and updating a couple of places in the >>> IP and IPv6 stacks that were using this macro to set their own global >>> variables. >> The better solution is to resurrect rwatson's patch that eliminates the >> interface queue, and does direct dispatch to the ethernet driver.. >> Usually the driver has a queue of 512 or more packets already, so putting >> them into a second queue doesn't provide much benefit besides increasing >> the amount of locking necessary to deliver packets... > > Actually I am making this change because I found on 10G hardware the > queue is too small. Also, there are many systems where you might want > to up this, usually ones that are highly biased towards transmit only, > like a multicast repeater of some sort. > One system I have seen, that I thought made sense used to define queue length globally in msecs and each interface interpretted that to a different length. > Best, > George > _______________________________________________ > 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 raffaele.delorenzo at libero.it Thu Sep 25 14:01:37 2008 From: raffaele.delorenzo at libero.it (raffaele.delorenzo@libero.it) Date: Thu Sep 25 14:01:53 2008 Subject: [IPFW add ARP support] - Request for testing Message-ID: Hi all, In the last 2 weeks i implemented a new filter method inside the ipfw firewall for ARP protocols. My idea for the new method was to create a new "proto" microinstruction exclusively for ARP protocol named "arp". This method permits filter tering from/to particular MAC address to be restricted to ARP protocol. Example: ipfw add deny arp from 52:54:00:12:34:56 to 00:11:43:cd:87:6t // Deny all ARP packets generated by "from" and destinated to "to". The wildcard "any" and "me" are supported; the semantic is the same for all old protocol rules: ipfw add deny arp from 00:11:43:cd:87:6t to any Moreover, I implemented some filter methods that restrict the filtering to some ARP header fields: 1) Source MAC address (srcmac-arp) 2) Source IP address (srcip-arp) 3) Destination MAC address (dstmac-arp) 4) Destination IP address (dstip-arp) Example: ./ipfw add deny arp from 00:11:43:cd:87:6e to 52:54:00:12:34:56 srcmac-arp 52:54:00:12:34:56 dstip-arp 192.9.217.29 To work properly, the ARP implementation requires that ipfw receives packets from Layer 2, In other words, you must set the sysctl variable "net.link.ether.ipfw=1". I attached the new sources and all diffs with reference to FreeBSD 7.0 Release source Tree. Please let me know what you think about this work and if possible eventually test it. Ciao Ciao Raffaele -------------- next part -------------- A non-text attachment was scrubbed... Name: =?iso-8859-1?Q?ipfw=5Farp=5Fext.tar.bz2?= Type: application/octet-stream Size: 118186 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080925/f537a2f9/iso-8859-1Qipfw5Farp5Fext.tar-0001.obj From brde at optusnet.com.au Thu Sep 25 17:47:24 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Sep 25 17:47:31 2008 Subject: Proposed patch, convert IFQ_MAXLEN to kernel tunable... In-Reply-To: References: <20080924195331.GQ783@funkthat.com> Message-ID: <20080925150227.L33284@delplex.bde.org> On Wed, 24 Sep 2008 gnn@FreeBSD.org wrote: > At Wed, 24 Sep 2008 12:53:31 -0700, > John-Mark Gurney wrote: >> >> George V. Neville-Neil wrote this message on Tue, Sep 23, 2008 at 15:29 -0400: >>> It turns out that the last time anyone looked at this constant was >>> before 1994 and it's very likely time to turn it into a kernel >>> tunable. On hosts that have a high rate of packet transmission >>> packets can be dropped at the interface queue because this value is >>> too small. Rather than make a sweeping code change I propose the >>> following change to the macro and updating a couple of places in the >>> IP and IPv6 stacks that were using this macro to set their own global >>> variables. The global value is rarely used (except by low-end and/or 10 Mbps hardware where it doesn't matter). One important place where it is used (that you changed) is for ipintrq, but this should have a different default anyway and already has its own sysctl to fix up the broken default. >> The better solution is to resurrect rwatson's patch that eliminates the >> interface queue, and does direct dispatch to the ethernet driver.. If this were really better, then rwatson would have committed it. >> Usually the driver has a queue of 512 or more packets already, so putting >> them into a second queue doesn't provide much benefit besides increasing >> the amount of locking necessary to deliver packets... No, the second queue provides the fairly large benefit of doing watermark processing via double buffering. Most or all network drivers do no watermark processing except accidentally via the second queue. Even with watermarks in the driver queue, it still takes a fairly large external queue to prevent the transmitter running dry under load. E.g., in my version of the bge driver, there is essentially a watermark at 112 descriptors before the end of the driver tx queue. Under load, the driver tx queue is normally filled with 496 descriptors on every output interrupt. The driver enters state IFF_DRV_OACTIVE and upper layers stop trying to transfer packets to the driver queue. The next output interrupt occurs after 384 of the 496 descriptors have been handled, so that 112 remain. Then IFF_DRV_OACTIVE is cleared and upper layers resume transferring packets to the driver queue. For output to stream, and for efficiency, it is essential for upper layers to have plenty of packets to transfer at this point, but without the double buffering they would have none. When things are working right, the upper layers produce more than 384 descriptors by transferring at this point so that the driver queue fills again. For output to stream, it is essential to produce 1 new descriptor faster than the hardware can handle the 112 remaining ones and then keep producing new descriptors faster than the hardware can handle the previous new ones. With my hardware, the 112 descriptors take about 150 usec to handle. Buffering in userland is too far away to deliver new packets within this time in many cases (though syscalls are fast enough, scheduling delays are usually too long). > Actually I am making this change because I found on 10G hardware the > queue is too small. Also, there are many systems where you might want > to up this, usually ones that are highly biased towards transmit only, > like a multicast repeater of some sort. You would rarely want the globabl default to apply to all interfaces. Anywyay, interfaces with a hardware queue length (er, ring count) of 512 normally don't use the default, but use their ring count (bogusly less 1) for the software queue length too. This can be too small too. In some cases, since select() for writing on sockets attached to hardware doesn't work (it should block if all queues are full and return soon IFF_DRV_ACTIVE transitions from set to clear and the queues become non-full, but it only unerstands the socket buffer and doesn't look at the queues), context switches to the application producing the packets is delayed until at least the next scheduling tick or two, which happens 2-20 msec later. I use sendq lengths of ~20000 for bge and em to prevent the queues running dry with a scheduling latency of 20 msec. (10 Gbps would require prepostorous queue lengths of ~200000 for the same result.) However, even a queue length of (512+512-1) is bad for performance. Cycling through mbufs in a circular way ensures busting of caches once the queue length is large enough for the memory to exceed the cache size[s]. With a queue length of 50 and today's cache sizes, it is almost possible to fit everything into the L1 cache. Bruce From gleb.kurtsou at gmail.com Fri Sep 26 08:51:46 2008 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Fri Sep 26 08:51:52 2008 Subject: [IPFW add ARP support] - Request for testing In-Reply-To: References: Message-ID: <4c1d27f20809260151u4e44bb8epee482eb0eafebd0a@mail.gmail.com> On Thu, Sep 25, 2008 at 4:49 PM, raffaele.delorenzo@libero.it wrote: > Hi all, > In the last 2 weeks i implemented a new filter method inside the ipfw firewall for ARP protocols. > My idea for the new method was to create a new "proto" microinstruction exclusively for ARP protocol named "arp". This method permits filter tering from/to particular MAC address to be restricted to ARP protocol. > > Example: > > ipfw add deny arp from 52:54:00:12:34:56 to 00:11:43:cd:87:6t // Deny all ARP packets generated by "from" and destinated to "to". > > The wildcard "any" and "me" are supported; the semantic is the same for all old protocol rules: > > ipfw add deny arp from 00:11:43:cd:87:6t to any > > > Moreover, I implemented some filter methods that restrict the filtering to some ARP header fields: > > 1) Source MAC address (srcmac-arp) > 2) Source IP address (srcip-arp) > 3) Destination MAC address (dstmac-arp) > 4) Destination IP address (dstip-arp) > > Example: > > ./ipfw add deny arp from 00:11:43:cd:87:6e to 52:54:00:12:34:56 srcmac-arp 52:54:00:12:34:56 dstip-arp 192.9.217.29 > > To work properly, the ARP implementation requires that ipfw receives packets from Layer 2, In other words, you must set the sysctl variable "net.link.ether.ipfw=1". > > I attached the new sources and all diffs with reference to FreeBSD 7.0 Release source Tree. Please let me know what you think about this work and if possible eventually test it. > > Ciao Ciao > Raffaele > > _______________________________________________ > 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" > Just my 2 cents. There is another implementation of ARP filtering with IPFW available. It was implemented as a part of Google Summer of Code'2008. I'm still waiting for a review by Max Laier Original message containing path to freebsd-net@: http://lists.freebsd.org/pipermail/freebsd-net/2008-September/019458.html From waynehendricks at gmail.com Fri Sep 26 06:29:13 2008 From: waynehendricks at gmail.com (Wayne Hendricks) Date: Fri Sep 26 11:23:17 2008 Subject: Hostapd network issue Message-ID: <3b965dec0809252258t15722eecn29494431bced3061@mail.gmail.com> I have been trying to make hostapd work with wifi card in my gateway box. WPA stays working for only a short time before hostapd locks up and needs to be restarted. I believe the hosapd config is fine, shows no errors. Running 7.0-RELEASE-p4 amd64 with mini-pci Atheros 5212 chipset. I have included the hostapd debug output below. What is this ioctl[SIOCS80211] weirdness? Configuration file: /etc/hostapd.conf ctrl_interface_group=0 (from group name 'wheel') bsd_set_iface_flags: dev_up=0 BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) ath0: IEEE 802.11 Fetching hardware channel/rate support not supported. Flushing old station entries bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 Deauthenticate all stations bsd_set_privacy: enabled=0 Mode: IEEE 802.11g Channel: 11 Frequency: 0 MHz bsd_del_key: addr=00:00:00:00:00:00 key_idx=0 bsd_del_key: addr=00:00:00:00:00:00 key_idx=1 bsd_del_key: addr=00:00:00:00:00:00 key_idx=2 bsd_del_key: addr=00:00:00:00:00:00 key_idx=3 bsd_get_ssid: ssid="bsdap" Using interface ath0 with hwaddr 00:90:96:6b:0f:c6 and ssid 'bsdap' SSID - hexdump_ascii(len=9): 52 4e 73 65 63 75 72 65 47 bsdap PSK (ASCII passphrase) - hexdump_ascii(len=12): 65 74 68 65 72 61 70 65 31 31 31 36 mypassphrase PSK (from passphrase) - hexdump(len=32): 17 ae 54 6a a7 c4 fc ce e2 d4 2e 07 0d 08 09 56 41 d3 a4 6a d2 18 26 d1 36 22 56 fe a0 af 26 43 bsd_set_ieee8021x: enabled=1 bsd_configure_wpa: group key cipher=TKIP (1) bsd_configure_wpa: pairwise key ciphers=0xa bsd_configure_wpa: key management algorithms=0x2 bsd_configure_wpa: rsn capabilities=0x0 bsd_configure_wpa: enable WPA= 0x1 bsd_set_iface_flags: dev_up=1 WPA: group state machine entering state GTK_INIT (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 bsd_set_privacy: enabled=1 ath0: Setup of interface done. ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: associated New STA ath0: STA 00:1e:c2:bf:74:60 WPA: event 1 notification bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 ath0: STA 00:1e:c2:bf:74:60 WPA: start authentication WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION2 WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITPSK WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKSTART ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 03 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 9f 2b fa 4e 6e 00 d2 a0 fd 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 123 bytes from 00:1e:c2:bf:74:60 IEEE 802.1X: version=1 type=3 length=119 ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/4 Pairwise) WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING PMK - hexdump(len=32): [REMOVED] PTK - hexdump(len=64): [REMOVED] WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING2 WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:1e:c2:bf:74:60 WPA: sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 keyidx=0 encr=0) TX EAPOL - hexdump(len=141): 00 1e c2 bf 74 60 00 00 96 6b 0f c6 88 8e 02 03 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cf 86 6a 87 74 59 72 dc 2f 01 f9 8b b4 20 51 1f 00 1c dd 1a 00 50 f2 0 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (4/4 Pairwise) WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITDONE bsd_set_key: alg=CCMP addr=00:1e:c2:bf:74:60 key_idx=0 bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=1 ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: authorizing port bsd_sta_clear_stats: addr=00:1e:c2:bf:74:60 ath0: STA 00:1e:c2:bf:74:60 WPA: pairwise key handshake completed (WPA) WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 d8 ba b9 34 15 fd ae 04 7c 59 05 d4 08 70 4c 00 28 36 25 48 ae 3c 8 d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 fc 57 fd 57 c1 90 be a2 50 a4 ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 46 6b 0f c6 88 8e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 3a d0 8a fd 74 2d 9a cf ba eb 75 56 26 71 63 00 28 36 25 48 ae 3c 8 d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 fc 37 fd 57 c1 00 be a2 50 a4 IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated New STA ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 e9 6e 68 d0 00 90 96 6b 0f c6 58 8e 02 03 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 IEEE 802.1X: version=1 type=3 length=119 ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING PMK - hexdump(len=32): [REMOVED] PTK - hexdump(len=64): [REMOVED] WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 keyidx=0 encr=0) TX EAPOL - hexdump(len=141): 00 21 e9 6e 98 d0 00 90 96 6b 0f c5 88 8e 02 03 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 55 c7 5a e3 2d 7a 54 f2 6d f0 7b 9f cc ca b3 00 1c dd 1a 00 50 f2 0 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 68 8e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb 76 69 1b 31 76 d5 81 87 d1 fb f5 ac 85 f1 d7 00 28 f6 9f 0d ca 6e 4 b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 8e 6b 1c 10 cd af a5 66 58 5f d2 fb 3d 48 ath0: STA 00:21:e9:6e:98:d0 WPA: EAPOL-Key timeout WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 88 8e 02 03 00 47 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ec 85 4f 9e d0 f7 89 9c a5 aa da f7 94 32 96 1b 00 28 f6 9f 0d ca 6e 4 b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 3e 6b 1c 10 cd af a5 96 58 5f d2 fb 3d 48 IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port Could not set station 00:21:e9:6e:98:d0 flags for kernel driver (errno=22). ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=2 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 03 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 05 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 21 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 4a 9b 73 a4 2a 85 58 43 ea 4b 26 39 52 da 0b 00 28 97 d8 b5 38 1a 9 9 dc 43 65 b5 bd ac 8c 7e 35 2c 12 7c 55 d4 79 0a 54 68 4c 5c 59 36 5b f6 69 31 ad 4a 90 ff 81 be c6 4f IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 76 6b 0f c6 88 8e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 06 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 16 82 a2 6d 95 4d 6b 3c ce 5b 05 47 76 55 00 28 7a a2 9a 85 ef a f a9 be 86 56 94 45 a3 ab b8 a5 b3 d5 44 3b a4 d3 9f 7b 3d ea 97 e6 c3 ed 9e 42 da 4b 91 2d fd 7f 1e 8d IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated New STA ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 e9 6e 98 d0 00 30 96 6b 0f c6 88 8e 02 03 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 3b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 IEEE 802.1X: version=1 type=3 length=119 ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING PMK - hexdump(len=32): [REMOVED] PTK - hexdump(len=64): [REMOVED] WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 keyidx=0 encr=0) TX EAPOL - hexdump(len=141): 00 21 e9 6e 78 d0 00 90 96 6b 0f c6 88 8e 02 03 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 95 a0 4e 64 c6 43 6c e9 8c 02 ef 75 27 f9 e5 00 1c dd 1a 00 50 f2 0 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 40 f2 02 IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 21 e9 6e 08 d0 00 90 96 6b 0f c6 88 5e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 dc 19 fc 24 e2 56 37 16 14 5a 0b 00 25 c2 47 00 28 78 92 48 df 3b e f 3c d7 25 82 34 d2 32 7d 1f cc 12 d1 4e c0 89 dc 29 80 88 45 95 27 13 49 b0 da ef f9 c9 fd f0 52 a9 b5 IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port Could not set station 00:21:e9:6e:98:d0 flags for kernel driver (errno=22). Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=2 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 78 8e 02 03 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 07 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 be eb 48 36 b5 ad 1f 17 bc 64 ca 6b c8 ca 00 28 8a 2b 24 9f ee 4 4 0f e7 4a ad a8 55 62 cd b9 d0 69 cc af e4 94 01 aa d8 e9 cf cc a7 ed 6e e0 90 b5 3c 35 1a ae 2e 32 d7 IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 IEEE 802.1X: version=1 type=3 length=95 ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active Checking STA 00:1e:c2:bf:74:60 inactivity: Station has been active ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 40 00 90 96 6b 0f c6 88 8e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 08 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 50 c3 fa 32 83 f8 05 c4 c3 78 e5 cf 48 25 79 00 28 10 4a c3 91 12 2 f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 97 54 a3 60 a9 d7 73 20 6d f1 ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 03 00 87 fe 03 92 00 10 00 00 00 00 00 00 00 09 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29 b1 39 72 aa d0 25 02 a4 5b 01 55 a9 c6 5b cf 00 28 10 4a c3 91 12 2 f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 57 54 a3 60 a9 d7 73 20 6d f1 ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 98 8e 02 03 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 0a 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 79 9c 20 34 dd 26 28 c7 c2 6f a3 1c a4 03 44 00 28 10 4a c3 91 12 2 f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 57 54 a3 60 a9 d7 73 20 6d f1 ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 keyidx=1 encr=1) Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 03 00 87 fe 03 02 00 20 00 00 00 00 00 00 00 0b 1c c4 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 91 86 ea b0 4b 7f c5 2b 2c 9c b2 94 67 d4 e6 14 00 28 10 4a c3 91 12 2 f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 57 54 a3 60 a8 d7 73 20 6d f1 WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state KEYERROR WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:1e:c2:bf:74:60 reason 2 bsd_sta_deauth: addr=00:1e:c2:bf:74:60 reason_code=2 WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECTED WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port Could not set station 00:1e:c2:bf:74:60 flags for kernel driver (errno=22). ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: deauthenticated due to local deauth request GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 ath0: WPA rekeying GTK WPA: group state machine entering state SETKEYS (VLAN-ID 0) GMK - hexdump(len=32): [REMOVED] GTK - hexdump(len=32): [REMOVED] WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: Invalid argument ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: Invalid argument ioctl[SIOCS80211]: No such file or directory ioctl[SIOCS80211]: Invalid argument Signal 2 received - terminating Flushing old station entries bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 Deauthenticate all stations bsd_set_privacy: enabled=0 bsd_set_ieee8021x: enabled=0 bsd_set_iface_flags: dev_up=0 From linimon at FreeBSD.org Fri Sep 26 12:44:01 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Sep 26 12:44:08 2008 Subject: kern/127644: [ndis] [panic] NDIS panic Message-ID: <200809261244.m8QCi1tO030105@freefall.freebsd.org> Old Synopsis: NDIS panic New Synopsis: [ndis] [panic] NDIS panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Sep 26 12:43:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127644 From ivoras at freebsd.org Fri Sep 26 13:05:16 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Sep 26 13:05:23 2008 Subject: Intel NIC ARP problem Message-ID: I have a strange problem with a PRO/1000 EB NIC (card=0x109615d9 chip=0x10968086) built into the motherboard (5000X chipset) that manifests itself in NIC stopping responding to ARP packets requesting its address while in Windows XP, after being rebooted from FreeBSD (dual-boot). The sequence is: ** cold boot (after the power has been disconnected from the PSU) into WinXP: NIC works on WinXP ** reboot into FreeBSD: NIC works ** reboot into WinXP: NIC doesn't respond to ARP ** reboot into FreeBSD: NIC works ** reboot into WinXP: NIC doesn't respond to ARP ** cold boot into WinXP: NIC starts working again I found the cold boot resolution by searching the net, apparently it's a semi-known problem: http://www.supermicro.com/support/faqs/faq.cfm?faq=7837 - my motherboard isn't the one mentioned on this page but they share the same chipset (Intel 5000X - this is a Xeon-based workstation). I confirmed that it's an ARP issue by two things: - computers with a large ARP timeout can access the machine while the ARP entry is cached at their side - connecting a laptop via crossover to the machine and using arping clearly shows that ARP is responding until reboot from FreeBSD to WinXP. This is a workstation for developing and testing cross-platform software so rebooting between operating systems is common. Any ideas? Software involved: - FreeBSD 8-CURRENT amd64 - WinXP SP3 i386 - For WinXP, tried both the drivers from the motherboard maker (12.4) and the newest available on Intel's web site (13.2.8) dmesg, etc. are available. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080926/e764a826/signature.pgp From steve at ibctech.ca Fri Sep 26 14:05:42 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Fri Sep 26 14:06:04 2008 Subject: netstat byte/bit confusion Message-ID: <48DCEC3E.70303@ibctech.ca> Hey all, I'm experiencing conflicting information on throughput numbers when comparing information garnered via MRTG on a 1000Mbps HP Procurve, and netstat -h -w1 on a server connected to the switch. What I want to know is if netstat in the below case is actually displaying the info in bits, even though it is telling me the result is in bytes: amanda# netstat -h -w1 input (Total) output packets errs bytes packets errs bytes colls 109K 0 90M 200 0 14K 0 104K 0 88M 201 0 14K 0 ^C On a different server running MRTG (FBSD 7.0-STABLE), I have configured it to display in bits/s, and it is showing ~90Mbps. Which one is accurate? I'm trying to evaluate the difference between Cisco Cat 29xx 100Mb switches and this ProCurve GigE 2848 switch. So far, my results are that the 100Mb Cisco can peak and sustain a 98Mbps throughput. The Procurve, unless MRTG is wrong, and netstat output should be 90M*8, I'm far less than impressed. ...or could it be that MRTG is broken/capped at ~100Mbps calculations? Thanks for any insight, Steve From jfvogel at gmail.com Fri Sep 26 16:12:00 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Sep 26 16:12:08 2008 Subject: Intel NIC ARP problem In-Reply-To: References: Message-ID: <2a41acea0809260839m72ee76f6m3e6671c4f0d67f0e@mail.gmail.com> So, distilling down the data, the problem is booting from FreeBSD into Windows, right? The underlying problem is that the management system is eatting the ARP I believe. It looks like my driver does not clean up something properly on exit, hmmm, I'll have to look into it Ivan. Thanks for the report. Jack On Fri, Sep 26, 2008 at 5:52 AM, Ivan Voras wrote: > I have a strange problem with a PRO/1000 EB NIC (card=0x109615d9 > chip=0x10968086) built into the motherboard (5000X chipset) that manifests > itself in NIC stopping responding to ARP packets requesting its > address while in Windows XP, after being rebooted from FreeBSD > (dual-boot). > > The sequence is: > > ** cold boot (after the power has been disconnected from the PSU) into > WinXP: NIC works on WinXP > ** reboot into FreeBSD: NIC works > ** reboot into WinXP: NIC doesn't respond to ARP > ** reboot into FreeBSD: NIC works > ** reboot into WinXP: NIC doesn't respond to ARP > ** cold boot into WinXP: NIC starts working again > > I found the cold boot resolution by searching the net, apparently it's > a semi-known problem: > http://www.supermicro.com/support/faqs/faq.cfm?faq=7837 - my > motherboard isn't the one mentioned on this page but they share the > same chipset (Intel 5000X - this is a Xeon-based workstation). > > I confirmed that it's an ARP issue by two things: > > - computers with a large ARP timeout can access the machine while > the ARP entry is cached at their side > - connecting a laptop via crossover to the machine and using arping > clearly shows that ARP is responding until reboot from FreeBSD to > WinXP. > > This is a workstation for developing and testing cross-platform > software so rebooting between operating systems is common. Any ideas? > > Software involved: > > - FreeBSD 8-CURRENT amd64 > - WinXP SP3 i386 > - For WinXP, tried both the drivers from the motherboard maker (12.4) > and the newest available on Intel's web site (13.2.8) > > dmesg, etc. are available. > > From 000.fbsd at quip.cz Fri Sep 26 16:58:52 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Sep 26 16:58:59 2008 Subject: netstat byte/bit confusion In-Reply-To: <48DCEC3E.70303@ibctech.ca> References: <48DCEC3E.70303@ibctech.ca> Message-ID: <48DD109E.9040900@quip.cz> Steve Bertrand wrote: > Hey all, > > I'm experiencing conflicting information on throughput numbers when > comparing information garnered via MRTG on a 1000Mbps HP Procurve, and > netstat -h -w1 on a server connected to the switch. > > What I want to know is if netstat in the below case is actually > displaying the info in bits, even though it is telling me the result is > in bytes: > > amanda# netstat -h -w1 > input (Total) output > packets errs bytes packets errs bytes colls > 109K 0 90M 200 0 14K 0 > 104K 0 88M 201 0 14K 0 > ^C > > On a different server running MRTG (FBSD 7.0-STABLE), I have configured > it to display in bits/s, and it is showing ~90Mbps. > > Which one is accurate? I'm trying to evaluate the difference between > Cisco Cat 29xx 100Mb switches and this ProCurve GigE 2848 switch. So > far, my results are that the 100Mb Cisco can peak and sustain a 98Mbps > throughput. > > The Procurve, unless MRTG is wrong, and netstat output should be 90M*8, > I'm far less than impressed. > > ...or could it be that MRTG is broken/capped at ~100Mbps calculations? > > Thanks for any insight, If you are using MRTG with SNMP info from switch, be aware of 32 bit counters. If you have high network load on the switch, the counter overflows between two five minutes intervals of MRTG and then MRTG shows inacurate results. (for example 60Mbps instead of 250Mbps peak) Some devices have 64 bit counters and MRTG can be configured to use these. netstat is in bytes AFAIK. Miroslav Lachman From ivoras at freebsd.org Fri Sep 26 17:24:09 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Sep 26 17:24:16 2008 Subject: Intel NIC ARP problem In-Reply-To: <2a41acea0809260839m72ee76f6m3e6671c4f0d67f0e@mail.gmail.com> References: <2a41acea0809260839m72ee76f6m3e6671c4f0d67f0e@mail.gmail.com> Message-ID: <9bbcef730809260958r73927e8et1adf9b0fcd010095@mail.gmail.com> 2008/9/26 Jack Vogel : > So, distilling down the data, the problem is booting from > FreeBSD into Windows, right? > > The underlying problem is that the management system > is eatting the ARP I believe. It looks like my driver does > not clean up something properly on exit, hmmm, I'll have > to look into it Ivan. Thanks for the report. Thank you for your quick response! As far as I know there's no management board installed (or at least none that I recognize - IPMI and the like), if it helps you somehow. From sam at freebsd.org Fri Sep 26 17:46:34 2008 From: sam at freebsd.org (Sam Leffler) Date: Fri Sep 26 17:46:42 2008 Subject: Hostapd network issue In-Reply-To: <3b965dec0809252258t15722eecn29494431bced3061@mail.gmail.com> References: <3b965dec0809252258t15722eecn29494431bced3061@mail.gmail.com> Message-ID: <48DD1FF6.6010608@freebsd.org> Wayne Hendricks wrote: > I have been trying to make hostapd work with wifi card in my gateway box. > WPA stays working for only a short time before hostapd locks up and needs to > be restarted. I believe the hosapd config is fine, shows no errors. > Running 7.0-RELEASE-p4 amd64 with mini-pci Atheros 5212 chipset. I have > included the hostapd debug output below. What is this ioctl[SIOCS80211] > weirdness? > > Configuration file: /etc/hostapd.conf > ctrl_interface_group=0 (from group name 'wheel') > bsd_set_iface_flags: dev_up=0 > BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) > ath0: IEEE 802.11 Fetching hardware channel/rate support not supported. > Flushing old station entries > bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 > Deauthenticate all stations > bsd_set_privacy: enabled=0 > Mode: IEEE 802.11g Channel: 11 Frequency: 0 MHz > bsd_del_key: addr=00:00:00:00:00:00 key_idx=0 > bsd_del_key: addr=00:00:00:00:00:00 key_idx=1 > bsd_del_key: addr=00:00:00:00:00:00 key_idx=2 > bsd_del_key: addr=00:00:00:00:00:00 key_idx=3 > bsd_get_ssid: ssid="bsdap" > Using interface ath0 with hwaddr 00:90:96:6b:0f:c6 and ssid 'bsdap' > SSID - hexdump_ascii(len=9): > 52 4e 73 65 63 75 72 65 47 bsdap > PSK (ASCII passphrase) - hexdump_ascii(len=12): > 65 74 68 65 72 61 70 65 31 31 31 36 mypassphrase > PSK (from passphrase) - hexdump(len=32): 17 ae 54 6a a7 c4 fc ce e2 d4 2e 07 > 0d 08 09 56 41 d3 a4 6a d2 18 26 d1 36 22 56 fe a0 > af 26 43 > bsd_set_ieee8021x: enabled=1 > bsd_configure_wpa: group key cipher=TKIP (1) > bsd_configure_wpa: pairwise key ciphers=0xa > bsd_configure_wpa: key management algorithms=0x2 > bsd_configure_wpa: rsn capabilities=0x0 > bsd_configure_wpa: enable WPA= 0x1 > bsd_set_iface_flags: dev_up=1 > WPA: group state machine entering state GTK_INIT (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 > bsd_set_privacy: enabled=1 > ath0: Setup of interface done. > ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: associated > New STA > ath0: STA 00:1e:c2:bf:74:60 WPA: event 1 notification > bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 > ath0: STA 00:1e:c2:bf:74:60 WPA: start authentication > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE > bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 > bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 > ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITPSK > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKSTART > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 > encr=0) > TX EAPOL - hexdump(len=113): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 03 > 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 9f 2b fa 4e 6e 00 d2 a0 fd > 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 123 bytes from 00:1e:c2:bf:74:60 > IEEE 802.1X: version=1 type=3 length=119 > ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/4 Pairwise) > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING > PMK - hexdump(len=32): [REMOVED] > PTK - hexdump(len=64): [REMOVED] > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING2 > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 3/4 msg of 4-Way Handshake > WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 > keyidx=0 encr=0) > TX EAPOL - hexdump(len=141): 00 1e c2 bf 74 60 00 00 96 6b 0f c6 88 8e 02 03 > 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cf 86 6a 87 74 59 > 72 dc 2f 01 f9 8b b4 20 51 1f 00 1c dd 1a 00 50 f2 0 > 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 > IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (4/4 Pairwise) > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITDONE > bsd_set_key: alg=CCMP addr=00:1e:c2:bf:74:60 key_idx=0 > bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=1 > ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: authorizing port > bsd_sta_clear_stats: addr=00:1e:c2:bf:74:60 > ath0: STA 00:1e:c2:bf:74:60 WPA: pairwise key handshake completed (WPA) > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 d8 ba b9 34 15 > fd ae 04 7c 59 05 d4 08 70 4c 00 28 36 25 48 ae 3c 8 > d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 fc > 57 fd 57 c1 90 be a2 50 a4 > ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 46 6b 0f c6 88 8e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 3a d0 8a fd 74 > 2d 9a cf ba eb 75 56 26 71 63 00 28 36 25 48 ae 3c 8 > d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 fc > 37 fd 57 c1 00 be a2 50 a4 > IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED > ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated > New STA > ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 > encr=0) > TX EAPOL - hexdump(len=113): 00 21 e9 6e 68 d0 00 90 96 6b 0f c6 58 8e 02 03 > 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 > IEEE 802.1X: version=1 type=3 length=119 > ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING > PMK - hexdump(len=32): [REMOVED] > PTK - hexdump(len=64): [REMOVED] > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake > WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 > keyidx=0 encr=0) > TX EAPOL - hexdump(len=141): 00 21 e9 6e 98 d0 00 90 96 6b 0f c5 88 8e 02 03 > 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 55 c7 5a e3 2d > 7a 54 f2 6d f0 7b 9f cc ca b3 00 1c dd 1a 00 50 f2 0 > 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 > IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE > bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 > bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port > bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 > ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 68 8e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb 76 69 1b 31 76 > d5 81 87 d1 fb f5 ac 85 f1 d7 00 28 f6 9f 0d ca 6e 4 > b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 8e 6b 1c 10 cd > af a5 66 58 5f d2 fb 3d 48 > ath0: STA 00:21:e9:6e:98:d0 WPA: EAPOL-Key timeout > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 88 8e 02 03 > 00 47 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ec 85 4f 9e d0 f7 > 89 9c a5 aa da f7 94 32 96 1b 00 28 f6 9f 0d ca 6e 4 > b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 3e 6b 1c 10 cd > af a5 96 58 5f d2 fb 3d 48 > IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED > ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated > ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port > Could not set station 00:21:e9:6e:98:d0 flags for kernel driver (errno=22). > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=2 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 03 > 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 05 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 21 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c0 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 4a 9b 73 a4 2a > 85 58 43 ea 4b 26 39 52 da 0b 00 28 97 d8 b5 38 1a 9 > 9 dc 43 65 b5 bd ac 8c 7e 35 2c 12 7c 55 d4 79 0a 54 68 4c 5c 59 36 5b f6 69 > 31 ad 4a 90 ff 81 be c6 4f > IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED > ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 76 6b 0f c6 88 8e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 06 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 16 82 a2 6d > 95 4d 6b 3c ce 5b 05 47 76 55 00 28 7a a2 9a 85 ef a > f a9 be 86 56 94 45 a3 ab b8 a5 b3 d5 44 3b a4 d3 9f 7b 3d ea 97 e6 c3 ed 9e > 42 da 4b 91 2d fd 7f 1e 8d > IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED > ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated > New STA > ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 > encr=0) > TX EAPOL - hexdump(len=113): 00 21 e9 6e 98 d0 00 30 96 6b 0f c6 88 8e 02 03 > 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 3b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 > IEEE 802.1X: version=1 type=3 length=119 > ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING > PMK - hexdump(len=32): [REMOVED] > PTK - hexdump(len=64): [REMOVED] > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake > WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 > keyidx=0 encr=0) > TX EAPOL - hexdump(len=141): 00 21 e9 6e 78 d0 00 90 96 6b 0f c6 88 8e 02 03 > 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 95 a0 4e 64 c6 > 43 6c e9 8c 02 ef 75 27 f9 e5 00 1c dd 1a 00 50 f2 0 > 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 40 f2 02 > IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE > bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 > bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port > bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 > ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING > bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 > ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 21 e9 6e 08 d0 00 90 96 6b 0f c6 88 5e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 dc 19 fc 24 e2 > 56 37 16 14 5a 0b 00 25 c2 47 00 28 78 92 48 df 3b e > f 3c d7 25 82 34 d2 32 7d 1f cc 12 d1 4e c0 89 dc 29 80 88 45 95 27 13 49 b0 > da ef f9 c9 fd f0 52 a9 b5 > IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED > ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) > WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated > ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED > WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE > bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 > bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 > ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port > Could not set station 00:21:e9:6e:98:d0 flags for kernel driver (errno=22). > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=2 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 78 8e 02 03 > 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 07 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c3 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 be eb 48 36 > b5 ad 1f 17 bc 64 ca 6b c8 ca 00 28 8a 2b 24 9f ee 4 > 4 0f e7 4a ad a8 55 62 cd b9 d0 69 cc af e4 94 01 aa d8 e9 cf cc a7 ed 6e e0 > 90 b5 3c 35 1a ae 2e 32 d7 > IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 > IEEE 802.1X: version=1 type=3 length=95 > ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED > ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > Checking STA 00:1e:c2:bf:74:60 inactivity: > Station has been active > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 40 00 90 96 6b 0f c6 88 8e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 08 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 50 c3 fa 32 83 > f8 05 c4 c3 78 e5 cf 48 25 79 00 28 10 4a c3 91 12 2 > f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 97 > 54 a3 60 a9 d7 73 20 6d f1 > ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 03 > 00 87 fe 03 92 00 10 00 00 00 00 00 00 00 09 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29 b1 39 72 aa d0 > 25 02 a4 5b 01 55 a9 c6 5b cf 00 28 10 4a c3 91 12 2 > f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 57 > 54 a3 60 a9 d7 73 20 6d f1 > ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 98 8e 02 03 > 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 0a 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 79 9c 20 34 dd > 26 28 c7 c2 6f a3 1c a4 03 44 00 28 10 4a c3 91 12 2 > f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 57 > 54 a3 60 a9 d7 73 20 6d f1 > ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING > ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake > WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 > keyidx=1 encr=1) > Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] > TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 03 > 00 87 fe 03 02 00 20 00 00 00 00 00 00 00 0b 1c c4 > 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd > 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 91 86 ea b0 4b 7f > c5 2b 2c 9c b2 94 67 d4 e6 14 00 28 10 4a c3 91 12 2 > f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec 57 > 54 a3 60 a8 d7 73 20 6d f1 > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state KEYERROR > The sta didn't complete the group key handshake. I don't see a timeout msg so not sure exactly why. > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > 00:1e:c2:bf:74:60 reason 2 > bsd_sta_deauth: addr=00:1e:c2:bf:74:60 reason_code=2 > hostapd dropped the station. > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECTED > WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE > bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 > bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 > ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port > Could not set station 00:1e:c2:bf:74:60 flags for kernel driver (errno=22). > ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: deauthenticated due to local deauth > request > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 > ath0: WPA rekeying GTK > WPA: group state machine entering state SETKEYS (VLAN-ID 0) > GMK - hexdump(len=32): [REMOVED] > GTK - hexdump(len=32): [REMOVED] > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 > ioctl[SIOCS80211]: No such file or directory > ioctl[SIOCS80211]: No such file or directory > ioctl[SIOCS80211]: Invalid argument > ioctl[SIOCS80211]: No such file or directory > ioctl[SIOCS80211]: No such file or directory > ioctl[SIOCS80211]: Invalid argument > ioctl[SIOCS80211]: No such file or directory > ioctl[SIOCS80211]: Invalid argument > hostapd was notified by net80211 the station went away so it tried to purge any keys but state was already gone. This is normal and the msgs can be ignored. > Signal 2 received - terminating > You hit ^C and stopped hostapd. > Flushing old station entries > bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 > Deauthenticate all stations > bsd_set_privacy: enabled=0 > bsd_set_ieee8021x: enabled=0 > bsd_set_iface_flags: dev_up=0 > _______________________________________________ > There is nothing unusual in the log. Your problems are likely lower; e.g. loss of communication between the ap and sta. Sam From toasty at dragondata.com Fri Sep 26 17:58:22 2008 From: toasty at dragondata.com (Kevin Day) Date: Fri Sep 26 17:58:54 2008 Subject: sfbufs on amd64? Message-ID: <81F28D26-4E90-4C6F-94DB-FB834F3B78F9@dragondata.com> When using sendfile() on an amd64 box, are sfbufs still used/needed? The reason I ask: # netstat -m 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 1334122 requests for I/O initiated by sendfile kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 Does sendfile work differently on amd64 so that sfbufs aren't needed, or is this a statistics issue? This is in 7.0-RELEASE, btw. -- Kevin From delphij at delphij.net Fri Sep 26 18:10:07 2008 From: delphij at delphij.net (Xin LI) Date: Fri Sep 26 18:10:13 2008 Subject: sfbufs on amd64? In-Reply-To: <81F28D26-4E90-4C6F-94DB-FB834F3B78F9@dragondata.com> References: <81F28D26-4E90-4C6F-94DB-FB834F3B78F9@dragondata.com> Message-ID: <48DD2572.4000001@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Day wrote: > > When using sendfile() on an amd64 box, are sfbufs still used/needed? The > reason I ask: > > # netstat -m > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 1334122 requests for I/O initiated by sendfile > > kern.ipc.nsfbufsused: 0 > kern.ipc.nsfbufspeak: 0 > kern.ipc.nsfbufs: 0 > > > Does sendfile work differently on amd64 so that sfbufs aren't needed, or > is this a statistics issue? > > This is in 7.0-RELEASE, btw. - From FreeBSD 7.0-RELEASE, the system gets the ability to make use of amd64-specific technique that eliminates the need of allocating sfbufs and avoids the copying. That's say, sendfile would work without needing to separately allocating sfbufs and this would be much faster than the old approach. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjdJXIACgkQi+vbBBjt66AatQCdG2KI6HcG+S5k2n56ZwevjbM1 kY0AoKF0fGHZmOrWuwQvsS1mU8/QTzyS =7oMA -----END PGP SIGNATURE----- From waynehendricks at gmail.com Fri Sep 26 19:45:39 2008 From: waynehendricks at gmail.com (Wayne Hendricks) Date: Fri Sep 26 19:45:47 2008 Subject: Hostapd network issue In-Reply-To: <48DD1FF6.6010608@freebsd.org> References: <3b965dec0809252258t15722eecn29494431bced3061@mail.gmail.com> <48DD1FF6.6010608@freebsd.org> Message-ID: <3b965dec0809261245s332043ecm8c2abd42c76995ef@mail.gmail.com> Well, the ap and sta are right next to each other. The sta is a MacBook Pro. After a few minutes, hostapd freezes and the sta will not reconnect at all. Odd. I think i may switch cards and see if it helps. On Fri, Sep 26, 2008 at 12:46 PM, Sam Leffler wrote: > Wayne Hendricks wrote: > >> I have been trying to make hostapd work with wifi card in my gateway box. >> WPA stays working for only a short time before hostapd locks up and needs >> to >> be restarted. I believe the hosapd config is fine, shows no errors. >> Running 7.0-RELEASE-p4 amd64 with mini-pci Atheros 5212 chipset. I have >> included the hostapd debug output below. What is this ioctl[SIOCS80211] >> weirdness? >> >> Configuration file: /etc/hostapd.conf >> ctrl_interface_group=0 (from group name 'wheel') >> bsd_set_iface_flags: dev_up=0 >> BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) >> ath0: IEEE 802.11 Fetching hardware channel/rate support not supported. >> Flushing old station entries >> bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 >> Deauthenticate all stations >> bsd_set_privacy: enabled=0 >> Mode: IEEE 802.11g Channel: 11 Frequency: 0 MHz >> bsd_del_key: addr=00:00:00:00:00:00 key_idx=0 >> bsd_del_key: addr=00:00:00:00:00:00 key_idx=1 >> bsd_del_key: addr=00:00:00:00:00:00 key_idx=2 >> bsd_del_key: addr=00:00:00:00:00:00 key_idx=3 >> bsd_get_ssid: ssid="bsdap" >> Using interface ath0 with hwaddr 00:90:96:6b:0f:c6 and ssid 'bsdap' >> SSID - hexdump_ascii(len=9): >> 52 4e 73 65 63 75 72 65 47 bsdap >> PSK (ASCII passphrase) - hexdump_ascii(len=12): >> 65 74 68 65 72 61 70 65 31 31 31 36 mypassphrase >> PSK (from passphrase) - hexdump(len=32): 17 ae 54 6a a7 c4 fc ce e2 d4 2e >> 07 >> 0d 08 09 56 41 d3 a4 6a d2 18 26 d1 36 22 56 fe a0 >> af 26 43 >> bsd_set_ieee8021x: enabled=1 >> bsd_configure_wpa: group key cipher=TKIP (1) >> bsd_configure_wpa: pairwise key ciphers=0xa >> bsd_configure_wpa: key management algorithms=0x2 >> bsd_configure_wpa: rsn capabilities=0x0 >> bsd_configure_wpa: enable WPA= 0x1 >> bsd_set_iface_flags: dev_up=1 >> WPA: group state machine entering state GTK_INIT (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >> bsd_set_privacy: enabled=1 >> ath0: Setup of interface done. >> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: associated >> New STA >> ath0: STA 00:1e:c2:bf:74:60 WPA: event 1 notification >> bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 >> ath0: STA 00:1e:c2:bf:74:60 WPA: start authentication >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE >> bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 >> bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 >> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION2 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITPSK >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKSTART >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/4 msg of 4-Way Handshake >> WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 >> keyidx=0 >> encr=0) >> TX EAPOL - hexdump(len=113): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 >> 03 >> 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 9f 2b fa 4e 6e 00 d2 a0 fd >> 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 >> IEEE 802.1X: 123 bytes from 00:1e:c2:bf:74:60 >> IEEE 802.1X: version=1 type=3 length=119 >> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/4 Pairwise) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING >> PMK - hexdump(len=32): [REMOVED] >> PTK - hexdump(len=64): [REMOVED] >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING2 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 3/4 msg of 4-Way Handshake >> WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 >> keyidx=0 encr=0) >> TX EAPOL - hexdump(len=141): 00 1e c2 bf 74 60 00 00 96 6b 0f c6 88 8e 02 >> 03 >> 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cf 86 6a 87 74 >> 59 >> 72 dc 2f 01 f9 8b b4 20 51 1f 00 1c dd 1a 00 50 f2 0 >> 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 >> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (4/4 Pairwise) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITDONE >> bsd_set_key: alg=CCMP addr=00:1e:c2:bf:74:60 key_idx=0 >> bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=1 >> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: authorizing port >> bsd_sta_clear_stats: addr=00:1e:c2:bf:74:60 >> ath0: STA 00:1e:c2:bf:74:60 WPA: pairwise key handshake completed (WPA) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 d8 ba b9 34 >> 15 >> fd ae 04 7c 59 05 d4 08 70 4c 00 28 36 25 48 ae 3c 8 >> d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 >> fc >> 57 fd 57 c1 90 be a2 50 a4 >> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 46 6b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 3a d0 8a fd >> 74 >> 2d 9a cf ba eb 75 56 26 71 63 00 28 36 25 48 ae 3c 8 >> d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 >> fc >> 37 fd 57 c1 00 be a2 50 a4 >> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated >> New STA >> ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake >> WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 >> keyidx=0 >> encr=0) >> TX EAPOL - hexdump(len=113): 00 21 e9 6e 68 d0 00 90 96 6b 0f c6 58 8e 02 >> 03 >> 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 >> IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 >> IEEE 802.1X: version=1 type=3 length=119 >> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING >> PMK - hexdump(len=32): [REMOVED] >> PTK - hexdump(len=64): [REMOVED] >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake >> WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 >> keyidx=0 encr=0) >> TX EAPOL - hexdump(len=141): 00 21 e9 6e 98 d0 00 90 96 6b 0f c5 88 8e 02 >> 03 >> 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 55 c7 5a e3 >> 2d >> 7a 54 f2 6d f0 7b 9f cc ca b3 00 1c dd 1a 00 50 f2 0 >> 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 >> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE >> bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 >> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port >> bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 >> ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 68 8e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb 76 69 1b 31 >> 76 >> d5 81 87 d1 fb f5 ac 85 f1 d7 00 28 f6 9f 0d ca 6e 4 >> b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 8e 6b 1c 10 >> cd >> af a5 66 58 5f d2 fb 3d 48 >> ath0: STA 00:21:e9:6e:98:d0 WPA: EAPOL-Key timeout >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 88 8e 02 >> 03 >> 00 47 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ec 85 4f 9e d0 >> f7 >> 89 9c a5 aa da f7 94 32 96 1b 00 28 f6 9f 0d ca 6e 4 >> b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 3e 6b 1c 10 >> cd >> af a5 96 58 5f d2 fb 3d 48 >> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED >> ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated >> ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >> Could not set station 00:21:e9:6e:98:d0 flags for kernel driver >> (errno=22). >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=2 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 05 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 21 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c0 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 4a 9b 73 a4 >> 2a >> 85 58 43 ea 4b 26 39 52 da 0b 00 28 97 d8 b5 38 1a 9 >> 9 dc 43 65 b5 bd ac 8c 7e 35 2c 12 7c 55 d4 79 0a 54 68 4c 5c 59 36 5b f6 >> 69 >> 31 ad 4a 90 ff 81 be c6 4f >> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 76 6b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 06 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 16 82 a2 >> 6d >> 95 4d 6b 3c ce 5b 05 47 76 55 00 28 7a a2 9a 85 ef a >> f a9 be 86 56 94 45 a3 ab b8 a5 b3 d5 44 3b a4 d3 9f 7b 3d ea 97 e6 c3 ed >> 9e >> 42 da 4b 91 2d fd 7f 1e 8d >> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated >> New STA >> ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake >> WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 >> keyidx=0 >> encr=0) >> TX EAPOL - hexdump(len=113): 00 21 e9 6e 98 d0 00 30 96 6b 0f c6 88 8e 02 >> 03 >> 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 3b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 >> IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 >> IEEE 802.1X: version=1 type=3 length=119 >> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING >> PMK - hexdump(len=32): [REMOVED] >> PTK - hexdump(len=64): [REMOVED] >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake >> WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 >> keyidx=0 encr=0) >> TX EAPOL - hexdump(len=141): 00 21 e9 6e 78 d0 00 90 96 6b 0f c6 88 8e 02 >> 03 >> 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 95 a0 4e 64 >> c6 >> 43 6c e9 8c 02 ef 75 27 f9 e5 00 1c dd 1a 00 50 f2 0 >> 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 40 f2 02 >> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE >> bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 >> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port >> bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 >> ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 21 e9 6e 08 d0 00 90 96 6b 0f c6 88 5e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 dc 19 fc 24 >> e2 >> 56 37 16 14 5a 0b 00 25 c2 47 00 28 78 92 48 df 3b e >> f 3c d7 25 82 34 d2 32 7d 1f cc 12 d1 4e c0 89 dc 29 80 88 45 95 27 13 49 >> b0 >> da ef f9 c9 fd f0 52 a9 b5 >> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED >> ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) >> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated >> ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED >> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >> Could not set station 00:21:e9:6e:98:d0 flags for kernel driver >> (errno=22). >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=2 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 78 8e 02 >> 03 >> 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 07 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c3 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 be eb 48 >> 36 >> b5 ad 1f 17 bc 64 ca 6b c8 ca 00 28 8a 2b 24 9f ee 4 >> 4 0f e7 4a ad a8 55 62 cd b9 d0 69 cc af e4 94 01 aa d8 e9 cf cc a7 ed 6e >> e0 >> 90 b5 3c 35 1a ae 2e 32 d7 >> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >> IEEE 802.1X: version=1 type=3 length=95 >> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> Checking STA 00:1e:c2:bf:74:60 inactivity: >> Station has been active >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 40 00 90 96 6b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 08 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 50 c3 fa 32 >> 83 >> f8 05 c4 c3 78 e5 cf 48 25 79 00 28 10 4a c3 91 12 2 >> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >> 97 >> 54 a3 60 a9 d7 73 20 6d f1 >> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 92 00 10 00 00 00 00 00 00 00 09 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29 b1 39 72 aa >> d0 >> 25 02 a4 5b 01 55 a9 c6 5b cf 00 28 10 4a c3 91 12 2 >> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >> 57 >> 54 a3 60 a9 d7 73 20 6d f1 >> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 98 8e 02 >> 03 >> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 0a 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 79 9c 20 34 >> dd >> 26 28 c7 c2 6f a3 1c a4 03 44 00 28 10 4a c3 91 12 2 >> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >> 57 >> 54 a3 60 a9 d7 73 20 6d f1 >> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >> keyidx=1 encr=1) >> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 >> 03 >> 00 87 fe 03 02 00 20 00 00 00 00 00 00 00 0b 1c c4 >> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 fd >> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 91 86 ea b0 4b >> 7f >> c5 2b 2c 9c b2 94 67 d4 e6 14 00 28 10 4a c3 91 12 2 >> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >> 57 >> 54 a3 60 a8 d7 73 20 6d f1 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state KEYERROR >> >> > > The sta didn't complete the group key handshake. I don't see a timeout msg > so not sure exactly why. > > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECT >> hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA >> 00:1e:c2:bf:74:60 reason 2 >> bsd_sta_deauth: addr=00:1e:c2:bf:74:60 reason_code=2 >> >> > > hostapd dropped the station. > > > WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECTED >> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE >> bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 >> bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 >> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port >> Could not set station 00:1e:c2:bf:74:60 flags for kernel driver >> (errno=22). >> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: deauthenticated due to local >> deauth >> request >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >> ath0: WPA rekeying GTK >> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >> GMK - hexdump(len=32): [REMOVED] >> GTK - hexdump(len=32): [REMOVED] >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >> ioctl[SIOCS80211]: No such file or directory >> ioctl[SIOCS80211]: No such file or directory >> ioctl[SIOCS80211]: Invalid argument >> ioctl[SIOCS80211]: No such file or directory >> ioctl[SIOCS80211]: No such file or directory >> ioctl[SIOCS80211]: Invalid argument >> ioctl[SIOCS80211]: No such file or directory >> ioctl[SIOCS80211]: Invalid argument >> >> > > hostapd was notified by net80211 the station went away so it tried to purge > any keys but state was already gone. This is normal and the msgs can be > ignored. > > Signal 2 received - terminating >> >> > > You hit ^C and stopped hostapd. > > Flushing old station entries >> bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 >> Deauthenticate all stations >> bsd_set_privacy: enabled=0 >> bsd_set_ieee8021x: enabled=0 >> bsd_set_iface_flags: dev_up=0 >> _______________________________________________ >> >> > There is nothing unusual in the log. Your problems are likely lower; e.g. > loss of communication between the ap and sta. > > Sam > > From waynehendricks at gmail.com Fri Sep 26 22:01:25 2008 From: waynehendricks at gmail.com (Wayne Hendricks) Date: Fri Sep 26 22:01:34 2008 Subject: Hostapd network issue In-Reply-To: <3b965dec0809261245s332043ecm8c2abd42c76995ef@mail.gmail.com> References: <3b965dec0809252258t15722eecn29494431bced3061@mail.gmail.com> <48DD1FF6.6010608@freebsd.org> <3b965dec0809261245s332043ecm8c2abd42c76995ef@mail.gmail.com> Message-ID: <3b965dec0809261501g1ef8eb7fh713d12bfc03e3f94@mail.gmail.com> Well, I haven't had a chance to switch cards, but on an interesting side note, none of my other wireless clients will connect after hostapd freezes. =W= On Fri, Sep 26, 2008 at 2:45 PM, Wayne Hendricks wrote: > Well, the ap and sta are right next to each other. The sta is a MacBook > Pro. After a few minutes, hostapd freezes and the sta will not reconnect at > all. Odd. I think i may switch cards and see if it helps. > > On Fri, Sep 26, 2008 at 12:46 PM, Sam Leffler wrote: > >> Wayne Hendricks wrote: >> >>> I have been trying to make hostapd work with wifi card in my gateway box. >>> WPA stays working for only a short time before hostapd locks up and needs >>> to >>> be restarted. I believe the hosapd config is fine, shows no errors. >>> Running 7.0-RELEASE-p4 amd64 with mini-pci Atheros 5212 chipset. I have >>> included the hostapd debug output below. What is this ioctl[SIOCS80211] >>> weirdness? >>> >>> Configuration file: /etc/hostapd.conf >>> ctrl_interface_group=0 (from group name 'wheel') >>> bsd_set_iface_flags: dev_up=0 >>> BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) >>> ath0: IEEE 802.11 Fetching hardware channel/rate support not supported. >>> Flushing old station entries >>> bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 >>> Deauthenticate all stations >>> bsd_set_privacy: enabled=0 >>> Mode: IEEE 802.11g Channel: 11 Frequency: 0 MHz >>> bsd_del_key: addr=00:00:00:00:00:00 key_idx=0 >>> bsd_del_key: addr=00:00:00:00:00:00 key_idx=1 >>> bsd_del_key: addr=00:00:00:00:00:00 key_idx=2 >>> bsd_del_key: addr=00:00:00:00:00:00 key_idx=3 >>> bsd_get_ssid: ssid="bsdap" >>> Using interface ath0 with hwaddr 00:90:96:6b:0f:c6 and ssid 'bsdap' >>> SSID - hexdump_ascii(len=9): >>> 52 4e 73 65 63 75 72 65 47 bsdap >>> PSK (ASCII passphrase) - hexdump_ascii(len=12): >>> 65 74 68 65 72 61 70 65 31 31 31 36 mypassphrase >>> PSK (from passphrase) - hexdump(len=32): 17 ae 54 6a a7 c4 fc ce e2 d4 2e >>> 07 >>> 0d 08 09 56 41 d3 a4 6a d2 18 26 d1 36 22 56 fe a0 >>> af 26 43 >>> bsd_set_ieee8021x: enabled=1 >>> bsd_configure_wpa: group key cipher=TKIP (1) >>> bsd_configure_wpa: pairwise key ciphers=0xa >>> bsd_configure_wpa: key management algorithms=0x2 >>> bsd_configure_wpa: rsn capabilities=0x0 >>> bsd_configure_wpa: enable WPA= 0x1 >>> bsd_set_iface_flags: dev_up=1 >>> WPA: group state machine entering state GTK_INIT (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >>> bsd_set_privacy: enabled=1 >>> ath0: Setup of interface done. >>> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: associated >>> New STA >>> ath0: STA 00:1e:c2:bf:74:60 WPA: event 1 notification >>> bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: start authentication >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE >>> bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 >>> bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 >>> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state AUTHENTICATION2 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITPSK >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKSTART >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/4 msg of 4-Way Handshake >>> WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 >>> keyidx=0 >>> encr=0) >>> TX EAPOL - hexdump(len=113): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 9f 2b fa 4e 6e 00 d2 a0 >>> fd >>> 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 >>> IEEE 802.1X: 123 bytes from 00:1e:c2:bf:74:60 >>> IEEE 802.1X: version=1 type=3 length=119 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/4 Pairwise) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING >>> PMK - hexdump(len=32): [REMOVED] >>> PTK - hexdump(len=64): [REMOVED] >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKCALCNEGOTIATING2 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 3/4 msg of 4-Way Handshake >>> WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 >>> keyidx=0 encr=0) >>> TX EAPOL - hexdump(len=141): 00 1e c2 bf 74 60 00 00 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd be 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cf 86 6a 87 74 >>> 59 >>> 72 dc 2f 01 f9 8b b4 20 51 1f 00 1c dd 1a 00 50 f2 0 >>> 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 >>> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (4/4 Pairwise) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state PTKINITDONE >>> bsd_set_key: alg=CCMP addr=00:1e:c2:bf:74:60 key_idx=0 >>> bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=1 >>> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: authorizing port >>> bsd_sta_clear_stats: addr=00:1e:c2:bf:74:60 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: pairwise key handshake completed (WPA) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 d8 ba b9 34 >>> 15 >>> fd ae 04 7c 59 05 d4 08 70 4c 00 28 36 25 48 ae 3c 8 >>> d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 >>> fc >>> 57 fd 57 c1 90 be a2 50 a4 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 46 6b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 3a d0 8a fd >>> 74 >>> 2d 9a cf ba eb 75 56 26 71 63 00 28 36 25 48 ae 3c 8 >>> d ad 9b 27 20 45 68 36 d7 57 ba 57 49 0f 7d e9 2b 1d 6b b5 21 c1 a4 e5 77 >>> fc >>> 37 fd 57 c1 00 be a2 50 a4 >>> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >>> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated >>> New STA >>> ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake >>> WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 >>> keyidx=0 >>> encr=0) >>> TX EAPOL - hexdump(len=113): 00 21 e9 6e 68 d0 00 90 96 6b 0f c6 58 8e 02 >>> 03 >>> 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 >>> IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 >>> IEEE 802.1X: version=1 type=3 length=119 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING >>> PMK - hexdump(len=32): [REMOVED] >>> PTK - hexdump(len=64): [REMOVED] >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake >>> WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 >>> keyidx=0 encr=0) >>> TX EAPOL - hexdump(len=141): 00 21 e9 6e 98 d0 00 90 96 6b 0f c5 88 8e 02 >>> 03 >>> 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd bf 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 55 c7 5a e3 >>> 2d >>> 7a 54 f2 6d f0 7b 9f cc ca b3 00 1c dd 1a 00 50 f2 0 >>> 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02 >>> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE >>> bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 >>> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port >>> bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 68 8e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb 76 69 1b 31 >>> 76 >>> d5 81 87 d1 fb f5 ac 85 f1 d7 00 28 f6 9f 0d ca 6e 4 >>> b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 8e 6b 1c 10 >>> cd >>> af a5 66 58 5f d2 fb 3d 48 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: EAPOL-Key timeout >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 21 e9 6e 98 d0 00 90 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 47 fe 03 92 00 20 00 00 00 00 00 00 00 04 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd bd 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 4c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ec 85 4f 9e d0 >>> f7 >>> 89 9c a5 aa da f7 94 32 96 1b 00 28 f6 9f 0d ca 6e 4 >>> b 9c 54 56 98 09 75 79 a1 35 b0 90 a2 77 33 48 3e 5c 5d 03 cc 3e 6b 1c 10 >>> cd >>> af a5 96 58 5f d2 fb 3d 48 >>> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED >>> ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated >>> ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >>> Could not set station 00:21:e9:6e:98:d0 flags for kernel driver >>> (errno=22). >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=2 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 3b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 05 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 21 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c0 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 4a 9b 73 a4 >>> 2a >>> 85 58 43 ea 4b 26 39 52 da 0b 00 28 97 d8 b5 38 1a 9 >>> 9 dc 43 65 b5 bd ac 8c 7e 35 2c 12 7c 55 d4 79 0a 54 68 4c 5c 59 36 5b f6 >>> 69 >>> 31 ad 4a 90 ff 81 be c6 4f >>> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >>> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 76 6b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 06 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 16 82 a2 >>> 6d >>> 95 4d 6b 3c ce 5b 05 47 76 55 00 28 7a a2 9a 85 ef a >>> f a9 be 86 56 94 45 a3 ab b8 a5 b3 d5 44 3b a4 d3 9f 7b 3d ea 97 e6 c3 ed >>> 9e >>> 42 da 4b 91 2d fd 7f 1e 8d >>> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >>> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: associated >>> New STA >>> ath0: STA 00:21:e9:6e:98:d0 WPA: event 1 notification >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: start authentication >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state AUTHENTICATION2 >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITPSK >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKSTART >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/4 msg of 4-Way Handshake >>> WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 >>> keyidx=0 >>> encr=0) >>> TX EAPOL - hexdump(len=113): 00 21 e9 6e 98 d0 00 30 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 5f fe 00 8a 00 10 00 00 00 00 00 00 00 01 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 3b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 >>> IEEE 802.1X: 123 bytes from 00:21:e9:6e:98:d0 >>> IEEE 802.1X: version=1 type=3 length=119 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/4 Pairwise) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING >>> PMK - hexdump(len=32): [REMOVED] >>> PTK - hexdump(len=64): [REMOVED] >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKCALCNEGOTIATING2 >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 3/4 msg of 4-Way Handshake >>> WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=28 >>> keyidx=0 encr=0) >>> TX EAPOL - hexdump(len=141): 00 21 e9 6e 78 d0 00 90 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 7b fe 01 ca 00 10 00 00 00 00 00 00 00 02 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c2 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 95 a0 4e 64 >>> c6 >>> 43 6c e9 8c 02 ef 75 27 f9 e5 00 1c dd 1a 00 50 f2 0 >>> 1 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 40 f2 02 >>> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (4/4 Pairwise) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state PTKINITDONE >>> bsd_set_key: alg=CCMP addr=00:21:e9:6e:98:d0 key_idx=0 >>> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=1 >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: authorizing port >>> bsd_sta_clear_stats: addr=00:21:e9:6e:98:d0 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: pairwise key handshake completed (WPA) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> bsd_get_seqnum: addr=00:00:00:00:00:00 idx=1 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 21 e9 6e 08 d0 00 90 96 6b 0f c6 88 5e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 03 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c1 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 dc 19 fc 24 >>> e2 >>> 56 37 16 14 5a 0b 00 25 c2 47 00 28 78 92 48 df 3b e >>> f 3c d7 25 82 34 d2 32 7d 1f cc 12 d1 4e c0 89 dc 29 80 88 45 95 27 13 49 >>> b0 >>> da ef f9 c9 fd f0 52 a9 b5 >>> IEEE 802.1X: 99 bytes from 00:21:e9:6e:98:d0 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:21:e9:6e:98:d0 WPA: received EAPOL-Key frame (2/2 Group) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state REKEYESTABLISHED >>> ath0: STA 00:21:e9:6e:98:d0 WPA: group key handshake completed (WPA) >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK_GROUP entering state IDLE >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.11: deassociated >>> ath0: STA 00:21:e9:6e:98:d0 WPA: event 2 notification >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state DISCONNECTED >>> WPA: 00:21:e9:6e:98:d0 WPA_PTK entering state INITIALIZE >>> bsd_del_key: addr=00:21:e9:6e:98:d0 key_idx=0 >>> bsd_set_sta_authorized: addr=00:21:e9:6e:98:d0 authorized=0 >>> ath0: STA 00:21:e9:6e:98:d0 IEEE 802.1X: unauthorizing port >>> Could not set station 00:21:e9:6e:98:d0 flags for kernel driver >>> (errno=22). >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=2 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 78 8e 02 >>> 03 >>> 00 87 fe 03 a2 00 20 00 00 00 00 00 00 00 07 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c3 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 be eb 48 >>> 36 >>> b5 ad 1f 17 bc 64 ca 6b c8 ca 00 28 8a 2b 24 9f ee 4 >>> 4 0f e7 4a ad a8 55 62 cd b9 d0 69 cc af e4 94 01 aa d8 e9 cf cc a7 ed 6e >>> e0 >>> 90 b5 3c 35 1a ae 2e 32 d7 >>> IEEE 802.1X: 99 bytes from 00:1e:c2:bf:74:60 >>> IEEE 802.1X: version=1 type=3 length=95 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: received EAPOL-Key frame (2/2 Group) >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYESTABLISHED >>> ath0: STA 00:1e:c2:bf:74:60 WPA: group key handshake completed (WPA) >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> Checking STA 00:1e:c2:bf:74:60 inactivity: >>> Station has been active >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 40 00 90 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 08 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 50 c3 fa 32 >>> 83 >>> f8 05 c4 c3 78 e5 cf 48 25 79 00 28 10 4a c3 91 12 2 >>> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >>> 97 >>> 54 a3 60 a9 d7 73 20 6d f1 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 92 00 10 00 00 00 00 00 00 00 09 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29 b1 39 72 aa >>> d0 >>> 25 02 a4 5b 01 55 a9 c6 5b cf 00 28 10 4a c3 91 12 2 >>> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >>> 57 >>> 54 a3 60 a9 d7 73 20 6d f1 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 98 8e 02 >>> 03 >>> 00 87 fe 03 92 00 20 00 00 00 00 00 00 00 0a 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 79 9c 20 34 >>> dd >>> 26 28 c7 c2 6f a3 1c a4 03 44 00 28 10 4a c3 91 12 2 >>> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >>> 57 >>> 54 a3 60 a9 d7 73 20 6d f1 >>> ath0: STA 00:1e:c2:bf:74:60 WPA: EAPOL-Key timeout >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state REKEYNEGOTIATING >>> ath0: STA 00:1e:c2:bf:74:60 WPA: sending 1/2 msg of Group Key Handshake >>> WPA: Send EAPOL(secure=1 mic=1 ack=1 install=0 pairwise=0 kde_len=32 >>> keyidx=1 encr=1) >>> Plaintext EAPOL-Key Key Data - hexdump(len=40): [REMOVED] >>> TX EAPOL - hexdump(len=153): 00 1e c2 bf 74 60 00 90 96 6b 0f c6 88 8e 02 >>> 03 >>> 00 87 fe 03 02 00 20 00 00 00 00 00 00 00 0b 1c c4 >>> 37 85 45 86 e9 2a 99 5c 65 8c 8b d0 b8 63 31 04 1f 2b fa 4e 8e 00 d2 a0 >>> fd >>> 9e f0 c1 fd c4 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 91 86 ea b0 4b >>> 7f >>> c5 2b 2c 9c b2 94 67 d4 e6 14 00 28 10 4a c3 91 12 2 >>> f 91 69 e3 84 e2 61 25 ce e9 b8 38 53 7f 8d f8 53 ec ac 90 43 41 5c b9 ec >>> 57 >>> 54 a3 60 a8 d7 73 20 6d f1 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state KEYERROR >>> >>> >> >> The sta didn't complete the group key handshake. I don't see a timeout >> msg so not sure exactly why. >> >> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECT >>> hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA >>> 00:1e:c2:bf:74:60 reason 2 >>> bsd_sta_deauth: addr=00:1e:c2:bf:74:60 reason_code=2 >>> >>> >> >> hostapd dropped the station. >> >> >> WPA: 00:1e:c2:bf:74:60 WPA_PTK_GROUP entering state IDLE >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state DISCONNECTED >>> WPA: 00:1e:c2:bf:74:60 WPA_PTK entering state INITIALIZE >>> bsd_del_key: addr=00:1e:c2:bf:74:60 key_idx=0 >>> bsd_set_sta_authorized: addr=00:1e:c2:bf:74:60 authorized=0 >>> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.1X: unauthorizing port >>> Could not set station 00:1e:c2:bf:74:60 flags for kernel driver >>> (errno=22). >>> ath0: STA 00:1e:c2:bf:74:60 IEEE 802.11: deauthenticated due to local >>> deauth >>> request >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=2 >>> ath0: WPA rekeying GTK >>> WPA: group state machine entering state SETKEYS (VLAN-ID 0) >>> GMK - hexdump(len=32): [REMOVED] >>> GTK - hexdump(len=32): [REMOVED] >>> WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) >>> bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 >>> ioctl[SIOCS80211]: No such file or directory >>> ioctl[SIOCS80211]: No such file or directory >>> ioctl[SIOCS80211]: Invalid argument >>> ioctl[SIOCS80211]: No such file or directory >>> ioctl[SIOCS80211]: No such file or directory >>> ioctl[SIOCS80211]: Invalid argument >>> ioctl[SIOCS80211]: No such file or directory >>> ioctl[SIOCS80211]: Invalid argument >>> >>> >> >> hostapd was notified by net80211 the station went away so it tried to >> purge any keys but state was already gone. This is normal and the msgs can >> be ignored. >> >> Signal 2 received - terminating >>> >>> >> >> You hit ^C and stopped hostapd. >> >> Flushing old station entries >>> bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 >>> Deauthenticate all stations >>> bsd_set_privacy: enabled=0 >>> bsd_set_ieee8021x: enabled=0 >>> bsd_set_iface_flags: dev_up=0 >>> _______________________________________________ >>> >>> >> There is nothing unusual in the log. Your problems are likely lower; e.g. >> loss of communication between the ap and sta. >> >> Sam >> >> > From ivoras at freebsd.org Sat Sep 27 01:00:41 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Sep 27 01:00:48 2008 Subject: Optimizing for high PPS, Intel NICs Message-ID: I have an application that consists of a server and clients which communicate via TCP. The communication consists of exchanging many small packets - around 96 bytes of payload (non-uniform). I'm testing it in 8-CURRENT with two machines connected directly via a patch cable. The server is a 8-core Xeon system with 5000X chipset and embedded Intel PRO/1000 EB NIC (card=0x109615d9 chip=0x10968086) and the client is a 4-core desktop Core2 also with Intel's embedded NIC, 82566DM-2. The client and server applications are multithreaded and verified that they scale well in environments like this. I've verified with iperf that the NICs and the cable are ok with gigabit traffic. Here's an example netstat trace from a test run on the client: input (Total) output packets errs bytes packets errs bytes colls 161700 0 29374199 161768 0 16290562 0 158320 0 28741763 158405 0 15962986 0 157617 0 28614088 157696 0 15889426 0 157569 0 28618951 157674 0 15884576 0 (i.e. the client receives about 2x the data it sends) I've noticed something strange: the server is bottlenecked with "em1 taskq" kernel thread taking 100% of a CPU core, while the global CPU utilization is around 50%, but the client's em0 taskq thread for this same load is ~~ 10% (with > 30% idle). The client CPU is a bit faster then the server (2.4 GHz vs 2.0 GHz) but I don't think this can account for such a big difference. Toggling TSO on the server doesn't help. This difference in taskq CPU load between the client and the server machine looks wrong to me. Also, I'd expect more PPS here. Can someone comment on this? Are there any known issues with the server NIC I have there? (Both machines run amd64 kernels, WITNESS & INVARIANTS are disabled on both machines). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080927/fc808e72/signature.pgp From arno at heho.snv.jussieu.fr Sat Sep 27 22:13:41 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sat Sep 27 22:13:48 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) Message-ID: Hello, I've serious network performance problems on a HP Turion X2 based brand new notebook; I only used a 7-1Beta CD and 7-STABLE on this thing. Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : # scp -p ports.tgz login@mv:/tmp/ ports.tgz 100% 98MB 88.7KB/s 18:49 (doing the same thing by copy from an nfs-mounted disk even takes mores than an hour ...) Doing a top(1) aside, just shows the box 100% idle : PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 4 root -8 - 0K 16K - 1 0:00 0.00% g_down 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer 3 root -8 - 0K 16K - 0 0:00 0.00% g_up 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq I tested : Update Bios ULE /4BSD PREEMPTION on/off PREEMPTION + IPI_PREEMPTION hw.nfe.msi[x]_disable=1 All don't seem to matter to the problem. I put two tcpdumps (server and client during another scp(1) ) on http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client I'm far from an expert on TCP/IP, but wireshark "expert info" shows lots of sequences like : TCP Previous segment lost TCP Duplicate ACK 1 TCP Window update TCP Duplicate ACK 2 TCP Duplicate ACK 3 TCP Duplicate ACK 4 TCP Duplicate ACK 5 TCP Fast retransmission (suspected) TCP ... TCP Out-of-Order segment TCP ... As usual, feel free to contact me for further info/tests. Thanx, Arno ##### uname -a FreeBSD mv 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 CEST 2008 root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON amd64 ##### pciconf -lcv (bits) nfe0@pci0:0:6:0: class=0x020000 card=0x30cf103c chip=0x045010de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP65 Ethernet' class = network subclass = ethernet cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ##### dmesg -a Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 CEST 2008 root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON Timecounter "i8254" frequency 1193250 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-62 (2109.70-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 3210813440 (3062 MB) avail memory = 3104542720 (2960 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (dsopcode-0671): Field [I9MN] at 544 exceeds Buffer [IORT] size 464 (bits) [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.LPC0.PMIO - AE_AML_BUFFER_LIMIT Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.3 (no driver attached) ohci0: mem 0xf2486000-0xf2486fff irq 18 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xf2488000-0xf24880ff irq 17 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered ugen0: on uhub1 nfe0: port 0x30e0-0x30e7 mem 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1e:68:5a:d2:e1 nfe0: [FILTER] pci0: at device 7.0 (no driver attached) pcib1: at device 8.0 on pci0 pci_link0: BIOS IRQ 15 for 7.5.INTA is invalid pci_link1: BIOS IRQ 10 for 7.5.INTB is invalid pci7: on pcib1 fwohci0: <1394 Open Host Controller Interface> irq 9 at device 5.0 on pci7 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:24:1b:00:a1:b7:e8:00 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:24:1b:b7:e8:00 fwe0: Ethernet address: 02:24:1b:b7:e8:00 fwip0: on firewire0 fwip0: Firewire address: 00:24:1b:00:a1:b7:e8:00 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x2550000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci7: at device 5.1 (no driver attached) pci7: at device 5.2 (no driver attached) pci7: at device 5.3 (no driver attached) pci7: at device 5.4 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30f8-0x30ff,0x30ec-0x30ef,0x30f0-0x30f7,0x30e8-0x30eb,0x30d0-0x30df mem 0xf2484000-0xf2485fff irq 23 at device 10.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib2: at device 11.0 on pci0 pci1: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 ath0: mem 0xf2000000-0xf200ffff irq 16 at device 0.0 on pci3 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 pcib4: at device 13.0 on pci0 pci5: on pcib4 vgapci0: port 0x4000-0x407f mem 0xce000000-0xceffffff,0xd0000000-0xdfffffff,0xcc000000-0xcdffffff irq 19 at device 0.0 on pci5 pcib5: at device 14.0 on pci0 pci9: on pcib5 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-72.6C) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 orm0: at iomem 0xcd800-0xcefff,0xdf000-0xdffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acpi_tz0: _CRT value is absurd, ignored (-72.6C) acd0: DVDR at ata0-master PIO4 ad4: 305245MB at ata2-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad4s2 is ntfs/HP_RECOVERY. From linimon at FreeBSD.org Sun Sep 28 02:50:35 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Sep 28 02:50:46 2008 Subject: kern/107944: [wi] [patch] Forget to unlock mutex-locks Message-ID: <200809280250.m8S2oZ1C077483@freefall.freebsd.org> Synopsis: [wi] [patch] Forget to unlock mutex-locks Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 28 02:50:27 UTC 2008 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=107944 From weongyo at FreeBSD.org Sun Sep 28 09:48:10 2008 From: weongyo at FreeBSD.org (weongyo@FreeBSD.org) Date: Sun Sep 28 09:48:17 2008 Subject: kern/127644: [ndis] [panic] NDIS panic Message-ID: <200809280948.m8S9mAxn056733@freefall.freebsd.org> Synopsis: [ndis] [panic] NDIS panic Responsible-Changed-From-To: freebsd-net->weongyo Responsible-Changed-By: weongyo Responsible-Changed-When: Sun Sep 28 09:47:01 UTC 2008 Responsible-Changed-Why: grab it. http://www.freebsd.org/cgi/query-pr.cgi?pr=127644 From Cy.Schubert at komquats.com Sun Sep 28 13:36:29 2008 From: Cy.Schubert at komquats.com (Cy Schubert) Date: Sun Sep 28 13:36:36 2008 Subject: Atheros releases ath5k HAL code Message-ID: <200809281308.m8SD8Q0f076575@cwsys.cwsent.com> I'm not sure of the veracity of this but here it is anyway. http://lwn.net/Articles/300758/ -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 From firmdog at gmail.com Sun Sep 28 18:14:46 2008 From: firmdog at gmail.com (firmdog@gmail.com) Date: Sun Sep 28 18:14:52 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: Message-ID: I have the same problem on a Dell Poweredge SC440 when I transferred over 50GB from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover cable and the link was 1000 full duplex, but could only get about 10M/s. Very odd. Did a tcpdump and saw lots of bad checksum errors. What other troubleshooting steps can we take? What could be the problem? [root@gray ~]# uname -a FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Sep 2 02:27:56 EDT 2008 andy@gray.home:/usr/obj/usr/src/sys/GENERIC i386 pciconf showing the NIC: bge0@pci0:5:0:0: class=0x020000 card=0x01df1028 chip=0x167a14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5754 Broadcom NetXtreme Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint from sysctl dev.bge.0.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0xb002 dev.bge.0.%driver: bge dev.bge.0.%location: slot=0 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x167a subvendor=0x1028 subdevice=0x01df class=0x020000 dev.bge.0.%parent: pci5 dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%parent: bge0 dev.brgphy.0.%desc: BCM5787 10/100/1000baseTX PHY On Sat, Sep 27, 2008 at 5:21 PM, Arno J. Klaassen wrote: > > > Hello, > > I've serious network performance problems on a HP Turion X2 > based brand new notebook; I only used a 7-1Beta CD and > 7-STABLE on this thing. > > Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : > > # scp -p ports.tgz login@mv:/tmp/ > ports.tgz 100% 98MB 88.7KB/s 18:49 > > (doing the same thing by copy from an nfs-mounted disk even > takes mores than an hour ...) > > > Doing a top(1) aside, just shows the box 100% idle : > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 > 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 > 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio > 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq > 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 > 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh > 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top > 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 > 4 root -8 - 0K 16K - 1 0:00 0.00% g_down > 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow > 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer > 3 root -8 - 0K 16K - 0 0:00 0.00% g_up > 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq > > > I tested : > > Update Bios > ULE /4BSD > PREEMPTION on/off > PREEMPTION + IPI_PREEMPTION > hw.nfe.msi[x]_disable=1 > > All don't seem to matter to the problem. > > I put two tcpdumps (server and client during another scp(1) ) on > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client > > I'm far from an expert on TCP/IP, but wireshark "expert info" shows > lots of sequences like : > > TCP Previous segment lost > TCP Duplicate ACK 1 > TCP Window update > TCP Duplicate ACK 2 > TCP Duplicate ACK 3 > TCP Duplicate ACK 4 > TCP Duplicate ACK 5 > TCP Fast retransmission (suspected) > TCP ... > TCP Out-of-Order segment > TCP ... > > > As usual, feel free to contact me for further info/tests. > > Thanx, Arno > > ##### uname -a > FreeBSD mv 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 > CEST 2008 root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON amd64 > > ##### pciconf -lcv (bits) > nfe0@pci0:0:6:0: class=0x020000 card=0x30cf103c chip=0x045010de > rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP65 Ethernet' > class = network > subclass = ethernet > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > > > ##### dmesg -a > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 CEST 2008 > root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON > Timecounter "i8254" frequency 1193250 Hz quality 0 > CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-62 (2109.70-MHz K8-class > CPU) > Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > usable memory = 3210813440 (3062 MB) > avail memory = 3104542720 (2960 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > ACPI Error (dsopcode-0671): Field [I9MN] at 544 exceeds Buffer [IORT] size > 464 (bits) [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT > ACPI Error (uteval-0309): Method execution failed > [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT > can't fetch resources for \\_SB_.PCI0.LPC0.PMIO - AE_AML_BUFFER_LIMIT > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 25000000 Hz quality 900 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: port 0x1d00-0x1dff at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > pci0: at device 1.3 (no driver attached) > ohci0: mem 0xf2486000-0xf2486fff irq 18 at > device 2.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 10 ports with 10 removable, self powered > ehci0: mem 0xf2488000-0xf24880ff irq 17 > at device 2.1 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb1: EHCI version 1.0 > usb1: companion controller, 10 ports each: usb0 > usb1: on ehci0 > usb1: USB revision 2.0 > uhub1: on usb1 > uhub1: 10 ports with 10 removable, self powered > ugen0: on uhub1 > nfe0: port 0x30e0-0x30e7 mem > 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 > miibus0: on nfe0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: Ethernet address: 00:1e:68:5a:d2:e1 > nfe0: [FILTER] > pci0: at device 7.0 (no driver attached) > pcib1: at device 8.0 on pci0 > pci_link0: BIOS IRQ 15 for 7.5.INTA is invalid > pci_link1: BIOS IRQ 10 for 7.5.INTB is invalid > pci7: on pcib1 > fwohci0: <1394 Open Host Controller Interface> irq 9 at device 5.0 on pci7 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:24:1b:00:a1:b7:e8:00 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:24:1b:b7:e8:00 > fwe0: Ethernet address: 02:24:1b:b7:e8:00 > fwip0: on firewire0 > fwip0: Firewire address: 00:24:1b:00:a1:b7:e8:00 @ 0xfffe00000000, S400, > maxrec 2048 > sbp0: on firewire0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x2550000 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > pci7: at device 5.1 (no driver attached) > pci7: at device 5.2 (no driver attached) > pci7: at device 5.3 (no driver attached) > pci7: at device 5.4 (no driver attached) > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf at device 9.0 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x30f8-0x30ff,0x30ec-0x30ef,0x30f0-0x30f7,0x30e8-0x30eb,0x30d0-0x30df mem > 0xf2484000-0xf2485fff irq 23 at device 10.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pcib2: at device 11.0 on pci0 > pci1: on pcib2 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > ath0: mem 0xf2000000-0xf200ffff irq 16 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: unable to attach hardware; HAL status 13 > device_attach: ath0 attach returned 6 > pcib4: at device 13.0 on pci0 > pci5: on pcib4 > vgapci0: port 0x4000-0x407f mem > 0xce000000-0xceffffff,0xd0000000-0xdfffffff,0xcc000000-0xcdffffff irq 19 at > device 0.0 on pci5 > pcib5: at device 14.0 on pci0 > pci9: on pcib5 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > acpi_tz0: _CRT value is absurd, ignored (-72.6C) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > powernow1: on cpu1 > orm0: at iomem 0xcd800-0xcefff,0xdf000-0xdffff on isa0 > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > acpi_tz0: _CRT value is absurd, ignored (-72.6C) > acd0: DVDR at ata0-master PIO4 > ad4: 305245MB at ata2-master UDMA33 > GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. > SMP: AP CPU #1 Launched! > GEOM_LABEL: Label for provider ad4s2 is ntfs/HP_RECOVERY. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From koitsu at FreeBSD.org Sun Sep 28 19:51:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 19:51:18 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: Message-ID: <20080928193511.GB87069@icarus.home.lan> On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > I have the same problem on a Dell Poweredge SC440 when I transferred over > 50GB > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover cable > and > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > Did a tcpdump and saw lots of bad checksum errors. This is probably because checksum offloading was being done on the NIC. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From gpalmer at freebsd.org Sun Sep 28 20:53:01 2008 From: gpalmer at freebsd.org (Gary Palmer) Date: Sun Sep 28 20:53:14 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: Message-ID: <20080928205300.GF60230@in-addr.com> On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > I have the same problem on a Dell Poweredge SC440 when I transferred over > 50GB > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover cable > and > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > Did a > tcpdump and saw lots of bad checksum errors. > > What other troubleshooting steps can we take? What could be the problem? Please post the first few lines of ifconfig for bge0. I'm suspecting you'll see something like em1: flags=8843 mtu 1500 options=1b (yes, I know thats an em, not bge, but I don't have any bge's around here) Note that the options line say that receive and transmit checksum offloading is enabled. This means that for packets transmitted by this system, tcpdump will show checksum errors as the kernel is not generating the checksums, the ethernet card will. Since tcpdump is seeting the packet before the ethernet card does its magic, you get the checksum errors on transmit. Received packets should be fine though. Regards, Gary From firmdog at gmail.com Sun Sep 28 22:15:45 2008 From: firmdog at gmail.com (firmdog@gmail.com) Date: Sun Sep 28 22:15:52 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: <20080928205300.GF60230@in-addr.com> References: <20080928205300.GF60230@in-addr.com> Message-ID: On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer wrote: > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > I have the same problem on a Dell Poweredge SC440 when I transferred over > > 50GB > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > cable > > and > > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > > Did a > > tcpdump and saw lots of bad checksum errors. > > > > What other troubleshooting steps can we take? What could be the problem? > > Please post the first few lines of ifconfig for bge0. I'm suspecting > you'll see something like > > em1: flags=8843 mtu 1500 > options=1b > > (yes, I know thats an em, not bge, but I don't have any bge's around > here) > > Note that the options line say that receive and transmit checksum > offloading is enabled. This means that for packets transmitted > by this system, tcpdump will show checksum errors as the kernel > is not generating the checksums, the ethernet card will. Since > tcpdump is seeting the packet before the ethernet card does its > magic, you get the checksum errors on transmit. Received packets > should be fine though. > > Regards, > > Gary > Pasted below. When I was doing the transfer, it was 1000 full duplex and was very slow. This is a web/email/database server and I don't see any performance problems yet, but I would like to know what the problem is/was. What else can I provide? bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1a:a0:23:c0:03 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active From firmdog at gmail.com Sun Sep 28 22:30:04 2008 From: firmdog at gmail.com (firmdog@gmail.com) Date: Sun Sep 28 22:30:17 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: <20080928222414.GA90269@icarus.home.lan> References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> Message-ID: On Sun, Sep 28, 2008 at 6:24 PM, Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog@gmail.com wrote: > > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer > wrote: > > > > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > > > I have the same problem on a Dell Poweredge SC440 when I transferred > over > > > > 50GB > > > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > > > cable > > > > and > > > > the link was 1000 full duplex, but could only get about 10M/s. Very > odd. > > > > Did a > > > > tcpdump and saw lots of bad checksum errors. > > > > > > > > What other troubleshooting steps can we take? What could be the > problem? > > > > > > Please post the first few lines of ifconfig for bge0. I'm suspecting > > > you'll see something like > > > > > > em1: flags=8843 mtu 1500 > > > options=1b > > > > > > (yes, I know thats an em, not bge, but I don't have any bge's around > > > here) > > > > > > Note that the options line say that receive and transmit checksum > > > offloading is enabled. This means that for packets transmitted > > > by this system, tcpdump will show checksum errors as the kernel > > > is not generating the checksums, the ethernet card will. Since > > > tcpdump is seeting the packet before the ethernet card does its > > > magic, you get the checksum errors on transmit. Received packets > > > should be fine though. > > > > > > Regards, > > > > > > Gary > > > > > > > > > Pasted below. When I was doing the transfer, it was 1000 full duplex and > > was very slow. > > This is a web/email/database server and I don't see any performance > problems > > yet, but > > I would like to know what the problem is/was. What else can I provide? > > > > bge0: flags=8843 metric 0 mtu > 1500 > > options=9b > > ether 00:1a:a0:23:c0:03 > > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > I see 100baseTX there, not 1000baseTX. This speed is being selected via > autoneg (auto speed/duplex negotiation). > > Whatever switch you're connected to is not properly negotiating the > speed. > > What brand and model of switch is this host connected to, and are you > *absolutely certain* it supports (and is configured for) gigE? No....you misunderstood. The 7.1 box was connected to a 5.4 box doing a 50GB data transfer over rsync. Both nics were 1000 full duplex with a crossover cable. The speed performance was terrible and I could only get up to 10 Mb/s and there was NO switch involved. I believe there is a problem or bug involved with the driver. Have the drivers or stack been updated in 7.1? What else can I provide? From koitsu at FreeBSD.org Sun Sep 28 22:34:17 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 22:34:38 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080928205300.GF60230@in-addr.com> Message-ID: <20080928222414.GA90269@icarus.home.lan> On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog@gmail.com wrote: > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer wrote: > > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > > I have the same problem on a Dell Poweredge SC440 when I transferred over > > > 50GB > > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > > cable > > > and > > > the link was 1000 full duplex, but could only get about 10M/s. Very odd. > > > Did a > > > tcpdump and saw lots of bad checksum errors. > > > > > > What other troubleshooting steps can we take? What could be the problem? > > > > Please post the first few lines of ifconfig for bge0. I'm suspecting > > you'll see something like > > > > em1: flags=8843 mtu 1500 > > options=1b > > > > (yes, I know thats an em, not bge, but I don't have any bge's around > > here) > > > > Note that the options line say that receive and transmit checksum > > offloading is enabled. This means that for packets transmitted > > by this system, tcpdump will show checksum errors as the kernel > > is not generating the checksums, the ethernet card will. Since > > tcpdump is seeting the packet before the ethernet card does its > > magic, you get the checksum errors on transmit. Received packets > > should be fine though. > > > > Regards, > > > > Gary > > > > > Pasted below. When I was doing the transfer, it was 1000 full duplex and > was very slow. > This is a web/email/database server and I don't see any performance problems > yet, but > I would like to know what the problem is/was. What else can I provide? > > bge0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:1a:a0:23:c0:03 > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active I see 100baseTX there, not 1000baseTX. This speed is being selected via autoneg (auto speed/duplex negotiation). Whatever switch you're connected to is not properly negotiating the speed. What brand and model of switch is this host connected to, and are you *absolutely certain* it supports (and is configured for) gigE? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Sun Sep 28 22:44:05 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 22:44:18 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> Message-ID: <20080928224403.GA90609@icarus.home.lan> On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: > On Sun, Sep 28, 2008 at 6:24 PM, Jeremy Chadwick wrote: > > > On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog@gmail.com wrote: > > > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer > > wrote: > > > > > > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog@gmail.com wrote: > > > > > I have the same problem on a Dell Poweredge SC440 when I transferred > > over > > > > > 50GB > > > > > from a FreeBSD 5.4 box to my new Dell running 7.1. Used a crossover > > > > cable > > > > > and > > > > > the link was 1000 full duplex, but could only get about 10M/s. Very > > odd. > > > > > Did a > > > > > tcpdump and saw lots of bad checksum errors. > > > > > > > > > > What other troubleshooting steps can we take? What could be the > > problem? > > > > > > > > Please post the first few lines of ifconfig for bge0. I'm suspecting > > > > you'll see something like > > > > > > > > em1: flags=8843 mtu 1500 > > > > options=1b > > > > > > > > (yes, I know thats an em, not bge, but I don't have any bge's around > > > > here) > > > > > > > > Note that the options line say that receive and transmit checksum > > > > offloading is enabled. This means that for packets transmitted > > > > by this system, tcpdump will show checksum errors as the kernel > > > > is not generating the checksums, the ethernet card will. Since > > > > tcpdump is seeting the packet before the ethernet card does its > > > > magic, you get the checksum errors on transmit. Received packets > > > > should be fine though. > > > > > > > > Regards, > > > > > > > > Gary > > > > > > > > > > > > > Pasted below. When I was doing the transfer, it was 1000 full duplex and > > > was very slow. > > > This is a web/email/database server and I don't see any performance > > problems > > > yet, but > > > I would like to know what the problem is/was. What else can I provide? > > > > > > bge0: flags=8843 metric 0 mtu > > 1500 > > > options=9b > > > ether 00:1a:a0:23:c0:03 > > > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > I see 100baseTX there, not 1000baseTX. This speed is being selected via > > autoneg (auto speed/duplex negotiation). > > > > Whatever switch you're connected to is not properly negotiating the > > speed. > > > > What brand and model of switch is this host connected to, and are you > > *absolutely certain* it supports (and is configured for) gigE? > No....you misunderstood. The 7.1 box was connected to a 5.4 box doing > a 50GB data transfer over rsync. Both nics were 1000 full duplex with > a crossover cable. The speed performance was terrible and I could > only get up to 10 Mb/s and there was NO switch involved. > > I believe there is a problem or bug involved with the driver. This is "after the fact" evidence. The problem is that there are numerous other factors here which could explain a 10MByte/sec cap, such as small TCP window sizes or limited disk bandwidth. Your systems are no longer in this configuration, is that correct? > Have the drivers or stack been updated in 7.1? What else can I > provide? you're asking me to give you a run-down of the changes in a driver across **two** major versions of FreeBSD (from 5 to 6 to 7). There have been changes not just to the driver, but everything the driver relies on. I don't think there's necessarily any hard evidence the "driver" is the problem -- it could be one of a hundred things. If you want to review the changes to the bge(4) driver, they are below. You'll want to look at all of the commit messages between May 9th 2005 and present. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From rjf12 at students.waikato.ac.nz Sun Sep 28 23:50:52 2008 From: rjf12 at students.waikato.ac.nz (Ryan French) Date: Sun Sep 28 23:50:59 2008 Subject: Initialisation of a networking protocol Message-ID: Hi everyone, I'm having a bit of trouble with my MPLS protocol code at the moment. I have the code written and compiling (mostly based on some OpenBSD code I was shown) but when an MPLS packet is received it doesnt appear as thou my mpls_input routine is being called. I believe this is because I have not initialised the protocol properly. I have created protosw structure for MPLS as well as created an mpls_init(void) function which registers the protocol with netisr via netisr_register. Other than that I am not really sure where I tell the kernel to call the mpls_init function so that the protocol is initialised, and a couple of hours of googling/looking through ip6 code hasnt really helped at all. If anyone can help and needs to see the code it can be viewed on Perforce at http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/rfrench_mpls&HIDEDEL=NO Thanks for any help. - Ryan French From pyunyh at gmail.com Mon Sep 29 05:01:53 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Sep 29 05:02:00 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: Message-ID: <20080929043134.GD54819@cdnetworks.co.kr> On Sat, Sep 27, 2008 at 11:21:00PM +0200, Arno J. Klaassen wrote: > > > Hello, > > I've serious network performance problems on a HP Turion X2 > based brand new notebook; I only used a 7-1Beta CD and > 7-STABLE on this thing. > > Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : > > # scp -p ports.tgz login@mv:/tmp/ > ports.tgz 100% 98MB 88.7KB/s 18:49 > > (doing the same thing by copy from an nfs-mounted disk even > takes mores than an hour ...) > > > Doing a top(1) aside, just shows the box 100% idle : > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 > 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 > 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio > 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq > 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 > 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh > 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top > 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 > 4 root -8 - 0K 16K - 1 0:00 0.00% g_down > 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow > 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer > 3 root -8 - 0K 16K - 0 0:00 0.00% g_up > 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq > > > I tested : > > Update Bios > ULE /4BSD > PREEMPTION on/off > PREEMPTION + IPI_PREEMPTION > hw.nfe.msi[x]_disable=1 ^^^^^^^^^^^^^^^^^^^^^^^ This has no effect as MCP65 lacks MSI/MSI-X capability. > > All don't seem to matter to the problem. > > I put two tcpdumps (server and client during another scp(1) ) on > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client > > I'm far from an expert on TCP/IP, but wireshark "expert info" shows > lots of sequences like : > > TCP Previous segment lost > TCP Duplicate ACK 1 > TCP Window update > TCP Duplicate ACK 2 > TCP Duplicate ACK 3 > TCP Duplicate ACK 4 > TCP Duplicate ACK 5 > TCP Fast retransmission (suspected) > TCP ... > TCP Out-of-Order segment > TCP ... > > > As usual, feel free to contact me for further info/tests. > AFAIK it seems that you're the first one that reports poor performance issue of MCP65. MCP65 has no checksum offload/TSO capability so nfe(4) never try to take advantage of the hardware capability. So you should have no checksum offload/TSO related issue here. Also note, checking network performance with scp(1) wouldn't show real numbers as scp(1) may involve other system activities. Use one of network benchmark programs in ports(e.g. benchmarks/netperf) to measure network performance. Other possible cause of issue could be link speed/duplex mismatch or excessive MAC control frames(e.g. pause frames). Does nfe(4) agree on resolved speed/duplex with link partner? If they all agree on resolved speed/duplex, would you check number of pause frames sent/received from link partner? Even though MCP65 supports hardware MAC statistics for pause frames nfe(4) has no support code yet so you may have to resort to managed switch that can show Tx/Rx statistics of each port. -- Regards, Pyun YongHyeon From noc at bg.net.ua Mon Sep 29 07:41:43 2008 From: noc at bg.net.ua (Zin'kov Oleg) Date: Mon Sep 29 07:41:52 2008 Subject: Problem with process parallelization In-Reply-To: References: <79dc33e3f3737f5beeadce88e96004bc.squirrel@webmail.bg.net.ua> Message-ID: <38eb68e1e4bd90145fe7e90708c8979f.squirrel@webmail.bg.net.ua> >> Hello, freebsd-net mailing list. >> >> We have server such configurtion: >> - 2 quadcore AMD Opteron processors; >> - 4 GB RAM; >> - NIC Intel Pro/1000 PT, Dual Port Server Adapter. >> >> ########################################################### >> >> Problem: >> >> in some moments of time, at the growth of the network activity, one of >> the processors is fully loaded at 100%. >> >> ########################################################### >> >> Kernel configuration: >> >> FreeBSD atlantis.bg.net.ua 7.0-STABLE FreeBSD 7.0-STABLE #1: Tue Apr 1 >> 15:06:30 EEST 2008 >> root@atlantis.bg.net.ua:/usr/obj/usr/src/sys/ATLANTIS amd64 >> >> /etc/sysctl.conf: >> >> net.inet.tcp.blackhole=2 >> net.inet.udp.blackhole=1 >> kern.ipc.somaxconn=16384 >> net.inet.ip.fastforwarding=1 >> net.inet.ip.maxfragpackets=2000 >> net.inet.ip.intr_queue_maxlen=1000 >> net.inet.ip.dummynet.hash_size=2048 >> net.inet.tcp.recvspace=65536 >> net.inet.udp.recvspace=65536 >> net.inet.raw.recvspace=32768 >> net.local.stream.recvspace=32768 >> net.local.dgram.recvspace=32768 >> net.local.stream.sendspace=32768 >> net.inet.tcp.sendspace=65536 >> net.inet.icmp.icmplim=500 >> dev.em.0.rx_int_delay=500 >> dev.em.0.tx_int_delay=500 >> dev.em.0.rx_abs_int_delay=800 >> dev.em.0.tx_abs_int_delay=800 >> dev.em.1.rx_int_delay=500 >> dev.em.1.tx_int_delay=500 >> dev.em.1.rx_abs_int_delay=800 >> dev.em.1.tx_abs_int_delay=800 >> net.link.ether.inet.max_age=600 >> >> /boot/loader.conf: >> >> hw.em.rxd=4096 >> hw.em.txd=4096 >> >> /etc/rc.firewall: >> >> 82 pipes like theese: >> >> pipe 387 ip from any to 193.227.x.x in recv vlan10 >> pipe 388 ip from 193.227.x.x to any out xmit vlan10 >> >> >> ######################################### >> Kernel: >> >> >> cpu HAMMER >> ident ATLANTIS >> >> # To statically compile in device wiring instead of /boot/device.hints >> #hints "GENERIC.hints" # Default places to look for >> devices. >> >> makeoptions DEBUG=-g # Build kernel with gdb(1) debug >> symbols >> >> options SCHED_ULE # 4BSD scheduler >> options PREEMPTION # Enable kernel thread >> preemption >> options INET # InterNETworking >> #options SCTP # Stream Control Transmission >> Protocol >> options FFS # Berkeley Fast Filesystem >> options >> SOFTUPDATES # Enable FFS soft updates support >> options >> UFS_ACL # Support for access control lists >> options >> UFS_DIRHASH # Improve performance on big directories >> options PROCFS # Process filesystem (requires >> PSEUDOFS) >> options PSEUDOFS # Pseudo-filesystem framework >> options GEOM_PART_GPT # GUID Partition Tables. >> options GEOM_LABEL # Provides labelization >> options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP >> THIS!] >> options COMPAT_IA32 # Compatible with i386 binaries >> options COMPAT_FREEBSD4 # Compatible with FreeBSD4 >> options >> COMPAT_FREEBSD5 # Compatible with FreeBSD5 options >> COMPAT_FREEBSD6 # Compatible with FreeBSD6 options >> KTRACE >> # ktrace(1) support >> options SYSVSHM # SYSV-style shared memory >> options >> SYSVMSG # SYSV-style message queues options >> SYSVSEM # SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time >> extensions >> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >> options ADAPTIVE_GIANT # Giant mutex is adaptive. >> options >> STOP_NMI # Stop CPUS using NMI instead of IPI >> options AUDIT # Security event auditing >> >> # Make an SMP-capable kernel by default >> options SMP # Symmetric MultiProcessor >> Kernel >> >> # Bus support. >> device acpi >> device pci >> >> # ATA and ATAPI devices >> device ata >> >> device atadisk # ATA disk drives >> options ATA_STATIC_ID # Static device numbering >> >> # RAID controllers >> device twe # 3ware ATA RAID >> >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> device atkbdc # AT keyboard controller >> device atkbd # AT keyboard >> >> device vga # VGA video card driver >> >> device splash # Splash screen and screen saver support >> >> # syscons is the default console driver, resembling an SCO console >> device >> sc >> >> ### COM >> device sio >> >> # PCI Ethernet NICs. >> device em # Intel PRO/1000 adapter Gigabit >> Ethernet >> Card >> >> # PCI Ethernet NICs that use the common MII bus controller code. >> # NOTE: Be sure to keep the 'device miibus' line in order to use these >> NICs! device miibus # MII bus support >> device bge # Broadcom BCM570xx Gigabit Ethernet >> device fxp # Intel EtherExpress PRO/100B (82557, >> 82558) >> >> # Pseudo devices. >> device loop # Network loopback >> device random # Entropy device >> device ether # Ethernet support >> device pty # Pseudo-ttys (telnet etc) >> device vlan >> >> # The `bpf' device enables the Berkeley Packet Filter. >> # Be aware of the administrative consequences of enabling this! >> # Note that 'bpf' is required for DHCP. >> device bpf # Berkeley packet filter >> >> ## Custom options >> # NetGraph >> options NETGRAPH >> options NETGRAPH_ONE2MANY >> options NETGRAPH_NETFLOW >> options NETGRAPH_CISCO >> options NETGRAPH_ETHER >> options NETGRAPH_KSOCKET >> options NETGRAPH_SOCKET >> options NETGRAPH_TEE >> >> options IPFIREWALL >> options IPFIREWALL_VERBOSE >> options IPFIREWALL_FORWARD >> options IPFIREWALL_VERBOSE_LIMIT=1000 >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> options DUMMYNET >> options HZ=1000 >> options DEVICE_POLLING >> ##################################################### >> >> Interfaces: >> - em0 >> - em1 >> - bge0 >> - bge1 >> - vlan (61 virtual interfaces) >> >> ##################################################### >> top -S >> >> last pid: 9673; load averages: 1.94, 1.75, 1.57 >> up 0+19:17:21 >> 19:45:01 >> 77 processes: 11 running, 49 sleeping, 17 waiting >> CPU states: 0.0% user, 0.0% nice, 22.6% system, 0.3% interrupt, 77.0% >> idle Mem: 198M Active, 410M Inact, 455M Wired, 228K Cache, 214M Buf, >> 2874M >> Free Swap: 4096M Total, 4096M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 11 root 1 171 ki31 0K 16K CPU7 7 19.0H 100.00% idle: >> cpu7 >> 16 root 1 171 ki31 0K 16K CPU2 2 18.9H 100.00% idle: >> cpu2 >> 17 root 1 171 ki31 0K 16K RUN 1 18.8H 100.00% idle: >> cpu1 >> 13 root 1 171 ki31 0K 16K CPU5 5 18.8H 100.00% idle: >> cpu5 >> 18 root 1 171 ki31 0K 16K CPU0 0 916:13 100.00% idle: >> cpu0 >> 12 root 1 171 ki31 0K 16K CPU6 6 18.8H 99.85% idle: >> cpu6 >> 35 root 1 -68 - 0K 16K CPU4 4 466:17 96.00% em1 >> taskq >> 34 root 1 -68 - 0K 16K CPU3 3 482:01 90.38% em0 >> taskq >> 15 root 1 171 ki31 0K 16K RUN 3 655:20 13.38% idle: >> cpu3 >> 14 root 1 171 ki31 0K 16K RUN 4 671:52 3.08% idle: >> cpu4 >> >> >> ############################################## >> 19:45[p0]root@atlantis#~>netstat -w 1 -I em0 >> input (em0) output >> packets errs bytes packets errs bytes colls >> 57381 0 36442155 68726 0 69126050 0 >> 56817 0 37480502 67656 0 66053093 0 >> 57847 0 39532712 68603 0 67037042 0 >> 56908 0 37197022 68924 0 68660108 0 >> 57107 0 37643382 68398 0 68113937 0 >> 56847 0 35944754 68394 0 67896267 0 >> 58754 0 39763361 68966 0 70029090 0 >> 58343 0 38301796 69635 0 69948678 0 >> ^C >> 19:46[p0]root@atlantis#~>netstat -w 1 -I em1 >> input (em1) output >> packets errs bytes packets errs bytes colls >> 67944 0 68877031 55376 0 36252905 0 >> 65943 0 66722222 54575 0 37710643 0 >> 64639 0 67149621 53298 0 35423539 0 >> 63988 0 65035759 51787 0 35402337 0 >> 63849 0 65968513 50727 0 31683425 0 >> 64301 0 66684912 50193 0 30917339 0 >> >> >> >> ################################################################### >> >> >> How can we solve this problem and parallelize em1:taskq kernel processes >> between all 8 processors? > > # sysctl net.isr.direct=0 > would add one more kernel thread to handle your network traffic. > > Regards, Dmitriy. > A problem remained :( >> >> >> -- >> ISP BGNet >> 288-03-53 >> 246-68-98 >> >> Zin'kov Oleg >> System administrator >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> ISP BGNet >> 288-03-53 >> 246-68-98 >> >> Zin'kov Oleg >> System administrator >> >> _______________________________________________ >> 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" >> > > -- ISP BGNet 288-03-53 246-68-98 Zin'kov Oleg System administrator From granica_raydom at rambler.ru Mon Sep 29 07:56:51 2008 From: granica_raydom at rambler.ru (granica_raydom@rambler.ru) Date: Mon Sep 29 07:56:58 2008 Subject: crpc-0.7.5 released Message-ID: <84984638.1222673892.144643464.45273@mcgi62.rambler.ru> Hi all, CRPC version 0.7.5 is released. CRPC or C-based Remote Procedure Call is a remote procedure call system with automatic parallelization capabilities integrated into C language. The project site is http://crpc.sourceforge.net/ Regards, Andrey Babanin. From hk at alogis.com Mon Sep 29 09:13:29 2008 From: hk at alogis.com (Holger Kipp) Date: Mon Sep 29 09:13:41 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> Message-ID: <20080929090310.GA70418@intserv.int1.b.intern> On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: > No....you misunderstood. The 7.1 box was connected to a 5.4 box doing a 50GB > data transfer over rsync. Both nics were 1000 full duplex with a crossover cable. > The speed performance was terrible and I could only get up to 10 Mb/s and there > was NO switch involved. I believe there is a problem or bug involved with the > driver. Have the drivers or stack been updated in 7.1? What else can I provide? Hi, I only flipped through the messages in this thread, faintly remembering someone writing something about ssh. Anyway, if you're copying using ssh (scp, sftp), then the transfer rate is much less than what you'd expect - due to the encryption/decryption overhead (unless you have hardware acceleration on both sideds). Just my two cents (Euro) on general reasons for slow data transfers. Regards, Holger Kipp From bugmaster at FreeBSD.org Mon Sep 29 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:08:18 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200809291106.m8TB6sgr040872@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/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/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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 bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 176 problems total. From arno at heho.snv.jussieu.fr Mon Sep 29 14:13:02 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Mon Sep 29 14:13:12 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: <20080929043134.GD54819@cdnetworks.co.kr> References: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: Dear Pyun, thanx for your prompt answer (as usual). Pyun YongHyeon writes: > On Sat, Sep 27, 2008 at 11:21:00PM +0200, Arno J. Klaassen wrote: > > > > > > Hello, > > > > I've serious network performance problems on a HP Turion X2 > > based brand new notebook; I only used a 7-1Beta CD and > > 7-STABLE on this thing. > > > > Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : > > > > # scp -p ports.tgz login@mv:/tmp/ > > ports.tgz 100% 98MB 88.7KB/s 18:49 > > > > (doing the same thing by copy from an nfs-mounted disk even > > takes mores than an hour ...) > > > > > > Doing a top(1) aside, just shows the box 100% idle : > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 > > 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 > > 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio > > 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq > > 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 > > 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh > > 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top > > 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 > > 4 root -8 - 0K 16K - 1 0:00 0.00% g_down > > 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow > > 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer > > 3 root -8 - 0K 16K - 0 0:00 0.00% g_up > > 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq > > > > > > I tested : > > > > Update Bios > > ULE /4BSD > > PREEMPTION on/off > > PREEMPTION + IPI_PREEMPTION > > hw.nfe.msi[x]_disable=1 > ^^^^^^^^^^^^^^^^^^^^^^^ > This has no effect as MCP65 lacks MSI/MSI-X capability. > > > > All don't seem to matter to the problem. > > > > I put two tcpdumps (server and client during another scp(1) ) on > > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server > > http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client > > > > I'm far from an expert on TCP/IP, but wireshark "expert info" shows > > lots of sequences like : > > > > TCP Previous segment lost > > TCP Duplicate ACK 1 > > TCP Window update > > TCP Duplicate ACK 2 > > TCP Duplicate ACK 3 > > TCP Duplicate ACK 4 > > TCP Duplicate ACK 5 > > TCP Fast retransmission (suspected) > > TCP ... > > TCP Out-of-Order segment > > TCP ... > > > > > > As usual, feel free to contact me for further info/tests. > > > > AFAIK it seems that you're the first one that reports poor > performance issue of MCP65. someone must be ;) no kiddin, I am not convinced this is (only) a driver issue (cf. "bad NFS/UDP performance" thread on -hackers). I just have no experience on this notebook, so I can't say " it worked great before" and my only other 7-stable-amd64 I have does not show the probs, having a cheap re0 *and* being UP. > MCP65 has no checksum offload/TSO > capability so nfe(4) never try to take advantage of the hardware > capability. So you should have no checksum offload/TSO related > issue here. > Also note, checking network performance with scp(1) wouldn't > show real numbers as scp(1) may involve other system activities. > Use one of network benchmark programs in ports(e.g. > benchmarks/netperf) to measure network performance. quite funny (even taken with lots of salt since the LAN is used for "normal work" as well in parallel, but differences are rather significant) : I test to same server (7-stable-amd64 from Jun 7 (using nfe0 as well btw, but another chip), either from a 6-stable-x86 (Jul 14, sk0) or the notebook (7-stable-x64 below), using for i in ; do echo $i; /usr/local/bin/netperf -H push -i 4,2 -I 95,10 -t $i; echo; done streaming results are OK for both : TCP_STREAM Throughput 10^6bits/sec 6-stable-x86 349.57 7-stable-x64 939.47 UDP_STREAM Throughput 10^6bits/sec 6-stable-x86 388.45 7-stable-x64 947.89 However, the "request/respones" tests are awfull for my notebook (test repeated on the notebook for the sake of conviction) : TCP_RR Trans. Rate per sec 6-stable-x86 9801.58 7-stable-x64 137.61 7-stable-x64 89.35 7-stable-x64 102.29 TCP_CRR Trans. Rate per sec 6-stable-x86 4520.98 7-stable-x64 7.00 7-stable-x64 8.10 7-stable-x64 18.49 UDP_RR Trans. Rate per sec 6-stable-x86 9473.20 7-stable-x64 9.60 7-stable-x64 0.90 7-stable-x64 0.10 I can send you complete results if wanted. > Other possible cause of issue could be link speed/duplex mismatch > or excessive MAC control frames(e.g. pause frames). Does nfe(4) > agree on resolved speed/duplex with link partner? yes (1000baseTX ) > If they all agree on resolved speed/duplex, would you check number > of pause frames sent/received from link partner? Even though MCP65 > supports hardware MAC statistics for pause frames nfe(4) has no > support code yet so you may have to resort to managed switch that > can show Tx/Rx statistics of each port. aargh; I do have a Netgear GS724TS around where I can connect it to. This thing should be manageable, but give me some time to find out how .... Thanx, Arno From remko at FreeBSD.org Mon Sep 29 19:47:49 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Sep 29 19:47:56 2008 Subject: bin/127719: arp: Segmentation fault (core dumped) Message-ID: <200809291947.m8TJlnG4087888@freefall.freebsd.org> Synopsis: arp: Segmentation fault (core dumped) Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Sep 29 19:47:28 UTC 2008 Responsible-Changed-Why: reassign to net http://www.freebsd.org/cgi/query-pr.cgi?pr=127719 From rwatson at FreeBSD.org Mon Sep 29 20:10:29 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 29 20:10:43 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > However, the "request/respones" tests are awfull for my notebook (test > repeated on the notebook for the sake of conviction) : Is it possible to rerun these tests with a 7.0 kernel of the same general configuration? That would help us determine if it's a regression between 7.0 and 7.1, or perhaps a more general issue between 6.x and 7.x. I wouldn't reject a hardware, driver, or general stack issue at this point as things are still fairly unclear. If it's definitely between 7.0 and 7.1 that the problem arises, trying a series of kernels spaced at, say, one month intervals in that period would be quite helpful in narrowing down the source. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > TCP_RR > Trans. > Rate > per sec > > 6-stable-x86 9801.58 > 7-stable-x64 137.61 > 7-stable-x64 89.35 > 7-stable-x64 102.29 > > TCP_CRR > Trans. > Rate > per sec > > 6-stable-x86 4520.98 > 7-stable-x64 7.00 > 7-stable-x64 8.10 > 7-stable-x64 18.49 > > > UDP_RR > Trans. > Rate > per sec > > 6-stable-x86 9473.20 > 7-stable-x64 9.60 > 7-stable-x64 0.90 > 7-stable-x64 0.10 > > > I can send you complete results if wanted. > >> Other possible cause of issue could be link speed/duplex mismatch >> or excessive MAC control frames(e.g. pause frames). Does nfe(4) >> agree on resolved speed/duplex with link partner? > > > yes (1000baseTX ) > >> If they all agree on resolved speed/duplex, would you check number >> of pause frames sent/received from link partner? Even though MCP65 >> supports hardware MAC statistics for pause frames nfe(4) has no >> support code yet so you may have to resort to managed switch that >> can show Tx/Rx statistics of each port. > > aargh; I do have a Netgear GS724TS around where I can connect it to. > This thing should be manageable, but give me some time to > find out how .... > > Thanx, Arno > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From rizzo at iet.unipi.it Mon Sep 29 21:08:44 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Sep 29 21:08:52 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: <20080929211218.GC69054@onelab2.iet.unipi.it> On Mon, Sep 29, 2008 at 09:10:29PM +0100, Robert Watson wrote: > > On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > > >However, the "request/respones" tests are awfull for my notebook (test > >repeated on the notebook for the sake of conviction) : > > Is it possible to rerun these tests with a 7.0 kernel of the same general > configuration? That would help us determine if it's a regression between > 7.0 and 7.1, or perhaps a more general issue between 6.x and 7.x. I > wouldn't reject a hardware, driver, or general stack issue at this point as > things are still fairly unclear. If it's definitely between 7.0 and 7.1 > that the problem arises, trying a series of kernels spaced at, say, one > month intervals in that period would be quite helpful in narrowing down the > source. two things: + the 'nfe' driver is not in 6.x so i wonder how these numbers were derived in 6.x -- perhaps using a backport, or using the nve driver instead ? In any case we cannot easily compare 6.x and 7.x behaviour with nfe. + with the nfe driver and the MCP67 chipset i have found a tendency of the card to stall at high data rates and with some system load (e.g. massive scp while some X applications is spinning). This was completely repeatable and caused the network card to become deaf (it could transmit though) and it required an ifconfig down/up to come back to life, watchdogs and timeouts did not fix it. Additionally i have found some bug in the polling implementation which may or may not relate to more generic interrupt handling. This was described in a thread in april. A patch to address the stalls is at http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080426.1044.diff (i have been running this on my home pc since late april) A related patch changes slightly the implementation of polling: http://info.iet.unipi.it/~luigi/FreeBSD/nfe-20080427.diff At the time when i raised the problem on the mailing list apparently others were not seeing the problem so i did not pursue the integration in the system - but if this is a significant problem in 7.1R then it is worth a try. cheers luigi From oberman at es.net Mon Sep 29 21:41:47 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Sep 29 21:42:00 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: Your message of "Mon, 29 Sep 2008 11:03:10 +0200." <20080929090310.GA70418@intserv.int1.b.intern> Message-ID: <20080929213122.204444500F@ptavv.es.net> > Date: Mon, 29 Sep 2008 11:03:10 +0200 > From: Holger Kipp > Sender: owner-freebsd-stable@freebsd.org > > On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: > > No....you misunderstood. The 7.1 box was connected to a 5.4 box > doing a 50GB > data transfer over rsync. Both nics were 1000 full > duplex with a crossover cable. > The speed performance was terrible > and I could only get up to 10 Mb/s and there > was NO switch involved. > I believe there is a problem or bug involved with the > driver. Have > the drivers or stack been updated in 7.1? What else can I provide? > > Hi, I only flipped through the messages in this thread, faintly > remembering someone writing something about ssh. Anyway, if you're > copying using ssh (scp, sftp), then the transfer rate is much less > than what you'd expect - due to the encryption/decryption overhead > (unless you have hardware acceleration on both sideds). > > Just my two cents (Euro) on general reasons for slow data transfers. ssh(1) and it's kin, scp(1) and sftp(1), are not at all well designed for performance. There are several issues and if you want details, read . If you want to use ssh(1) for high-bandwidth TCP streams, especially scp/sftp, install openssh-portable from ports after selecting the "enable HPN-SSH patch" option. You may want to over-write the base install, but be sure to edit make.conf/src.conf so that a system upgrade won't re-overwrite it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080929/0e7fdd12/attachment.pgp From nomadlogic at gmail.com Mon Sep 29 21:57:39 2008 From: nomadlogic at gmail.com (pete wright) Date: Mon Sep 29 21:58:10 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: <20080929090310.GA70418@intserv.int1.b.intern> References: <20080928205300.GF60230@in-addr.com> <20080928222414.GA90269@icarus.home.lan> <20080929090310.GA70418@intserv.int1.b.intern> Message-ID: <57d710000809291433n2d8f48ebv9e54f868a7422654@mail.gmail.com> On Mon, Sep 29, 2008 at 2:03 AM, Holger Kipp wrote: > On Sun, Sep 28, 2008 at 06:30:03PM -0400, firmdog@gmail.com wrote: >> No....you misunderstood. The 7.1 box was connected to a 5.4 box doing a 50GB >> data transfer over rsync. Both nics were 1000 full duplex with a crossover cable. >> The speed performance was terrible and I could only get up to 10 Mb/s and there >> was NO switch involved. I believe there is a problem or bug involved with the >> driver. Have the drivers or stack been updated in 7.1? What else can I provide? > > Hi, I only flipped through the messages in this thread, faintly remembering someone > writing something about ssh. Anyway, if you're copying using ssh (scp, sftp), then > the transfer rate is much less than what you'd expect - due to the encryption/decryption > overhead (unless you have hardware acceleration on both sideds). > FWIW I think the general issue for the ssh suite of tools is the compiled in window size is not tuned for large transfers like this: http://www.psc.edu/networking/projects/hpn-ssh/theory.php we use a propritary tool called aspera to overcome these issues when moving large amounts of data b/w remote sites on our WAN: http://www.asperasoft.com/products/scp/index.html the encrytp/decrypt overhead should be pretty minimal on modern hardware, so i would not expect that to be the first bottle neck you run into. -pete -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group From rwatson at FreeBSD.org Mon Sep 29 22:17:50 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 29 22:17:56 2008 Subject: Initialisation of a networking protocol In-Reply-To: References: Message-ID: On Mon, 29 Sep 2008, Ryan French wrote: > I'm having a bit of trouble with my MPLS protocol code at the moment. I have > the code written and compiling (mostly based on some OpenBSD code I was > shown) but when an MPLS packet is received it doesnt appear as thou my > mpls_input routine is being called. I believe this is because I have not > initialised the protocol properly. I have created protosw structure for MPLS > as well as created an mpls_init(void) function which registers the protocol > with netisr via netisr_register. Other than that I am not really sure where > I tell the kernel to call the mpls_init function so that the protocol is > initialised, and a couple of hours of googling/looking through ip6 code > hasnt really helped at all. If anyone can help and needs to see the code it > can be viewed on Perforce at > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/rfrench_mpls&HIDEDEL=NO Hi Ryan: netisr is just a dispatch facility consisting of a series of named queues, worker thread(s), and a dispatch model -- it is the responsibility of some other piece of driver or protocol code to inject packets using netisr_queue() or netisr_dispatch(). Typically this occurs in the decapsulation code for the layer below the dispatched layer -- often the link layer. You can take a look at current dispatch points here: http://fxr.watson.org/fxr/ident?im=bigexcerpts;i=netisr_queue http://fxr.watson.org/fxr/ident?im=bigexcerpts;i=netisr_dispatch A typical dispatch point is ether_demux(), which switches on the etherhet frame header's protocol field and then hands off the packet to netisr for dispatch. If the dispatch may lead to recursion, then you may need to use netisr_queue() rather than netisr_direct() to disallow direct dispatch. Robert N M Watson Computer Laboratory University of Cambridge From bms at FreeBSD.org Mon Sep 29 22:26:06 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Sep 29 22:26:12 2008 Subject: Initialisation of a networking protocol In-Reply-To: References: Message-ID: <48E155FB.7050009@FreeBSD.org> Hi Ryan, Did you initialize the .pr_init member of struct protosw for MPLS? AFAIK, MPLS does not use an outer IP header, so adding a struct ipprotosw won't work; they are similar structs however. cheers BMS From rjf12 at students.waikato.ac.nz Mon Sep 29 23:10:34 2008 From: rjf12 at students.waikato.ac.nz (Ryan French) Date: Mon Sep 29 23:11:25 2008 Subject: Initialisation of a networking protocol In-Reply-To: References: Message-ID: Hi, Thanks for the help. I managed to figure out that the problem was I had left out the DOMAIN_SET command in my code, but I've got that sorted now and am just working through bugs in my code causing page faults whenever an MPLS packet is received. Should hopefully have something up and running by the weeks end. Thanks again, Ryan French. From linimon at FreeBSD.org Tue Sep 30 00:41:57 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 30 00:42:09 2008 Subject: kern/127724: [rtalloc] rtfree: 0xc5a8f870 has 1 refs Message-ID: <200809300041.m8U0fvvh011752@freefall.freebsd.org> Old Synopsis: rtfree: 0xc5a8f870 has 1 refs New Synopsis: [rtalloc] rtfree: 0xc5a8f870 has 1 refs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 30 00:40:50 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127724 From pyunyh at gmail.com Tue Sep 30 04:20:12 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Sep 30 04:20:19 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: <20080930041807.GC59136@cdnetworks.co.kr> On Mon, Sep 29, 2008 at 04:12:56PM +0200, Arno J. Klaassen wrote: [...] > > > > AFAIK it seems that you're the first one that reports poor > > performance issue of MCP65. > > > someone must be ;) no kiddin, I am not convinced this is (only) > a driver issue (cf. "bad NFS/UDP performance" thread on -hackers). > > I just have no experience on this notebook, so I can't say " it worked > great before" and my only other 7-stable-amd64 I have does not > show the probs, having a cheap re0 *and* being UP. > > > > MCP65 has no checksum offload/TSO > > capability so nfe(4) never try to take advantage of the hardware > > capability. So you should have no checksum offload/TSO related > > issue here. > > Also note, checking network performance with scp(1) wouldn't > > show real numbers as scp(1) may involve other system activities. > > Use one of network benchmark programs in ports(e.g. > > benchmarks/netperf) to measure network performance. > > quite funny (even taken with lots of salt since the LAN is used > for "normal work" as well in parallel, but differences are > rather significant) : > > I test to same server (7-stable-amd64 from Jun 7 (using > nfe0 as well btw, but another chip), either from a > 6-stable-x86 (Jul 14, sk0) or the notebook (7-stable-x64 below), using > > for i in ; do > echo $i; /usr/local/bin/netperf -H push -i 4,2 -I 95,10 -t $i; echo; > done > > streaming results are OK for both : > > TCP_STREAM > Throughput > 10^6bits/sec > > 6-stable-x86 349.57 > 7-stable-x64 939.47 > > UDP_STREAM > Throughput > 10^6bits/sec > > 6-stable-x86 388.45 > 7-stable-x64 947.89 > > > However, the "request/respones" tests are awfull for my notebook > (test repeated on the notebook for the sake of conviction) : > > TCP_RR > Trans. > Rate > per sec > > 6-stable-x86 9801.58 > 7-stable-x64 137.61 > 7-stable-x64 89.35 > 7-stable-x64 102.29 > > TCP_CRR > Trans. > Rate > per sec > > 6-stable-x86 4520.98 > 7-stable-x64 7.00 > 7-stable-x64 8.10 > 7-stable-x64 18.49 > > > UDP_RR > Trans. > Rate > per sec > > 6-stable-x86 9473.20 > 7-stable-x64 9.60 > 7-stable-x64 0.90 > 7-stable-x64 0.10 > > > I can send you complete results if wanted. > Based on poor TCP_RR numbers I wonder how you can get such a high TCP_STREAM numbers. > > Other possible cause of issue could be link speed/duplex mismatch > > or excessive MAC control frames(e.g. pause frames). Does nfe(4) > > agree on resolved speed/duplex with link partner? > > > yes (1000baseTX ) > > > If they all agree on resolved speed/duplex, would you check number > > of pause frames sent/received from link partner? Even though MCP65 > > supports hardware MAC statistics for pause frames nfe(4) has no > > support code yet so you may have to resort to managed switch that > > can show Tx/Rx statistics of each port. > > aargh; I do have a Netgear GS724TS around where I can connect it to. > This thing should be manageable, but give me some time to > find out how .... > Or try attached patch. Use "sysctl dev.nfe.0.stats" to get statistics. -- Regards, Pyun YongHyeon -------------- next part -------------- Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 183480) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -122,6 +122,9 @@ static int sysctl_int_range(SYSCTL_HANDLER_ARGS, int, int); static int sysctl_hw_nfe_proc_limit(SYSCTL_HANDLER_ARGS); +static void nfe_sysctl_node(struct nfe_softc *); +static void nfe_stats_clear(struct nfe_softc *); +static void nfe_stats_update(struct nfe_softc *); #ifdef NFE_DEBUG static int nfedebug = 0; @@ -245,6 +248,22 @@ "NVIDIA nForce MCP73 Networking Adapter"}, {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP73_LAN4, "NVIDIA nForce MCP73 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN1, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN2, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN3, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP77_LAN4, + "NVIDIA nForce MCP77 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN1, + "NVIDIA nForce MCP79 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN2, + "NVIDIA nForce MCP79 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN3, + "NVIDIA nForce MCP79 Networking Adapter"}, + {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP79_LAN4, + "NVIDIA nForce MCP79 Networking Adapter"}, {0, 0, NULL} }; @@ -438,18 +457,19 @@ break; case PCI_PRODUCT_NVIDIA_MCP51_LAN1: case PCI_PRODUCT_NVIDIA_MCP51_LAN2: - sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT; + sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT | NFE_MIB_V1; break; case PCI_PRODUCT_NVIDIA_CK804_LAN1: case PCI_PRODUCT_NVIDIA_CK804_LAN2: case PCI_PRODUCT_NVIDIA_MCP04_LAN1: case PCI_PRODUCT_NVIDIA_MCP04_LAN2: - sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | NFE_HW_CSUM; + sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | NFE_HW_CSUM | + NFE_MIB_V1; break; case PCI_PRODUCT_NVIDIA_MCP55_LAN1: case PCI_PRODUCT_NVIDIA_MCP55_LAN2: sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | NFE_HW_CSUM | - NFE_HW_VLAN | NFE_PWR_MGMT | NFE_TX_FLOW_CTRL; + NFE_HW_VLAN | NFE_PWR_MGMT | NFE_TX_FLOW_CTRL | NFE_MIB_V2; break; case PCI_PRODUCT_NVIDIA_MCP61_LAN1: @@ -465,14 +485,26 @@ case PCI_PRODUCT_NVIDIA_MCP73_LAN3: case PCI_PRODUCT_NVIDIA_MCP73_LAN4: sc->nfe_flags |= NFE_40BIT_ADDR | NFE_PWR_MGMT | - NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL; + NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL | NFE_MIB_V2; break; + case PCI_PRODUCT_NVIDIA_MCP77_LAN1: + case PCI_PRODUCT_NVIDIA_MCP77_LAN2: + case PCI_PRODUCT_NVIDIA_MCP77_LAN3: + case PCI_PRODUCT_NVIDIA_MCP77_LAN4: + case PCI_PRODUCT_NVIDIA_MCP79_LAN1: + case PCI_PRODUCT_NVIDIA_MCP79_LAN2: + case PCI_PRODUCT_NVIDIA_MCP79_LAN3: + case PCI_PRODUCT_NVIDIA_MCP79_LAN4: + sc->nfe_flags |= NFE_40BIT_ADDR | NFE_HW_CSUM | NFE_PWR_MGMT | + NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL | NFE_MIB_V3; + break; case PCI_PRODUCT_NVIDIA_MCP65_LAN1: case PCI_PRODUCT_NVIDIA_MCP65_LAN2: case PCI_PRODUCT_NVIDIA_MCP65_LAN3: case PCI_PRODUCT_NVIDIA_MCP65_LAN4: sc->nfe_flags |= NFE_JUMBO_SUP | NFE_40BIT_ADDR | - NFE_PWR_MGMT | NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL; + NFE_PWR_MGMT | NFE_CORRECT_MACADDR | NFE_TX_FLOW_CTRL | + NFE_MIB_V2; break; } @@ -519,25 +551,9 @@ goto fail; nfe_alloc_jrx_ring(sc, &sc->jrxq); + /* Create sysctl node. */ + nfe_sysctl_node(sc); - SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), - OID_AUTO, "process_limit", CTLTYPE_INT | CTLFLAG_RW, - &sc->nfe_process_limit, 0, sysctl_hw_nfe_proc_limit, "I", - "max number of Rx events to process"); - - sc->nfe_process_limit = NFE_PROC_DEFAULT; - error = resource_int_value(device_get_name(dev), device_get_unit(dev), - "process_limit", &sc->nfe_process_limit); - if (error == 0) { - if (sc->nfe_process_limit < NFE_PROC_MIN || - sc->nfe_process_limit > NFE_PROC_MAX) { - device_printf(dev, "process_limit value out of range; " - "using default: %d\n", NFE_PROC_DEFAULT); - sc->nfe_process_limit = NFE_PROC_DEFAULT; - } - } - ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); ifp->if_mtu = ETHERMTU; @@ -902,6 +918,8 @@ if (sc->nfe_link != 0 && (ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { txctl |= NFE_TX_START; rxctl |= NFE_RX_START; + /* Got a link, clear hardware stats. */ + nfe_stats_clear(sc); } else { txctl &= ~NFE_TX_START; rxctl &= ~NFE_RX_START; @@ -2823,6 +2841,8 @@ tdata->m = NULL; } } + /* Update hardware stats. */ + nfe_stats_update(sc); } @@ -2874,6 +2894,7 @@ mii = device_get_softc(sc->nfe_miibus); mii_tick(mii); + nfe_stats_update(sc); nfe_watchdog(ifp); callout_reset(&sc->nfe_stat_ch, hz, nfe_tick, sc); } @@ -2981,3 +3002,199 @@ return (sysctl_int_range(oidp, arg1, arg2, req, NFE_PROC_MIN, NFE_PROC_MAX)); } + + +#define NFE_SYSCTL_STAT_ADD32(c, h, n, p, d) \ + SYSCTL_ADD_UINT(c, h, OID_AUTO, n, CTLFLAG_RD, p, 0, d) +#define NFE_SYSCTL_STAT_ADD64(c, h, n, p, d) \ + SYSCTL_ADD_QUAD(c, h, OID_AUTO, n, CTLFLAG_RD, p, d) + +static void +nfe_sysctl_node(struct nfe_softc *sc) +{ + struct sysctl_ctx_list *ctx; + struct sysctl_oid_list *child, *parent; + struct sysctl_oid *tree; + struct nfe_hw_stats *stats; + int error; + + stats = &sc->nfe_stats; + ctx = device_get_sysctl_ctx(sc->nfe_dev); + child = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->nfe_dev)); + SYSCTL_ADD_PROC(ctx, child, + OID_AUTO, "process_limit", CTLTYPE_INT | CTLFLAG_RW, + &sc->nfe_process_limit, 0, sysctl_hw_nfe_proc_limit, "I", + "max number of Rx events to process"); + + sc->nfe_process_limit = NFE_PROC_DEFAULT; + error = resource_int_value(device_get_name(sc->nfe_dev), + device_get_unit(sc->nfe_dev), "process_limit", + &sc->nfe_process_limit); + if (error == 0) { + if (sc->nfe_process_limit < NFE_PROC_MIN || + sc->nfe_process_limit > NFE_PROC_MAX) { + device_printf(sc->nfe_dev, + "process_limit value out of range; " + "using default: %d\n", NFE_PROC_DEFAULT); + sc->nfe_process_limit = NFE_PROC_DEFAULT; + } + } + + if ((sc->nfe_flags & (NFE_MIB_V1 | NFE_MIB_V2 | NFE_MIB_V3)) == 0) + return; + + tree = SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "stats", CTLFLAG_RD, + NULL, "NFE statistics"); + parent = SYSCTL_CHILDREN(tree); + + /* Rx statistics. */ + tree = SYSCTL_ADD_NODE(ctx, parent, OID_AUTO, "tx", CTLFLAG_RD, + NULL, "Tx MAC statistics"); + child = SYSCTL_CHILDREN(tree); + NFE_SYSCTL_STAT_ADD64(ctx, child, "octets", + &stats->tx_octets, "Octets"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "zero_rexmits", + &stats->tx_zero_rexmits, "Zero Retransmits"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "one_rexmits", + &stats->tx_one_rexmits, "One Retransmits"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "multi_rexmits", + &stats->tx_multi_rexmits, "Multiple Retransmits"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "late_cols", + &stats->tx_late_cols, "Late Collisions"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "fifo_underuns", + &stats->tx_fifo_underuns, "FIFO Underruns"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "carrier_losts", + &stats->tx_carrier_losts, "Carrier Losts"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "excess_deferrals", + &stats->tx_excess_deferals, "Excess Deferrals"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "retry_errors", + &stats->tx_retry_errors, "Retry Errors"); + if ((sc->nfe_flags & NFE_MIB_V2) != 0) { + NFE_SYSCTL_STAT_ADD32(ctx, child, "deferrals", + &stats->tx_deferals, "Deferrals"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "frames", + &stats->tx_frames, "Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "pause", + &stats->tx_pause, "Pause Frames"); + } + if ((sc->nfe_flags & NFE_MIB_V3) != 0) { + NFE_SYSCTL_STAT_ADD32(ctx, child, "unicast", + &stats->tx_deferals, "Unicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "multicast", + &stats->tx_frames, "Multicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "broadcast", + &stats->tx_pause, "Broadcast Frames"); + } + + /* Rx statistics. */ + tree = SYSCTL_ADD_NODE(ctx, parent, OID_AUTO, "rx", CTLFLAG_RD, + NULL, "Rx MAC statistics"); + child = SYSCTL_CHILDREN(tree); + + NFE_SYSCTL_STAT_ADD32(ctx, child, "frame_errors", + &stats->rx_frame_errors, "Framing Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "extra_bytes", + &stats->rx_extra_bytes, "Extra Bytes"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "late_cols", + &stats->rx_late_cols, "Late Collisions"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "runts", + &stats->rx_runts, "Runts"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "jumbos", + &stats->rx_jumbos, "Jumbos"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "fifo_overuns", + &stats->rx_fifo_overuns, "FIFO Overruns"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "crc_errors", + &stats->rx_crc_errors, "CRC Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "fae", + &stats->rx_fae, "Frame Alignment Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "len_errors", + &stats->rx_len_errors, "Length Errors"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "unicast", + &stats->rx_unicast, "Unicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "multicast", + &stats->rx_multicast, "Multicast Frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "brocadcast", + &stats->rx_broadcast, "Broadcast Frames"); + if ((sc->nfe_flags & NFE_MIB_V2) != 0) { + NFE_SYSCTL_STAT_ADD64(ctx, child, "octets", + &stats->rx_octets, "Octets"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "pause", + &stats->rx_pause, "Pause frames"); + NFE_SYSCTL_STAT_ADD32(ctx, child, "drops", + &stats->rx_drops, "Drop frames"); + } +} + +#undef NFE_SYSCTL_STAT_ADD32 +#undef NFE_SYSCTL_STAT_ADD64 + +static void +nfe_stats_clear(struct nfe_softc *sc) +{ + int i, mib_cnt; + + if ((sc->nfe_flags & NFE_MIB_V1) != 0) + mib_cnt = NFE_NUM_MIB_STATV1; + else if ((sc->nfe_flags & (NFE_MIB_V2 | NFE_MIB_V3)) != 0) + mib_cnt = NFE_NUM_MIB_STATV2; + else + return; + + for (i = 0; i < mib_cnt; i += sizeof(uint32_t)) + NFE_READ(sc, NFE_TX_OCTET + i); + + if ((sc->nfe_flags & NFE_MIB_V3) != 0) { + NFE_READ(sc, NFE_TX_UNICAST); + NFE_READ(sc, NFE_TX_MULTICAST); + NFE_READ(sc, NFE_TX_BROADCAST); + } +} + +static void +nfe_stats_update(struct nfe_softc *sc) +{ + struct nfe_hw_stats *stats; + + NFE_LOCK_ASSERT(sc); + + if ((sc->nfe_flags & (NFE_MIB_V1 | NFE_MIB_V2 | NFE_MIB_V3)) == 0) + return; + + stats = &sc->nfe_stats; + stats->tx_octets += NFE_READ(sc, NFE_TX_OCTET); + stats->tx_zero_rexmits += NFE_READ(sc, NFE_TX_ZERO_REXMIT); + stats->tx_one_rexmits += NFE_READ(sc, NFE_TX_ONE_REXMIT); + stats->tx_multi_rexmits += NFE_READ(sc, NFE_TX_MULTI_REXMIT); + stats->tx_late_cols += NFE_READ(sc, NFE_TX_LATE_COL); + stats->tx_fifo_underuns += NFE_READ(sc, NFE_TX_FIFO_UNDERUN); + stats->tx_carrier_losts += NFE_READ(sc, NFE_TX_CARRIER_LOST); + stats->tx_excess_deferals += NFE_READ(sc, NFE_TX_EXCESS_DEFERRAL); + stats->tx_retry_errors += NFE_READ(sc, NFE_TX_RETRY_ERROR); + stats->rx_frame_errors += NFE_READ(sc, NFE_RX_FRAME_ERROR); + stats->rx_extra_bytes += NFE_READ(sc, NFE_RX_EXTRA_BYTES); + stats->rx_late_cols += NFE_READ(sc, NFE_RX_LATE_COL); + stats->rx_runts += NFE_READ(sc, NFE_RX_RUNT); + stats->rx_jumbos += NFE_READ(sc, NFE_RX_JUMBO); + stats->rx_fifo_overuns += NFE_READ(sc, NFE_RX_FIFO_OVERUN); + stats->rx_crc_errors += NFE_READ(sc, NFE_RX_CRC_ERROR); + stats->rx_fae += NFE_READ(sc, NFE_RX_FAE); + stats->rx_len_errors += NFE_READ(sc, NFE_RX_LEN_ERROR); + stats->rx_unicast += NFE_READ(sc, NFE_RX_UNICAST); + stats->rx_multicast += NFE_READ(sc, NFE_RX_MULTICAST); + stats->rx_broadcast += NFE_READ(sc, NFE_RX_BROADCAST); + + if ((sc->nfe_flags & NFE_MIB_V2) != 0) { + stats->tx_deferals += NFE_READ(sc, NFE_TX_DEFERAL); + stats->tx_frames += NFE_READ(sc, NFE_TX_FRAME); + stats->rx_octets += NFE_READ(sc, NFE_RX_OCTET); + stats->tx_pause += NFE_READ(sc, NFE_TX_PAUSE); + stats->rx_pause += NFE_READ(sc, NFE_RX_PAUSE); + stats->rx_drops += NFE_READ(sc, NFE_RX_DROP); + } + + if ((sc->nfe_flags & NFE_MIB_V3) != 0) { + stats->tx_unicast += NFE_READ(sc, NFE_TX_UNICAST); + stats->tx_multicast += NFE_READ(sc, NFE_TX_MULTICAST); + stats->rx_broadcast += NFE_READ(sc, NFE_TX_BROADCAST); + } +} Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 183480) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -51,7 +51,7 @@ #define NFE_MSI_MAP0 0x020 #define NFE_MSI_MAP1 0x024 #define NFE_MSI_IRQ_MASK 0x030 -#define NFE_MAC_RESET 0x03c +#define NFE_MAC_RESET 0x034 #define NFE_MISC1 0x080 #define NFE_TX_CTL 0x084 #define NFE_TX_STATUS 0x088 @@ -87,11 +87,41 @@ #define NFE_PHY_SPEED 0x18c #define NFE_PHY_CTL 0x190 #define NFE_PHY_DATA 0x194 +#define NFE_TX_UNICAST 0x1a0 +#define NFE_TX_MULTICAST 0x1a4 +#define NFE_TX_BROADCAST 0x1a8 #define NFE_WOL_CTL 0x200 #define NFE_PATTERN_CRC 0x204 #define NFE_PATTERN_MASK 0x208 #define NFE_PWR_CAP 0x268 #define NFE_PWR_STATE 0x26c +#define NFE_TX_OCTET 0x280 +#define NFE_TX_ZERO_REXMIT 0x284 +#define NFE_TX_ONE_REXMIT 0x288 +#define NFE_TX_MULTI_REXMIT 0x28c +#define NFE_TX_LATE_COL 0x290 +#define NFE_TX_FIFO_UNDERUN 0x294 +#define NFE_TX_CARRIER_LOST 0x298 +#define NFE_TX_EXCESS_DEFERRAL 0x29c +#define NFE_TX_RETRY_ERROR 0x2a0 +#define NFE_RX_FRAME_ERROR 0x2a4 +#define NFE_RX_EXTRA_BYTES 0x2a8 +#define NFE_RX_LATE_COL 0x2ac +#define NFE_RX_RUNT 0x2b0 +#define NFE_RX_JUMBO 0x2b4 +#define NFE_RX_FIFO_OVERUN 0x2b8 +#define NFE_RX_CRC_ERROR 0x2bc +#define NFE_RX_FAE 0x2c0 +#define NFE_RX_LEN_ERROR 0x2c4 +#define NFE_RX_UNICAST 0x2c8 +#define NFE_RX_MULTICAST 0x2cc +#define NFE_RX_BROADCAST 0x2d0 +#define NFE_TX_DEFERAL 0x2d4 +#define NFE_TX_FRAME 0x2d8 +#define NFE_RX_OCTET 0x2dc +#define NFE_TX_PAUSE 0x2e0 +#define NFE_RX_PAUSE 0x2e4 +#define NFE_RX_DROP 0x2e8 #define NFE_VTAG_CTL 0x300 #define NFE_MSIX_MAP0 0x3e0 #define NFE_MSIX_MAP1 0x3e4 @@ -182,6 +212,10 @@ #define NFE_SEED_100TX 0x00002d00 #define NFE_SEED_1000T 0x00007400 +#define NFE_NUM_MIB_STATV1 21 +#define NFE_NUM_MIB_STATV2 27 +#define NFE_NUM_MIB_STATV3 30 + #define NFE_MSI_MESSAGES 8 #define NFE_MSI_VECTOR_0_ENABLED 0x01 @@ -295,6 +329,14 @@ #define PCI_PRODUCT_NVIDIA_MCP73_LAN2 0x07dd #define PCI_PRODUCT_NVIDIA_MCP73_LAN3 0x07de #define PCI_PRODUCT_NVIDIA_MCP73_LAN4 0x07df +#define PCI_PRODUCT_NVIDIA_MCP77_LAN1 0x0760 +#define PCI_PRODUCT_NVIDIA_MCP77_LAN2 0x0761 +#define PCI_PRODUCT_NVIDIA_MCP77_LAN3 0x0762 +#define PCI_PRODUCT_NVIDIA_MCP77_LAN4 0x0763 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN1 0x0ab0 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN2 0x0ab1 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN3 0x0ab2 +#define PCI_PRODUCT_NVIDIA_MCP79_LAN4 0x0ab3 #define PCI_PRODUCT_NVIDIA_NFORCE3_LAN2 PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN1 #define PCI_PRODUCT_NVIDIA_NFORCE3_LAN3 PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN2 Index: sys/dev/nfe/if_nfevar.h =================================================================== --- sys/dev/nfe/if_nfevar.h (revision 183480) +++ sys/dev/nfe/if_nfevar.h (working copy) @@ -70,6 +70,39 @@ int jnext; }; +struct nfe_hw_stats { + uint64_t tx_octets; + uint32_t tx_zero_rexmits; + uint32_t tx_one_rexmits; + uint32_t tx_multi_rexmits; + uint32_t tx_late_cols; + uint32_t tx_fifo_underuns; + uint32_t tx_carrier_losts; + uint32_t tx_excess_deferals; + uint32_t tx_retry_errors; + uint32_t rx_frame_errors; + uint32_t rx_extra_bytes; + uint32_t rx_late_cols; + uint32_t rx_runts; + uint32_t rx_jumbos; + uint32_t rx_fifo_overuns; + uint32_t rx_crc_errors; + uint32_t rx_fae; + uint32_t rx_len_errors; + uint32_t rx_unicast; + uint32_t rx_multicast; + uint32_t rx_broadcast; + uint32_t tx_deferals; + uint32_t tx_frames; + uint64_t rx_octets; + uint32_t tx_pause; + uint32_t rx_pause; + uint32_t rx_drops; + uint32_t tx_unicast; + uint32_t tx_multicast; + uint32_t tx_broadcast; +}; + struct nfe_softc { struct ifnet *nfe_ifp; device_t nfe_dev; @@ -96,10 +129,14 @@ #define NFE_PWR_MGMT 0x0010 #define NFE_CORRECT_MACADDR 0x0020 #define NFE_TX_FLOW_CTRL 0x0040 +#define NFE_MIB_V1 0x0080 +#define NFE_MIB_V2 0x0100 +#define NFE_MIB_V3 0x0200 int nfe_jumbo_disable; uint32_t rxtxctl; uint8_t mii_phyaddr; uint8_t eaddr[ETHER_ADDR_LEN]; + struct nfe_hw_stats nfe_stats; struct taskqueue *nfe_tq; struct task nfe_int_task; struct task nfe_tx_task; From s.c.sprong at student.utwente.nl Tue Sep 30 09:24:06 2008 From: s.c.sprong at student.utwente.nl (s.c.sprong@student.utwente.nl) Date: Tue Sep 30 09:24:13 2008 Subject: kern/127529: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update References: <200809220627.m8M6RJ8o062822@freefall.freebsd.org> Message-ID: <3F5099632A78C7488A80D6535C4F4E800A93DA@EX01.service.utwente.nl> yongari@FreeBSD.org wrote: >Would you try patch at the followng URL? >http://people.freebsd.org/~yongari/nfe/nfe.mcp77_79.patch Sorry for the late reply, but it took quite some effort to obtain a bootable system with the latest RELENG_7 source. Unfortunately neither the kernel nor world doesn't fully compile at the moment. Your patch works against the current RELENG_7 nfe module and compiles correctly, but RELENG_7 is too new for the 7.0R kernel to load. Since the patch only adds pci ids you can assume that it is correct. regards, scs From arno at heho.snv.jussieu.fr Tue Sep 30 14:35:29 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Tue Sep 30 14:35:36 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: Robert Watson writes: > On Mon, 29 Sep 2008, Arno J. Klaassen wrote: > > > However, the "request/respones" tests are awfull for my notebook > > (test repeated on the notebook for the sake of conviction) : > > Is it possible to rerun these tests with a 7.0 kernel of the same > general configuration? That would help us determine if it's a > regression between 7.0 and 7.1, 7.0-RELEASE-p4 kernel (and 7.1 world) as well as 7.0-RELEASE life-cd give same results : great streaming, very poor request/response > or perhaps a more general issue > between 6.x and 7.x. nve(4) does not recognise this chip. If someone does have a bootable 6-stable .iso with a backported nfe(4) ... or email if_nfe.ko to me and I will tes under 6-stable For now I will test the patches Pyun and Luigi sent me and let you know. Best, arno From rwatson at FreeBSD.org Tue Sep 30 14:37:46 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 30 14:37:59 2008 Subject: 7.1-PRERELEASE : bad network performance (nfe0) In-Reply-To: References: <20080929043134.GD54819@cdnetworks.co.kr> Message-ID: On Tue, 30 Sep 2008, Arno J. Klaassen wrote: >>> However, the "request/respones" tests are awfull for my notebook (test >>> repeated on the notebook for the sake of conviction) : >> >> Is it possible to rerun these tests with a 7.0 kernel of the same general >> configuration? That would help us determine if it's a regression between >> 7.0 and 7.1, > > 7.0-RELEASE-p4 kernel (and 7.1 world) as well as 7.0-RELEASE life-cd give > same results : great streaming, very poor request/response Thanks for testing this -- it rules out a host of potential issues that could have been from changes in flight between 7.0 and 7.1, which is very helpful. At least for me, since I made many of those changes :-). >> or perhaps a more general issue between 6.x and 7.x. > > nve(4) does not recognise this chip. > > If someone does have a bootable 6-stable .iso with a backported nfe(4) ... > or email if_nfe.ko to me and I will tes under 6-stable > > For now I will test the patches Pyun and Luigi sent me and let you know. OK. I'll drop out of the loop on this one unless it's determined that the network stack itself is implicated rather than the drivers. Robert N M Watson Computer Laboratory University of Cambridge From ivoras at freebsd.org Tue Sep 30 20:01:45 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Sep 30 20:01:52 2008 Subject: Optimizing for high PPS, Intel NICs In-Reply-To: References: Message-ID: Ivan Voras wrote: > I've noticed something strange: the server is bottlenecked with "em1 > taskq" kernel thread taking 100% of a CPU core, while the global CPU > utilization is around 50%, but the client's em0 taskq thread for this > same load is ~~ 10% (with > 30% idle). The client CPU is a bit faster > then the server (2.4 GHz vs 2.0 GHz) but I don't think this can account > for such a big difference. Toggling TSO on the server doesn't help. I've switched the server and the client role and the behaviour is always the same - on this one machine the taskq starts using 100% of a core when pushing more than about 150,000 PPS. It's the same when testing under Linux so it looks like I need to shop for a better NIC. Can anyone recommend a good but basic (no fancy features needed) PCI-E or PCI-X NIC that's known to be able to push > 500,000 PPS? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080930/bf8a3a21/signature.pgp