From vulture at netvulture.com Mon Dec 1 00:46:50 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Mon Dec 1 00:47:02 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge Message-ID: <4933A00E.7080201@netvulture.com> Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- A non-text attachment was scrubbed... Name: dhclient_badcsum.cap Type: application/octet-stream Size: 1098 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081201/e2429cf4/dhclient_badcsum.obj From bugmaster at FreeBSD.org Mon Dec 1 03:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 1 03:08:42 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200812011106.mB1B6xBY052622@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/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/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 kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/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 197 problems total. From paulo at nlink.com.br Mon Dec 1 06:20:15 2008 From: paulo at nlink.com.br (Paulo Fragoso) Date: Mon Dec 1 06:20:24 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? Message-ID: <4933EC58.5030204@nlink.com.br> Hi, We was using one machine with FreeBSD 6.4-RELEASE running apache-worker-2.2.3 + mysql, this server can answer high request from one client using ab: {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE ... Benchmarking ***** (be patient) Completed 200 requests Completed 400 requests Completed 600 requests Completed 800 requests Completed 1000 requests Completed 1200 requests Completed 1400 requests Completed 1600 requests Completed 1800 requests Finished 2000 requests ... {client}$ Using other hardware whit FreeBSD 7.1-PRERELEASE running apache-worker-2.2.9_5 + mysql, we have a poor result: {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE ... Test aborted after 10 failures apr_connect(): Invalid argument (22) {client}$ Looking for a problem on new server log we found: kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored All sysctl and apache conf are same on both server, is there a tcp problem with FreeBSD 7.x? Paulo Fragoso. From ivoras at freebsd.org Mon Dec 1 06:40:19 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Dec 1 06:40:28 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <4933EC58.5030204@nlink.com.br> References: <4933EC58.5030204@nlink.com.br> Message-ID: Paulo Fragoso wrote: > > Using other hardware whit FreeBSD 7.1-PRERELEASE running > apache-worker-2.2.9_5 + mysql, we have a poor result: > > > {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE > ... > Test aborted after 10 failures > > apr_connect(): Invalid argument (22) > {client}$ The important thing is what operating system is used on the machine running "ab", in both cases. "ab" is known to be broken with FreeBSD so if you run "ab" on FreeBSD, you'll get various problems. -------------- 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/20081201/779ca505/signature.pgp From andre at freebsd.org Mon Dec 1 06:42:22 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon Dec 1 06:43:19 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <4933EC58.5030204@nlink.com.br> References: <4933EC58.5030204@nlink.com.br> Message-ID: <4933F7D6.50805@freebsd.org> Paulo Fragoso wrote: > Hi, > > We was using one machine with FreeBSD 6.4-RELEASE running > apache-worker-2.2.3 + mysql, this server can answer high request from > one client using ab: > > {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE > ... > Benchmarking ***** (be patient) > Completed 200 requests > Completed 400 requests > Completed 600 requests > Completed 800 requests > Completed 1000 requests > Completed 1200 requests > Completed 1400 requests > Completed 1600 requests > Completed 1800 requests > Finished 2000 requests > ... > {client}$ > > Using other hardware whit FreeBSD 7.1-PRERELEASE running > apache-worker-2.2.9_5 + mysql, we have a poor result: > > {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE > ... > Test aborted after 10 failures > > apr_connect(): Invalid argument (22) > {client}$ > > Looking for a problem on new server log we found: > > kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored This error is harmless and occurs when the client closes the socket before the TCP session has terminated. The RST have crossed and hit the syncache. The same happens on 6.4 but it never told you about it. > All sysctl and apache conf are same on both server, is there a tcp > problem with FreeBSD 7.x? Are you using the HTTP accept filter on the server? This may cause the listen accept queue to overflow. Please post the output of "netstat -n -s -p tcp" to further diagnose the problem. -- Andre From paulo at nlink.com.br Mon Dec 1 07:19:52 2008 From: paulo at nlink.com.br (Paulo Fragoso) Date: Mon Dec 1 07:19:59 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <4933F7D6.50805@freebsd.org> References: <4933EC58.5030204@nlink.com.br> <4933F7D6.50805@freebsd.org> Message-ID: <4934008C.1070303@nlink.com.br> Em 01/12/2008 11:42, Andre Oppermann escreveu: > Paulo Fragoso wrote: >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored > > This error is harmless and occurs when the client closes the socket > before the TCP session has terminated. The RST have crossed and hit > the syncache. The same happens on 6.4 but it never told you about it. Ok, but we can not understand why same solution fails using FreeBSD 7.1 and works fina with > >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? > > Are you using the HTTP accept filter on the server? This may cause > the listen accept queue to overflow. No. server-7.1# kldstat Id Refs Address Size Name 1 4 0xffffffff80100000 b302e0 kernel 2 1 0xffffffffa3391000 8eba ipfw.ko 3 1 0xffffffffa33fe000 1ea green_saver.ko server-7.1# server-6.4# kldstat Id Refs Address Size Name 1 4 0xffffffff80100000 a380f0 kernel 2 1 0xffffffff979f0000 8566 ipfw.ko 3 1 0xffffffff97a35000 1dd green_saver.ko server-6.4# > > > Please post the output of "netstat -n -s -p tcp" to further diagnose > the problem. netstat output from two servers was attached. Our tests are based on 08 ab tests, changing -n and -c parameters at client machine, starting with: ab -n 100 -c 10 http://server/path_to_cgi and finishing with: ab -n 5000 -c 1000 http://server/path_to_cgi The old server using FreeBSD-6.4 and running on worst hardware can answer all request with some errors: FreeBSD 6.4: ab -n -c ------------------------------------------------ 100 10 1000 10 (8 errors) 1000 50 (12 errors) 1000 100 (12 errors) 1000 500 (11 errors) 2000 500 (24 errors) 2000 1000 (24 errors) 5000 1000 (4997 errors) but we can not receive any answer for two last test using server-7.1 FreeBSD 7.1: ab -n -c ------------------------------------------------ 100 10 (1 error) 1000 10 (5 errors) 1000 50 (7 errors) 1000 100 (8 errors) 1000 500 (11 errors) 2000 500 (15 errors) 2000 1000 no answer 5000 1000 no answer ab return this error on test machine: -------------------------------------- Test aborted after 10 failures apr_connect(): Invalid argument (22) -------------------------------------- Is there a new limit in FreeBSD-7.1? Paulo Fragoso -------------- next part -------------- server-7.1# netstat -n -s -p tcp tcp: 75063 packets sent 31728 data packets (27702356 bytes) 2 data packets (1864 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 34657 ack-only packets (9002 delayed) 0 URG only packets 0 window probe packets 142 window update packets 8532 control packets 80919 packets received 28917 acks (for 15918245 bytes) 9425 duplicate acks 0 acks for unsent data 26168 packets (3681069 bytes) received in-sequence 893 completely duplicate packets (76110 bytes) 0 old duplicate packets 15 packets with some dup. data (1770 bytes duped) 60 out-of-order packets (86880 bytes) 10 packets (0 bytes) of data after window 0 window probes 3323 window update packets 2 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 3 connection requests 11907 connection accepts 0 bad connection attempts 618 listen queue overflows 6398 ignored RSTs in the windows 11910 connections established (including accepts) 9740 connections closed (including 3266 drops) 24 connections updated cached RTT on close 24 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 28917 segments updated rtt (of 17512 attempts) 3 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 281 correct ACK header predictions 13610 correct data packet header predictions 12526 syncache entries added 6 retransmitted 8 dupsyn 0 dropped 11907 completed 28 bucket overflow 0 cache overflow 10 reset 0 stale 618 aborted 0 badack 0 unreach 0 zone failures 12526 cookies sent 37 cookies received 1 SACK recovery episode 1 segment rexmit in SACK recovery episodes 416 byte rexmits in SACK recovery episodes 4 SACK options (SACK blocks) received 31 SACK options (SACK blocks) sent 0 SACK scoreboard overflow -------------- next part -------------- server-6.4# netstat -n -s -p tcp tcp: 419071 packets sent 357030 data packets (378965034 bytes) 26 data packets (3665 bytes) retransmitted 15 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 44767 ack-only packets (13440 delayed) 0 URG only packets 0 window probe packets 11 window update packets 17237 control packets 315358 packets received 242513 acks (for 373590012 bytes) 12703 duplicate acks 0 acks for unsent data 59283 packets (4705080 bytes) received in-sequence 7 completely duplicate packets (384 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 16 out-of-order packets (3904 bytes) 0 packets (0 bytes) of data after window 0 window probes 11056 window update packets 0 packets received after close 1 discarded for bad checksum 0 discarded for bad header offset fields 0 discarded because packet too short 4537 connection requests 13438 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 15708 connections established (including accepts) 15610 connections closed (including 2579 drops) 4556 connections updated cached RTT on close 4556 connections updated cached RTT variance on close 2 connections updated cached ssthresh on close 2265 embryonic connections dropped 241277 segments updated rtt (of 138901 attempts) 21 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 14 keepalive timeouts 14 keepalive probes sent 0 connections dropped by keepalive 31855 correct ACK header predictions 7454 correct data packet header predictions 13438 syncache entries added 17 retransmitted 0 dupsyn 0 dropped 13438 completed 34 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 13438 cookies sent 34 cookies received 7 SACK recovery episodes 7 segment rexmits in SACK recovery episodes 336 byte rexmits in SACK recovery episodes 119 SACK options (SACK blocks) received 8 SACK options (SACK blocks) sent 0 SACK scoreboard overflow From paulo at nlink.com.br Mon Dec 1 07:24:35 2008 From: paulo at nlink.com.br (Paulo Fragoso) Date: Mon Dec 1 07:24:42 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <49340061.1060100@helenius.fi> References: <4933EC58.5030204@nlink.com.br> <4933F7D6.50805@freebsd.org> <49340061.1060100@helenius.fi> Message-ID: <493401AD.90801@nlink.com.br> Our machine test have apache-2.0.61_2 running FreeBSD-6.3-RELEASE-p3, its ab program is used on all tests. Paulo. On 01/12/2008 12:18, Petri Helenius wrote: > > I couldn't get Apache 2.2 ab to work on 7.0 at all. The ab from 2.0 > worked fine... > > Pete > > > Andre Oppermann wrote: >> Paulo Fragoso wrote: >>> Hi, >>> >>> We was using one machine with FreeBSD 6.4-RELEASE running >>> apache-worker-2.2.3 + mysql, this server can answer high request >>> from one client using ab: >>> >>> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >>> ... >>> Benchmarking ***** (be patient) >>> Completed 200 requests >>> Completed 400 requests >>> Completed 600 requests >>> Completed 800 requests >>> Completed 1000 requests >>> Completed 1200 requests >>> Completed 1400 requests >>> Completed 1600 requests >>> Completed 1800 requests >>> Finished 2000 requests >>> ... >>> {client}$ >>> >>> Using other hardware whit FreeBSD 7.1-PRERELEASE running >>> apache-worker-2.2.9_5 + mysql, we have a poor result: >>> >>> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >>> ... >>> Test aborted after 10 failures >>> >>> apr_connect(): Invalid argument (22) >>> {client}$ >>> >>> Looking for a problem on new server log we found: >>> >>> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >>> syncache_chkrst: Spurious RST without matching syncache entry >>> (possibly syncookie only), segment ignored >>> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >>> syncache_chkrst: Spurious RST without matching syncache entry >>> (possibly syncookie only), segment ignored >>> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >>> syncache_chkrst: Spurious RST without matching syncache entry >>> (possibly syncookie only), segment ignored >> >> This error is harmless and occurs when the client closes the socket >> before the TCP session has terminated. The RST have crossed and hit >> the syncache. The same happens on 6.4 but it never told you about it. >> >>> All sysctl and apache conf are same on both server, is there a tcp >>> problem with FreeBSD 7.x? >> >> Are you using the HTTP accept filter on the server? This may cause >> the listen accept queue to overflow. >> >> Please post the output of "netstat -n -s -p tcp" to further diagnose >> the problem. >> > From petri at helenius.fi Mon Dec 1 07:43:12 2008 From: petri at helenius.fi (Petri Helenius) Date: Mon Dec 1 07:43:20 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <4933F7D6.50805@freebsd.org> References: <4933EC58.5030204@nlink.com.br> <4933F7D6.50805@freebsd.org> Message-ID: <49340061.1060100@helenius.fi> I couldn't get Apache 2.2 ab to work on 7.0 at all. The ab from 2.0 worked fine... Pete Andre Oppermann wrote: > Paulo Fragoso wrote: >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored > > This error is harmless and occurs when the client closes the socket > before the TCP session has terminated. The RST have crossed and hit > the syncache. The same happens on 6.4 but it never told you about it. > >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? > > Are you using the HTTP accept filter on the server? This may cause > the listen accept queue to overflow. > > Please post the output of "netstat -n -s -p tcp" to further diagnose > the problem. > From venkatvenkatsubra at yahoo.com Mon Dec 1 08:05:25 2008 From: venkatvenkatsubra at yahoo.com (Venkat Venkatsubra) Date: Mon Dec 1 08:05:32 2008 Subject: FreeBSD Window updates References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> Message-ID: <538219.92538.qm@web58307.mail.re3.yahoo.com> Hi Andre, When delayed Ack is set the window update is not sent. Does this mean when odd number of packets are received and later read, a window update won't go out either till the next segment arrives or 200 msecs delayed ack timer ? Can this reduced window block the sender from sending the next segment that we are waiting for to open up the window ? What's the purpose of the 2 MSS check by the way?? Venkat?? ________________________________ From: Andre Oppermann To: David Malone Cc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venkatsubra ; Kevin Oberman Sent: Sunday, November 30, 2008 5:18:22 PM Subject: Re: FreeBSD Window updates Andre Oppermann wrote: > David Malone wrote: >> I've got an example extract tcpdump of this at the end of the mail >> - here 6 ACKs are sent, 5 of which are pure window updates and >> several are 2us apart! >> >> I think the easy option is to delete the code that generates explicit >> window updates if the window moves by 2*MSS. We then should be doing >> something similar to Linux. The other easy alternative would be to >> add a sysclt that lets us generate an window update every N*MSS and >> by default set it to something big, like 10 or 100. That should >> effectively eliminate the updates during bulk data transfer, but >> may still generate some window updates after a loss. > > The main problem of the pure window update test in tcp_output() is > its complete ignorance of delayed ACKs.? Second is the strict 4.4BSD > adherence to sending an update for every window increase of >= 2*MSS. > The third issue of sending a slew of window updates after having > received a FIN (telling us the other end won't ever send more data) > I have already fixed some moons ago. > > In my new-tcp work I've come across the window update logic some time > ago and backchecked with relevant RFCs and other implementations. > Attached is a compiling but otherwise untested backport of the new logic. Slightly improved version attached. -- Andre From tevans.uk at googlemail.com Mon Dec 1 08:07:00 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Mon Dec 1 08:07:06 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <4933EC58.5030204@nlink.com.br> References: <4933EC58.5030204@nlink.com.br> Message-ID: <1228146079.4196.26.camel@localhost> On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote: > Hi, > > We was using one machine with FreeBSD 6.4-RELEASE running > apache-worker-2.2.3 + mysql, this server can answer high request from > one client using ab: > > > {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE > ... > Benchmarking ***** (be patient) > Completed 200 requests > Completed 400 requests > Completed 600 requests > Completed 800 requests > Completed 1000 requests > Completed 1200 requests > Completed 1400 requests > Completed 1600 requests > Completed 1800 requests > Finished 2000 requests > ... > {client}$ > > > Using other hardware whit FreeBSD 7.1-PRERELEASE running > apache-worker-2.2.9_5 + mysql, we have a poor result: > > > {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE > ... > Test aborted after 10 failures > > apr_connect(): Invalid argument (22) > {client}$ > > > Looking for a problem on new server log we found: > > kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > > All sysctl and apache conf are same on both server, is there a tcp > problem with FreeBSD 7.x? > > Paulo Fragoso. > Just to rule it out, have you tried testing using a more robust tool than ab? ab is generally disliked by the apache devs I've met. Does it still fall over using something like siege[1] or flood[2]? Cheers Tom [1] http://www.joedog.org/JoeDog/Siege [2] http://httpd.apache.org/test/flood/ From dwmalone at maths.tcd.ie Mon Dec 1 12:15:42 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Mon Dec 1 12:15:48 2008 Subject: FreeBSD Window updates In-Reply-To: Your message of "Mon, 01 Dec 2008 00:18:22 +0100." <49331F3E.2090305@freebsd.org> Message-ID: <200812012015.aa21449@walton.maths.tcd.ie> Hi Andre, > Slightly improved version attached. I like the idea of checking if the change is about 1 when scaled by the window scaling factor. It might even be better to check if the new window would look better when scaled down, because these aren't exactly the same. Especially when the window is small. > + * If the receive socket buffer has less than 1/4 of space > + * available and if the difference is at least two max size > + * segments, send an immediate window update to peer. I'm worried that this might leave us still being too aggressive in sending these updates. The "change by a factor of two" check might be - it will send lots of updates if the window is small (and at risk of closing) but won't send frequent pure updates if the window is big. This shouldn't be a problem because if the window is big then either: 1) there's lots of data in flight, which will naturally generate ACKs to keep the sender updated or 2) there's not much data in flight, in which case the window should be in no danger of getting too small. If we keep a rule like this, it might be better to make the limit >= 3*MSS, rather than >= 2*MSS, as I think this will tend to piggy back updates on the delayed ACK naturally (though I haven't tested this). > + * Otherwise if the difference is 1/8 (or more) of the receive > + * socket buffer, or at least 1/2 of the maximum possible window, > + * then we send a window update too. What's the motivation here? David. From paulo at nlink.com.br Mon Dec 1 12:25:55 2008 From: paulo at nlink.com.br (Paulo Fragoso) Date: Mon Dec 1 12:26:01 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: <1228146079.4196.26.camel@localhost> References: <4933EC58.5030204@nlink.com.br> <1228146079.4196.26.camel@localhost> Message-ID: <4934484F.2020104@nlink.com.br> On 01/12/2008 12:41, Tom Evans wrote: > On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote: > >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? >> >> Paulo Fragoso. >> >> > > Just to rule it out, have you tried testing using a more robust tool > than ab? ab is generally disliked by the apache devs I've met. Does it > still fall over using something like siege[1] or flood[2]? > > Cheers > > Tom > > [1] http://www.joedog.org/JoeDog/Siege > [2] http://httpd.apache.org/test/flood/ > > > We have tried siege because similar to ab configuration, but we have problem to repeat our ab tests: client$ siege -b -r1000 -c10 http://system_using_7.1-PRERELEASE HTTP/1.1 200 0.05 secs: 1948 bytes ==> /cgi-bin/path_to_program HTTP/1.1 200 0.04 secs: 1948 bytes ==> /cgi-bin/path_to_program HTTP/1.1 200 0.05 secs: 1948 bytes ==> /cgi-bin/path_to_program Segmentation fault: 11 (core dumped) same problem is happening trying old url: http://system_using_6.4-RELEASE. Have you had some advice? We are using ab since 2004 to make a historical reference for our tests for different hardware and systems. Why using same hardware to run ab we can test one server running 6.4-RELEASE but fails to teste 7.1-PRERELEASE? New way to answer request in 7.1 can crash ab at another machine? We are suspecting there is a new limit in 7.x which not clear for us yet. Paulo. From andre at freebsd.org Mon Dec 1 13:11:36 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon Dec 1 13:11:43 2008 Subject: FreeBSD Window updates In-Reply-To: <538219.92538.qm@web58307.mail.re3.yahoo.com> References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> <538219.92538.qm@web58307.mail.re3.yahoo.com> Message-ID: <4934530F.20104@freebsd.org> Venkat Venkatsubra wrote: > Hi Andre, > > When delayed Ack is set the window update is not sent. > Does this mean when odd number of packets are received and later read, > a window update won't go out either till the next segment arrives or > 200 msecs delayed ack timer ? Can this reduced window block the sender from > sending the next segment that we are waiting for to open up the window ? Yes. The very idea of delayed ACK is to reduce the network utilization by ACKing only every other segment. Window updates should not override this as they currently do. Nagle comes into plays as well where we wait for the application to write something within the delayed ACK timeout to piggyback the answer together with the ACK (and window update). To answer your question: I do think we are fine with waiting for the delayed ACK. If an application starts to seriously lag behind like in your example the feedback mechanism should work and cause the sender to slow down too. The feedback loop in TCP is not only the network but also the sending and receiving application. In a normal bulk transfer where the receiving application services the receive buffer in regular intervals we update the window with every ACK. I'm open to other ideas if they fix the problem David is seeing without having more serious shortcomings. > What's the purpose of the 2 MSS check by the way ? This is part of the Silly Window Syndrome prevention. A good description is here: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm PS: Attached is an updated version of the patch. The flag TF_DELACK can't be used to test for the presence of a delayed ACK. The presence of the delack timer has to be tested. -- Andre > Venkat > > > > > ________________________________ > From: Andre Oppermann > To: David Malone > Cc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venkatsubra ; Kevin Oberman > Sent: Sunday, November 30, 2008 5:18:22 PM > Subject: Re: FreeBSD Window updates > > Andre Oppermann wrote: >> David Malone wrote: >>> I've got an example extract tcpdump of this at the end of the mail >>> - here 6 ACKs are sent, 5 of which are pure window updates and >>> several are 2us apart! >>> >>> I think the easy option is to delete the code that generates explicit >>> window updates if the window moves by 2*MSS. We then should be doing >>> something similar to Linux. The other easy alternative would be to >>> add a sysclt that lets us generate an window update every N*MSS and >>> by default set it to something big, like 10 or 100. That should >>> effectively eliminate the updates during bulk data transfer, but >>> may still generate some window updates after a loss. >> The main problem of the pure window update test in tcp_output() is >> its complete ignorance of delayed ACKs. Second is the strict 4.4BSD >> adherence to sending an update for every window increase of >= 2*MSS. >> The third issue of sending a slew of window updates after having >> received a FIN (telling us the other end won't ever send more data) >> I have already fixed some moons ago. >> >> In my new-tcp work I've come across the window update logic some time >> ago and backchecked with relevant RFCs and other implementations. >> Attached is a compiling but otherwise untested backport of the new logic. > > Slightly improved version attached. > -------------- next part -------------- Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 1 Dec 2008 21:06:28 -0000 @@ -539,29 +539,59 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds when the: + * - next segment arrives we have to ack immediately; + * - application sends some data back to the peer; + * - delayed ACK timer expires. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ - if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && - !TCPS_HAVERCVDFIN(tp->t_state)) { + if (recwin > 0 && !tcp_timer_active(tp, TT_DELACK) && + !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { /* * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* From jhb at freebsd.org Mon Dec 1 13:43:45 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Dec 1 13:43:57 2008 Subject: Gathering Hardware State During a Driver Initiated Kernel Panic In-Reply-To: <492B2306.60404@freebsd.org> References: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> <492B2306.60404@freebsd.org> Message-ID: <200812011505.56535.jhb@freebsd.org> On Monday 24 November 2008 04:56:22 pm Sam Leffler wrote: > David Christensen wrote: > > Is there a method or callback in FreeBSD where a driver can > > be notified that it has caused a kernel panic in order to > > generate a dump of internal hardware state information? I've > > written a sysctl call for manual intervention and can handle > > some "expected" hardware events completely in the driver but > > I don't know of a way to get control again in cases where the > > driver wasn't expecting a failure. > > > > Not sure how one can deduce a driver is at fault but you might define a > ddb command for the driver and invoke that on panic using the ddb script > mechanisms (see ddb(4)). You might be able to set the current 'panic' ddb script function to one you define in your code somehow. That is, set it on entry to bce_start() and then reset it to empty when bce_start() returns. Similarly for the interrupt handler, bce_init(), and bce_ioctl(). I haven't looked to see if there is a clean way to set a script function in C though. -- John Baldwin From venkatvenkatsubra at yahoo.com Mon Dec 1 13:53:41 2008 From: venkatvenkatsubra at yahoo.com (Venkat Venkatsubra) Date: Mon Dec 1 13:53:48 2008 Subject: FreeBSD Window updates References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> <538219.92538.qm@web58307.mail.re3.yahoo.com> <4934530F.20104@freebsd.org> Message-ID: <624505.9242.qm@web58307.mail.re3.yahoo.com> Hi Andre, >To answer your question: I do think we are fine with waiting for the >delayed ACK.? If an application starts to seriously lag behind like >in your example the feedback mechanism should work and cause the sender >to slow down too.? The feedback loop in TCP is not only the network but The case I was thinking was not apps lagging behind on the read. The incoming packets got ahead and got dumped on the socket receive buffer before the app's blocked read could get scheduled by the OS and start reading the data. I am assuming the read needs the socket lock and it has to contend for this lock with the incoming packets. The stack may not have any control over when the read eventually gets to run. Suppose it runs after the 13th incoming packet got copied to the socket buffer? and the window size is 13 MSS ? >?> What's the purpose of the 2 MSS check by the way ? >This is part of the Silly Window Syndrome prevention.? A good description is here: Even without the 2 MSS check you are going to prevent SWS, isn't that right ? The other checks will make sure small window updates are not sent. Venkat ________________________________ From: Andre Oppermann To: Venkat Venkatsubra Cc: David Malone ; Rui Paulo ; Kevin Oberman ; freebsd-net@freebsd.org Sent: Monday, December 1, 2008 3:11:43 PM Subject: Re: FreeBSD Window updates Venkat Venkatsubra wrote: > Hi Andre, > > When delayed Ack is set the window update is not sent. > Does this mean when odd number of packets are received and later read, > a window update won't go out either till the next segment arrives or > 200 msecs delayed ack timer ? Can this reduced window block the sender from > sending the next segment that we are waiting for to open up the window ? Yes.? The very idea of delayed ACK is to reduce the network utilization by ACKing only every other segment.? Window updates should not override this as they currently do.? Nagle comes into plays as well where we wait for the application to write something within the delayed ACK timeout to piggyback the answer together with the ACK (and window update). To answer your question: I do think we are fine with waiting for the delayed ACK.? If an application starts to seriously lag behind like in your example the feedback mechanism should work and cause the sender to slow down too.? The feedback loop in TCP is not only the network but also the sending and receiving application.? In a normal bulk transfer where the receiving application services the receive buffer in regular intervals we update the window with every ACK. I'm open to other ideas if they fix the problem David is seeing without having more serious shortcomings. > What's the purpose of the 2 MSS check by the way ? This is part of the Silly Window Syndrome prevention.? A good description is here: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm PS: Attached is an updated version of the patch.? The flag TF_DELACK can't be used to test for the presence of a delayed ACK.? The presence of the delack timer has to be tested. -- Andre > Venkat? > > > > ________________________________ > From: Andre Oppermann > To: David Malone > Cc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venkatsubra ; Kevin Oberman > Sent: Sunday, November 30, 2008 5:18:22 PM > Subject: Re: FreeBSD Window updates > > Andre Oppermann wrote: >> David Malone wrote: >>> I've got an example extract tcpdump of this at the end of the mail >>> - here 6 ACKs are sent, 5 of which are pure window updates and >>> several are 2us apart! >>> >>> I think the easy option is to delete the code that generates explicit >>> window updates if the window moves by 2*MSS. We then should be doing >>> something similar to Linux. The other easy alternative would be to >>> add a sysclt that lets us generate an window update every N*MSS and >>> by default set it to something big, like 10 or 100. That should >>> effectively eliminate the updates during bulk data transfer, but >>> may still generate some window updates after a loss. >> The main problem of the pure window update test in tcp_output() is >> its complete ignorance of delayed ACKs.? Second is the strict 4.4BSD >> adherence to sending an update for every window increase of >= 2*MSS. >> The third issue of sending a slew of window updates after having >> received a FIN (telling us the other end won't ever send more data) >> I have already fixed some moons ago. >> >> In my new-tcp work I've come across the window update logic some time >> ago and backchecked with relevant RFCs and other implementations. >> Attached is a compiling but otherwise untested backport of the new logic. > > Slightly improved version attached. > From linimon at FreeBSD.org Mon Dec 1 14:53:53 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Dec 1 14:53:59 2008 Subject: kern/129352: [xl] [patch] xl0 watchdog timeout Message-ID: <200812012253.mB1MrqAe095381@freefall.freebsd.org> Old Synopsis: xl0 watchdog timeout New Synopsis: [xl] [patch] xl0 watchdog timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 1 22:53:23 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 From citrin at citrin.ru Mon Dec 1 15:10:06 2008 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon Dec 1 15:10:16 2008 Subject: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 Message-ID: <200812012310.mB1NA30h002607@freefall.freebsd.org> The following reply was made to PR kern/122743; it has been noted by GNATS. From: Anton Yuzhaninov To: bug-followup@FreeBSD.org, okor@zone.salut.ru Cc: Subject: Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 Date: Tue, 02 Dec 2008 02:00:40 +0300 It looks like similar to this: http://docs.freebsd.org/cgi/mid.cgi?492B2F46.9000709 Try to change type for wire_count in struct vm_page from u_short to u_int (on i386 it has some overhead - sizeof(vm_page) increased by 4 bytes). -- Anton Yuzhaninov From andrewwtulloch at gmail.com Mon Dec 1 16:50:08 2008 From: andrewwtulloch at gmail.com (Andrew) Date: Mon Dec 1 16:50:15 2008 Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 In-Reply-To: <20081201043218.GB1082@cdnetworks.co.kr> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> <20081201043218.GB1082@cdnetworks.co.kr> Message-ID: <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> 2008/12/1 Pyun YongHyeon : > On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > following when the re driver attempts to attach to the two onboard > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > re0: > Ethernet> port 0x9e00-0x9eff mem > > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > pci8 > > re0: Chip rev. 0x28000000 > > re0: MAC rev. 0x00100000 > > re0: Unknown H/W revision: 0x28000000 > > device_attach: re0 attach returned 6 > > pcib9: irq 17 at device 28.5 on pci0 > > pci9: on pcib9 > > re1: > Ethernet> port 0x8e00-0x8eff mem > > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > pci9 > > re1: Chip rev. 0x28000000 > > re1: MAC rev. 0x00100000 > > re1: Unknown H/W revision: 0x28000000 > > device_attach: re1 attach returned 6 > > > > pciconf -lvc extract: > > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit 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 4 messages in map 0x20 > > cap 03[cc] = VPD > > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit 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 4 messages in map 0x20 > > cap 03[cc] = VPD > > > > > > Is there any simple patch I can apply to get the driver to attach, > > assuming it should work? > > > > This controller seems to support MSI-X with 4 messages. > Unfortunately previous PCIe controllers from RealTek were notorious > for MSI issues so it's hard to know this revision really works with > MSI-X. I guess it was added to support RSS(receive-side scaling of > MS NDIS 6.0). > As sephe said if the controller configuration is the same as 8168C > family, the attached patch would make re(4) work as expected. > > -- > Regards, > Pyun YongHyeon > Pyun, I applied the patch, but it didn't attach initially, I added an extra entry to re_hwrevs as that seemed to be what was missing and it attached and seems to function (as far as a quick ping test and make update). Changes I made to if_re.c attached. If you have anything to try for MSI-X I can probably test those. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: re.patch Type: application/octet-stream Size: 990 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081202/b71ca266/re.obj From pyunyh at gmail.com Mon Dec 1 17:04:43 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Dec 1 17:04:50 2008 Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 In-Reply-To: <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> <20081201043218.GB1082@cdnetworks.co.kr> <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> Message-ID: <20081202010431.GA5306@cdnetworks.co.kr> On Tue, Dec 02, 2008 at 12:50:07AM +0000, Andrew wrote: > 2008/12/1 Pyun YongHyeon : > > On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > > following when the re driver attempts to attach to the two onboard > > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > > > re0: > > Ethernet> port 0x9e00-0x9eff mem > > > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > > pci8 > > > re0: Chip rev. 0x28000000 > > > re0: MAC rev. 0x00100000 > > > re0: Unknown H/W revision: 0x28000000 > > > device_attach: re0 attach returned 6 > > > pcib9: irq 17 at device 28.5 on pci0 > > > pci9: on pcib9 > > > re1: > > Ethernet> port 0x8e00-0x8eff mem > > > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > > pci9 > > > re1: Chip rev. 0x28000000 > > > re1: MAC rev. 0x00100000 > > > re1: Unknown H/W revision: 0x28000000 > > > device_attach: re1 attach returned 6 > > > > > > pciconf -lvc extract: > > > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit 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 4 messages in map 0x20 > > > cap 03[cc] = VPD > > > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit 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 4 messages in map 0x20 > > > cap 03[cc] = VPD > > > > > > > > > Is there any simple patch I can apply to get the driver to attach, > > > assuming it should work? > > > > > > > This controller seems to support MSI-X with 4 messages. > > Unfortunately previous PCIe controllers from RealTek were notorious > > for MSI issues so it's hard to know this revision really works with > > MSI-X. I guess it was added to support RSS(receive-side scaling of > > MS NDIS 6.0). > > As sephe said if the controller configuration is the same as 8168C > > family, the attached patch would make re(4) work as expected. > > > > -- > > Regards, > > Pyun YongHyeon > > > > Pyun, > I applied the patch, but it didn't attach initially, I added an extra > entry to re_hwrevs as that seemed to be what was missing and it > attached and seems to function (as far as a quick ping test and make > update). Changes I made to if_re.c attached. If you have anything to > try for MSI-X I can probably test those. > You're right. I've missed to update revision entry. :-) I guess MSI-X requires a documentation from RealTek as it may have to map interrupt source to MSI-X vectors. It may also need to map PBA to MSI-X work on 8168D. Would you show me dmesg output of re(4)? Thanks for the patch and testing! -- Regards, Pyun YongHyeon From jiabwang at redhat.com Mon Dec 1 18:20:25 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Mon Dec 1 18:20:31 2008 Subject: [ipsec]could you help me explain where problem is for aes-ctr of ESP Message-ID: <49349B93.40208@redhat.com> Hello, all: following is my setkey configration. I can get SAD and SPD. but when I run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must be multiple of 16 kernel: decrypt fail in IPv6 ESP input : SA(SPI 8192 src=3ffe:0501:ffff:0103:020a:ebff:fe85:9e56 dst=3ffe:0501:ffff:0104:021d:0fff:fe19:59fc) but when I use "ping6 -I rl0 -s 4(or 6 or 20) 3ffe:501:ffff:103:20a:ebff:fe85:9e56" that the report disappear. I read RFC, did not find the explain. could you give me a explain? Thanks on RedHat (ipsec-tools 0.6.5) #!/sbin/setkey -f flush; spdflush; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x1000 -m transport -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 any -P in ipsec esp/transport//require; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x2000 -m transport -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc any -P out ipsec esp/transport//require; on FreeBSD6.3(ipsec-tools 0.7, using 0.6.6, problem keep still ) flush; spdflush; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x2000 -m transport -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc any -P in ipsec esp/transport//require; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x1000 -m transport -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 any -P out ipsec esp/transport//require; From jiabwang at redhat.com Mon Dec 1 18:22:13 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Mon Dec 1 18:22:20 2008 Subject: [ipsec] why did not freebsd6.3 support icmp6 echo request on tunnel mode ? it is ok on transport mode. Message-ID: <49349C00.5080902@redhat.com> Hello, all: the following configuration is my setkey info. when I run " setkey -f filename", system report "the result of line 4 :Invalid argument. the result of line 6 : Invalid argument." change "icmp6 128,0" to "icmp6 or any" , that is no problem . or change "tunnel" to "transport" , that is no problem. I do not know why , but the following configuration is no problem on RHEL5.2 that FreeBSD6.3 need patch ? could you give me explain Thank you very much flush; spdflush; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x2000 -m tunnel -E 3des-cbc "ipv6readylogo3des1to2req" -A hmac-sha1 ?ipv6readysha11to2req?; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc icmp6 128,0 -P in ipsec esp/tunnel/3ffe:501:ffff:103:20a:ebff:fe85:9e56-3ffe:501:ffff:104:21d:fff:fe19:59fc/require; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x1000 -m tunnel -E 3des-cbc "ipv6readylogo3des2to1req" -A hmac-sha1 ?ipv6readysha12to1req?; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 icmp6 128,0 -P out ipsec esp/tunnel/3ffe:501:ffff:104:21d:fff:fe19:59fc-3ffe:501:ffff:103:20a:ebff:fe85:9e56/require; From jiabwang at redhat.com Mon Dec 1 18:31:23 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Mon Dec 1 18:31:31 2008 Subject: [ipsec] aes-ctr question Message-ID: <49349E26.30002@redhat.com> Hello, all: following is my setkey configration. I can get SAD and SPD. but when I run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must be multiple of 16 kernel: decrypt fail in IPv6 ESP input : SA(SPI 8192 src=3ffe:0501:ffff:0103:020a:ebff:fe85:9e56 dst=3ffe:0501:ffff:0104:021d:0fff:fe19:59fc) but when I use "ping6 -I rl0 -s 11(or 12 or 13 or 14) 3ffe:501:ffff:103:20a:ebff:fe85:9e56" that the ping pass. I read RFC, did not find the explain. could you give me a explain? Thanks flush; spdflush; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc any -P in ipsec esp/tunnel/3ffe:501:ffff:103:20a:ebff:fe85:9e56-3ffe:501:ffff:104:21d:fff:fe19:59fc/require; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x2000 -m tunnel -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 any -P out ipsec esp/tunnel/3ffe:501:ffff:104:21d:fff:fe19:59fc-3ffe:501:ffff:103:20a:ebff:fe85:9e56/require; From vulture at netvulture.com Mon Dec 1 21:27:12 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Mon Dec 1 21:27:25 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <4933A00E.7080201@netvulture.com> References: <4933A00E.7080201@netvulture.com> Message-ID: <4934C733.4020506@netvulture.com> Can someone please confirm or rule out my issue with dhclient sending bad IP checksum packets. It would really suck if 7.1 was released with a broken DHCP client. Jonathan Feally wrote: > Sorry for the cross-post, but this could be either lists problem. > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from > make world. > > The server is refusing to answer the DISCOVER request, as it thinks > the IP checksum is wrong, which tcpdump also confirms. Other DHCP > clients are working fine on this network, so I do not believe it to be > the network, server or dhcpd. > > Server is running a 2 Port Intel card - em driver. > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > I have tried turning off both RXCSUM and TXCSUM on both the client and > server machines with no luck. I also tried the second NIC on the > server with the same result. > > This setup was working just a couple of weeks ago, and the only thing > that has changed is updating the src for a make world. PXE booting > this server does result in an IP being issued, so it is pointing > towards something new/changed in 7-STABLE. > > I have attached a 3 packet dump of the DISCOVER requests. > > Can anybody shed some light on this for me? > > Thanks, -Jon > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From doconnor at gsoft.com.au Mon Dec 1 22:53:41 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Dec 1 22:53:48 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <4934C733.4020506@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Message-ID: <200812021703.44935.doconnor@gsoft.com.au> On Tuesday 02 December 2008 15:57:15 Jonathan Feally wrote: > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. I had 7.1-PRE (early Octover) send out DHCP requests without issue, although I don't have that system available now. It was using em card. I have a 7.0-STABLE system with an sk card from July that does DHCP requests just fine too.. I don't have any bge systems running 7 to test with though sorry.. Does it always give dud packets or just DHCP? Can you try another card in the client? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081202/93b9145d/attachment.pgp From paulo at nlink.com.br Tue Dec 2 03:25:20 2008 From: paulo at nlink.com.br (Paulo Fragoso) Date: Tue Dec 2 03:25:28 2008 Subject: FreeBSD 7.1 tcp problem (syncache)? In-Reply-To: References: <4933EC58.5030204@nlink.com.br> Message-ID: <49351B19.4030507@nlink.com.br> Em 01/12/2008 11:40, Ivan Voras escreveu: > Paulo Fragoso wrote: > > >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> > > > The important thing is what operating system is used on the machine > running "ab", in both cases. "ab" is known to be broken with FreeBSD so > if you run "ab" on FreeBSD, you'll get various problems. > client$ uname -a FreeBSD client 6.3-RELEASE-p3 FreeBSD 6.3-RELEASE-p3 #10: Wed Aug 20 10:45:00 BRT 2008 paulo@client:/usr/obj/usr/src/sys/KERNEL1 i386 Paulo. From vlad at prokk.net Tue Dec 2 04:44:07 2008 From: vlad at prokk.net (Vladimir V. Kobal) Date: Tue Dec 2 04:44:32 2008 Subject: Multiple netgraph threads Message-ID: <001401c95476$67aec1b0$370c4510$@net> Hello, I'm interested in the information of further development of Subject. I have a bottleneck: swi_net limited by one CPU core time. There was a thread http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html . Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not available :(. Could somebody mail it to me. Are there any other similar patches? Best regards, Vladimir Kobal From brooks at freebsd.org Tue Dec 2 07:45:06 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Dec 2 07:45:12 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge In-Reply-To: <4933A00E.7080201@netvulture.com> References: <4933A00E.7080201@netvulture.com> Message-ID: <20081202154550.GA91152@lor.one-eyed-alien.net> On Mon, Dec 01, 2008 at 12:27:58AM -0800, Jonathan Feally wrote: > Sorry for the cross-post, but this could be either lists problem. > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make > world. > > The server is refusing to answer the DISCOVER request, as it thinks the IP > checksum is wrong, which tcpdump also confirms. Other DHCP clients are > working fine on this network, so I do not believe it to be the network, > server or dhcpd. > > Server is running a 2 Port Intel card - em driver. > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > I have tried turning off both RXCSUM and TXCSUM on both the client and > server machines with no luck. I also tried the second NIC on the server > with the same result. > > This setup was working just a couple of weeks ago, and the only thing that > has changed is updating the src for a make world. PXE booting this server > does result in an IP being issued, so it is pointing towards something > new/changed in 7-STABLE. > > I have attached a 3 packet dump of the DISCOVER requests. > > Can anybody shed some light on this for me? Where are you running tcpdump? If on the host with the bge0 device, the checksums are probably useless due to checksum offloading. They should be valid on the server end of things. You might try disabling checksum offloading on the nic and see if that changes the results. It's possible the change to bpf.c to send packets through a socket when reassociateing isn't working correctly in that case. You might try backing out this change and seeing if the problem goes away (this will cause problems on some networks). http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?revision=178675&view=markup -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081202/64aa3bba/attachment.pgp From danny at cs.huji.ac.il Tue Dec 2 08:27:40 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Dec 2 08:27:46 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <4934C733.4020506@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Message-ID: > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. > I've had many problems lately, but none involved checksum nor the dhcpd (btw, I assume that you are seeing bad checksum on the receiving server) could you add a nic to your PE1750? danny > Jonathan Feally wrote: > > Sorry for the cross-post, but this could be either lists problem. > > > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from > > make world. > > > > The server is refusing to answer the DISCOVER request, as it thinks > > the IP checksum is wrong, which tcpdump also confirms. Other DHCP > > clients are working fine on this network, so I do not believe it to be > > the network, server or dhcpd. > > > > Server is running a 2 Port Intel card - em driver. > > > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > > > I have tried turning off both RXCSUM and TXCSUM on both the client and > > server machines with no luck. I also tried the second NIC on the > > server with the same result. > > > > This setup was working just a couple of weeks ago, and the only thing > > that has changed is updating the src for a make world. PXE booting > > this server does result in an IP being issued, so it is pointing > > towards something new/changed in 7-STABLE. > > > > I have attached a 3 packet dump of the DISCOVER requests. > > > > Can anybody shed some light on this for me? > > > > Thanks, -Jon > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > 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 vulture at netvulture.com Tue Dec 2 09:40:53 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 09:41:05 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Message-ID: <49357329.9000107@netvulture.com> I will try another em card in that server to confirm/rule out the nic driver. I am seeing the same checksum number on both the source machine, the dhcp server machine, and a 3rd windows xp machine sniffing the traffic with etherreal/wireshark. The windows xp box is running an intel nic as well, and those 0.0.0.0.67 -> 255.255.255.255.68 packets as seen by the server do have the correct checksum. After the nic test, if no change from one driver to the other, then I'll try to un-patch the bpf.c change. At this point it is acting like the checksum offloading (which I did disable on both the client and server) just isn't working. Will let you know. -Jon Danny Braniss wrote: >> Can someone please confirm or rule out my issue with dhclient sending >> bad IP checksum packets. It would really suck if 7.1 was released with a >> broken DHCP client. >> >> > I've had many problems lately, but none involved checksum nor the dhcpd > (btw, I assume that you are seeing bad checksum on the receiving server) > could you add a nic to your PE1750? > > danny > > > >> Jonathan Feally wrote: >> >>> Sorry for the cross-post, but this could be either lists problem. >>> >>> I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is >>> running ISC DHCPD 3.0.x from recent ports, and the other dhclient from >>> make world. >>> >>> The server is refusing to answer the DISCOVER request, as it thinks >>> the IP checksum is wrong, which tcpdump also confirms. Other DHCP >>> clients are working fine on this network, so I do not believe it to be >>> the network, server or dhcpd. >>> >>> Server is running a 2 Port Intel card - em driver. >>> >>> Client is a Dell PE1750 with 2 onboard NIC's - bge driver. >>> >>> I have tried turning off both RXCSUM and TXCSUM on both the client and >>> server machines with no luck. I also tried the second NIC on the >>> server with the same result. >>> >>> This setup was working just a couple of weeks ago, and the only thing >>> that has changed is updating the src for a make world. PXE booting >>> this server does result in an IP being issued, so it is pointing >>> towards something new/changed in 7-STABLE. >>> >>> I have attached a 3 packet dump of the DISCOVER requests. >>> >>> Can anybody shed some light on this for me? >>> >>> Thanks, -Jon >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vulture at netvulture.com Tue Dec 2 11:09:04 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 11:09:17 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) In-Reply-To: <49357329.9000107@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> Message-ID: <493587D4.5000400@netvulture.com> Jonathan Feally wrote: > I will try another em card in that server to confirm/rule out the nic > driver. I am seeing the same checksum number on both the source > machine, the dhcp server machine, and a 3rd windows xp machine > sniffing the traffic with etherreal/wireshark. The windows xp box is > running an intel nic as well, and those 0.0.0.0.67 -> > 255.255.255.255.68 packets as seen by the server do have the correct > checksum. After the nic test, if no change from one driver to the > other, then I'll try to un-patch the bpf.c change. > > At this point it is acting like the checksum offloading (which I did > disable on both the client and server) just isn't working. > > Will let you know. > > -Jon > > Danny Braniss wrote: Tried a add-in em0 card - intel pro/1000 XT server card - 82544E chip - no change. also tried with ifconfig em0 -rxcsum ifconfig em0 -txcsum dhclient em0 No change. Packets still received with bad IP checksum. Went back to bge0 now and reversed rev 178675 back to 172506 care of patch via http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?r1=172506&r2=178675&view=patch Also no change. So this change to dhclient doesn't seem to be the issue. >From looking at http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/ this patch I took out is 7 months old, and I had this system running on 7-STABLE just fine about as of about 2-3 weeks ago. So it must have been something else in the sys/net or sys/netinet. I do seem some changes that are 3 weeks old, 4 weeks, and 6 days for these directories on files that would effect the packet assembly. Authors are julian, rwatson, and bz. I'm going to look through these recent changes to try to find some that has to do with the checksum process. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From andrew at flarn.com Tue Dec 2 12:05:13 2008 From: andrew at flarn.com (Andrew Tulloch) Date: Tue Dec 2 12:05:21 2008 Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 In-Reply-To: <20081202010431.GA5306@cdnetworks.co.kr> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> <20081201043218.GB1082@cdnetworks.co.kr> <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> <20081202010431.GA5306@cdnetworks.co.kr> Message-ID: <54854a7a0812021205p5fc84511i4a596716f291d1a4@mail.gmail.com> 2008/12/2 Pyun YongHyeon : > On Tue, Dec 02, 2008 at 12:50:07AM +0000, Andrew wrote: > > 2008/12/1 Pyun YongHyeon : > > > On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > > > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > > > following when the re driver attempts to attach to the two onboard > > > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > > > > > re0: > > > Ethernet> port 0x9e00-0x9eff mem > > > > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > > > pci8 > > > > re0: Chip rev. 0x28000000 > > > > re0: MAC rev. 0x00100000 > > > > re0: Unknown H/W revision: 0x28000000 > > > > device_attach: re0 attach returned 6 > > > > pcib9: irq 17 at device 28.5 on pci0 > > > > pci9: on pcib9 > > > > re1: > > > Ethernet> port 0x8e00-0x8eff mem > > > > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > > > pci9 > > > > re1: Chip rev. 0x28000000 > > > > re1: MAC rev. 0x00100000 > > > > re1: Unknown H/W revision: 0x28000000 > > > > device_attach: re1 attach returned 6 > > > > > > > > pciconf -lvc extract: > > > > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > > vendor = 'Realtek Semiconductor' > > > > device = 'RTL8168/8111 PCI-E Gigabit 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 4 messages in map 0x20 > > > > cap 03[cc] = VPD > > > > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > > vendor = 'Realtek Semiconductor' > > > > device = 'RTL8168/8111 PCI-E Gigabit 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 4 messages in map 0x20 > > > > cap 03[cc] = VPD > > > > > > > > > > > > Is there any simple patch I can apply to get the driver to attach, > > > > assuming it should work? > > > > > > > > > > This controller seems to support MSI-X with 4 messages. > > > Unfortunately previous PCIe controllers from RealTek were notorious > > > for MSI issues so it's hard to know this revision really works with > > > MSI-X. I guess it was added to support RSS(receive-side scaling of > > > MS NDIS 6.0). > > > As sephe said if the controller configuration is the same as 8168C > > > family, the attached patch would make re(4) work as expected. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > > > > Pyun, > > I applied the patch, but it didn't attach initially, I added an extra > > entry to re_hwrevs as that seemed to be what was missing and it > > attached and seems to function (as far as a quick ping test and make > > update). Changes I made to if_re.c attached. If you have anything to > > try for MSI-X I can probably test those. > > > > You're right. I've missed to update revision entry. :-) > > I guess MSI-X requires a documentation from RealTek as it may have > to map interrupt source to MSI-X vectors. It may also need to map > PBA to MSI-X work on 8168D. Would you show me dmesg output of > re(4)? > > Thanks for the patch and testing! Pyun, Full dmesg from boot -v attached. Thanks, Andrew -------------- next part -------------- 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-BETA2 #1: Tue Dec 2 00:16:48 GMT 2008 root@:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80c4c000. Calibrating clock(s) ... i8254 clock: 1193202 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2698773787 Hz CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2698.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 Features=0xbfebfbff Features2=0x98e3bd,,> AMD Features=0x28100800 AMD Features2=0x1 Cores per package: 8 Logical CPUs per core: 2 usable memory = 3205701632 (3057 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000d49000 - 0x00000000ba397fff, 3110400000 bytes (759375 pages) avail memory = 3099422720 (2955 MB) ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 7 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 6 APIC: CPU 4 has ACPI ID 2 APIC: CPU 5 has ACPI ID 5 APIC: CPU 6 has ACPI ID 1 APIC: CPU 7 has ACPI ID 4 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu 1 ULE: adding cpu 1 to group 0: cpus 2 mask 0x3 ULE: setup cpu group 1 ULE: setup cpu 2 ULE: adding cpu 2 to group 1: cpus 1 mask 0x4 ULE: setup cpu 3 ULE: adding cpu 3 to group 1: cpus 2 mask 0xC ULE: setup cpu group 2 ULE: setup cpu 4 ULE: adding cpu 4 to group 2: cpus 1 mask 0x10 ULE: setup cpu 5 ULE: adding cpu 5 to group 2: cpus 2 mask 0x30 ULE: setup cpu group 3 ULE: setup cpu 6 ULE: adding cpu 6 to group 3: cpus 1 mask 0x40 ULE: setup cpu 7 ULE: adding cpu 7 to group 3: cpus 2 mask 0xC0 ACPI: RSDP @ 0x0xf7710/0x0014 (v 0 GBT ) ACPI: RSDT @ 0x0xbfee2040/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: FACP @ 0x0xbfee20c0/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: DSDT @ 0x0xbfee2180/0x4919 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x0100000C) ACPI: FACS @ 0x0xbfee0000/0x0040 ACPI: EUDS @ 0x0xbfee6cc0/0x0470 (v 1 GBT 0x00000000 0x00000000) ACPI: MCFG @ 0x0xbfee6c80/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: APIC @ 0x0xbfee6b00/0x00BC (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: SSDT @ 0x0xbfee7140/0x1EBC (v 1 INTEL PPM RCM 0x80000001 INTL 0x20061109) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic6: Routing NMI -> LINT1 lapic6: LINT1 trigger: edge lapic6: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic7: Routing NMI -> LINT1 lapic7: LINT1 trigger: edge lapic7: LINT1 polarity: high lapic5: Routing NMI -> LINT1 lapic5: LINT1 trigger: edge lapic5: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ath_rate: version 1.2 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Dec 2 2008 00:16:43) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIRQ -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PX40.PIR2 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bfde0000 (3) failed ACPI timer: 1/1 1/1 1/2 1/2 1/0 1/2 1/0 1/1 1/1 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 7 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 4 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3405, revid=0x12 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks pcib0: matched entry for 0.0.INTA pcib0: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3408, revid=0x12 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x340a, revid=0x12 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x340c, revid=0x12 domain=0, bus=0, slot=5, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks pcib0: matched entry for 0.5.INTA pcib0: slot 5 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x340e, revid=0x12 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3410, revid=0x12 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3425, revid=0x12 domain=0, bus=0, slot=16, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3426, revid=0x12 domain=0, bus=0, slot=16, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3427, revid=0x12 domain=0, bus=0, slot=17, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3428, revid=0x12 domain=0, bus=0, slot=17, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x342d, revid=0x12 domain=0, bus=0, slot=19, func=0 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdfff000, size 12, enabled found-> vendor=0x8086, dev=0x342e, revid=0x12 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x12 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x12 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x342f, revid=0x12 domain=0, bus=0, slot=21, func=0 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 map[20]: type I/O Port, range 32, base 0xff00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=4 map[20]: type I/O Port, range 32, base 0xfe00, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[20]: type I/O Port, range 32, base 0xfd00, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdffe000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3e, revid=0x00 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdff8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a42, revid=0x00 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a4a, revid=0x00 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[20]: type I/O Port, range 32, base 0xfc00, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xfb00, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[20]: type I/O Port, range 32, base 0xfa00, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdffd000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a20, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 3 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xf900, size 4, enabled map[24]: type I/O Port, range 32, base 0xf800, size 4, enabled found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[10]: type Memory, range 64, base 0xfdffc000, size 8, enabled map[20]: type I/O Port, range 32, base 0x500, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a26, revid=0x00 domain=0, bus=0, slot=31, func=5 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xf600, size 3, enabled map[14]: type I/O Port, range 32, base 0xf500, size 2, enabled map[18]: type I/O Port, range 32, base 0xf400, size 3, enabled map[1c]: type I/O Port, range 32, base 0xf300, size 2, enabled map[20]: type I/O Port, range 32, base 0xf200, size 4, enabled map[24]: type I/O Port, range 32, base 0xf100, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x5000-0x5fff pcib1: memory decode 0xfdb00000-0xfdbfffff pcib1: prefetched decode 0xfda00000-0xfdafffff pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 16 at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xf8000000-0xfbffffff pcib2: prefetched decode 0xd0000000-0xdfffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10de, dev=0x05e2, revid=0xa1 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfa000000, size 24, enabled pcib2: requested memory range 0xfa000000-0xfaffffff: good map[14]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib2: requested memory range 0xd0000000-0xdfffffff: good map[1c]: type Memory, range 64, base 0xf8000000, size 25, enabled pcib2: requested memory range 0xf8000000-0xf9ffffff: good map[24]: type I/O Port, range 32, base 0xdf00, size 7, enabled pcib2: requested I/O range 0xdf00-0xdf7f: in range pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 pcib2: slot 0 INTA is routed to irq 16 vgapci0: port 0xdf00-0xdf7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci2 pcib3: irq 16 at device 5.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfd900000-0xfd9fffff pcib3: prefetched decode 0xfd000000-0xfd0fffff pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: irq 16 at device 7.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x7000-0x7fff pcib4: memory decode 0xfcd00000-0xfcdfffff pcib4: prefetched decode 0xfde00000-0xfdefffff pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: irq 16 at device 9.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xfdd00000-0xfddfffff pcib5: prefetched decode 0xfdc00000-0xfdcfffff pci5: on pcib5 pci5: domain=0, physical bus=5 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) uhci0: port 0xff00-0xff1f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xff00 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xfe00-0xfe1f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfe00 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xfd00-0xfd1f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfd00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfdffe000-0xfdffe3ff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfdffe000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: waiting for BIOS to give up control usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib6: irq 16 at device 28.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xb000-0xbfff pcib6: memory decode 0xfd800000-0xfd8fffff pcib6: prefetched decode 0xfd700000-0xfd7fffff pci6: on pcib6 pci6: domain=0, physical bus=6 pcib7: irq 17 at device 28.1 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xa000-0xafff pcib7: memory decode 0xfd600000-0xfd6fffff pcib7: prefetched decode 0xfd500000-0xfd5fffff pci7: on pcib7 pci7: domain=0, physical bus=7 found-> vendor=0x197b, dev=0x2363, revid=0x02 domain=0, bus=7, slot=0, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xaf00, size 3, enabled pcib7: requested I/O range 0xaf00-0xaf07: in range map[14]: type I/O Port, range 32, base 0xae00, size 2, enabled pcib7: requested I/O range 0xae00-0xae03: in range map[18]: type I/O Port, range 32, base 0xad00, size 3, enabled pcib7: requested I/O range 0xad00-0xad07: in range map[1c]: type I/O Port, range 32, base 0xac00, size 2, enabled pcib7: requested I/O range 0xac00-0xac03: in range map[20]: type I/O Port, range 32, base 0xab00, size 4, enabled pcib7: requested I/O range 0xab00-0xab0f: in range map[24]: type Memory, range 32, base 0xfd6fe000, size 13, enabled pcib7: requested memory range 0xfd6fe000-0xfd6fffff: good pcib7: matched entry for 7.0.INTA pcib7: slot 0 INTA hardwired to IRQ 17 atapci0: port 0xaf00-0xaf07,0xae00-0xae03,0xad00-0xad07,0xac00-0xac03,0xab00-0xab0f mem 0xfd6fe000-0xfd6fffff irq 17 at device 0.0 on pci7 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xab00 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 52 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfd6fe000 atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: SATA connect status=00000000 ata2: ahci_reset devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: ahci_reset devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xaf00 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xae00 ata4: reset tp1 mask=03 ostat0=60 ostat1=70 ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata4: reset tp2 stat0=20 stat1=30 devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] pcib8: irq 16 at device 28.4 on pci0 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0x9000-0x9fff pcib8: memory decode 0xfd400000-0xfd4fffff pcib8: prefetched decode 0xfd300000-0xfd3fffff pci8: on pcib8 pci8: domain=0, physical bus=8 found-> vendor=0x10ec, dev=0x8168, revid=0x03 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type I/O Port, range 32, base 0x9e00, size 8, enabled pcib8: requested I/O range 0x9e00-0x9eff: in range map[18]: type Prefetchable Memory, range 64, base 0xfd3ff000, size 12, enabled pcib8: requested memory range 0xfd3ff000-0xfd3fffff: good map[20]: type Prefetchable Memory, range 64, base 0xfd3f8000, size 14, enabled pcib8: requested memory range 0xfd3f8000-0xfd3fbfff: good pcib8: matched entry for 8.0.INTA pcib8: slot 0 INTA hardwired to IRQ 16 re0: port 0x9e00-0x9eff mem 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfd3ff000 re0: MSI count : 1 re0: Chip rev. 0x28000000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1f:d0:ae:5d:a2 re0: [MPSAFE] re0: [FILTER] pcib9: irq 17 at device 28.5 on pci0 pcib9: domain 0 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0x8000-0x8fff pcib9: memory decode 0xfd200000-0xfd2fffff pcib9: prefetched decode 0xfd100000-0xfd1fffff pci9: on pcib9 pci9: domain=0, physical bus=9 found-> vendor=0x10ec, dev=0x8168, revid=0x03 domain=0, bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type I/O Port, range 32, base 0x8e00, size 8, enabled pcib9: requested I/O range 0x8e00-0x8eff: in range map[18]: type Prefetchable Memory, range 64, base 0xfd1ff000, size 12, enabled pcib9: requested memory range 0xfd1ff000-0xfd1fffff: good map[20]: type Prefetchable Memory, range 64, base 0xfd1f8000, size 14, enabled pcib9: requested memory range 0xfd1f8000-0xfd1fbfff: good pcib9: matched entry for 9.0.INTA pcib9: slot 0 INTA hardwired to IRQ 17 re1: port 0x8e00-0x8eff mem 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on pci9 re1: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfd1ff000 re1: MSI count : 1 re1: Chip rev. 0x28000000 re1: MAC rev. 0x00100000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: bpf attached re1: Ethernet address: 00:1f:d0:ae:5d:a4 re1: [MPSAFE] re1: [FILTER] uhci3: port 0xfc00-0xfc1f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfc00 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 53 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xfb00-0xfb1f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfb00 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 54 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xfa00-0xfa1f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfa00 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfdffd000-0xfdffd3ff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfdffd000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: waiting for BIOS to give up control usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered umass0: on uhub7 umass0:0:0:-1: Attached to scbus0 pcib10: at device 30.0 on pci0 pcib10: domain 0 pcib10: secondary bus 10 pcib10: subordinate bus 10 pcib10: I/O decode 0xe000-0xefff pcib10: memory decode 0xfcf00000-0xfcffffff pcib10: prefetched decode 0xfce00000-0xfcefffff pcib10: Subtractively decoded bridge. pci10: on pcib10 pci10: domain=0, physical bus=10 found-> vendor=0x104c, dev=0x8024, revid=0x00 domain=0, bus=10, slot=6, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x02 (60 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcfff000, size 11, enabled pcib10: requested memory range 0xfcfff000-0xfcfff7ff: good map[14]: type Memory, range 32, base 0xfcff8000, size 14, enabled pcib10: requested memory range 0xfcff8000-0xfcffbfff: good pcib10: matched entry for 10.6.INTA pcib10: slot 6 INTA hardwired to IRQ 18 fwohci0: mem 0xfcfff000-0xfcfff7ff,0xfcff8000-0xfcffbfff irq 18 at device 6.0 on pci10 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfcfff000 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:ab:88:9a:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x114c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:ab:88:00:1f:d0 fwe0: bpf attached fwe0: Ethernet address: 02:ab:88:00:1f:d0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:ab:88:9a:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f,0xf800-0xf80f at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf900 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat1=0x7f err=0xff lsb=0xff msb=0xff ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=00 ostat1=50 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=50 devices=0x6 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 56 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xf600-0xf607,0xf500-0xf503,0xf400-0xf407,0xf300-0xf303,0xf200-0xf20f,0xf100-0xf10f irq 19 at device 31.5 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf200 atapci2: [MPSAFE] atapci2: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf600 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf500 ata5: reset tp1 mask=03 ostat0=7f ostat1=7f ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat1=0x7f err=0xff lsb=0xff msb=0xff ata5: reset tp2 stat0=ff stat1=ff devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0xf400 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xf300 ata6: reset tp1 mask=03 ostat0=50 ostat1=00 ata6: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata6: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata6: reset tp2 stat0=50 stat1=00 devices=0x1 ata6: [MPSAFE] ata6: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 57 fdc0: [FILTER] cpu0: on acpi0 est0: on cpu0 est0: Invalid id16 (set, cur) = (20, 21) est0: Invalid freq 2660, ignored. est0: Invalid id16 (set, cur) = (19, 21) est0: Invalid freq 2527, ignored. est0: Invalid id16 (set, cur) = (18, 21) est0: Invalid freq 2394, ignored. est0: Invalid id16 (set, cur) = (17, 21) est0: Invalid freq 2261, ignored. est0: Invalid id16 (set, cur) = (16, 21) est0: Invalid freq 2128, ignored. est0: Invalid id16 (set, cur) = (15, 21) est0: Invalid freq 1995, ignored. est0: Invalid id16 (set, cur) = (14, 21) est0: Invalid freq 1862, ignored. est0: Invalid id16 (set, cur) = (13, 21) est0: Invalid freq 1729, ignored. est0: Invalid id16 (set, cur) = (12, 21) est0: Invalid freq 1596, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (20, 21) est1: Invalid freq 2660, ignored. est1: Invalid id16 (set, cur) = (19, 21) est1: Invalid freq 2527, ignored. est1: Invalid id16 (set, cur) = (18, 21) est1: Invalid freq 2394, ignored. est1: Invalid id16 (set, cur) = (17, 21) est1: Invalid freq 2261, ignored. est1: Invalid id16 (set, cur) = (16, 21) est1: Invalid freq 2128, ignored. est1: Invalid id16 (set, cur) = (15, 21) est1: Invalid freq 1995, ignored. est1: Invalid id16 (set, cur) = (14, 21) est1: Invalid freq 1862, ignored. est1: Invalid id16 (set, cur) = (13, 21) est1: Invalid freq 1729, ignored. est1: Invalid id16 (set, cur) = (12, 21) est1: Invalid freq 1596, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (20, 21) est2: Invalid freq 2660, ignored. est2: Invalid id16 (set, cur) = (19, 21) est2: Invalid freq 2527, ignored. est2: Invalid id16 (set, cur) = (18, 21) est2: Invalid freq 2394, ignored. est2: Invalid id16 (set, cur) = (17, 21) est2: Invalid freq 2261, ignored. est2: Invalid id16 (set, cur) = (16, 21) est2: Invalid freq 2128, ignored. est2: Invalid id16 (set, cur) = (15, 21) est2: Invalid freq 1995, ignored. est2: Invalid id16 (set, cur) = (14, 21) est2: Invalid freq 1862, ignored. est2: Invalid id16 (set, cur) = (13, 21) est2: Invalid freq 1729, ignored. est2: Invalid id16 (set, cur) = (12, 21) est2: Invalid freq 1596, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (20, 21) est3: Invalid freq 2660, ignored. est3: Invalid id16 (set, cur) = (19, 21) est3: Invalid freq 2527, ignored. est3: Invalid id16 (set, cur) = (18, 21) est3: Invalid freq 2394, ignored. est3: Invalid id16 (set, cur) = (17, 21) est3: Invalid freq 2261, ignored. est3: Invalid id16 (set, cur) = (16, 21) est3: Invalid freq 2128, ignored. est3: Invalid id16 (set, cur) = (15, 21) est3: Invalid freq 1995, ignored. est3: Invalid id16 (set, cur) = (14, 21) est3: Invalid freq 1862, ignored. est3: Invalid id16 (set, cur) = (13, 21) est3: Invalid freq 1729, ignored. est3: Invalid id16 (set, cur) = (12, 21) est3: Invalid freq 1596, ignored. p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 est4: Invalid id16 (set, cur) = (20, 21) est4: Invalid freq 2660, ignored. est4: Invalid id16 (set, cur) = (19, 21) est4: Invalid freq 2527, ignored. est4: Invalid id16 (set, cur) = (18, 21) est4: Invalid freq 2394, ignored. est4: Invalid id16 (set, cur) = (17, 21) est4: Invalid freq 2261, ignored. est4: Invalid id16 (set, cur) = (16, 21) est4: Invalid freq 2128, ignored. est4: Invalid id16 (set, cur) = (15, 21) est4: Invalid freq 1995, ignored. est4: Invalid id16 (set, cur) = (14, 21) est4: Invalid freq 1862, ignored. est4: Invalid id16 (set, cur) = (13, 21) est4: Invalid freq 1729, ignored. est4: Invalid id16 (set, cur) = (12, 21) est4: Invalid freq 1596, ignored. p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est5: Invalid id16 (set, cur) = (20, 21) est5: Invalid freq 2660, ignored. est5: Invalid id16 (set, cur) = (19, 21) est5: Invalid freq 2527, ignored. est5: Invalid id16 (set, cur) = (18, 21) est5: Invalid freq 2394, ignored. est5: Invalid id16 (set, cur) = (17, 21) est5: Invalid freq 2261, ignored. est5: Invalid id16 (set, cur) = (16, 21) est5: Invalid freq 2128, ignored. est5: Invalid id16 (set, cur) = (15, 21) est5: Invalid freq 1995, ignored. est5: Invalid id16 (set, cur) = (14, 21) est5: Invalid freq 1862, ignored. est5: Invalid id16 (set, cur) = (13, 21) est5: Invalid freq 1729, ignored. est5: Invalid id16 (set, cur) = (12, 21) est5: Invalid freq 1596, ignored. p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 est6: Invalid id16 (set, cur) = (20, 21) est6: Invalid freq 2660, ignored. est6: Invalid id16 (set, cur) = (19, 21) est6: Invalid freq 2527, ignored. est6: Invalid id16 (set, cur) = (18, 21) est6: Invalid freq 2394, ignored. est6: Invalid id16 (set, cur) = (17, 21) est6: Invalid freq 2261, ignored. est6: Invalid id16 (set, cur) = (16, 21) est6: Invalid freq 2128, ignored. est6: Invalid id16 (set, cur) = (15, 21) est6: Invalid freq 1995, ignored. est6: Invalid id16 (set, cur) = (14, 21) est6: Invalid freq 1862, ignored. est6: Invalid id16 (set, cur) = (13, 21) est6: Invalid freq 1729, ignored. est6: Invalid id16 (set, cur) = (12, 21) est6: Invalid freq 1596, ignored. p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est7: Invalid id16 (set, cur) = (20, 21) est7: Invalid freq 2660, ignored. est7: Invalid id16 (set, cur) = (19, 21) est7: Invalid freq 2527, ignored. est7: Invalid id16 (set, cur) = (18, 21) est7: Invalid freq 2394, ignored. est7: Invalid id16 (set, cur) = (17, 21) est7: Invalid freq 2261, ignored. est7: Invalid id16 (set, cur) = (16, 21) est7: Invalid freq 2128, ignored. est7: Invalid id16 (set, cur) = (15, 21) est7: Invalid freq 1995, ignored. est7: Invalid id16 (set, cur) = (14, 21) est7: Invalid freq 1862, ignored. est7: Invalid id16 (set, cur) = (13, 21) est7: Invalid freq 1729, ignored. est7: Invalid id16 (set, cur) = (12, 21) est7: Invalid freq 1596, ignored. p4tcc7: on cpu7 ex_isa_identify() fdc: fdc0 already exists; skipping it ahc_isa_probe 10: ioport 0xac00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: strange result for test aux port (1). psm0: failed to reset the aux device. ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 59 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices ukbd0: on uhub6 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 uhid0: on uhub6 uhid1: on uhub6 Device configuration finished. Reducing kern.maxvnodes 196046 -> 100000 procfs registered lapic: Divisor 2, Frequency 67469340 hz Timecounter "TSC" frequency 2698773787 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attachedfirewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) hptrr: no controller detected. ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire acd0: DVDR drive at ata1 as master acd0: read 8269KB/s (8269KB/s) write 8269KB/s (8269KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ad3: 286167MB at ata1-slave UDMA33 ad3: 586070255 sectors [581418C/16H/63S] 16 sectors/interrupt 1 depth queue ad3: Intel check1 failed ad3: Adaptec check1 failed ad3: LSI (v3) check1 failed ad3: LSI (v2) check1 failed ad3: FreeBSD check1 failed ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 476940MB at ata6-master UDMA33 ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad3 GEOM: new disk ad12 ad12: Intel check1 failed ad12: Adaptec check1 failed ad12: LSI (v3) check1 failed ad12: LSI (v2) check1 failed ad12: FreeBSD check1 failed (probe1:sbp0:0:0:0): error 22 (probe1:sbp0:0:0:0): Unretryable Error (probe2:sbp0:0:1:0): error 22 (probe2:sbp0:0:1:0): Unretryable Error (probe3:sbp0:0:2:0): error 22 (probe3:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:3:0): error 22 (probe4:sbp0:0:3:0): Unretryable Error (probe5:sbp0:0:4:0): error 22 (probe5:sbp0:0:4:0): Unretryable Error (probe6:sbp0:0:5:0): error 22 (probe6:sbp0:0:5:0): Unretryable Error (probe7:sbp0:0:6:0): error 22 (probe7:sbp0:0:6:0): Unretryable Error pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 40.000MB/s transfers GEOM: new disk da0 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #7 Launched! cpu7 AP: ID: 0x07000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x05000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #4 Launched! cpu4 AP: ID: 0x04000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x06000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 2 ioapic0: Assigning ISA IRQ 6 to local APIC 4 ioapic0: Assigning ISA IRQ 9 to local APIC 6 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 4 ioapic0: Assigning PCI IRQ 17 to local APIC 6 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 2 ioapic0: Assigning PCI IRQ 21 to local APIC 4 ioapic0: Assigning PCI IRQ 23 to local APIC 6 Trying to mount root from ufs:/dev/ad12s2a start_init: trying /sbin/init re0: link state changed to UP From benjie at addgene.org Tue Dec 2 12:34:41 2008 From: benjie at addgene.org (Benjie Chen) Date: Tue Dec 2 12:34:48 2008 Subject: Weird TCP connect issue in FreeBSD 6 Message-ID: Hi I have a weird issue to report, and I am not sure if it's a bug or some other configuration problem. Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 = 192.168.0.1, and the other one is em1 = 192.168.0.2. I have an Apache server listening on 80 and 443 on both IP addresses. So we have 0.1:80, 0.1:443, 0.2:80, 0.2:443 Connections to 0.1:80, 0.1:443, 0.2:80, I have not experienced any problems. Connections to 0.2:443, however, I get frequently connection issues. I am connecting using telnet -- eg: telnet 192.168.0.2 443 Sometimes the connection would be established (past accept, I get to type something or ^]q out of telnet). Sometimes, however, immediately after connect is established, the connection would be terminated. I traced the problem by running tcpdump -p on em0 and em1, as well as a tcpdump on the same subnet as the client (which is on a whole different network). Packets to 0.2 are definitely arriving on em1, but responses from 0.2 back to client go out em0. This is just because of the default route. Here is what's happening on the failed/terminated connects: 1. client sends SYN to 0.2:443 2. 0.2:443 responds with SYN ACK 3. on tcpdumps on server, we see that before the SYN ACK from step 2 even reaches the client, we get repeated SYN packets to 0.2:443, and repeated (as expected) SYN ACK for each of the packet. we do not see the repeated SYNs on the tcpdump on the client network 4. step 3 goes on for a long time, even after the SYN ACK reaches client and client respond with an ACK 5. client receives a bunch of SYN ACK, and sends an ACK for each 6. at some point, I believe FreeBSD syn attack prevention kicks in and a RST is set to the server, connection is then terminated. Interesting observations: this does not happen all the time, just sometimes. This also does not happen (at least I can't get it to occur) for 0.2:80, or any of the 0.1:80 or 0.1:443 ports. I just switched to using IP aliasing on the same NIC, and so far I have not been able to re-produce the same problem. I am not familiar with the SYN cache/cookie code in FreeBSD, but is it possible that the dual NIC is confusing that piece of code, and in some cases, it does not see the SYN ACK from the server and retransmits the SYN? Something is retransmitting the SYN packets! If anyone has any information on this, please help! Thanks, Benjie --- Benjie Chen, Ph.D. Addgene, a better way to share plasmids www.addgene.org Manage your lab more efficiently Addgene Labs - www.addgenelabs.org From naddy at mips.inka.de Tue Dec 2 12:44:45 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue Dec 2 12:44:52 2008 Subject: [ipsec] aes-ctr question References: <49349E26.30002@redhat.com> Message-ID: wang_jiabo wrote: > following is my setkey configration. I can get SAD and SPD. but when I > run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD > FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must > be multiple of 16 > kernel: decrypt fail in IPv6 ESP input : (I cannot comment on this problem. Looks like a padding bug.) > add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 > 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr > "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; Do not use AES-CTR with static keys! Re-use of keys with a stream cipher will allow listeners to recover the plaintext. (See section 7 of RFC 3686.) -- Christian "naddy" Weisgerber naddy@mips.inka.de From jiabwang at redhat.com Tue Dec 2 17:00:13 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Tue Dec 2 17:00:20 2008 Subject: [ipsec] aes-ctr question In-Reply-To: References: <49349E26.30002@redhat.com> Message-ID: <4935DA42.2010804@redhat.com> Christian Weisgerber wrote: > wang_jiabo wrote: > > >> following is my setkey configration. I can get SAD and SPD. but when I >> run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD >> FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must >> be multiple of 16 >> kernel: decrypt fail in IPv6 ESP input : >> > > (I cannot comment on this problem. Looks like a padding bug.) > > >> add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 >> 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr >> "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; >> > > Do not use AES-CTR with static keys! Re-use of keys with a stream > cipher will allow listeners to recover the plaintext. > (See section 7 of RFC 3686.) > > but when I use " ping6 -I rl0 -s 11(or 12,13,14) 3ffe:501:ffff:103:20a:ebff:fe85:9e56" it is no problem From vulture at netvulture.com Tue Dec 2 19:17:40 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 19:17:53 2008 Subject: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper?? NOPE - We're OK) In-Reply-To: <493587D4.5000400@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> <493587D4.5000400@netvulture.com> Message-ID: <4935FA57.6080106@netvulture.com> OK, so I installed a different PE1750 with BETA2 and then updated the source via cvsup RELENG_7 from cvsup3 and all is ok now on that box. Went back the first box and cvsup'ed the src again into an empty directory and it compiled and worked fine. Looks like my updating of the source along the way missed http://svn.freebsd.org/viewvc/base?view=revision&revision=182924 as that is the only diff between the 2 local source trees. Sorry for the confusion. I've never had this issue before with cvsup, but guess there's always a first time. Thanks to all for checking my own bad testing work. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vulture at netvulture.com Tue Dec 2 23:09:08 2008 From: vulture at netvulture.com (Jonathan Feally) Date: Tue Dec 2 23:09:15 2008 Subject: dhclient doing DISCOVER with bad IP checksum - compile optimization issue In-Reply-To: <4935FA57.6080106@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> <493587D4.5000400@netvulture.com> <4935FA57.6080106@netvulture.com> Message-ID: <49363099.5040701@netvulture.com> Ok, I managed to cause it again. dhclient was the problem. My source tree was fine. Turns out that it is my make.conf CFLAGS=-O3 setting. When compiled with -O3 it will generate packets with bad checksums. Simply recompiling it with -O2 did not cause this issue and dhclient works fine. So the question becomes, what is happening with -O3 that is breaking it? So far I am not having any other issues with -O3 on the rest of the system. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rea-fbsd at codelabs.ru Tue Dec 2 23:54:58 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Dec 2 23:55:05 2008 Subject: [ipsec] aes-ctr question In-Reply-To: References: <49349E26.30002@redhat.com> Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081203/4bf12806/attachment-0001.pgp From mav at FreeBSD.org Wed Dec 3 00:17:47 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Dec 3 00:17:53 2008 Subject: Multiple netgraph threads In-Reply-To: <1228234984.00043656.1228222202@10.7.7.3> References: <1228234984.00043656.1228222202@10.7.7.3> Message-ID: <493640A9.8080701@FreeBSD.org> Hi. Vladimir V. Kobal wrote: > I'm interested in the information of further development of Subject. I have > a bottleneck: swi_net limited by one CPU core time. There was a thread > http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html . > Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not available > :(. Could somebody mail it to me. Are there any other similar patches? I have uploaded that patch back. Not sure is it correct at this moment, there was some changes, but that time it worked fine. I have measured some benefit on my tests with Core2Quad using NetPerf cluster. But even having all 4 cores busy, I have got just only about 20% performance benefit on that test setup (routing between three Gigabit PPTP links). I suppose it was result of constant cache trashing, when the same netgraph nodes write-accessed by different CPUs. But may be on more diverse workload, or with some heavy compression/encryption used benefit can be bigger. -- Alexander Motin From vanhu at FreeBSD.org Wed Dec 3 00:41:22 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Wed Dec 3 00:41:29 2008 Subject: [ipsec] aes-ctr question In-Reply-To: References: <49349E26.30002@redhat.com> Message-ID: <20081203082549.GA62889@zeninc.net> On Wed, Dec 03, 2008 at 10:54:55AM +0300, Eygene Ryabinkin wrote: [...] > Good catch. Perhaps setkey should be extended to warn the user about > this neat. The patch is attached. George, people, what do you think > about it? If we're going to add security warnings in setkey, we could just put a warning when using static keys (so basically put a warning for "add" command....). Yvan. From julian at elischer.org Wed Dec 3 01:47:40 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Dec 3 01:47:46 2008 Subject: Multiple netgraph threads In-Reply-To: <493640A9.8080701@FreeBSD.org> References: <1228234984.00043656.1228222202@10.7.7.3> <493640A9.8080701@FreeBSD.org> Message-ID: <49364EF1.90703@elischer.org> Alexander Motin wrote: > Hi. > > Vladimir V. Kobal wrote: >> I'm interested in the information of further development of Subject. I have >> a bottleneck: swi_net limited by one CPU core time. There was a thread >> http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html . >> Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not available >> :(. Could somebody mail it to me. Are there any other similar patches? > > I have uploaded that patch back. Not sure is it correct at this moment, > there was some changes, but that time it worked fine. > > I have measured some benefit on my tests with Core2Quad using NetPerf > cluster. But even having all 4 cores busy, I have got just only about > 20% performance benefit on that test setup (routing between three > Gigabit PPTP links). I suppose it was result of constant cache trashing, > when the same netgraph nodes write-accessed by different CPUs. But may > be on more diverse workload, or with some heavy compression/encryption > used benefit can be bigger. > I would like to see this work followed through.. From bzeeb-lists at lists.zabbadoz.net Wed Dec 3 03:05:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 3 03:05:15 2008 Subject: Problem with new source address selection In-Reply-To: <200811280653.mAS6r1P3014050@post.behrens.de> References: <200811271542.mARFgglB004902@post.behrens.de> <200811280653.mAS6r1P3014050@post.behrens.de> Message-ID: <20081203104040.D80401@maildrop.int.zabbadoz.net> On Fri, 28 Nov 2008, Frank Behrens wrote: Hi, > Bjoern A. Zeeb wrote on 27 Nov 2008 16:47: >>> Now I want to tunnel between my 192.168.90.0/24 and a foreign >>> 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created >>> a static route. >> >> So if you don't mind to go out with a source address of 192.168.90.1 >> instead of .254, what about this hack. What happens if you change the >> route to >> route change -net 192.168.200.0/24 192.168.90.2 >> (assuming the .2 is not on your local machine). > > That works for the router, but for incoming packets on the internal > interface (from -net 192.168.90.0/24) the machine will send an ICMP > redirect to new router 192.168.90.2. Of course that is a black hole. > When I use the route to own interface address > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also > for every incoming packet an ICMP redirect is sent. So that solution > is a workaround for short time only. You can disable icmp redircts entirely but not sure if soemthing else would stop working in your network topology then. sysctl net.inet.ip.redirect > Does anybody have a better solution for source address selection? Am > I the only one with an IPSEC tunnel? The best solution actually is to teach your application to bind for this connection I guess instead of relying on any hack. When it comes to the source address selection I am tempted to answer with: I am willing to still allow this in 7 to not break production setups but I am inclined to not change HEAD and keep the behavior dropped there. See patch below, which basically is what you had with the version check and the if (ia == NULL) check to not blindly overwrite if we had found anything closer (untested). Currently trying to discuss this with people. ------------------------------------------------------------------------ Index: sys/netinet/in_pcb.c =================================================================== --- sys/netinet/in_pcb.c (revision 185571) +++ sys/netinet/in_pcb.c (working copy) @@ -696,6 +696,10 @@ ia = ifatoia(ifa_ifwithnet(sintosa(&sain))); if (cred == NULL || !jailed(cred)) { +#if __FreeBSD_version < 800000 + if (ia == NULL) + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa; +#endif if (ia == NULL) { error = ENETUNREACH; goto done; ------------------------------------------------------------------------ /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From frank at harz.behrens.de Wed Dec 3 04:20:16 2008 From: frank at harz.behrens.de (Frank Behrens) Date: Wed Dec 3 04:20:29 2008 Subject: Problem with new source address selection In-Reply-To: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811280653.mAS6r1P3014050@post.behrens.de> Message-ID: <200812031220.mB3CK204015947@post.behrens.de> Bjoern A. Zeeb wrote on 3 Dec 2008 11:03: > On Fri, 28 Nov 2008, Frank Behrens wrote: > > That works for the router, but for incoming packets on the internal > > interface (from -net 192.168.90.0/24) the machine will send an ICMP > > redirect to new router 192.168.90.2. Of course that is a black hole. > > When I use the route to own interface address > > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also > > for every incoming packet an ICMP redirect is sent. So that solution > > is a workaround for short time only. > > You can disable icmp redircts entirely but not sure if soemthing else > would stop working in your network topology then. > > sysctl net.inet.ip.redirect This is the workaround I made in the meantime. I believe icmp redirects are for a working network not necessary, they are only an optimization. > > Does anybody have a better solution for source address selection? Am > > I the only one with an IPSEC tunnel? > > The best solution actually is to teach your application to bind for > this connection I guess instead of relying on any hack. Hm, is this so easy? I thought address selection for outgoing connections is made by the OS? One of my test cases is bind/named. I don't know how to configure _multiple_ bind addresses for outgoing connections dependent from destination network. As I mentioned earlier I believe the main problem is IPSEC itself, where we don't have an interface for tunneled connections. So I made a workaround with a dummy loopback device. So I have a question to the network specialists: Is there no other solution? Am I the only stupid man, who wants to tunnel a subnet with private address range via IPSEC? > When it comes to the source address selection I am tempted to answer > with: I am willing to still allow this in 7 to not break production > setups but I am inclined to not change HEAD and keep the behavior > dropped there. See patch below, which basically is what you had with > the version check and the if (ia == NULL) check to not blindly overwrite > if we had found anything closer (untested). Thanks, I will try this. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From julian at elischer.org Wed Dec 3 06:12:03 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Dec 3 06:12:10 2008 Subject: Problem with new source address selection In-Reply-To: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811271542.mARFgglB004902@post.behrens.de> <200811280653.mAS6r1P3014050@post.behrens.de> <20081203104040.D80401@maildrop.int.zabbadoz.net> Message-ID: <493693B1.3030306@elischer.org> Bjoern A. Zeeb wrote: > On Fri, 28 Nov 2008, Frank Behrens wrote: > > Hi, > >> Bjoern A. Zeeb wrote on 27 Nov 2008 >> 16:47: >>>> Now I want to tunnel between my 192.168.90.0/24 and a foreign >>>> 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created >>>> a static route. >>> >>> So if you don't mind to go out with a source address of 192.168.90.1 >>> instead of .254, what about this hack. What happens if you change the >>> route to >>> route change -net 192.168.200.0/24 192.168.90.2 >>> (assuming the .2 is not on your local machine). >> >> That works for the router, but for incoming packets on the internal >> interface (from -net 192.168.90.0/24) the machine will send an ICMP >> redirect to new router 192.168.90.2. Of course that is a black hole. >> When I use the route to own interface address >> (route change -net 192.168.200.0/24 192.168.90.1) it works, but also >> for every incoming packet an ICMP redirect is sent. So that solution >> is a workaround for short time only. > > You can disable icmp redircts entirely but not sure if soemthing else > would stop working in your network topology then. > > sysctl net.inet.ip.redirect > > >> Does anybody have a better solution for source address selection? Am >> I the only one with an IPSEC tunnel? > > The best solution actually is to teach your application to bind for > this connection I guess instead of relying on any hack. > > > When it comes to the source address selection I am tempted to answer > with: I am willing to still allow this in 7 to not break production > setups but I am inclined to not change HEAD and keep the behavior > dropped there. See patch below, which basically is what you had with > the version check and the if (ia == NULL) check to not blindly overwrite > if we had found anything closer (untested). > > Currently trying to discuss this with people. can you assign a second FIB to handle this case? > > ------------------------------------------------------------------------ > Index: sys/netinet/in_pcb.c > =================================================================== > --- sys/netinet/in_pcb.c (revision 185571) > +++ sys/netinet/in_pcb.c (working copy) > @@ -696,6 +696,10 @@ > ia = ifatoia(ifa_ifwithnet(sintosa(&sain))); > > if (cred == NULL || !jailed(cred)) { > +#if __FreeBSD_version < 800000 > + if (ia == NULL) > + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa; > +#endif > if (ia == NULL) { > error = ENETUNREACH; > goto done; > ------------------------------------------------------------------------ > > > /bz > From peterjeremy at optushome.com.au Wed Dec 3 11:36:16 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Dec 3 11:36:23 2008 Subject: Weird TCP connect issue in FreeBSD 6 In-Reply-To: References: Message-ID: <20081203193609.GB58682@server.vk2pj.dyndns.org> On 2008-Dec-02 15:10:11 -0500, Benjie Chen wrote: >I have a weird issue to report, and I am not sure if it's a bug or >some other configuration problem. I would suggest it is a configuration problem. >Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 >= 192.168.0.1, and the other one is em1 = 192.168.0.2. This is not a supported configuration - you cannot have addresses within the same subnet on more than one interface. >I just switched to using IP aliasing on the same NIC, and so far I >have not been able to re-produce the same problem. This is the correct configuration. -- 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/20081203/01b5fe6a/attachment.pgp From benjie at addgene.org Wed Dec 3 14:40:03 2008 From: benjie at addgene.org (Benjie Chen) Date: Wed Dec 3 14:40:14 2008 Subject: Weird TCP connect issue in FreeBSD 6 In-Reply-To: <20081203193609.GB58682@server.vk2pj.dyndns.org> References: <20081203193609.GB58682@server.vk2pj.dyndns.org> Message-ID: Peter, Thanks for the response. When I had two IPs from two different subnets configured for the two NICs, I had the same error. So while I did have a configuration issue, the problem with replicated SYNs did occur even when the two NICs had IP addresses on different networks. Benjie On Wed, Dec 3, 2008 at 2:36 PM, Peter Jeremy wrote: > On 2008-Dec-02 15:10:11 -0500, Benjie Chen wrote: >>I have a weird issue to report, and I am not sure if it's a bug or >>some other configuration problem. > > I would suggest it is a configuration problem. > >>Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 >>= 192.168.0.1, and the other one is em1 = 192.168.0.2. > > This is not a supported configuration - you cannot have addresses within > the same subnet on more than one interface. > >>I just switched to using IP aliasing on the same NIC, and so far I >>have not been able to re-produce the same problem. > > This is the correct configuration. > > -- > 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. > From yongari at FreeBSD.org Wed Dec 3 20:41:01 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Wed Dec 3 20:41:07 2008 Subject: kern/128181: [fxp] panic in fxp_add_rfabuf Message-ID: <200812040441.mB44f0uY093932@freefall.freebsd.org> Synopsis: [fxp] panic in fxp_add_rfabuf State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Dec 4 04:36:10 UTC 2008 State-Changed-Why: I think this issue might be fixed in HEAD. Would you try fxp(4) in HEAD? (Replacing fxp(4) with HEAD version would also work on latest stable/7). Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Dec 4 04:36:10 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=128181 From jiabwang at redhat.com Wed Dec 3 21:05:36 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Wed Dec 3 21:05:47 2008 Subject: [ipv6]how to configure ipv6 address in /etc/rc.conf Message-ID: <49376544.70006@redhat.com> I would like configure manual ipv6 address in /etc/rc.conf I add the following command : ipv6_enable="yes" ifconfig_rl0="inet6 3ffe:501:ffff:100::20 prefixlen 64" but, when I reboot the system, then ifconfig check, did not show the address please tell me how to configure From bzeeb-lists at lists.zabbadoz.net Wed Dec 3 23:10:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 3 23:10:15 2008 Subject: [ipv6]how to configure ipv6 address in /etc/rc.conf In-Reply-To: <49376544.70006@redhat.com> References: <49376544.70006@redhat.com> Message-ID: <20081204070239.X80401@maildrop.int.zabbadoz.net> On Thu, 4 Dec 2008, wang_jiabo wrote: > I would like configure manual ipv6 address in /etc/rc.conf > I add the following command : > ipv6_enable="yes" > ifconfig_rl0="inet6 3ffe:501:ffff:100::20 prefixlen 64" > but, when I reboot the system, then ifconfig check, did not show the address > please tell me how to configure check /etc/defaults/rc.conf or better read man rc.conf and search for ipv6_network_interfaces and read it entirely. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From vlad at prokk.net Thu Dec 4 06:08:30 2008 From: vlad at prokk.net (Vladimir V. Kobal) Date: Thu Dec 4 06:08:37 2008 Subject: Multiple netgraph threads In-Reply-To: <493640A9.8080701@FreeBSD.org> References: <1228234984.00043656.1228222202@10.7.7.3> <493640A9.8080701@FreeBSD.org> Message-ID: <003001c95619$be6e98a0$3b4bc9e0$@net> Alexander Motin wrote: >I have uploaded that patch back. Not sure is it correct at this moment, >there was some changes, but that time it worked fine. Thanks a lot. I've installed the patch with some changes. I'm using the 7-STABLE (ng_base.c,v 1.135.2.10) at a production NAS. Corresponding patch is in the attachment. I can't say anything of performance yet. Not enough statistics data is collected at the moment. But there is a strangeness with ng_queue threads: under high network load top display too low WCPU (while TIME has a normal value) for these threads. The maximum WCPU I saw under lower network load was 35-40% per ng_queue thread. Are there any ideas? Am I using correctly the kthread_create() in the patch? last pid: 21000; load averages: 1.52, 1.40, 1.02 up 0+00:25:39 14:24:28 79 processes: 5 running, 63 sleeping, 11 waiting CPU: 0.3% user, 0.0% nice, 41.4% system, 0.6% interrupt, 57.7% idle Mem: 40M Active, 11M Inact, 166M Wired, 112K Cache, 77M Buf, 1731M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K RUN 2 18:36 58.50% idle: cpu2 11 root 1 171 ki31 0K 16K RUN 3 18:02 63.87% idle: cpu3 13 root 1 171 ki31 0K 16K CPU1 1 17:56 41.26% idle: cpu1 14 root 1 171 ki31 0K 16K CPU0 0 17:20 59.96% idle: cpu0 2 root 1 96 - 0K 16K sleep 0 7:16 0.20% ng_queue0 3 root 1 96 - 0K 16K sleep 1 7:13 0.20% ng_queue1 25 root 1 -68 - 0K 16K - 1 5:44 36.67% em0 taskq 26 root 1 -68 - 0K 16K - 2 5:26 35.60% em1 taskq 16 root 1 -32 - 0K 16K WAIT 0 1:30 3.86% swi4: clock 2538 root 1 48 0 36720K 15228K select 3 0:25 0.59% mpd5 -- Vladimir Kobal -------------- next part -------------- A non-text attachment was scrubbed... Name: netgraph.threads.patch Type: application/octet-stream Size: 4075 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081204/79ea8a8c/netgraph.threads.obj From antonio.tommasi at unile.it Fri Dec 5 00:17:11 2008 From: antonio.tommasi at unile.it (Antonio Tommasi) Date: Fri Dec 5 00:17:18 2008 Subject: Virtual machine on freebsd In-Reply-To: <20081204070239.X80401@maildrop.int.zabbadoz.net> References: <49376544.70006@redhat.com> <20081204070239.X80401@maildrop.int.zabbadoz.net> Message-ID: <4938DF2A.6080409@unile.it> Hi to all, i want to install a virtual machine on my FreeBSD 7.0 box. Can you tell me which is the better sofware to do this? Thanks in advance Antonio From randy at psg.com Fri Dec 5 00:43:43 2008 From: randy at psg.com (Randy Bush) Date: Fri Dec 5 00:43:50 2008 Subject: bgp, is-is, ... Message-ID: <4938E9BD.3040607@psg.com> openbgp is said to be the best bsd implementation of bgp. but i see that ports/openbgpd has not been updated in a while. it is at 4.0 while 4.3 is the current public release. ports/quagga is at 0.99.10, while the public release is 0.99.11. so that's a bit better. and, as i need is-is, i think quagga is my only choice, yes? i am not seeing any useful is-is docco on the quagga doc pages. but a bit of googling finds some. does the isisd work in a simple lan config, nothing fancy? for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? randy From lev at FreeBSD.org Fri Dec 5 00:48:02 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Fri Dec 5 00:48:33 2008 Subject: NFS performance tuning? Message-ID: <1682252731.20081205112939@serebryakov.spb.ru> Hello, Freebsd-net. I have two systems (7-Stable), connected with gigabit link. iperf shows 667 Mbits/sec on TCP and 600Mbit/s on UDP without any tuning. But NFS gives me only 17Mb/s (~136 Mbit/s) on sequential read of very big files, and about 8-10Mb/s on "real" workloads. Are here any guides how to tune NFS for performance? -- // Black Lion AKA Lev Serebryakov From delphij at delphij.net Fri Dec 5 00:58:10 2008 From: delphij at delphij.net (Xin LI) Date: Fri Dec 5 00:58:27 2008 Subject: NFS performance tuning? In-Reply-To: <1682252731.20081205112939@serebryakov.spb.ru> References: <1682252731.20081205112939@serebryakov.spb.ru> Message-ID: <4938ED14.8090101@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lev Serebryakov wrote: > Hello, Freebsd-net. > > I have two systems (7-Stable), connected with gigabit link. iperf > shows 667 Mbits/sec on TCP and 600Mbit/s on UDP without any tuning. > > But NFS gives me only 17Mb/s (~136 Mbit/s) on sequential read of > very big files, and about 8-10Mb/s on "real" workloads. > > Are here any guides how to tune NFS for performance? rsize/wsize? I think the current default (8192) is too smal, perhaps 262144 would be a better choice. What I usually use is: mount_nfs -3Tr 262144 -w 262144 - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk47RQACgkQi+vbBBjt66BYkwCgh+Eu+C+OJW9WdU7s1qww9GEb c5gAoKotFAXFTNTKD1ac+mNRAufck15t =pdBF -----END PGP SIGNATURE----- From brad at comstyle.com Fri Dec 5 01:22:53 2008 From: brad at comstyle.com (Brad) Date: Fri Dec 5 01:23:00 2008 Subject: bgp, is-is, ... In-Reply-To: <4938E9BD.3040607@psg.com> References: <4938E9BD.3040607@psg.com> Message-ID: <200812050422.44586.brad@comstyle.com> On Friday 05 December 2008 03:43:41 Randy Bush wrote: > openbgp is said to be the best bsd implementation of bgp. but i see > that ports/openbgpd has not been updated in a while. it is at 4.0 while > 4.3 is the current public release. Actually 4.4 is the latset release, although only available in CVS. I have prodded Henning again about updating the website/FTP site. The OpenOSPF port could use an update to 4.4. > for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? A machine with 512MB of memory should have no problem with 3 maybe 4 feeds depending on BGP implementation and setup. So 2GB should be more than enough -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From randy at psg.com Fri Dec 5 01:28:43 2008 From: randy at psg.com (Randy Bush) Date: Fri Dec 5 01:28:50 2008 Subject: bgp, is-is, ... In-Reply-To: <200812050422.44586.brad@comstyle.com> References: <4938E9BD.3040607@psg.com> <200812050422.44586.brad@comstyle.com> Message-ID: <4938F449.3000401@psg.com> Brad wrote: > On Friday 05 December 2008 03:43:41 Randy Bush wrote: >> openbgp is said to be the best bsd implementation of bgp. but i see >> that ports/openbgpd has not been updated in a while. it is at 4.0 while >> 4.3 is the current public release. > Actually 4.4 is the latset release, although only available in CVS. I have > prodded Henning again about updating the website/FTP site. > The OpenOSPF port could use an update to 4.4. but no is-is? not to start an emacs/vi debate, but most of us old pharts are is-is, as are the big old backbones (and the smarter new ones:-). >> for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? > A machine with 512MB of memory should have no problem with 3 maybe 4 feeds > depending on BGP implementation and setup. So 2GB should be more than enough cool. this will have at least two ibgp peers who have full external transit feeds, i.e. 200k prefixes each. randy From brad at comstyle.com Fri Dec 5 01:38:50 2008 From: brad at comstyle.com (Brad) Date: Fri Dec 5 01:38:56 2008 Subject: bgp, is-is, ... In-Reply-To: <4938F449.3000401@psg.com> References: <4938E9BD.3040607@psg.com> <200812050422.44586.brad@comstyle.com> <4938F449.3000401@psg.com> Message-ID: <200812050438.42163.brad@comstyle.com> On Friday 05 December 2008 04:28:41 Randy Bush wrote: > but no is-is? not to start an emacs/vi debate, but most of us old > pharts are is-is, as are the big old backbones (and the smarter new > ones:-). Not yet. You're welcome to help start an isisd. ;) So far BGP, OSPF, RIP and DVMRP working. OSPF6d started. > >> for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? > > > > A machine with 512MB of memory should have no problem with 3 maybe 4 > > feeds depending on BGP implementation and setup. So 2GB should be more > > than enough > > cool. this will have at least two ibgp peers who have full external > transit feeds, i.e. 200k prefixes each. Ya, with how cheap memory is for anything you will most likely use there is no point not having at least 1GB and that will provide more than enough memory to work with. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From lev at FreeBSD.org Fri Dec 5 04:10:13 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Fri Dec 5 04:10:20 2008 Subject: NFS performance tuning? In-Reply-To: <4938ED14.8090101@delphij.net> References: <1682252731.20081205112939@serebryakov.spb.ru> <4938ED14.8090101@delphij.net> Message-ID: <49391A5C.50302@FreeBSD.org> Xin LI wrote: > What I usually use is: > mount_nfs -3Tr 262144 -w 262144 Yep, it helps to double speed. Much better. How should these options translates to /etc/fstab options? -- // Lev Serebryakov From samflanker at gmail.com Fri Dec 5 06:10:50 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Fri Dec 5 06:11:00 2008 Subject: vlan support trouble in if_sis driver ? Message-ID: <49392FDD.8050209@gmail.com> Hello Using sis card (SiS 900) sis0: port 0xe800-0xe8ff mem 0xed160000-0xed160fff irq 19 at device 4.0 on pci0 # uname -a FreeBSD damask 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # netstat -bin Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll sis0 1500 00:0d:61:xx:xx:xx 356 4 40934 155 0 29276 0 em0 1500 00:02:55:xx:xx:xx 0 0 0 0 0 0 0 lo0 16384 0 0 0 0 0 0 0 lo0 16384 fe80:3::1/64 fe80:3::1 0 - 0 0 - 0 - lo0 16384 ::1/128 ::1 0 - 0 0 - 0 - lo0 16384 127.0.0.0/8 127.0.0.1 0 - 0 0 - 0 - vlan0 1500 00:02:55:xx:xx:xx 0 0 0 0 0 0 0 vlan1 1500 00:0d:61:xx:xx:xx 255 0 29543 155 0 28656 0 # ifconfig sis0 sis0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0d:61:xx:xx:xx media: Ethernet autoselect (100baseTX ) status: active # ifconfig vlan1 vlan1: flags=8843 metric 0 mtu 1500 ether 00:0d:61:xx:xx:xx inet 192.168.1.221 netmask 0xffffff80 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 12 parent interface: sis0 noticed the following troubles with using interface vlan1 (vlandev sis0): - can not download a file using fget tool - increases Ierrs on the physical interface sis0 this bug in if_sis driver ? /Vladimir Ermakov From glebius at FreeBSD.org Fri Dec 5 06:40:23 2008 From: glebius at FreeBSD.org (glebius@FreeBSD.org) Date: Fri Dec 5 06:40:32 2008 Subject: kern/126984: [carp][patch] add carp userland notifications via devctl(4) Message-ID: <200812051440.mB5EeMm3086907@freefall.freebsd.org> Synopsis: [carp][patch] add carp userland notifications via devctl(4) State-Changed-From-To: open->feedback State-Changed-By: glebius State-Changed-When: Fri Dec 5 14:37:54 UTC 2008 State-Changed-Why: I've just committed a change that makes link state change announcement when CARP changes status. This includes devd announcement. This is more standard than arbitrary message and also makes us compatible with OpenBSD. Alexander, are you satisfied with this change? Can the PR be closed after merging? Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Fri Dec 5 14:37:54 UTC 2008 Responsible-Changed-Why: I've just committed a change that makes link state change announcement when CARP changes status. This includes devd announcement. This is more standard than arbitrary message and also makes us compatible with OpenBSD. Alexander, are you satisfied with this change? Can the PR be closed after merging? http://www.freebsd.org/cgi/query-pr.cgi?pr=126984 From brde at optusnet.com.au Fri Dec 5 08:50:18 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Dec 5 08:50:25 2008 Subject: NFS performance tuning? In-Reply-To: <4938ED14.8090101@delphij.net> References: <1682252731.20081205112939@serebryakov.spb.ru> <4938ED14.8090101@delphij.net> Message-ID: <20081206031724.F76672@delplex.bde.org> On Fri, 5 Dec 2008, Xin LI wrote: > Lev Serebryakov wrote: >> Hello, Freebsd-net. >> >> I have two systems (7-Stable), connected with gigabit link. iperf >> shows 667 Mbits/sec on TCP and 600Mbit/s on UDP without any tuning. >> >> But NFS gives me only 17Mb/s (~136 Mbit/s) on sequential read of MB >> very big files, and about 8-10Mb/s on "real" workloads. >> >> Are here any guides how to tune NFS for performance? > > rsize/wsize? I think the current default (8192) is too smal, perhaps > 262144 would be a better choice. The defaults of NFS_RSIZE/NFS_WSIZE (8192/8192) are only used for udp. The default is NFS_MAXDATA (32768) for tcp. This is large enough. > What I usually use is: > > mount_nfs -3Tr 262144 -w 262144 262144 is not supported. Size parameters larger than MAXBSIZE (65536) are silently reduced to MAXBSIZE. I use the defaults with tcp and IIRC 16K/16K with udp. IIRC 32K/32K doesn't work so well with udp, and there is a bug setting the defaults when toggling -T (apparently, defaults are only set initially, so if you start with udp and switch to tcp you keep the udp defaults for tcp, and vice versa). I use several optimizations for writing in the nfs server and several bug fixes for reading and writing in vfs clustering. Nfs latency is more of a problem than nfs throughput for some applications. E.g., compiling can take several times longer on nfs mainly because most of the time is spent waiting to reopen many include files many times each (the data normally remains cached after the first used, but each open() requires RPCs). I tune networks for latency and use some hacks to reduce the number of nfs RPCs, and compile with -j4 even on UP systems to reduce the effects of nonzero latency. Bruce From fjwcash at gmail.com Fri Dec 5 09:35:00 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Dec 5 09:35:07 2008 Subject: Virtual machine on freebsd In-Reply-To: <4938DF2A.6080409@unile.it> References: <49376544.70006@redhat.com> <20081204070239.X80401@maildrop.int.zabbadoz.net> <4938DF2A.6080409@unile.it> Message-ID: <200812050913.00889.fjwcash@gmail.com> On December 4, 2008 11:58 pm Antonio Tommasi wrote: > Hi to all, > i want to install a virtual machine on my FreeBSD 7.0 box. Can you tell > me which is the better sofware to do this? For a FreeBSD host, QEmu is the best supported option. There's also Win4BSD, which is a customised/modified version of QEmu. I've seen several reports online of this being better/faster than QEmu. I've never personally been able to get it to work, though. And that's pretty much it if you want full-OS virtualisation (ie, the VMs have their own OS). If you don't need that, and just want to run multiple FreeBSD setups on one host, have a look at jail(8). -- Freddie fjwcash@gmail.com From peterjeremy at optushome.com.au Fri Dec 5 11:44:56 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Dec 5 11:45:03 2008 Subject: Weird TCP connect issue in FreeBSD 6 In-Reply-To: References: <20081203193609.GB58682@server.vk2pj.dyndns.org> Message-ID: <20081205194449.GL58682@server.vk2pj.dyndns.org> On 2008-Dec-03 17:40:01 -0500, Benjie Chen wrote: >When I had two IPs from two different subnets configured for the two >NICs, I had the same error. So while I did have a configuration issue, >the problem with replicated SYNs did occur even when the two NICs had >IP addresses on different networks. OK, that does sound wrong. Can you describe that setup please - what local addresses/netmasks and routes did you have and what was the remote IP address. -- 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/20081205/7fcdbe1a/attachment.pgp From benjie at addgene.org Fri Dec 5 15:22:37 2008 From: benjie at addgene.org (Benjie Chen) Date: Fri Dec 5 15:22:44 2008 Subject: Weird TCP connect issue in FreeBSD 6 In-Reply-To: <20081205194449.GL58682@server.vk2pj.dyndns.org> References: <20081203193609.GB58682@server.vk2pj.dyndns.org> <20081205194449.GL58682@server.vk2pj.dyndns.org> Message-ID: Local address em0: some IP XXX, with appropriate mask, /27 em1: some IP YYY, on different subnet, with appropriate mask /27 apache: listening on XXX:80, YYY:80, XXX:443, YYY:443 I can connect to the 80 ports on both machine from a third IP on yet another network, and I can connect to XXX:443 just fine. Connecting to YYY:443 results in connection termination frequently, but not all the time. Tcpdump on XXX shows packets are coming into em1 and returned on em0, and that when termination occurs, initial SYN from client to YYY:443 is repeated many many times, resulting in many SYN ACKs and then later on ACKs from the client. I think syn-attack protecting code then kicks in and send a RST to tear down the connection on the server (this part I understand, but not sure why the SYN packets are repeatedly sent to the kernel) Benjie --- Benjie Chen, Ph.D. Addgene, a better way to share plasmids www.addgene.org Manage your lab more efficiently Addgene Labs - www.addgenelabs.org On Fri, Dec 5, 2008 at 2:44 PM, Peter Jeremy wrote: > On 2008-Dec-03 17:40:01 -0500, Benjie Chen wrote: >>When I had two IPs from two different subnets configured for the two >>NICs, I had the same error. So while I did have a configuration issue, >>the problem with replicated SYNs did occur even when the two NICs had >>IP addresses on different networks. > > OK, that does sound wrong. Can you describe that setup please - what > local addresses/netmasks and routes did you have and what was the > remote IP address. > > -- > 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. > From pyunyh at gmail.com Fri Dec 5 18:22:13 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 5 18:22:19 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <49392FDD.8050209@gmail.com> References: <49392FDD.8050209@gmail.com> Message-ID: <20081206022205.GD22093@cdnetworks.co.kr> On Fri, Dec 05, 2008 at 04:42:53PM +0300, Vladimir Ermakov wrote: > Hello > > Using sis card (SiS 900) > sis0: port 0xe800-0xe8ff mem > 0xed160000-0xed160fff irq 19 at device 4.0 on pci0 > > # uname -a > FreeBSD damask 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 > UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > # netstat -bin > Name Mtu Network Address Ipkts Ierrs Ibytes > Opkts Oerrs Obytes Coll > sis0 1500 00:0d:61:xx:xx:xx 356 4 > 40934 155 0 29276 0 > em0 1500 00:02:55:xx:xx:xx 0 0 > 0 0 0 0 0 > lo0 16384 0 0 > 0 0 0 0 0 > lo0 16384 fe80:3::1/64 fe80:3::1 0 - > 0 0 - 0 - > lo0 16384 ::1/128 ::1 0 - > 0 0 - 0 - > lo0 16384 127.0.0.0/8 127.0.0.1 0 - > 0 0 - 0 - > vlan0 1500 00:02:55:xx:xx:xx 0 0 > 0 0 0 0 0 > vlan1 1500 00:0d:61:xx:xx:xx 255 0 > 29543 155 0 28656 0 > > # ifconfig sis0 > sis0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:0d:61:xx:xx:xx > media: Ethernet autoselect (100baseTX ) > status: active > # ifconfig vlan1 > vlan1: flags=8843 metric 0 mtu 1500 > ether 00:0d:61:xx:xx:xx > inet 192.168.1.221 netmask 0xffffff80 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 12 parent interface: sis0 > > noticed the following troubles with using interface vlan1 (vlandev sis0): > - can not download a file using fget tool > - increases Ierrs on the physical interface sis0 > > this bug in if_sis driver ? I don't have sis(4) hardwares so I'm not sure it's bug. Since you see Ierrs on parent interface sis0, I guess the hardware might set a giant bit when it receives VLAN frames. Driver might think it received errored frames which in turn make driver drop these VLAN frames. Would you try attached patch?(Just compile tested). -- Regards, Pyun YongHyeon -------------- next part -------------- Index: sys/dev/sis/if_sisreg.h =================================================================== --- sys/dev/sis/if_sisreg.h (revision 185658) +++ sys/dev/sis/if_sisreg.h (working copy) @@ -348,6 +348,11 @@ #define SIS_RXSTAT_OVERRUN 0x02000000 #define SIS_RXSTAT_RX_ABORT 0x04000000 +#define SIS_RXSTAT_ERROR(x) \ + ((x) & (SIS_RXSTAT_RX_ABORT | SIS_RXSTAT_OVERRUN | \ + SIS_RXSTAT_GIANT | SIS_RXSTAT_SYMBOLERR | SIS_RXSTAT_RUNT | \ + SIS_RXSTAT_CRCERR | SIS_RXSTAT_ALIGNERR)) + #define SIS_DSTCLASS_REJECT 0x00000000 #define SIS_DSTCLASS_UNICAST 0x00800000 #define SIS_DSTCLASS_MULTICAST 0x01000000 Index: sys/dev/sis/if_sis.c =================================================================== --- sys/dev/sis/if_sis.c (revision 185658) +++ sys/dev/sis/if_sis.c (working copy) @@ -1432,7 +1432,11 @@ * it should simply get re-used next time this descriptor * comes up in the ring. */ - if (!(rxstat & SIS_CMDSTS_PKT_OK)) { + if ((ifp->if_capenable & IFCAP_VLAN_MTU) != 0 && + total_len <= (ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN - + ETHER_CRC_LEN)) + rxstat &= ~SIS_RXSTAT_GIANT; + if (SIS_RXSTAT_ERROR(rxstat) != 0) { ifp->if_ierrors++; if (rxstat & SIS_RXSTAT_COLL) ifp->if_collisions++; From healthy-wealthy-tea at freemail.lt Sat Dec 6 07:40:18 2008 From: healthy-wealthy-tea at freemail.lt (healthy-wealthy-tea freebsd-net) Date: Sat Dec 6 07:40:25 2008 Subject: Your friend healthy-wealthy-tea freebsd-net has recommended this great product from Green Tea & Me Message-ID: <3oUmtk-1L8z4H1rqZ-00050t@infong660.perfora.net> Hi freebsd-net! Your friend, healthy-wealthy-tea freebsd-net, thought that you would be interested in Matcha from Green Tea & Me. healthy-wealthy-tea freebsd-net sent a note saying: Amazing News, Get Paid, Look Smart And Stay Healthy! Hi Friend, Here's how it works... First, we detoxifies your body. Second, we burn your unwanted fats. Thus, we make all your friends jealous because you will actually lose weight the first day. And Third, you'll be paid the moment you start spreading the good news for others to try themselves with this extraordinary product. Visit this very important link below now!. http://123redirect.com/healthy-and-wealthy-tea So Goodluck, Look Good And Be Healthy, Associates http://123redirect.com/healthy-and-wealthy-tea Online Promoter P.S. Dr. Miller's Iaso Tea - formulated by Dr. Bill Miller (Bs.Ms.Ph.D. Nutritional Science) of Tennessee, USA - is a unique herbal blend of safe, all-natural ingredients designed to gently cleanse the digestive tract and detoxify the whole body. Iaso Tea is like a white tea, a green tea, a weight loss tea, and a great-tasting herbal tea - all wrapped up in each unbleached tea bag. But, most of all, Dr. Miller's Iaso Tea is a healing tea. Remarkable things happen when you drink Iaso Tea every day. It is gentle, yet surprisingly powerful as a colon cleanse, parasite cleanse, Candida cleanse, blood purifier, and whole body detoxifier. It acts like a general health tonic and a home remedy for many ailments like the ones mentioned below. Some want to call it a "miracle tea", but this cleansing and slimming tea is really just a special blend of high-quality herbs, tested and refined over time, which produce fast and effective results that no imitator has been able to copy. ------------------------------ Email here: healthy-wealthy-tea@freemail.lt and add "Not interested" ---------------------------------------------------------------------------------------- To view the product, click on the link below or copy and paste the link into your web browser: http://www.greenteame.com/store/index.php?main_page=product_info&products_id=1 Regards, Green Tea & Me http://www.greenteame.com/store/ ----- IMPORTANT: For your protection and to prevent malicious use, all emails sent via this web site are logged and the contents recorded and available to the store owner. If you feel that you have received this email in error, please send an email to customersupport@greenteame.com From samflanker at gmail.com Sat Dec 6 10:55:53 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Sat Dec 6 10:55:59 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <20081206022205.GD22093@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> Message-ID: > I don't have sis(4) hardwares so I'm not sure it's bug. Since you > see Ierrs on parent interface sis0, I guess the hardware might set > a giant bit when it receives VLAN frames. Driver might think it > received errored frames which in turn make driver drop these VLAN > frames. Thanks, your patch fixes a problem with the card (sis). in the output of netstat no errors and files downloaded through fget what tests need to try? /Vladimir Ermakov From marius at alchemy.franken.de Sun Dec 7 09:40:06 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Dec 7 09:40:12 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200812071740.mB7He5P4083821@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: freebsd@amc-os.com Cc: "bug-followup@FreeBSD.org" Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sun, 7 Dec 2008 18:36:26 +0100 Aurélien, could you please verify that the patch at: http://people.freebsd.org/~marius/bge_5701b5_pcix.diff solves your problem? Thanks, Marius From pyunyh at gmail.com Sun Dec 7 16:48:11 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Dec 7 16:48:17 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> Message-ID: <20081208004802.GB29560@cdnetworks.co.kr> On Sat, Dec 06, 2008 at 09:55:52PM +0300, Vladimir Ermakov wrote: > > I don't have sis(4) hardwares so I'm not sure it's bug. Since you > > see Ierrs on parent interface sis0, I guess the hardware might set > > a giant bit when it receives VLAN frames. Driver might think it > > received errored frames which in turn make driver drop these VLAN > > frames. > > Thanks, your patch fixes a problem with the card (sis). > in the output of netstat no errors and files downloaded through fget > Good. Would you show me the output of "pciconf -lcv"? If I don't see any oddities in the output, I would commit the patch. > what tests need to try? > If parent interface sis0 still works as expected(i.e. without VLAN) there is no need to test other cases, I guess. > /Vladimir Ermakov -- Regards, Pyun YongHyeon From numardbsd at gmail.com Sun Dec 7 22:33:29 2008 From: numardbsd at gmail.com (Norberto Meijome) Date: Sun Dec 7 22:33:36 2008 Subject: Virtual machine on freebsd In-Reply-To: <200812050913.00889.fjwcash@gmail.com> References: <49376544.70006@redhat.com> <20081204070239.X80401@maildrop.int.zabbadoz.net> <4938DF2A.6080409@unile.it> <200812050913.00889.fjwcash@gmail.com> Message-ID: <20081208171245.4271ca86@ayiin> On Fri, 5 Dec 2008 09:13:00 -0800 Freddie Cash wrote: > On December 4, 2008 11:58 pm Antonio Tommasi wrote: > > Hi to all, > > i want to install a virtual machine on my FreeBSD 7.0 box. Can you tell > > me which is the better sofware to do this? Antonio, you would have received more answers if you asked in the right forum ( questions@). > > For a FreeBSD host, QEmu is the best supported option. > > There's also Win4BSD, which is a customised/modified version of QEmu. I've > seen several reports online of this being better/faster than QEmu. I've > never personally been able to get it to work, though. Works ok, though I don't think it's that so much faster than QEmu that makes it worth going through the effort of recreating your VMs.... YMMV. > > And that's pretty much it if you want full-OS virtualisation (ie, the VMs > have their own OS). If you don't need that, and just want to run multiple > FreeBSD setups on one host, have a look at jail(8). > - VMWare Workstation {very old version} is in ports. You need an *old* license from vmware...no idea how well it works. - http://wiki.freebsd.org/FreeBSD/Xen - still not production ready. Check the archives of questions@ for more threads on this subject. cheers, B _________________________ {Beto|Norberto|Numard} Meijome If you were supposed to understand it, we wouldn't call it 'code'. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From fernercc at gmail.com Sun Dec 7 23:58:39 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Sun Dec 7 23:58:46 2008 Subject: FreeBSD kernel module and sending udp packets Message-ID: <1228699701.4940.2.camel@mobiliare.Belkin> Hello everyone. I need help with documentation concerning how to send a udp or tcp packet from a kernel module. I have found this information for Linux but not for FreeBSD. Please help me. Thank you :) From fernercc at gmail.com Mon Dec 8 00:13:43 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Mon Dec 8 00:13:49 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <493CD5AB.8030303@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> Message-ID: <1228702422.4940.7.camel@mobiliare.Belkin> Thanks for the reply. I read something about that but I didn't understand what was being said. Can you please help me in understanding. I have googled for sample code and didn't find anything useful. Can you, or anyone else, please help me understand this? Thanks again :) On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: > Ferner Cilloniz wrote: > > Hello everyone. > > > > I need help with documentation concerning how to send a udp or tcp > > packet from a kernel module. I have found this information for Linux but > > not for FreeBSD. > > > > Please help me. > > you could give your module a netgraph interface. Then it can connect > directly to the ng_ksocket node type and use that. as a nin-kernel socket. > > > > > > > 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 julian at elischer.org Mon Dec 8 00:20:04 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 00:20:11 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <1228699701.4940.2.camel@mobiliare.Belkin> References: <1228699701.4940.2.camel@mobiliare.Belkin> Message-ID: <493CD5AB.8030303@elischer.org> Ferner Cilloniz wrote: > Hello everyone. > > I need help with documentation concerning how to send a udp or tcp > packet from a kernel module. I have found this information for Linux but > not for FreeBSD. > > Please help me. you could give your module a netgraph interface. Then it can connect directly to the ng_ksocket node type and use that. as a nin-kernel socket. > > 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 julian at elischer.org Mon Dec 8 00:23:40 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 00:23:46 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <1228702422.4940.7.camel@mobiliare.Belkin> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> Message-ID: <493CD98D.7000909@elischer.org> Ferner Cilloniz wrote: > Thanks for the reply. I read something about that but I didn't > understand what was being said. > > Can you please help me in understanding. I have googled for sample code > and didn't find anything useful. Can you, or anyone else, please help me > understand this? http://people.freebsd.org/~julian/netgraph.html > > Thanks again :) > > On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: >> Ferner Cilloniz wrote: >>> Hello everyone. >>> >>> I need help with documentation concerning how to send a udp or tcp >>> packet from a kernel module. I have found this information for Linux but >>> not for FreeBSD. >>> >>> Please help me. >> you could give your module a netgraph interface. Then it can connect >> directly to the ng_ksocket node type and use that. as a nin-kernel socket. >> >> >> >>> 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 julian at elischer.org Mon Dec 8 00:32:12 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 00:32:19 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <493CD98D.7000909@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> Message-ID: <493CDB8F.7040709@elischer.org> Julian Elischer wrote: > Ferner Cilloniz wrote: >> Thanks for the reply. I read something about that but I didn't >> understand what was being said. >> >> Can you please help me in understanding. I have googled for sample code >> and didn't find anything useful. Can you, or anyone else, please help me >> understand this? > > http://people.freebsd.org/~julian/netgraph.html I should add: http://fxr.watson.org/fxr/source/netgraph/ng_sample.c as a pointer to netgraph sources. From julian at elischer.org Mon Dec 8 00:47:54 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 00:48:02 2008 Subject: Vimage howto Message-ID: <493CDF3C.5030608@elischer.org> Well not completely, but I've had a number of questions over the last few months about what it is, so, as Marko and I have written the following "how to virtualize your module" document, I've been directing people to it. After another couple of questions I think this could do with wider distribition.. It is available at: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt but I include it here for popular enjoyment. Please contact me or Marko if you have any questions or suggestions on this. -------------- next part -------------- =================== Vimage: what is it? =================== Vimage is a framework in the BSD kernel which allows a co-operating module to operate on multiple independent instances of its state so that it can participate in a virtual machine / virtual environment scenario. The implementation approach taken by the vimage framwork is a replacement of selected global state variables with constructs that allow for the virtualized state to be stored and resolved in appropriate instances of module-specific container structures. The code operating on virtualized state has to conform to a set of rules described further below, among other things in order to allow for all the changes to be conditionally compilable, i.e. permitting the virtualized code to fall back to operation on global state. The most visible change throughout the existing code is typically replacement of direct references to global variables with macros; foo_bar thus becomes V_foo_bar. V_foo_bar macros will resolve back to foo_bar global in default kernel builds, and alternatively to some_base_pointer->_foo_bar for "options VIMAGE" kernel configs. Prepending of "V_" prefixes to variable references helps in visual discrimination between global and virtualized state. The framework extends the sysctl infrastructure to support access to virtualized state through introduction of the SYSCTL_V family of macros; those also automatically fall back to their standard SYSCTL counterparts in default kernel builds. Transparent kldsym(2) lookups are provided to virtualized variables explicitly marked for visibility to kldsym interface, which permits userland binaries such as netstat to operate unmodified on "options VIMAGE" kernels, though this may have wide security implications. The vimage struct is currently primarily a placeholder for pointers to module-specific struct instances; currently V_NET (networking), V_CPU (CPU scheduling), and V_PROCG (jail-style interprocess protection) major module classes are defined. Each vimage module may or may not be further split into minor or submodules; the networking subsystem (vimage id V_NET; struct vnet) in particular is organized in submodules such as VNET_MOD_NET (mandatory shared infrastructure: routing tables, interface lists etc.); VNET_MOD_INET (IPv4 state including transport protocols); VNET_MOD_INET6, VNET_MOD_IPSEC, VNET_MOD_IPFW, VNET_MOD_NETGRAPH etc. The speciality of VNET submodules is in that they not only provide storage for virtualized data, but also enforce ordering of initialization and cleanup. Hence, not all submodules must necessarily allocate private storage for their specific data; they may be defined solely for to support proper initialization ordering. Each process is associated with a vimage, and vimages currently hang off of ucred-s. This relationship defines a process's administrative affinity to a vimage and thus indirectly to all of its modules (NET, CPU, PROCG) as well as to any submodules. All network interfaces and sockets hold pointers back to their parent vnets; this relationship is obviously entirely independent from proc->ucred->vimage bindings. Hence, when a process opens a socket, the socket will get bound to a vnet instance hanging off of proc->ucred->vimage->vnet, but once such a socket->vnet binding gets established, it cannot be changed for the entire socket lifetime. Certain classes of network interfaces (Ethernet in particular) can be assigned from one vnet to another at any time. By definition all vnets are are independent and can communicate only if they are explicitly provided with communication paths; currently only netgraph can be used to establish inter-vnet datapaths. In network traffic processing the vnet affinity is defined either by the inbound interface or by the socket / pcb -> vnet binding. However, there are many functions in the network stack that cannot implicitly fetch the vnet context from their standard arguments. Instead of explicitly extending argument lists of such functions with a struct vnet *, a per-thread variable td_vnet was introduced, which can be fetched via the curvnet macro (#define curvnet curthread->td_vnet). The curvnet context has to be set on entry to the network stack (socket operations, packet reception, or timer-driven functions) and cleared on exit. This must be done via provided CURVNET_SET() / CURVNET_RESTORE() family of macros, which allow for "stacking" of curvnet context setting and provide additional debugging info in INVARIANTS kernel configs. In most cases however a developer writing virtualized code will not have to set / restore the curvnet context unless the code would include timer-driven events, given that those are inherently vnet-contextless on entry. Converting / virtualizing existing code ======================================= There are several steps need in virtualisation. 1/ decide whether the module needs to be virtualised. if the module is a driver for specific hardware, it makes sense that there be only one instance of the driver as there is only one piece of physical hardware. There are changes in the networking code to allow physical (or virtual) interfaces to be moved between vnets. This generally requires NO changes to the network drivers of the classes covered (e.g. ethernet). 2/ decide if your module is part of one of the major module groups. These are currently V_NET V_PROCG V_CPU. The reader will note that the descriptions below use the acronym VNET a lot. The vimage system has been at this time broken into a number of subsections. One of these is the "VNET" group. The idea of these subsections is that they might be individually selected as virtualizable in a particular virtual machine instance. As an example, in a virtualization, one might to allocate a couple of processors to it, but keep the same filesystem and network setup, or alternatively to share processors but to have virtualised networking. 3/ If the module is to be virtualised, decide which attributes of the module should be virtualised. For example, It may make sense that there be a single central pool of "struct foo" and a single uma zone for them to come from, with a single lock guarding it. It might also make sense if the "foo_debug" sysctl controls all the instances at once, while on the other hand, the "foo_mode" sysctl might make better sense if it were controllable on a virtual system by virtual system basis. 4/ Work out what global variables and structures are to be virtualised to achieve the behaviour required for part #3. 5/ Work out for all the code paths through the module, how the path entering the module can divine which virtual environment it is on. Some examples: * Since interfaces are all assigned to one vnet or another, an incoming packet has a pointer to the receive interface, which in turn has a pointer back to the vnet. Often "curvnet" will already have been set by the time your code is called anyhow. * Similarly, on any request from outside the kernel, (direct or indirect) the current thread has a way to get to the current virtual environment instance via td->ucred->vimage. For existing sockets the vnet context must be used via so->so_vnet since td->ucred->vimage might change after socket creation. * Timer initiated actions usually have a (void *) argument which points to some private structure for the module. It should be possible to add a pointer to the appropriate module instance into whatever structure that points to. * Sometimes an action (timer trigerred or trigerred by module load or unload simply has to check all the vimage or module instances. There are macro (pairs) for this which will iterate through all the VNET or VPROCG instances. This covers most of the cases, however in some cases it may still be required for the module to stash away the virtual environment instance somewhere, and make associated changes in the code. 6/ Add the code described below to the files that make up the module Details: temp. note: for module FOO add a definition for VNET_MOD_FOO in sys/vimage.h. This will eventually be dynamically assigned. For now these instructions refer mainly to VNET and not VCPU, VPROCG etc. Symbols defined in other modules that have been virtualised will have been moved to a module-specific virtualisation structure. It will be defined in a .h file for just this purpose. If a module will never export virtualise symbols beyond it's borders, then this structure may well just be in a common include file for that module. As an example, common networking (but not protocol) variables have been moved to a file called net/vnet.h, but the gre module has simply added the virtualisation structure to if_gre.h as no code outside the gre interface will access those values. Accesses to virtualised symbols are achieved via macros, which generally are of the same name as the original symbol but with a "V_" prepended, thus the head of the interface list, called 'ifnet' is replaced whereever used with "V_ifnet". In SCTP, because the code is shared with other OS's they are replaced with a macro MODULE_GLOBAL(modulename, symbol). In the current version of vimage, when VIMAGE is not compiled into the kernel, the macros evaluate to a direct reference to the symbol. In future versions it will evaluate to a global version of the virtualisation structure with the offset to the entry in quesiton, which will result in a single direct memory reference, so that the speed will be as it is now. When VIMAGE is compiled in, the macro will evaluate to an access to an element in a structure pointed to by a local varible. For this reason, it is necessary to also add, at the beginning of these functions another macro that will instantiate this local variable and point it at the correct place. As an example, prior to using the "V_ifnet" structure in a program block, we must add the following macro at the head of a code block enclosing the references to set up module-specific base pointer variable: INIT_VNET_NET(initial_value); /* initial value is usually curvnet */ When VIMAGE is not defined, this will evaluate to nothing but when it IS defined, it will evaluate to: struct vnet_net *vnet_net = (initial_value); The initial value is usually something like "curvnet" which in turn is a macro that derives the vnet affinity from the current thread. It could also be (m->m_ifp->if_vnet) if we were receiving an mbuf. In the case where it is just one function in a module calling another (static), the porter might decide to simply pass the local variable as an argument, rather than to reevaluate it in the function, but should be prepared to cope with the fact that the code might be compiled in the "no-VIMAGE" manner (in which case the argument would be marked as "unused"). Usually, when a packet enters the system it is carried through the processing path via a single thread, and that thread will set its virtual environment reference to that indicated by the packet on picking up that new packet. This means that in the normal inbound processing path as well as the outgoing process path the current thread can be used to indicate the current virtual environment. In the case of timer initiated events, best practice would also be to set the current virtual module reference to that indicated calculated by whatever way that would be done, so that any functions called could rely on the current thread being a good reference for the correct virtual module. When a new VNET submodule is defined for virtualisation, the following structure defining macro is used to define it to the framework. #define VNET_MOD_DECLARE(m_name_uc, m_name_lc, m_iattach, m_idetach, \ m_dependson, m_symmap) \ static const struct vnet_modinfo vnet_##m_name_lc##_modinfo = { \ .vmi_id = VNET_MOD_##m_name_uc, \ .vmi_dependson = VNET_MOD_##m_dependson, \ .vmi_name = #m_name_lc, \ .vmi_iattach = m_iattach, \ .vmi_idetach = m_idetach, \ .vmi_struct_size = \ sizeof(struct vnet_##m_name_lc), \ .vmi_symmap = m_symmap \ The ID we allocated in the temporary first step in "Details" is the first entry here; eventually this should be automatically done by module name. The DEPENDSON field tells us the order that modules should be initialised in a new virtual environment. This may later need to be changed to a list of text module names for dynamic calculation. The rest of the fields are self explanatory, with the exception of the symmap entry. The symmap allows us to intercept calls by libkvm to the linker when it is looking up symbols and to redirect it dynamically. this allows for example "netstat -r" to find the routing tables for THIS virtual environment. (of course that won't work for core dumps). (XXX *needs thought *) As example of virtualising a dummy module named the FOO module the following code might be added to a special vfoo.h or at least to the exisitng foo.h file: ======================================================== #ifndef _DIR_VFOO_H_ #define _DIR_VFOO_H_ #include /* for struct foo_bar */ #define INIT_VNET_FOO(vnet) \ INIT_FROM_VNET(vnet, VNET_MOD_FOO, \ struct vnet_foo, vnet_foo) #define VNET_FOO(sym) VSYM(vnet_foo, sym) #if (defined(VIMAGE) || defined(FUTURE)) struct vnet_foo { int _foo_counter struct foo_bar _foo_barx; }; #endif /* Symbol translation macros */ #define V_foo_counter VNET_FOO(foo_counter) #define V_foo_barx VNET_FOO(foo_barx) #endif /* !_FOO_VFOO_H_ */ ========================================================= For each time the foo module is initiated for a new virtual environment, the foo_bar structure must be initiated, so a new foo_creator and destructor functions are defined for the module. The Module will call these when a new virtual environment is created or destroyed. The constructor must be called once for the base machine when the system is booted, even when options VIMAGE is not defined. ==================== in module foo.c ====== #include "opt_vimage.h" [...] #include [...] #include [...] #ifndef VIMAGE /* initially the globals would have been here, * and for now we will leave them here when not using VIMAGE. * In the future we will instead have a static version of the structure. */ # if defined(FUTURE) struct vnet_foo vnet_foo_globals; # else /* !FUTURE */ int foo_counter = 0; struct foo_bar foo_barx = {}; # endif /* !FUTURE */ #endif /* !VIMAGE */ [...] #if (defined(VIMAGE) || defined(FUTURE)) static vnet_attach_fn vnet_foo_iattach; static vnet_detach_fn vnet_foo_idetach; #endif #ifdef VIMAGE /* If we have symbols we need to divert for libkvm * then put them in here. We may not need to do anything if * the symbols are not used by libkvm. */ static struct vnet_symmap vnet_net_symmap[] = { VNET_SYMMAP(foo, foo_counter), VNET_SYMMAP(foo, foo_barx), VNET_SYMMAP_END }; /* * Declare our module and state that we want to be done after the * loopback interface is initialised for the virtual environment. */ VNET_MOD_DECLARE(FOO, foo, vnet_foo_iattach, vnet_foo_idetach, LOIF, vnet_foo_symmap) #endif /* VIMAGE */ [...] /* a pre-exisiting 'foo' function that will be converted. */ void foo_work(void) { INIT_VNET_FOO(curvnet); /* Add this at the front */ V_foo_counter++; /* add "V_" to the front of the symbol */ [...] V_foo_barx.mumble = V_foo_counter; /* and here too */ [...] } /* * A function which on entry has no idea of which vnet it is on * and needs to look at them all for some reason. * NOTE! if this code is running in a thread that * does nothing else, or otherwise doesn't care about which * vnet it is on then the steps that save and restore the previous vnet * need not be done. (Marked with /* XXX */) */ void foo_tick(void) { VNET_ITERATOR_DECL(vnet_iter); [...] [...] VNET_LIST_RLOCK(); VNET_LIST_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); INIT_VNET_NET(vnet_iter); [...] do work, including calling code that assumes we have curvnet set. [...] CURVNET_RESTORE(); } VNET_LIST_RUNLOCK(); [...] } #if (defined(VIMAGE) || defined(FUTURE)) static int vnet_foo_iattach(const void *unused) { INIT_VNET_FOO(curvnet); V_foo_counter = 0; bzero (&V_foo_barx, sizeof (V_foo_barx)); return 0; } #endif #ifdef VIMAGE static int vnet_foo_idetach(const void *unused) { INIT_VNET_FOO(curvnet); /* prove we are ready to remove the module */ /* code here to do work required */ return 0; } #endif /* VIMAGE */ /* * Handle loading and unloading for this code. * The only thing we need to link into is the NETISR strucure. */ static int foo_mod_event(module_t mod, int event, void *data) { int error = 0; switch (event) { case MOD_LOAD: /* Initialize everything. */ /* put your code here */ #ifdef VIMAGE /* This will do the work for each vortual environment. */ vnet_mod_register(&vnet_foo_modinfo); #else /* !VIMAGE */ #ifdef FUTURE /* otherwise do the initialisation directly */ vnet_foo_iattach(NULL); #else /* !FUTURE */ /* otherwise the intialisation is done statically */ #endif /* !FUTURE */ #endif /* !VIMAGE */ break; case MOD_UNLOAD: /* You can't unload it because an interface may be using it. */ /* this needs work */ /* Should refuse to unload if any virtual environment */ /* are using this still. */ /* MARKO, fill in here */ error = EBUSY; break; default: error = EOPNOTSUPP; break; } return (error); } From jiabwang at redhat.com Mon Dec 8 01:55:21 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Mon Dec 8 01:55:28 2008 Subject: [snmpd]could you tell me how to open upd6 port 161 Message-ID: <493CEF35.7050009@redhat.com> Hello, all: could you help me how to open inet6 udp port 161 of snmpd agent as a listen port Thanks jiabo From samflanker at gmail.com Mon Dec 8 02:16:52 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Mon Dec 8 02:16:58 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <20081208004802.GB29560@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> Message-ID: <493CF424.4040206@gmail.com> Pyun YongHyeon wrote: > Good. Would you show me the output of "pciconf -lcv"? > If I don't see any oddities in the output, I would commit the > patch. > > > what tests need to try? > > > > If parent interface sis0 still works as expected(i.e. without VLAN) > there is no need to test other cases, I guess. > > OK # pciconf -lvc ... sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 rev=0x90 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 sis 900 and integrated lan' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 ... /Vladimir Ermakov From bugmaster at FreeBSD.org Mon Dec 8 03:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 8 03:08:33 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200812081106.mB8B6x8o014335@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/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/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 kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/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 196 problems total. From bms at FreeBSD.org Mon Dec 8 08:21:39 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Dec 8 08:21:45 2008 Subject: Vimage howto In-Reply-To: <493CDF3C.5030608@elischer.org> References: <493CDF3C.5030608@elischer.org> Message-ID: <493D458D.1000308@FreeBSD.org> Julian, Thank you (and Marko) very much for preparing this document. The VIMAGE import has had me at something of an impasse re: the IGMPv3 branch and clearly written documentation is a big help indeed. Julian Elischer wrote: > Well not completely, but I've had a number of questions over the > last few months about what it is, so, as Marko and I have written > the following "how to virtualize your module" document, I've been > directing people to it. After another couple of questions I think > this could do with wider distribition.. Thank you also for providing it here on the list, as opposed to relying on Perforce alone. Whilst I understand committers rate p4 for experimental work in the FreeBSD sphere, sadly it is simply not accessible to the not-so-silent majority in the FreeBSD sphere who are not committers, which makes its continued use questionable at best. regards, BMS From espartano.mail at gmail.com Mon Dec 8 10:13:28 2008 From: espartano.mail at gmail.com (Espartano) Date: Mon Dec 8 10:13:35 2008 Subject: Driver Iwn in FreeBSD 7.1 ? Message-ID: Hi list, Someone know if the driver iwn will be officially included in FreeBSD 7.1 ? -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From fernercc at gmail.com Mon Dec 8 10:47:21 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Mon Dec 8 10:47:28 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <493CD98D.7000909@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> Message-ID: <1228740437.4956.1.camel@mobiliare> Hi Julian. I'm very happy for your help. I have read the guide to netgraph and find it very interesting :) I still dont understand when you say "you could give your module a netgraph interface." Can you please explain this a little more please? Thanks. On Mon, 2008-12-08 at 00:23 -0800, Julian Elischer wrote: > Ferner Cilloniz wrote: > > Thanks for the reply. I read something about that but I didn't > > understand what was being said. > > > > Can you please help me in understanding. I have googled for sample code > > and didn't find anything useful. Can you, or anyone else, please help me > > understand this? > > http://people.freebsd.org/~julian/netgraph.html > > > > > Thanks again :) > > > > On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: > >> Ferner Cilloniz wrote: > >>> Hello everyone. > >>> > >>> I need help with documentation concerning how to send a udp or tcp > >>> packet from a kernel module. I have found this information for Linux but > >>> not for FreeBSD. > >>> > >>> Please help me. > >> you could give your module a netgraph interface. Then it can connect > >> directly to the ng_ksocket node type and use that. as a nin-kernel socket. > >> > >> > >> > >>> 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" > > > -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From julian at elischer.org Mon Dec 8 11:32:12 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 11:32:19 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <1228740437.4956.1.camel@mobiliare> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> Message-ID: <493D6F6E.4020900@elischer.org> Ferner Cilloniz wrote: > Hi Julian. I'm very happy for your help. I have read the guide to > netgraph and find it very interesting :) > > I still dont understand when you say "you could give your module a > netgraph interface." > > Can you please explain this a little more please? You indicated that you were going to be writing your own module. your module should include the interface functions indicated in ng_sample.c That will allow your module to be hooked up to the other netgraph modules in whatever orrder you want, and that includes the ng_ksocket module that would allow your module to sned and receive data through the in-kernel socket. > > Thanks. > > On Mon, 2008-12-08 at 00:23 -0800, Julian Elischer wrote: >> Ferner Cilloniz wrote: >>> Thanks for the reply. I read something about that but I didn't >>> understand what was being said. >>> >>> Can you please help me in understanding. I have googled for sample code >>> and didn't find anything useful. Can you, or anyone else, please help me >>> understand this? >> http://people.freebsd.org/~julian/netgraph.html >> >>> Thanks again :) >>> >>> On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: >>>> Ferner Cilloniz wrote: >>>>> Hello everyone. >>>>> >>>>> I need help with documentation concerning how to send a udp or tcp >>>>> packet from a kernel module. I have found this information for Linux but >>>>> not for FreeBSD. >>>>> >>>>> Please help me. >>>> you could give your module a netgraph interface. Then it can connect >>>> directly to the ng_ksocket node type and use that. as an in-kernel socket. >>>> >>>> >>>> >>>>> 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 bzeeb-lists at lists.zabbadoz.net Mon Dec 8 13:05:06 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Dec 8 13:05:14 2008 Subject: Problem with new source address selection In-Reply-To: <200812031220.mB3CK204015947@post.behrens.de> References: <200811280653.mAS6r1P3014050@post.behrens.de> <200812031220.mB3CK204015947@post.behrens.de> Message-ID: <20081208205426.V80401@maildrop.int.zabbadoz.net> On Wed, 3 Dec 2008, Frank Behrens wrote: Hi, > As I mentioned earlier I believe the main problem is IPSEC itself, > where we don't have an interface for tunneled connections. So I made > a workaround with a dummy loopback device. So I have a question to > the network specialists: Is there no other solution? Am I the only > stupid man, who wants to tunnel a subnet with private address range > via IPSEC? No, you aren't. Let me try to explain a bit further why I don't think it's an IPsec problem (at least not in first place). Asume you'd not run IPsec but communicate with the people directly (with valid IPs). Instead of having policies to control the traffic you are using simple IP filters on each side. So now in your network topology, with your setup, with the destination not being on a directly connected network, what would source address selection pick as outgoing IP (obviously w/o the hack with the route to the loopback)? Would that IP match your policy and thus would the peer permit it in its firewall? >> When it comes to the source address selection I am tempted to answer >> with: I am willing to still allow this in 7 to not break production >> setups but I am inclined to not change HEAD and keep the behavior >> dropped there. See patch below, which basically is what you had with >> the version check and the if (ia == NULL) check to not blindly overwrite >> if we had found anything closer (untested). > > Thanks, I will try this. I am still discussing things, or rather have the question queued with someone but we are all a bit busy atm. Did you try the patch and did it work for you as expected? If so I'll add it to my repo and the next jail patch. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From ericx at vineyard.net Mon Dec 8 13:15:13 2008 From: ericx at vineyard.net (Eric W. Bates) Date: Mon Dec 8 13:15:26 2008 Subject: ipfw policy routing esp Message-ID: <493D8A3F.6040502@vineyard.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have a bewildering problem attempting to policy route esp traffic. We have 2 up steam internet sources: a routable T1 and a cable modem. The cable modem provides better bandwidth so while we default to the T1, we use policy routing to send some of our traffic out the cable modem. In particular we use the cable modem for all the port 80 traffic via squid. squid's source IP is the one belonging to the cable network and we have the following ipfw rule for the policy route: ${fwcmd} add 64902 fwd ${cable_gw} ip from ${net_wan3_local} to any cable_gw is the cable company's router. net_wan3_local is the cable company's IP on our external interface. This works great for all port 80 tcp traffic. To this we added some IPSec. Racoon is hanging off the same ${net_wan3_local} and the udp port 500 traffic passes in and out thru the cable interface as we hoped. The bewildering part is that while the esp traffic can demonstrably be seen to be hitting the policy route rule, those packets continue to pass out the default route to the T1 rather than being forwarded to the cable router as we want. Any thoughts? Is this a known problem? Thank you for your time. - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPYo/D1roJTQ4LlERAp//AJ9C5VFQWk0Q5iwKVD6elTItny8pLgCbB5Tn 9a3/ut3rswi7nPs10nCkk9s= =wW3o -----END PGP SIGNATURE----- From ericx at vineyard.net Mon Dec 8 13:15:13 2008 From: ericx at vineyard.net (Eric W. Bates) Date: Mon Dec 8 13:15:26 2008 Subject: [Fwd: ipfw policy routing esp] Message-ID: <493D8C4C.5030105@vineyard.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I forgot to mention: we are using 6.2-RELEASE-p1. - -------- Original Message -------- Subject: ipfw policy routing esp Date: Mon, 08 Dec 2008 15:57:35 -0500 From: Eric W. Bates To: freebsd-net@freebsd.org We have a bewildering problem attempting to policy route esp traffic. We have 2 up steam internet sources: a routable T1 and a cable modem. The cable modem provides better bandwidth so while we default to the T1, we use policy routing to send some of our traffic out the cable modem. In particular we use the cable modem for all the port 80 traffic via squid. squid's source IP is the one belonging to the cable network and we have the following ipfw rule for the policy route: ${fwcmd} add 64902 fwd ${cable_gw} ip from ${net_wan3_local} to any cable_gw is the cable company's router. net_wan3_local is the cable company's IP on our external interface. This works great for all port 80 tcp traffic. To this we added some IPSec. Racoon is hanging off the same ${net_wan3_local} and the udp port 500 traffic passes in and out thru the cable interface as we hoped. The bewildering part is that while the esp traffic can demonstrably be seen to be hitting the policy route rule, those packets continue to pass out the default route to the T1 rather than being forwarded to the cable router as we want. Any thoughts? Is this a known problem? Thank you for your time. - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPYxMD1roJTQ4LlERAoDTAKDJPqrxuz0hOPrAPJFS67Aduqw66gCgseE6 XOj2frj9zTFp70UcQcuBgQA= =qa+4 -----END PGP SIGNATURE----- From julian at elischer.org Mon Dec 8 13:53:59 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 13:54:06 2008 Subject: ipfw policy routing esp In-Reply-To: <493D8A3F.6040502@vineyard.net> References: <493D8A3F.6040502@vineyard.net> Message-ID: <493D9777.8070508@elischer.org> Eric W. Bates wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We have a bewildering problem attempting to policy route esp traffic. > > We have 2 up steam internet sources: a routable T1 and a cable modem. > The cable modem provides better bandwidth so while we default to the T1, > we use policy routing to send some of our traffic out the cable modem. > > In particular we use the cable modem for all the port 80 traffic via > squid. squid's source IP is the one belonging to the cable network and > we have the following ipfw rule for the policy route: > > ${fwcmd} add 64902 fwd ${cable_gw} ip from ${net_wan3_local} to any > > cable_gw is the cable company's router. > net_wan3_local is the cable company's IP on our external interface. > > This works great for all port 80 tcp traffic. > > To this we added some IPSec. Racoon is hanging off the same > ${net_wan3_local} and the udp port 500 traffic passes in and out thru > the cable interface as we hoped. > > The bewildering part is that while the esp traffic can demonstrably be > seen to be hitting the policy route rule, those packets continue to pass > out the default route to the T1 rather than being forwarded to the cable > router as we want. > > Any thoughts? > Is this a known problem. There are definitely some oddnesses with IPSEC encapsulation and routes etc. If you are using 7.1-PRERELEASE or 8 you might consider using setfib to assign a separate routing table to the tcp traffic. > > Thank you for your time. > > - -- > Eric W. Bates > ericx@vineyard.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJPYo/D1roJTQ4LlERAp//AJ9C5VFQWk0Q5iwKVD6elTItny8pLgCbB5Tn > 9a3/ut3rswi7nPs10nCkk9s= > =wW3o > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From linimon at FreeBSD.org Mon Dec 8 14:05:17 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Dec 8 14:05:28 2008 Subject: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Message-ID: <200812082205.mB8M5HLu020502@freefall.freebsd.org> Old Synopsis: Kernel panic with EtherIP (may be related to SVN commit 178025) New Synopsis: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 8 22:04:09 UTC 2008 Responsible-Changed-Why: Possibly net-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=129508 From fernercc at gmail.com Mon Dec 8 14:21:48 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Mon Dec 8 14:21:55 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <493D6F6E.4020900@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> <493D6F6E.4020900@elischer.org> Message-ID: <1228753304.4948.6.camel@mobiliare.Belkin> Yes I am writing my own loadable kernel module such that I can send a UDP packet when i tell it to by issuing a homemade system call. I have been looking at /usr/src/sys/netgraph/ng_sample.c Am i supposed to implement the functions in that file? I am a little lost. I only want to send a UDP packet and in that file I see functions concerning receiving. Is there any other way? Thanks Julian and everyone else. On Mon, 2008-12-08 at 11:03 -0800, Julian Elischer wrote: > Ferner Cilloniz wrote: > > Hi Julian. I'm very happy for your help. I have read the guide to > > netgraph and find it very interesting :) > > > > I still dont understand when you say "you could give your module a > > netgraph interface." > > > > Can you please explain this a little more please? > > > You indicated that you were going to be writing your own module. > your module should include the interface functions indicated in > ng_sample.c > > That will allow your module to be hooked up to the other netgraph > modules in whatever orrder you want, and that includes the ng_ksocket > module that would allow your module to sned and receive data through > the in-kernel socket. > > > > > > Thanks. > > > > On Mon, 2008-12-08 at 00:23 -0800, Julian Elischer wrote: > >> Ferner Cilloniz wrote: > >>> Thanks for the reply. I read something about that but I didn't > >>> understand what was being said. > >>> > >>> Can you please help me in understanding. I have googled for sample code > >>> and didn't find anything useful. Can you, or anyone else, please help me > >>> understand this? > >> http://people.freebsd.org/~julian/netgraph.html > >> > >>> Thanks again :) > >>> > >>> On Mon, 2008-12-08 at 00:07 -0800, Julian Elischer wrote: > >>>> Ferner Cilloniz wrote: > >>>>> Hello everyone. > >>>>> > >>>>> I need help with documentation concerning how to send a udp or tcp > >>>>> packet from a kernel module. I have found this information for Linux but > >>>>> not for FreeBSD. > >>>>> > >>>>> Please help me. > >>>> you could give your module a netgraph interface. Then it can connect > >>>> directly to the ng_ksocket node type and use that. as an in-kernel socket. > >>>> > >>>> > >>>> > >>>>> 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" > -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From spawk at acm.poly.edu Mon Dec 8 14:22:28 2008 From: spawk at acm.poly.edu (Boris Kochergin) Date: Mon Dec 8 14:22:40 2008 Subject: if_gif/if_bridge problem In-Reply-To: <20081024042123.GA45452@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> <4900D086.2000703@acm.poly.edu> <20081024042123.GA45452@svzserv.kemerovo.su> Message-ID: <493D97D5.8090908@acm.poly.edu> Eugene Grosbein wrote: > On Thu, Oct 23, 2008 at 03:29:10PM -0400, Boris Kochergin wrote: > > >> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 >> 241 dumptid = curthread->td_tid; >> (kgdb) where >> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:241 >> #1 0xc05583ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 >> #2 0xc0558861 in panic (fmt=Could not find the frame base for "panic". >> ) at /usr/src/sys/kern/kern_shutdown.c:563 >> #3 0xc07c033d in trap_fatal (frame=0xe9f3f63c, eva=12) at >> /usr/src/sys/i386/i386/trap.c:899 >> #4 0xc07bfee0 in trap_pfault (frame=0xe9f3f63c, usermode=0, eva=12) at >> /usr/src/sys/i386/i386/trap.c:812 >> #5 0xc07bf79d in trap (frame=0xe9f3f63c) at >> /usr/src/sys/i386/i386/trap.c:490 >> #6 0xc079ed4b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #7 0xc05bfb83 in m_copym (m=0x0, off0=1500, len=20, wait=1) at >> /usr/src/sys/kern/uipc_mbuf.c:538 >> #8 0xc065c536 in ip_fragment (ip=0xc60fabe8, m_frag=0xe9f3f7a8, >> mtu=1500, if_hwassist_flags=0, sw_csum=769) at >> /usr/src/sys/netinet/ip_output.c:726 >> #9 0xc065bf35 in ip_output (m=0xc60fab00, opt=0x0, ro=0xc589dd24, >> flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:565 >> #10 0xc064c431 in in_gif_output (ifp=0xc58a9000, family=18, >> m=0xc60fab00) at /usr/src/sys/netinet/in_gif.c:228 >> #11 0xc06321c3 in gif_output (ifp=0xc58a9000, m=0xc60f9900, >> dst=0xc58b52a0, rt=0x0) at /usr/src/sys/net/if_gif.c:455 >> #12 0xc0631e29 in gif_start (ifp=0xc58a9000) at >> /usr/src/sys/net/if_gif.c:352 >> #13 0xc06297a9 in bridge_enqueue (sc=0xc58d6600, dst_ifp=0xc58a9000, >> m=0x0) at /usr/src/sys/net/if_bridge.c:1714 >> #14 0xc062b80e in bridge_broadcast (sc=0xc58d6600, src_if=0xc58a3400, >> m=0xc60f9900, runfilt=1) at /usr/src/sys/net/if_bridge.c:2394 >> #15 0xc062a5e4 in bridge_forward (sc=0xc58d6600, sbif=0xc56f3600, >> m=0xc60f9900) at /usr/src/sys/net/if_bridge.c:2018 >> #16 0xc062af00 in bridge_input (ifp=0xc58a3400, m=0xc614e700) at >> /usr/src/sys/net/if_bridge.c:2189 >> #17 0xc06324dd in gif_input (m=0xc614e700, af=18, ifp=0xc58a3400) at >> /usr/src/sys/net/if_gif.c:564 >> #18 0xc064c89e in in_gif_input (m=0xc614e700, off=20) at >> /usr/src/sys/netinet/in_gif.c:326 >> #19 0xc0653f85 in encap4_input (m=0xc614e700, off=20) at >> /usr/src/sys/netinet/ip_encap.c:191 >> #20 0xc065819f in ip_input (m=0xc614e700) at >> /usr/src/sys/netinet/ip_input.c:665 >> #21 0xc06346ba in netisr_dispatch (num=2, m=0xc614e700) at >> /usr/src/sys/net/netisr.c:185 >> #22 0xc0630918 in ether_demux (ifp=0xc56bc000, m=0xc614e700) at >> /usr/src/sys/net/if_ethersubr.c:834 >> #23 0xc06306e2 in ether_input (ifp=0xc56bc000, m=0xc614e700) at >> /usr/src/sys/net/if_ethersubr.c:692 >> #24 0xc0704874 in xl_rxeof (sc=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2062 >> #25 0xc070531e in xl_intr (arg=0xc56ed000) at /usr/src/sys/pci/if_xl.c:2298 >> #26 0xc05328a0 in ithread_execute_handlers (p=0xc56ec2ac, ie=0xc55e3d00) >> at /usr/src/sys/kern/kern_intr.c:1036 >> #27 0xc0532a63 in ithread_loop (arg=0xc56f2430) at >> /usr/src/sys/kern/kern_intr.c:1121 >> #28 0xc0530b8c in fork_exit (callout=0xc05329e0 , >> arg=0xc56f2430, frame=0xe9f3fd38) at /usr/src/sys/kern/kern_fork.c:781 >> #29 0xc079edc0 in fork_trampoline () at >> /usr/src/sys/i386/i386/exception.s:205 >> > > Very nice backtrace. If your system runs without patches, > you should send PR with all details included (system version, > interface configuration, backtrace and how-to-repeat recipe. > Please report back PR number once you get it. > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > I've encountered the problem on a machine running RELENG_7 without the patch and have filed a PR. Its number is 129508. Thanks. -Boris From julian at elischer.org Mon Dec 8 15:22:56 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Dec 8 15:23:02 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <1228753304.4948.6.camel@mobiliare.Belkin> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> <493D6F6E.4020900@elischer.org> <1228753304.4948.6.camel@mobiliare.Belkin> Message-ID: <493DAC50.5060501@elischer.org> Ferner Cilloniz wrote: > Yes I am writing my own loadable kernel module such that I can send a > UDP packet when i tell it to by issuing a homemade system call. > > I have been looking at /usr/src/sys/netgraph/ng_sample.c > > Am i supposed to implement the functions in that file? I am a little > lost. I only want to send a UDP packet and in that file I see functions > concerning receiving. > > Is there any other way? > > Thanks Julian and everyone else. > If you won't receive, then just don't implement it :-) on the other hand if you are really only doing packet level output then maybe you would look at ng_source.c which simply acts as a source of packets you need to give a bit more details to what you want to do..\ From fernercc at gmail.com Mon Dec 8 15:29:07 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Mon Dec 8 15:29:14 2008 Subject: FreeBSD kernel module and sending udp packets In-Reply-To: <493DAC50.5060501@elischer.org> References: <1228699701.4940.2.camel@mobiliare.Belkin> <493CD5AB.8030303@elischer.org> <1228702422.4940.7.camel@mobiliare.Belkin> <493CD98D.7000909@elischer.org> <1228740437.4956.1.camel@mobiliare> <493D6F6E.4020900@elischer.org> <1228753304.4948.6.camel@mobiliare.Belkin> <493DAC50.5060501@elischer.org> Message-ID: <1228757344.4948.10.camel@mobiliare.Belkin> Julian, thank you for the reply and for the information :) What I am trying to is send data across the network. I have a created a system call such that i give it a string and the necesarry networking information and it will send it across the network. I just dont know where to start coding this because the information concerning this is very limited. Thank you. On Mon, 2008-12-08 at 15:22 -0800, Julian Elischer wrote: > /usr/src/sys/netgraph/ -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From espartano.mail at gmail.com Mon Dec 8 20:05:16 2008 From: espartano.mail at gmail.com (Espartano) Date: Mon Dec 8 20:05:23 2008 Subject: how to program a driver? Message-ID: hi people first and foremost apologize me for my bad english I have a little question, if i want to understand how work a net driver, what things i will need to learn? Actually i know how to program with C language in a basic level but i don't know nothing about hardware or computer organization, what topics i should study for gain knowledges about net-drivers ? or if someone can recommend me books about this topic i will be very thankful. thanks in advance. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From pyunyh at gmail.com Mon Dec 8 20:31:39 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Dec 8 20:31:46 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <493CF424.4040206@gmail.com> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> Message-ID: <20081209043130.GC33723@cdnetworks.co.kr> On Mon, Dec 08, 2008 at 01:17:08PM +0300, Vladimir Ermakov wrote: > Pyun YongHyeon wrote: > >Good. Would you show me the output of "pciconf -lcv"? > >If I don't see any oddities in the output, I would commit the > >patch. > > > > > what tests need to try? > > > > > > >If parent interface sis0 still works as expected(i.e. without VLAN) > >there is no need to test other cases, I guess. > > > > > OK > > # pciconf -lvc > ... > sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 > rev=0x90 hdr=0x00 > vendor = 'Silicon Integrated Systems (SiS)' > device = 'SiS900 sis 900 and integrated lan' > class = network > subclass = ethernet > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > ... > Thanks. Patch committed to HEAD(r185784). -- Regards, Pyun YongHyeon From delphij at delphij.net Mon Dec 8 21:04:42 2008 From: delphij at delphij.net (Xin LI) Date: Mon Dec 8 21:04:48 2008 Subject: how to program a driver? In-Reply-To: References: Message-ID: <493DFC60.2040305@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Espartano wrote: > hi people first and foremost apologize me for my bad english I have a > little question, if i want to understand how work a net driver, what > things i will need to learn? > > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. I think you need some understanding on how the hardware is composed into a computer system, usually this is taught in freshmen days for a CS or EE major, and it's possible to learn yourself. Basically, NIC drivers implement common interfaces like probe, transfer data, callback when data is received, etc., this part would be easier if you do understand how things works and have data sheets at your hand. There is a book available to give you some ideas about how to write code for FreeBSD Kernel, <> which would help you to understand the basic concepts, etc. My personal suggestion is to start from a simple network driver and try start to get knowledge by tweaking some stuff and see what would happen. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk9/GAACgkQi+vbBBjt66Cv4wCfVKw9Wkqfzr/dQcqlQ6zQUDI6 DDYAn3UIGWs7RBw1VF+M4iHzlI8ZKTpq =8FQC -----END PGP SIGNATURE----- From samflanker at gmail.com Mon Dec 8 23:04:01 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Mon Dec 8 23:04:08 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <20081209043130.GC33723@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> Message-ID: <493E1872.9010306@gmail.com> Pyun YongHyeon wrote: > On Mon, Dec 08, 2008 at 01:17:08PM +0300, Vladimir Ermakov wrote: > > Pyun YongHyeon wrote: > > >Good. Would you show me the output of "pciconf -lcv"? > > >If I don't see any oddities in the output, I would commit the > > >patch. > > > > > > > what tests need to try? > > > > > > > > > >If parent interface sis0 still works as expected(i.e. without VLAN) > > >there is no need to test other cases, I guess. > > > > > > > > OK > > > > # pciconf -lvc > > ... > > sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 > > rev=0x90 hdr=0x00 > > vendor = 'Silicon Integrated Systems (SiS)' > > device = 'SiS900 sis 900 and integrated lan' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > > ... > > > > Thanks. Patch committed to HEAD(r185784). > > MFC? /Vladimir Ermakov From mlists08 at gmail.com Tue Dec 9 00:42:44 2008 From: mlists08 at gmail.com (oklahoma) Date: Tue Dec 9 00:42:50 2008 Subject: [snmpd]could you tell me how to open upd6 port 161 References: <493CEF35.7050009@redhat.com> Message-ID: <007a01c959d7$015f8e10$146ea8c0@midnight> ----- Original Message ----- From: "wang_jiabo" To: Sent: Monday, December 08, 2008 11:56 AM Subject: [snmpd]could you tell me how to open upd6 port 161 > Hello, all: > could you help me how to open inet6 udp port 161 of snmpd agent as a > listen port Basically just start the deamon as root and it will listen to it's assigned by default port. If you want to change the port on wich snmpd listens - look around the configuration file for such option. If you have firewall - make appropriate rule set to allow in/out traffic to this port. It will be usefull to know what firewall you use. From linimon at FreeBSD.org Tue Dec 9 00:50:00 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Dec 9 00:50:12 2008 Subject: kern/129517: [ipsec] [panic] double fault / stack overflow Message-ID: <200812090850.mB98o0WX037064@freefall.freebsd.org> Old Synopsis: Ipsec / panic: double fault / stack overflow New Synopsis: [ipsec] [panic] double fault / stack overflow Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 9 08:49:40 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129517 From bms at FreeBSD.org Tue Dec 9 00:56:17 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Dec 9 00:56:23 2008 Subject: how to program a driver? In-Reply-To: References: Message-ID: <493E32AE.5040907@FreeBSD.org> Espartano wrote: > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. > Try "The Indispensable PC Hardware Book" by Hans-Peter Messmer for a general overview of PC architecture. cheers BMS From bms at FreeBSD.org Tue Dec 9 01:20:05 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Dec 9 01:20:12 2008 Subject: how to program a driver? In-Reply-To: References: Message-ID: <493E3842.7030100@FreeBSD.org> [Resend to list for everyone] Espartano wrote: > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. > The seminal work is TCP/IP Illustrated Volume 2 (Gary Wright and W. Richard Stevens, Addison-Wesley). Whilst dated it will give you an overview of how all the parts in the BSD networking stack fit together. It really needs to be updated, however enough things are in flux right now that summarising all the changes would be difficult until say after FreeBSD 8.0 dust is settled. For computer architecture, probably best to learn PC architecture these days -- x86 is here to stay, kids, and Netbooks are something of a reactionary response triggered by the One-Laptop-Per-Child (OLPC) project. In my day, I learned 68000 assembly and C on the Amiga. Hans-Peter Messmer's "The Indispensable PC Hardware Book" is a huge book which cost me about 50 GBP new when I first bought it -- I was working in a reasonably well paid job at the time, but it can be found second hand no doubt around the world. Cover to cover it will tell you what you need to know about how the PC architecture fits together, but if you need more detail e.g. on stuff like FreeBSD network drivers, again, it's best to refer back to the source code itself. Hope this helps. cheers BMS From aturetta at commit.it Tue Dec 9 04:50:29 2008 From: aturetta at commit.it (Angelo Turetta) Date: Tue Dec 9 04:50:49 2008 Subject: Multiple routing table clarification Message-ID: <493E66BD.6090907@commit.it> I need to run squid, serving different networks with different (potentially conflicting) IP address schemes. I read the original implementation notes for setfib/multiple routing tables: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt and I would like to ask for some clarifications: - is it possible for a single process to listen for TCP connections using more than one socket, each with its own 'fib'? - if I use ipfw rules to tag incoming traffic, can I force the fib on a incoming TCP connection to be different from the fib of the process/socket listening for that connection? Thanks for any help (oh, BTW, if somewhere more detailed howto/doc about this feature can be found, please forward any pointers) Angelo. From csjp at freebsd.org Tue Dec 9 09:46:59 2008 From: csjp at freebsd.org (Christian Peron) Date: Tue Dec 9 09:47:05 2008 Subject: [patch] link state notifications for tun(4) Message-ID: <20081209172903.GA72817@jnz.sqrt.ca> I would like to propose a change for tun(4) but before I do, I would like to read any feedback this list might have. Basically we have a situation where we need to manually configure tunnel interfaces when a process opens them. We would like to hook into devd(8) for this. i.e. when we see tunX "linkup" call ifconfig as well, add some routes. The trouble is, tun(4) does not generate linkup/linkdown events. We would consider the tun device to be linked up when a process has it open, and linked down when the process closes it. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: tun.diff Type: text/x-diff Size: 504 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081209/fc67868a/tun.bin From jespasac at minibofh.org Tue Dec 9 09:58:57 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Tue Dec 9 09:59:04 2008 Subject: start_if. comments Message-ID: <493EAD8B.8040605@minibofh.org> Hi all, I'm testing the use of /etc/start_if. instead the classical 'ifconfig....' in /etc/rc.conf. All seems work fine, but if I comment a line in /etc/start_if., any interface is loaded by the system! If I use $ cat /etc/start_if.nfe0 /sbin/ifconfig $1 inet netmask 255.255.254.0 /sbin/ifconfig $1 alias netmask 0xffffffff /sbin/ifconfig $1 alias netmask 0xffffffff all works fine. But if I use $ cat /etc/start_if.nfe0 /sbin/ifconfig $1 inet netmask 255.255.254.0 #/sbin/ifconfig $1 alias netmask 0xffffffff /sbin/ifconfig $1 alias netmask 0xffffffff any nfe0 associated interface is loaded! I don't understand this issue, because according to rc.conf: "If the /etc/start_if. file is present, it is read and executed by the sh(1) interpreter before configuring the interface as specified in the ifconfig_ and ifconfig__alias variables." and all of us know that sh(1) symbol of comment is always '#' ?Is it normal or is it a bug? -- Thanks, Jordi Espasa Clofent From julian at elischer.org Tue Dec 9 10:00:28 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Dec 9 10:00:35 2008 Subject: Multiple routing table clarification In-Reply-To: <493E66BD.6090907@commit.it> References: <493E66BD.6090907@commit.it> Message-ID: <493EAB8F.7090509@elischer.org> Angelo Turetta wrote: > I need to run squid, serving different networks with different > (potentially conflicting) IP address schemes. > > I read the original implementation notes for setfib/multiple routing > tables: > http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt > > > and I would like to ask for some clarifications: > > - is it possible for a single process to listen for TCP connections > using more than one socket, each with its own 'fib'? yes, but only if you have source. you need to do a setsockopt(SOO_SETFIB,...) on each socket before you do the listen(). Otherwise all socekts from the same process get the same fib. > > - if I use ipfw rules to tag incoming traffic, can I force the fib on a > incoming TCP connection to be different from the fib of the > process/socket listening for that connection? no, the fib for a socket is set by the process that does the listen. HOWEVER I have been asked to add a feature where setting a fib of -1 on a socket will allow it to get its fib from the incoming SYN packet.. Ithink that would bewhat you are asking for. > > Thanks for any help (oh, BTW, if somewhere more detailed howto/doc about > this feature can be found, please forward any pointers) man 2 setsockopt man 1 setfib man 2 setfib > > Angelo. > _______________________________________________ > 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 aturetta at commit.it Tue Dec 9 10:06:53 2008 From: aturetta at commit.it (Angelo Turetta) Date: Tue Dec 9 10:06:59 2008 Subject: Multiple routing table clarification In-Reply-To: <493EAB8F.7090509@elischer.org> References: <493E66BD.6090907@commit.it> <493EAB8F.7090509@elischer.org> Message-ID: <493EB3A7.40108@commit.it> Julian Elischer wrote: > Angelo Turetta wrote: >> - is it possible for a single process to listen for TCP connections >> using more than one socket, each with its own 'fib'? > > yes, but only if you have source. you need to do a > setsockopt(SOO_SETFIB,...) on each socket before you do the listen(). > Otherwise all socekts from the same process get the same fib. OK, shouldn't be too hard to hack squid for this. > HOWEVER I have been asked to add a feature where setting a fib of -1 > on a socket will allow it to get its fib from the incoming SYN packet.. > Ithink that would bewhat you are asking for. Yes, please! It would be much more general-purpose than hacking squid, of course if -1 be supported by setfib too... I can help test a patch on RELENG_7, whenever "someone" writes it ;-) Thanks a lot, Angelo Turetta From fernercc at gmail.com Tue Dec 9 11:39:02 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Tue Dec 9 11:39:09 2008 Subject: kldload telling not finding .ko file when it is indeed there Message-ID: <1228829938.4948.27.camel@mobiliare.Belkin> Hi everyone. I'm running into a problem where kldload is reporting that my .ko file is not found when it is indeed there. It is strange because when i comment out a call to the function sotoinpcb(struct socket *) it finds the .ko file and loads, but when i uncomment that line and try to load it, kldload reports that the .ko file is not found. What is going on? Thanks :) -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From rnoland at FreeBSD.org Tue Dec 9 11:59:46 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Dec 9 11:59:53 2008 Subject: kldload telling not finding .ko file when it is indeed there In-Reply-To: <1228829938.4948.27.camel@mobiliare.Belkin> References: <1228829938.4948.27.camel@mobiliare.Belkin> Message-ID: <1228852775.9860.20.camel@squirrel.corp.cox.com> On Tue, 2008-12-09 at 13:38 +0000, Ferner Cilloniz wrote: > Hi everyone. > > I'm running into a problem where kldload is reporting that my .ko file > is not found when it is indeed there. > > It is strange because when i comment out a call to the function > sotoinpcb(struct socket *) it finds the .ko file and loads, but when i > uncomment that line and try to load it, kldload reports that the .ko > file is not found. > > What is going on? I expect that the load is failing due to an undefined symbol and the error is just being obfuscated. robert. > Thanks :) > -------------- 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/20081209/9ad6e70c/attachment.pgp From yamamoto436 at oki.com Tue Dec 9 22:14:31 2008 From: yamamoto436 at oki.com (Hideki Yamamoto) Date: Tue Dec 9 22:14:37 2008 Subject: MLDv2 on FreeBSD 7 (mcastread cannot work well) Message-ID: <20081210.144334.88509243.yamamoto436@oki.com> Hi, I have compiled mcast-tools on FreeBSD 7. When running mcastread to send join to MLDv2 available router, the command output as follows: "Can't allocate socket" It seems that KERNEL cannot support MLDv2, source specific multicast on my environment. Are there any special kernel paramters to turn on MLDv2? Or are there any further documment on this matter? Thanks in advance. Best regards, Hideki Yamamoto ----------------------------------------------------------------------- Hideki YAMAMOTO yamamoto436@oki.com Software Development Department- 4, Development Division, OKI Networks Co., Ltd. (http://www.oki-networks.com/) Tel: +81-48-420-7012 FAX: +81-48-420-7138 ----------------------------------------------------------------------- From stutiredboy at gmail.com Tue Dec 9 22:14:44 2008 From: stutiredboy at gmail.com (=?GB2312?B?s8LQocn6?=) Date: Tue Dec 9 22:14:50 2008 Subject: [help]strange problem about gethostbyname/getaddrinfo Message-ID: hi,all,we have a project which must resolv some domains in the server process our system in FreeBSD 6.2 or 6.3, the server process may open 7000+ sockets,not fork we have set the maxopensockets as 65536,as follows: kern.ipc.numopensockets: 4737 kern.ipc.maxsockets: 65536 socket: 356, 65538, 4737, 6747, 64793968 and the follow is our limit info: cputime unlimited filesize unlimited datasize 2621440 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse unlimited vmemoryuse unlimited descriptors 655000 memorylocked unlimited maxproc 5547 sbsize unlimited I am sure we have set the /etc/reslov.conf correctly, I can resolve any legal domain use dig or gethostbyname or getaddrinfo in my another test program The problem is we found when the server porcess open 1000+ or higher sockets(but we can query any legal domain in the system normally), the gethostbyname or getaddrinfo might fetch nothing(sometimes the query is ok), the gethostbyname's return error is: errno=2,strerror=Host name lookup failure and the getaddrinfo's return error is: "hostname nor servname provided, or not known", /* EAI_NONAME */ we have tried to use the tcpdump to analyse the query packets, unluckily , we catch nothing, seem like that the program does not query anything(or get none dns server,even 127.0.0.1) , neither using gethostbyname nor getaddrinfo,and we also try set the query type as tcp and udp, the same disappointment result. The stranger thing is we have tried to run another demo process which have open 4000+ sockets, all work well..so the problem might not related to open too much sockets..and we found that, even we set the /etc/resolve.conf nothing, normally the gethostbyname/getaddrinfo will check 127.0.0.1, and we can get the query packets The server process's query is under a single process not multi threads Can anyone help me analyse the error/problem, which may raise this situation or any useful info, thanks very much ! From jespasac at minibofh.org Tue Dec 9 23:04:37 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Tue Dec 9 23:04:44 2008 Subject: start_if. comments [SOLVED] In-Reply-To: <493EAD8B.8040605@minibofh.org> References: <493EAD8B.8040605@minibofh.org> Message-ID: <493F69F6.9060802@minibofh.org> It seems that I'd the file open with ee(1) when I forced a reboot during my tests. Surely the fsck process deleted the file. If I re-create the file, all seems ok. Rare but true. -- Thanks, Jordi Espasa Clofent From qingli at FreeBSD.org Tue Dec 9 23:40:53 2008 From: qingli at FreeBSD.org (Qing Li) Date: Tue Dec 9 23:41:00 2008 Subject: last call for L2/L3 rewrite code review Message-ID: <200812100740.mBA7eqjO034924@freefall.freebsd.org> As you know the L2+L3 rewrite project (aka arp-v2) for both ARP and ND6 has been active for quite some time now. In a nutshell, the work removes the L2 tables (ARP and ND6) from the L3 routing table. This redesign simplifies the routing code and completely eliminates the route cloning concept. I discussed about this work at BSDCan 2007 and again at the recent devsummit at Google. I have requested code review and feedback since last May. It's becoming increasingly difficult to maintain a separate branch (p4 or svn) due to the high volume of new features' related commits. The integration and unit testing efforts increase in complexity by the week. We (Julian, Sam, Kip, Robert and I) discussed about a possible commit timeframe during the devsummit. And it seems now is as good as any because we all have overcommitted ourselves, and frankly speaking unless the feature is fully committed, getting the thorough code review and broader testing is simply unrealistic. I have been running the new arp-v2 kernel as a regular production machine on a daily basis, however, I am certain my testing is insufficient, which is another good reason to get the feature into the official -current tree. Putting a closure on this work will allow me to focus on developing additional networking features and completing my other backlog tasks for the project. Although the code will continue to evolve, on the other hand, the code is stable enough that I believe it is ready for general (-CURRENT) consumption. I would like to commit the code within a week if not sooner. Again, I would like to ask for your review and feedback. Flaming is fine, which I prefer getting the flames now rather than later. Quite a few developers have contributed to this project in the past: Glebius Smirnoff, Luigi Rizzo, Alessandro Cerri, and Andre Oppermann. And most recently: - Kip Macy revised the locking code completely, thus completing the last piece of the puzzle, Kip has also been conducting active functional testing - Sam Leffler has helped me improving/refactoring the code, and provided valuable reviews - Julian Elischer setup the perforce tree for me and has helped me maintaining that branch The latest patch that is generated out of Perforce without Kip Macy's locking modification is at http://people.freebsd.org/~qingli/arp-v2-p4-diff The complete P4 project tree is located at //depot/projects/arp-v2 The full project sits in the svn branch that is located at svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Once this code is fully committed into -CURRENT, I will be on standby to fix any arp/nd6 related bugs. Kip Macy will be on standby to fix any locking related issues. Kip will also be acting as my backup when I'd be out partying. Thanks, -- Qing mailto: qingli@freebsd.org From fox at verio.net Tue Dec 9 23:58:41 2008 From: fox at verio.net (David DeSimone) Date: Tue Dec 9 23:58:47 2008 Subject: [help]strange problem about gethostbyname/getaddrinfo In-Reply-To: References: Message-ID: <20081210075838.GB12948@verio.net> wrote: > > The problem is we found when the server porcess open 1000+ or higher > sockets(but we can query any legal domain in the system normally), the > gethostbyname or getaddrinfo might fetch nothing(sometimes the query > is ok), the gethostbyname's return error is: errno=2,strerror=Host > name lookup failure It sounds like the resolver library is running into a 1024-descriptor limit. From select(2): NOTES The default size of FD_SETSIZE is currently 1024. In order to accommo- date programs which might potentially use a larger number of open files with select(), it is possible to increase this size by having the program define FD_SETSIZE before the inclusion of any header which includes . Unfortunately you might have to rebuild the resolver library itself in order for it to be able to query file descriptors larger than 1024. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From ume at freebsd.org Wed Dec 10 00:14:38 2008 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Wed Dec 10 00:14:44 2008 Subject: [help]strange problem about gethostbyname/getaddrinfo In-Reply-To: <20081210075838.GB12948@verio.net> References: <20081210075838.GB12948@verio.net> Message-ID: Hi, >>>>> On Wed, 10 Dec 2008 01:58:38 -0600 >>>>> "David DeSimone" said: fox> It sounds like the resolver library is running into a 1024-descriptor fox> limit. From select(2): Our resolver doesn't use select(2) but use kqueue(2). So, we don't have this limitation. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From rea-fbsd at codelabs.ru Wed Dec 10 00:28:20 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Dec 10 00:28:26 2008 Subject: [ipsec] aes-ctr question In-Reply-To: <20081203082549.GA62889@zeninc.net> References: <49349E26.30002@redhat.com> <20081203082549.GA62889@zeninc.net> Message-ID: Yvan, good day. Wed, Dec 03, 2008 at 09:25:49AM +0100, VANHULLEBUS Yvan wrote: > On Wed, Dec 03, 2008 at 10:54:55AM +0300, Eygene Ryabinkin wrote: > [...] > > Good catch. Perhaps setkey should be extended to warn the user about > > this neat. The patch is attached. George, people, what do you think > > about it? > > If we're going to add security warnings in setkey, we could just put a > warning when using static keys (so basically put a warning for "add" > command....). In general -- you're perfectly right: people should use IKE and company. But CTR mode is particularily evil in respect to the nonce sinsitivity: for the given key and initialization vector it will produce the same gamma (running key in English terminology) used for encryption and decryption. But we seem to be more-or-less safe here: IV is generated randomly, so one will have 2^64 different initialization vectors for a single passphrase. Sooo, the issue seems to be of a less value, but still -- it is here. And for passive attacker who has access to all CTR mode sessions with static keys will be rather simple to analyze for the gamma coincidence: providing that the first bytes of the packets to be encrypted are the same (think UDP/TCP header of something simular), then it should just XOR the stream beginnings and wait when the bits that correspond to the same (constant) bits of the payload will be zeroed. Sufficient number of zeros will indicate gamma coincidence and one can focus on further fun with such streams. Of course, I may be missing something. -- 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/20081210/cb893517/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Wed Dec 10 01:10:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 10 01:10:17 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> Message-ID: <20081210090429.G97918@maildrop.int.zabbadoz.net> On Wed, 10 Dec 2008, Qing Li wrote: Hi, > It's becoming increasingly difficult to maintain a separate > branch (p4 or svn) due to the high volume of new features' > related commits. The integration and unit testing efforts > increase in complexity by the week. [..] > I would like to commit the code within > a week if not sooner. I think waiting another few days would be good, so end of the weekend or something seems realistic, but not so before. The reason I am asking is that people are still seeing panics from the rnh locking and aren't even able to boot machines. Mixng route locking bugs with this rewrite will be painful. As I hope that the rnh bugs will be solved within 2-3 days things would be good for getting this monster in:) > The complete P4 project tree is located at > > //depot/projects/arp-v2 > > The full project sits in the svn branch that is located at > > svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Which of the two is the one to track the next days or are you going to keep them in sync? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From kmacy at freebsd.org Wed Dec 10 01:30:36 2008 From: kmacy at freebsd.org (Kip Macy) Date: Wed Dec 10 01:30:42 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <20081210090429.G97918@maildrop.int.zabbadoz.net> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> Message-ID: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> > The reason I am asking is that people are still seeing panics from > the rnh locking and aren't even able to boot machines. I have not seen this. Please tell me where this occurs. > Mixng route > locking bugs with this rewrite will be painful. As I hope that the > rnh bugs will be solved within 2-3 days things would be good for > getting this monster in:) To the best of my knowledge, the few bugs that have occurred have been fixed within a day of them being reported. >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > Which of the two is the one to track the next days or are you going to > keep them in sync? > The svn branch will be the one that is kept up to date with all fixes. I will be IFC'ing in to it once a day. Thanks, Kip From zec at icir.org Wed Dec 10 02:21:20 2008 From: zec at icir.org (Marko Zec) Date: Wed Dec 10 02:21:30 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> Message-ID: <200812101109.14851.zec@icir.org> On Wednesday 10 December 2008 10:30:35 Kip Macy wrote: > > The reason I am asking is that people are still seeing panics from > > the rnh locking and aren't even able to boot machines. > > I have not seen this. Please tell me where this occurs. I had a machine with defaultrouter from /etc/rc.conf pointing to a gateway which wasn't directly reachable, so the machine would panic before going multiuser. Nevertheless I can confirm that your change 185849 just resolved this issue, thanks a lot for a quick fix! Marko > > Mixng route > > locking bugs with this rewrite will be painful. As I hope that the > > rnh bugs will be solved within 2-3 days things would be good for > > getting this monster in:) > > To the best of my knowledge, the few bugs that have occurred have > been fixed within a day of them being reported. > > >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > > > Which of the two is the one to track the next days or are you going > > to keep them in sync? > > The svn branch will be the one that is kept up to date with all > fixes. I will be IFC'ing in to it once a day. > > Thanks, > Kip > _______________________________________________ > 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 nvass at teledomenet.gr Thu Dec 11 03:10:34 2008 From: nvass at teledomenet.gr (Nikos Vassiliadis) Date: Thu Dec 11 03:10:40 2008 Subject: ng_bridge + ng_ksocket Message-ID: <200812111250.38046.nvass@teledomenet.gr> Hello, I would like to create an ethernet over UDP tunnel. For my purposes, using ng_bridge and ng_ksocket seem fine. The problem is that the peer address/port is not known, since it will be behind a NAT device and will have a dynamically assigned IP address. In userspace I would use something like recvfrom() to get the peer address. I don't know what to do for ngctl and ng_ksocket. Any suggestions? Is this doable? Is there something I can do to circumvent the problem? Thanks in advance, Nikos From nrml at att.net Thu Dec 11 04:28:29 2008 From: nrml at att.net (Gabe) Date: Thu Dec 11 04:28:35 2008 Subject: NAT-T + ipsec integration Message-ID: <20081211122828.CF3958FC16@mx1.freebsd.org> Hello all Does anyone know how to enable nat traversal on freebsd? I've got a site to site ipsec tunnel setup but clients behind the nat can't vpn through it. Any help would be appreciated. Thanks /gabe From vanhu at FreeBSD.org Thu Dec 11 04:39:41 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Thu Dec 11 04:39:48 2008 Subject: NAT-T + ipsec integration In-Reply-To: <20081211122828.CF3958FC16@mx1.freebsd.org> References: <20081211122828.CF3958FC16@mx1.freebsd.org> Message-ID: <20081211123958.GA5332@zeninc.net> On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > Hello all Hi. > Does anyone know how to enable nat traversal on freebsd? > > I've got a site to site ipsec tunnel setup but clients behind the > nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means "implemented + heavilly tested + reviewed"). Yvan. From rrs at lakerest.net Thu Dec 11 04:50:42 2008 From: rrs at lakerest.net (Randall Stewart) Date: Thu Dec 11 04:50:48 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <200811201450.30016.max@love2party.net> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> Message-ID: <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> All: Ok here is what I have come up with.. going along the lines of Max's suggestion.. its pretty clean I think. Comments would be most welcome.. The only thing possibly a bit dodgy is that 1) UDP has no per-protocol block. 2) Instead of creating one, I am using the block pointer in the inp as the function pointer for the tunneling. What this means if we EVERY did add a per protocol structure for UDP we would need to move the function pointer in there.. The nice thing it does is make it so we have no structural changes to the code... i.e. complete compatibility... no changes to inp or other UDP structures :-) Here is the patch.. please send comments ;-D -------------- next part -------------- A non-text attachment was scrubbed... Name: diff_for_udp Type: application/octet-stream Size: 2853 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081211/b20498e5/diff_for_udp.obj -------------- next part -------------- On Nov 20, 2008, at 8:50 AM, Max Laier wrote: > On Thursday 20 November 2008 14:00:11 Randall Stewart wrote: >> On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>>> Its not new, its the same ip header.. >>>> Its just you go into the mbuf chain and take out >>>> the udp header... >>> >>> well you can't do that at the socket buffer becasue you've discarded >>> the IP header. It may not even be in the mbufs you have. (though >>> it's >>> unlikely). After you've processed the UDP part the IP part is gone >>> so >>> you'd need to intercept the packet way earlier and then do your >>> own UDP processing, (or maybe attach the IP header onto it with a >>> tag). >> >> One would definitely have to do some work in udp_input() not a lot >> from >> what I can tell... but it would take some work. >> >> Maybe good course is to use the socket(9) stuff, but add an option >> that can set a "by-pass function" if the socket is udp... right >> after you establish the INP the packet goes to, if the function is >> set, you engage the bypass... > > This sounds reasonable. One would only have to replace calls to > udp_append in > udp_input with the by-pass function et voila. Should be clean > enough. There > might be some problems with holding the socket lock, though. > > For the record, I don't like all the UDP-tunneling madness either, > but it > seems that we are stuck with it ... so we should at least try to > come up with > a somewhat reasonable implementation for this hackery. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From max at love2party.net Thu Dec 11 05:12:19 2008 From: max at love2party.net (Max Laier) Date: Thu Dec 11 05:12:27 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> References: <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> Message-ID: <200812111412.16757.max@love2party.net> On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: > All: > > Ok here is what I have come up with.. going along the > lines of Max's suggestion.. its pretty clean I think. > > Comments would be most welcome.. > > The only thing possibly a bit dodgy is that > > 1) UDP has no per-protocol block. > 2) Instead of creating one, I am using the block pointer in the inp > as the function pointer for the tunneling. > > What this means if we EVERY did add a per protocol structure for > UDP we would need to move the function pointer in there.. > > The nice thing it does is make it so we have no structural changes to > the code... i.e. complete compatibility... no changes to inp or > other UDP structures :-) > > > Here is the patch.. please send comments ;-D I like it, though I have no idea what the implications of using the block pointer might be. One thing about the patch: What about the multi-/broadcast cases? I think if we introduce this, we want to make sure it works there as well - no? And finally, is there a potential race with setting the function and data arriving at the socket - should udp_set_kernel_tunneling maybe check that the socket isn't bound yet? -- /"\ 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 nrml at att.net Thu Dec 11 05:31:33 2008 From: nrml at att.net (Gabe) Date: Thu Dec 11 05:31:43 2008 Subject: NAT-T + ipsec integration Message-ID: <20081211133133.080C58FC12@mx1.freebsd.org> Ok recompiling now. Hopefully it works fine. I'll report back. Thanks. -----Original Message----- From: VANHULLEBUS Yvan Sent: Thursday, December 11, 2008 4:39 AM To: Gabe Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > Hello all Hi. > Does anyone know how to enable nat traversal on freebsd? > > I've got a site to site ipsec tunnel setup but clients behind the > nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means "implemented + heavilly tested + reviewed"). Yvan. _______________________________________________ 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 adeepv at gmail.com Thu Dec 11 06:56:32 2008 From: adeepv at gmail.com (Vyacheslav Bocharov) Date: Thu Dec 11 06:56:40 2008 Subject: strange problem with ifconfig alias Message-ID: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> Hello. I have strange problem with ifconfig: I can't add ip address to interface: root@chip# route get 195.3.245.xx route to: 195.3.245.xx destination: default mask: default gateway: gadget interface: vlan10 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 root@chip# ifconfig |grep 195.3.245. root@chip# root@chip# ifconfig em1 alias 195.3.245.xx/30 ifconfig: ioctl (SIOCAIFADDR): File exists root@chip# route get 195.3.245.xx route to: 195.3.245.xx destination: 195.3.245.xx-1 mask: 255.255.255.252 interface: em1 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 -3 root@chip# ifconfig em1 |grep 195.3.245. root@chip# -- Vyacheslav Bocharov From bms at FreeBSD.org Thu Dec 11 10:11:47 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Dec 11 10:11:54 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> Message-ID: <494157DF.6030802@FreeBSD.org> Hi, I am missing context of what Max's suggestion was, do you have a reference to an old email thread? Style bugs: * needs style(9) and whitespace cleanup. * C typedefs should be suffixed with _t for consistency with other kernel typedefs. * Function typedefs usually named like foo_func_t (see other subsystems) Have you looked at m_apply() ? It already exists for stuff like this i.e. functions which act on an mbuf chain, although it doesn't necessarily expect chain heads. cheers BMS From bms at FreeBSD.org Thu Dec 11 10:18:34 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Dec 11 10:18:39 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> Message-ID: <49415977.6010307@FreeBSD.org> Hi, Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely for lltbl purposes; this clashes with the IGMPv3 code drop. Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' to make more general use of that slot. IGMPv3 needs to store per-interface state for AF_INET, so this slot really needs to be shared with other AF_INET stuff. Looks like it needs to be updated for VIMAGE also, hopefully others more familiar with this can help -- I am busy enough with non-programming activity as it is to get up to speed on this, although I have at least managed to print Julian's write-up... Other than that, it looks like a much needed improvement and we are all very grateful for our work on this. thanks BMS From kmacy at freebsd.org Thu Dec 11 13:38:06 2008 From: kmacy at freebsd.org (Kip Macy) Date: Thu Dec 11 13:38:12 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <49415977.6010307@FreeBSD.org> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <49415977.6010307@FreeBSD.org> Message-ID: <3c1674c90812111338p69c33bd5sa26315cba4981011@mail.gmail.com> I think that you're request to not monopolize the AF_INET slot is reasonable. Do you intend to merge bms_netdev before 8 branches (I'm guessing this coming summer)? Cheers, Kip On Thu, Dec 11, 2008 at 10:18 AM, Bruce M. Simpson wrote: > Hi, > > Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely > for lltbl purposes; this clashes with the IGMPv3 code drop. > > Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' > to make more general use of that slot. IGMPv3 needs to store per-interface > state for AF_INET, so this slot really needs to be shared with other AF_INET > stuff. > > Looks like it needs to be updated for VIMAGE also, hopefully others more > familiar with this can help -- I am busy enough with non-programming > activity as it is to get up to speed on this, although I have at least > managed to print Julian's write-up... > > Other than that, it looks like a much needed improvement and we are all very > grateful for our work on this. > > 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" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From linimon at FreeBSD.org Thu Dec 11 14:23:09 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Dec 11 14:23:15 2008 Subject: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. Message-ID: <200812112223.mBBMN8qk098455@freefall.freebsd.org> Old Synopsis: Netgear WG311v3 (ndis) causes kenel trap at boot. New Synopsis: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 11 22:22:26 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129580 From mamruoc at gmail.com Thu Dec 11 15:20:05 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Thu Dec 11 15:20:13 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <20081129065950.GG99324@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> Message-ID: <494199E2.5050806@gmail.com> Pyun YongHyeon wrote: > I think there was a similar report. Would you show me the output of > "pciconf -lcv"? I finally got an SSD disk instead of the CF/IDE. The output is attached. > For a long time I wanted to clean up vge(4). Unfortunately the PCI > NIC I have seem to broken so I guess it's hard to complete the > cleanup. You can get a WIP(now stalled) in the following URL. Note, > the driver may be chatty due to various debugging statements and it > may not work at all for your controller. I guess that I should recompile the whole src tree, or is the driver enough? I am new to FreeBSD, could anybody help? Mam -------------- next part -------------- FreeBSD test 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 hostb0@pci0:0:0:0: class=0x060000 card=0xaa081106 chip=0x03141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Host Bridge' class = bridge subclass = HOST-PCI cap 02[80] = AGP v3 8x 4x SBA disabled cap 01[50] = powerspec 2 supports D0 D3 current D0 hostb1@pci0:0:0:1: class=0x060000 card=0x00000000 chip=0x13141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Standard Host Bridge' class = bridge subclass = HOST-PCI hostb2@pci0:0:0:2: class=0x060000 card=0x00000000 chip=0x23141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Standard Host Bridge' class = bridge subclass = HOST-PCI hostb3@pci0:0:0:3: class=0x060000 card=0x00000000 chip=0x32081106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4X800 CPU to PCI Bridge' class = bridge subclass = HOST-PCI hostb4@pci0:0:0:4: class=0x060000 card=0x00000000 chip=0x43141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Host Bridge' class = bridge subclass = HOST-PCI hostb5@pci0:0:0:7: class=0x060000 card=0x00000000 chip=0x73141106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'CN700/VN800/P4M800CE/Pro Host Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0xb1981106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'ProSavageDDR P4X600,Apollo KT400/A/600 CPU to AGP Bridge' class = bridge subclass = PCI-PCI cap 01[70] = powerspec 2 supports D0 D1 D3 current D0 fwohci0@pci0:0:13:0: class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller' class = serial bus subclass = FireWire cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 vge0@pci0:0:14:0: class=0x020000 card=0x01101106 chip=0x31191106 rev=0x11 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6120/VT6121/VT6122 'Velocity' Gigabit Ethernet Controllers' class = network subclass = ethernet cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 atapci0@pci0:0:15:0: class=0x01018f card=0x31491106 chip=0x31491106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 VT6410 SATA RAID Controller' class = mass storage subclass = ATA cap 01[c0] = powerspec 2 supports D0 D3 current D0 atapci1@pci0:0:15:1: class=0x01018a card=0x05711106 chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C586A/B/VT82C686/A/B/VT823x/A/C Bus Master IDE Controller' class = mass storage subclass = ATA cap 01[c0] = powerspec 2 supports D0 D3 current D0 uhci0@pci0:0:16:0: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 uhci1@pci0:0:16:1: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 uhci2@pci0:0:16:2: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:16:4: class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x86 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6202/12 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 isab0@pci0:0:17:0: class=0x060100 card=0xaa081106 chip=0x32271106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 PCI-to-ISA Bridge' class = bridge subclass = PCI-ISA cap 01[c0] = powerspec 2 supports D0 D3 current D0 em0@pci0:0:20:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction vgapci0@pci0:1:0:0: class=0x030000 card=0x33441106 chip=0x33441106 rev=0x01 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M800PRO&8237R VIA/S3G UniChrome Pro IGP' class = display subclass = VGA cap 01[60] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 02[70] = AGP v3 8x 4x SBA disabled From fernercc at gmail.com Thu Dec 11 15:54:32 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Thu Dec 11 15:54:39 2008 Subject: freebsd system calls Message-ID: <1229018069.4966.1.camel@mobiliare.Belkin> Hello everyone. I am interested in looking at the code for system calls in FreeBSD, like read, etc. In which directory can i find them? I have tried grepping /usr/src/sys. Thanks :) -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From kmacy at freebsd.org Thu Dec 11 16:01:55 2008 From: kmacy at freebsd.org (Kip Macy) Date: Thu Dec 11 16:02:01 2008 Subject: native ATM users Message-ID: <3c1674c90812111601u27415582j385c865d32ca233d@mail.gmail.com> Native ATM relies on the use of route cloning for managing virtual circuits. Support for route cloning will be removed from the kernel in the near future. I thus need to determine how many users of NATM there are and their availability for testing changes. Thanks, Kip From max at love2party.net Thu Dec 11 16:07:36 2008 From: max at love2party.net (Max Laier) Date: Thu Dec 11 16:07:43 2008 Subject: freebsd system calls In-Reply-To: <1229018069.4966.1.camel@mobiliare.Belkin> References: <1229018069.4966.1.camel@mobiliare.Belkin> Message-ID: <200812120107.33230.max@love2party.net> On Thursday 11 December 2008 18:54:29 Ferner Cilloniz wrote: > Hello everyone. > > I am interested in looking at the code for system calls in FreeBSD, like > read, etc. > > In which directory can i find them? I have tried grepping /usr/src/sys. src/sys/kern mostly ... "grep ^read *" should get you started. For the C function names take a look as syscalls.master in the same directory. -- /"\ 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 pyunyh at gmail.com Thu Dec 11 17:40:20 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Dec 11 17:40:27 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <493E1872.9010306@gmail.com> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> <493E1872.9010306@gmail.com> Message-ID: <20081212014011.GG46707@cdnetworks.co.kr> On Tue, Dec 09, 2008 at 10:04:18AM +0300, Vladimir Ermakov wrote: > Pyun YongHyeon wrote: > >On Mon, Dec 08, 2008 at 01:17:08PM +0300, Vladimir Ermakov wrote: > > > Pyun YongHyeon wrote: > > > >Good. Would you show me the output of "pciconf -lcv"? > > > >If I don't see any oddities in the output, I would commit the > > > >patch. > > > > > > > > > what tests need to try? > > > > > > > > > > > > >If parent interface sis0 still works as expected(i.e. without VLAN) > > > >there is no need to test other cases, I guess. > > > > > > > > > > > OK > > > > > > # pciconf -lvc > > > ... > > > sis0@pci0:0:4:0: class=0x020000 card=0xe0001458 chip=0x09001039 > > > rev=0x90 hdr=0x00 > > > vendor = 'Silicon Integrated Systems (SiS)' > > > device = 'SiS900 sis 900 and integrated lan' > > > class = network > > > subclass = ethernet > > > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > > > ... > > > > > > >Thanks. Patch committed to HEAD(r185784). > > > > > MFC? > sis(4) supports two kind of controllers. One was made by SiS and the other was manufactured by National Semiconductor. So I think we need test report for NatSemi DP83815 case prior to MFC. -- Regards, Pyun YongHyeon From pyunyh at gmail.com Thu Dec 11 17:58:50 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Dec 11 17:58:57 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <494199E2.5050806@gmail.com> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> Message-ID: <20081212015842.GH46707@cdnetworks.co.kr> On Thu, Dec 11, 2008 at 11:53:22PM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >I think there was a similar report. Would you show me the output of > >"pciconf -lcv"? > > I finally got an SSD disk instead of the CF/IDE. The output is attached. > > >For a long time I wanted to clean up vge(4). Unfortunately the PCI > >NIC I have seem to broken so I guess it's hard to complete the > >cleanup. You can get a WIP(now stalled) in the following URL. Note, > >the driver may be chatty due to various debugging statements and it > >may not work at all for your controller. > > I guess that I should recompile the whole src tree, or is the driver > enough? I am new to FreeBSD, could anybody help? If you use vge(4) kernel module, rebuilding vge(4) is enough. If vge(4) is statically linked to kernel, rebuilding kernel is necessary(i.e. not whole source tree). I've added some macros to make it build on 7.0-RELEASE. So if you already fetched sources, please refetch it from the following URL. http://people.freebsd.org/~yongari/vge/if_vge.c http://people.freebsd.org/~yongari/vge/if_vgereg.h http://people.freebsd.org/~yongari/vge/if_vgevar.h -- Regards, Pyun YongHyeon From mamruoc at gmail.com Thu Dec 11 18:05:03 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Thu Dec 11 18:05:09 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <20081212015842.GH46707@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> Message-ID: <4941C6BF.4080809@gmail.com> Pyun YongHyeon wrote: > If you use vge(4) kernel module, rebuilding vge(4) is enough. > If vge(4) is statically linked to kernel, rebuilding kernel is > necessary(i.e. not whole source tree). Sorry for being stupid, but I did just install a clean install of FreeBSD 7.0, kernel or driver only? If driver only, how do I do that? Mam From pyunyh at gmail.com Thu Dec 11 18:16:10 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Dec 11 18:16:16 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <4941C6BF.4080809@gmail.com> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> Message-ID: <20081212021549.GJ46707@cdnetworks.co.kr> On Fri, Dec 12, 2008 at 03:04:47AM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >If you use vge(4) kernel module, rebuilding vge(4) is enough. > >If vge(4) is statically linked to kernel, rebuilding kernel is > >necessary(i.e. not whole source tree). > > Sorry for being stupid, but I did just install a clean install of > FreeBSD 7.0, kernel or driver only? > > If driver only, how do I do that? > First save your old vge sources and download the the files. #cd /usr/src/sys/dev/vge #cp -p if_vge.c if_vge.c.orig #cp -p if_vgereg.h if_vgereg.h.orig #cp -p if_vgevar.h if_vgevar.h.orig #fetch http://people.freebsd.org/~yongari/vge/if_vge.c #fetch http://people.freebsd.org/~yongari/vge/if_vgereg.h #fetch http://people.freebsd.org/~yongari/vge/if_vgevar.h And rebuild kernel and then reboot. You don't need to reinstall FreeBSD. -- Regards, Pyun YongHyeon From scaron at umich.edu Thu Dec 11 18:59:30 2008 From: scaron at umich.edu (Sean Thomas Caron) Date: Thu Dec 11 18:59:37 2008 Subject: native ATM users Message-ID: <20081211213503.154712aj9y9bl2a8@web.mail.umich.edu> Hi Kip, I am currently using NATM on FreeBSD/sparc64 with FORE PCA-200E boards. It is a little buggy but it works and I am hoping to continue along with it as long as I can. :) -Sean From kmacy at freebsd.org Thu Dec 11 19:04:00 2008 From: kmacy at freebsd.org (Kip Macy) Date: Thu Dec 11 19:04:31 2008 Subject: native ATM users In-Reply-To: <20081211213503.154712aj9y9bl2a8@web.mail.umich.edu> References: <20081211213503.154712aj9y9bl2a8@web.mail.umich.edu> Message-ID: <3c1674c90812111903o34ef8770vcda21b94b9b07ece@mail.gmail.com> On Thu, Dec 11, 2008 at 6:35 PM, Sean Thomas Caron wrote: > Hi Kip, > > I am currently using NATM on FreeBSD/sparc64 with FORE PCA-200E boards. It > is a little buggy but it works and I am hoping to continue along with it as > long as I can. :) Hi Sean, Thanks for the prompt response. Are you running -CURRENT with it? How long do you foresee using the hardware for? Have you had any direct interaction with the ATM code? Thanks, Kip From glen.j.barber at gmail.com Thu Dec 11 21:40:04 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Thu Dec 11 21:40:10 2008 Subject: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. Message-ID: <200812120540.mBC5e3cd029128@freefall.freebsd.org> The following reply was made to PR kern/129580; it has been noted by GNATS. From: "Glen Barber" To: bug-followup@freebsd.org, glen.j.barber@gmail.com Cc: Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. Date: Fri, 12 Dec 2008 00:04:10 -0500 As it turns out, the problem is not related solely to 7.1-R*. I've had this happen last night on 6.4-RELEASE as well. Same problem with the same workaround. Regards, -- Glen Barber From fernercc at gmail.com Thu Dec 11 22:36:21 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Thu Dec 11 22:36:28 2008 Subject: warning: implicit declaration of function 'VOP_READDIR' Message-ID: <1229042178.4978.2.camel@mobiliare.Belkin> Hello everyone. Im trying to create a system call similar to getdirentries(). When compiling the module, i get the following error: ReadMod.c:160: warning: implicit declaration of function 'VOP_READDIR' I have included all the required header files. #include #include #include Any help will be greatly appreciated. Thanks :) -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From weongyo.jeong at gmail.com Thu Dec 11 23:42:38 2008 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Thu Dec 11 23:42:45 2008 Subject: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. In-Reply-To: <200812120540.mBC5e3cd029128@freefall.freebsd.org> References: <200812120540.mBC5e3cd029128@freefall.freebsd.org> Message-ID: <20081212074221.GA8907@freebsd.weongyo.org> On Fri, Dec 12, 2008 at 05:40:03AM +0000, Glen Barber wrote: > The following reply was made to PR kern/129580; it has been noted by GNATS. > > From: "Glen Barber" > To: bug-followup@freebsd.org, glen.j.barber@gmail.com > Cc: > Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. > Date: Fri, 12 Dec 2008 00:04:10 -0500 > > As it turns out, the problem is not related solely to 7.1-R*. > > I've had this happen last night on 6.4-RELEASE as well. Same problem > with the same workaround. Not related with ndis(4); AFAIK Netgear WG311v3 uses Marvell 88W8335 which is supported by malo(4) shipped with RELENG 7.1. regards, Weongyo Jeong From adeepv at gmail.com Thu Dec 11 23:56:01 2008 From: adeepv at gmail.com (Vyacheslav Bocharov) Date: Thu Dec 11 23:56:07 2008 Subject: crash in dummynet Message-ID: <80861bfa0812112355o386ece39v76cb5cc0f69d5c75@mail.gmail.com> I have frequent panics in dummynet module: Dec 12 08:27:58 chip syslogd: restart Dec 12 08:27:58 chip syslogd: kernel boot file is /boot/kernel/kernel Dec 12 08:27:58 chip kernel: Dec 12 08:27:58 chip kernel: Dec 12 08:27:58 chip kernel: Fatal trap 12: page fault while in kernel mode Dec 12 08:27:58 chip kernel: cpuid = 1; apic id = 01 Dec 12 08:27:58 chip kernel: fault virtual address = 0x10 Dec 12 08:27:58 chip kernel: fault code = supervisor read, page not present Dec 12 08:27:58 chip kernel: instruction pointer = 0x20:0xc06af1fd Dec 12 08:27:58 chip kernel: stack pointer = 0x28:0xe8733bd4 Dec 12 08:27:58 chip kernel: frame pointer = 0x28:0xe8733c18 Dec 12 08:27:58 chip kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Dec 12 08:27:58 chip kernel: = DPL 0, pres 1, def32 1, gran 1 Dec 12 08:27:58 chip kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Dec 12 08:27:58 chip kernel: current process = 48 (dummynet) Dec 12 08:27:58 chip kernel: trap number = 12 Dec 12 08:27:58 chip kernel: panic: page fault Dec 12 08:27:58 chip kernel: cpuid = 1 Dec 12 08:27:58 chip kernel: Uptime: 16h42m29s Dec 12 08:27:58 chip kernel: Physical memory: 3572 MB Dec 12 08:27:58 chip kernel: Dumping 227 MB: Dec 12 08:27:58 chip kernel: arp: 00:15:17:28:39:7f is using my IP address 10.200.216.1 on vlan24! Dec 12 08:27:58 chip kernel: Copyright (c) 1992-2008 The FreeBSD Project. Dec 12 08:27:58 chip kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 12 08:27:58 chip kernel: The Regents of the University of California. All rights reserved. Dec 12 08:27:58 chip kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Dec 12 08:27:58 chip kernel: FreeBSD 7.1-PRERELEASE #3: Wed Dec 10 10:07:04 EET 2008 Dec 12 08:27:58 chip kernel: root@chip.lexi.net.ua:/usr/obj/usr/src/sys/chip Dec 12 08:27:58 chip kernel: module_register: module g_journal already exists! Dec 12 08:27:58 chip kernel: Module g_journal failed to register: 17 Dec 12 08:27:58 chip kernel: module_register: module g_mirror already exists! Dec 12 08:27:58 chip kernel: Module g_mirror failed to register: 17 Dec 12 08:27:58 chip kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Dec 12 08:27:58 chip kernel: CPU: Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz (1995.01-MHz 686-class CPU) Dec 12 08:27:58 chip kernel: Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Dec 12 08:27:58 chip kernel: Features=0xbfebfbff Dec 12 08:27:58 chip kernel: Features2=0xe39d Dec 12 08:27:58 chip kernel: AMD Features=0x20100000 Dec 12 08:27:58 chip kernel: AMD Features2=0x1 Dec 12 08:27:58 chip kernel: Cores per package: 2 Dec 12 08:27:58 chip kernel: real memory = 3755986944 (3581 MB) ... Dec 12 08:27:58 chip kernel: Checking for core dump on /dev/mirror/vpns1b... Dec 12 08:27:58 chip kernel: savecore: no dumps found Dec 12 08:27:58 chip savecore: no dumps found -- Vyacheslav Bocharov From mav at mavhome.dp.ua Fri Dec 12 01:20:04 2008 From: mav at mavhome.dp.ua (Alexander Motin) Date: Fri Dec 12 01:20:11 2008 Subject: ng_bridge + ng_ksocket In-Reply-To: <1229005383.00046904.1228994401@10.7.7.3> References: <1229005383.00046904.1228994401@10.7.7.3> Message-ID: <49421EB0.7040205@mavhome.dp.ua> Nikos Vassiliadis wrote: > I would like to create an ethernet over UDP tunnel. For my > purposes, using ng_bridge and ng_ksocket seem fine. The > problem is that the peer address/port is not known, since > it will be behind a NAT device and will have a dynamically > assigned IP address. In userspace I would use something like > recvfrom() to get the peer address. I don't know what to do > for ngctl and ng_ksocket. Any suggestions? Is this doable? > Is there something I can do to circumvent the problem? Five years ago I had the same problem. In result, I have written a small program which monitor interface with libpcap and calls script to reconnect ng_ksocket to the new peer address/port when it changes. The code is old, dirty and was not used for a long time, but if you wish to try that way - it is attached. -- Alexander Motin -------------- next part -------------- #ifdef HAVE_CONFIG_H #include #endif extern "C" { # include # include # include # include # include # include # include # include # include # include # include # include # include # include # include }; #include #include #include #include extern char *optarg; extern int optind; extern int optopt; extern int opterr; extern int optreset; char our_iface[5]; char our_addr[16]; int our_port; char our_script[128]; unsigned int cur_addr=0; unsigned int cur_port=0; void discard(int sig) { std::cerr << "??????? ??????" << std::endl; } void usage() { std::cout << "program -i iface -a addr -p port -s script" << std::endl; } int if_ip(register const u_char *buf, unsigned int size) { if (size < sizeof(struct ip)) { std::cerr << "it is too small (" << size << " bytes) to be an ip packet." << std::endl; return 1; } struct ip *ip = (struct ip*) buf; if (ip->ip_v != IPVERSION) { std::cerr << "ip ver != " << IPVERSION << ": discard " << size << "bytes" << std::endl; return 2; } if ((ip->ip_p == IPPROTO_UDP)&&((ntohs(ip->ip_off) & IP_OFFMASK) == 0)) { u_int hlen = ip->ip_hl * 4; u_char *cp = (u_char *)ip + hlen; unsigned int addr=ip->ip_src.s_addr; struct in_addr in; in.s_addr=addr; unsigned int port=ntohs(((struct udphdr *)cp)->uh_sport); if ((cur_addr!=addr) || (cur_port!=port)) { std::cerr << "CHANGED to " << inet_ntoa(in)<< ":" << port << std::endl; cur_addr=addr; cur_port=port; switch (fork()) { case 0: char tmp[128]; snprintf(tmp,128,"%s:%d",inet_ntoa(in),port); // std::cerr << our_script<<","<caplen)) { // validate Ether packet length return; } struct ether_header *p = (struct ether_header *)buf; if (ntohs(p->ether_type)==ETHERTYPE_IP) { if_ip(buf+sizeof(struct ether_header), h->caplen-sizeof(struct ether_header)); } return; } int main(int argc, char *argv[]) { int ch; while ((ch = getopt(argc, argv,"i:a:p:s:"))!=-1) { switch (ch) { case 'i': strncpy(our_iface,optarg,5); break; case 'a': strncpy(our_addr,optarg,16); break; case 'p': our_port = atoi(optarg); break; case 's': strncpy(our_script,optarg,128); break; case '?': default: usage(); return 1; } } //------------------------------------------- signal(SIGTERM, discard); siginterrupt(SIGTERM, 1); pcap_t *pd; char ebuf[PCAP_ERRBUF_SIZE]; /* open bpf with required snaplen */ if ((pd = pcap_open_live(our_iface, 100, 0/*no_promisc...*/, 10000, ebuf)) == NULL) { std::cerr<<"?????? pcap_open_live " < Synopsis: [if_rl]: rl driver does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Dec 12 09:46:25 UTC 2008 Responsible-Changed-Why: REassign to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=129538 From glen.j.barber at gmail.com Fri Dec 12 02:06:14 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Fri Dec 12 02:06:20 2008 Subject: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. In-Reply-To: <20081212074221.GA8907@freebsd.weongyo.org> References: <200812120540.mBC5e3cd029128@freefall.freebsd.org> <20081212074221.GA8907@freebsd.weongyo.org> Message-ID: <20081212093710.GA50649@orion.hsd1.pa.comcast.net> Weongyo Jeong said: > On Fri, Dec 12, 2008 at 05:40:03AM +0000, Glen Barber wrote: > > The following reply was made to PR kern/129580; it has been noted by GNATS. > > > > From: "Glen Barber" > > To: bug-followup@freebsd.org, glen.j.barber@gmail.com > > Cc: > > Subject: Re: kern/129580: [ndis] Netgear WG311v3 (ndis) causes kenel trap at boot. > > Date: Fri, 12 Dec 2008 00:04:10 -0500 > > > > As it turns out, the problem is not related solely to 7.1-R*. > > > > I've had this happen last night on 6.4-RELEASE as well. Same problem > > with the same workaround. > > Not related with ndis(4); AFAIK Netgear WG311v3 uses Marvell 88W8335 > which is supported by malo(4) shipped with RELENG 7.1. > I'm not currently running 7.1 at the moment, or I'd test this; however, this doesn't explain why it happens on 6.X also, unless there is a different driver I'm missing. I checked out the GENERIC kernel config to be sure, but didn't see anything. Regards, -- Glen Barber From yongari at FreeBSD.org Fri Dec 12 02:21:14 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Fri Dec 12 02:21:24 2008 Subject: kern/129538: [if_rl]: rl driver does not work Message-ID: <200812121021.mBCALDgh065349@freefall.freebsd.org> Synopsis: [if_rl]: rl driver does not work State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Dec 12 10:20:12 UTC 2008 State-Changed-Why: Would you show me the output of "ifconfig rl0" and dmesg information? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Dec 12 10:20:12 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=129538 From nvass at teledomenet.gr Fri Dec 12 04:30:31 2008 From: nvass at teledomenet.gr (Nikos Vassiliadis) Date: Fri Dec 12 04:30:37 2008 Subject: ng_bridge + ng_ksocket In-Reply-To: <49421EB0.7040205@mavhome.dp.ua> References: <1229005383.00046904.1228994401@10.7.7.3> <49421EB0.7040205@mavhome.dp.ua> Message-ID: <200812121429.38205.nvass@teledomenet.gr> On Friday 12 December 2008 10:20:00 Alexander Motin wrote: > Five years ago I had the same problem. In result, I have written a small > program which monitor interface with libpcap and calls script to > reconnect ng_ksocket to the new peer address/port when it changes. > > The code is old, dirty and was not used for a long time, but if you wish > to try that way - it is attached. It works, but I don't want go to down that road. I was hopping that I was missing something... Would you ever consider such a feature, totally unrelated to PPP, for mpd? Nikos From onemda at gmail.com Fri Dec 12 04:52:20 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Dec 12 04:52:31 2008 Subject: crash in dummynet In-Reply-To: <80861bfa0812112355o386ece39v76cb5cc0f69d5c75@mail.gmail.com> References: <80861bfa0812112355o386ece39v76cb5cc0f69d5c75@mail.gmail.com> Message-ID: <3a142e750812120452s2cd7c629m484261fba700610b@mail.gmail.com> On 12/12/08, Vyacheslav Bocharov wrote: > I have frequent panics in dummynet module: > > Dec 12 08:27:58 chip syslogd: restart > Dec 12 08:27:58 chip syslogd: kernel boot file is /boot/kernel/kernel > Dec 12 08:27:58 chip kernel: > Dec 12 08:27:58 chip kernel: > Dec 12 08:27:58 chip kernel: Fatal trap 12: page fault while in kernel mode > Dec 12 08:27:58 chip kernel: cpuid = 1; apic id = 01 > Dec 12 08:27:58 chip kernel: fault virtual address = 0x10 > Dec 12 08:27:58 chip kernel: fault code = supervisor read, page not > present > Dec 12 08:27:58 chip kernel: instruction pointer = 0x20:0xc06af1fd > Dec 12 08:27:58 chip kernel: stack pointer = 0x28:0xe8733bd4 > Dec 12 08:27:58 chip kernel: frame pointer = 0x28:0xe8733c18 > Dec 12 08:27:58 chip kernel: code segment = base 0x0, limit > 0xfffff, type 0x1b > Dec 12 08:27:58 chip kernel: = DPL 0, pres 1, def32 1, gran 1 > Dec 12 08:27:58 chip kernel: processor eflags = interrupt enabled, resume, > IOPL = 0 > Dec 12 08:27:58 chip kernel: current process = 48 (dummynet) > Dec 12 08:27:58 chip kernel: trap number = 12 > Dec 12 08:27:58 chip kernel: panic: page fault > Dec 12 08:27:58 chip kernel: cpuid = 1 > Dec 12 08:27:58 chip kernel: Uptime: 16h42m29s > Dec 12 08:27:58 chip kernel: Physical memory: 3572 MB > Dec 12 08:27:58 chip kernel: Dumping 227 MB: backtrace? -- Paul From rrs at lakerest.net Fri Dec 12 04:56:41 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 12 04:56:48 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <200812111412.16757.max@love2party.net> References: <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <200812111412.16757.max@love2party.net> Message-ID: <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> On Dec 11, 2008, at 8:12 AM, Max Laier wrote: > On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: >> All: >> >> Ok here is what I have come up with.. going along the >> lines of Max's suggestion.. its pretty clean I think. >> >> Comments would be most welcome.. >> >> The only thing possibly a bit dodgy is that >> >> 1) UDP has no per-protocol block. >> 2) Instead of creating one, I am using the block pointer in the inp >> as the function pointer for the tunneling. >> >> What this means if we EVERY did add a per protocol structure for >> UDP we would need to move the function pointer in there.. >> >> The nice thing it does is make it so we have no structural changes to >> the code... i.e. complete compatibility... no changes to inp or >> other UDP structures :-) >> >> >> Here is the patch.. please send comments ;-D > > I like it, though I have no idea what the implications of using the > block > pointer might be. > > One thing about the patch: What about the multi-/broadcast cases? > I think if > we introduce this, we want to make sure it works there as well - no? Hmm.. Well I don't know if I like the idea of the broadcast/ multicast... for tunneling.. Then again.. you may be right.. thinking on this DCCP can do multicast as well.. so let me go look at it. > > > And finally, is there a potential race with setting the function and > data > arriving at the socket - should udp_set_kernel_tunneling maybe check > that the > socket isn't bound yet? Yep, in fact I figured that out as I started trying to get SCTP to use this. We HAVE to have it un-bound when you do the set_kernel_tunneling function... that way you can make sure no packets have arrived for you BEFORE you bind. So I have removed the bind restriction. Another thing... kinda weird.. when I have this thing working with SCTP and I let the SCTP stack try to initialize the socket right away.. I get bogus results. The port is actually binding.. but yet it cant be sent to. If I unbind i.e. close the socket that got created.. then do a sysctl to re- add the same port.. all works fine. For now I am going to make SCTP NOT do this.. and have to add it to the sysctl's in /etc/sysctl.conf to add UDP tunneling. Only other solution would be a timer in the transport after startup to do this binding... I was wondering if I would see a race in the protocol stack initialization.. basically my guess is SCTP initializes ahead of UDP.. so its actually a wonder I did not crash ;-D R > > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rrs at lakerest.net Fri Dec 12 04:59:49 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 12 04:59:55 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <494157DF.6030802@FreeBSD.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> Message-ID: <57BBB796-7E00-4D96-BACE-1306FC4C1417@lakerest.net> Bruce: On Dec 11, 2008, at 1:11 PM, Bruce M. Simpson wrote: > Hi, > > I am missing context of what Max's suggestion was, do you have a > reference to an old email thread? As to the context... Nov 18 2008 10:01 (am Eastern) I started a thread "Thinking about UDP and tunneling" > > > Style bugs: > * needs style(9) and whitespace cleanup. Hmm.. I thought I had got all this stuff... I actually (shudder) switched to vi since my emacs spacing always messes up.. in the SCTP code I have the s9indent function that fixes any issues.. but I did not want to run that on the udp src and cause other changes ... I will go back and look at the patch.. > > * C typedefs should be suffixed with _t for consistency with other > kernel typedefs. Good point I will fix the stuff to have _t in it :-) > > * Function typedefs usually named like foo_func_t (see other > subsystems) R > > > Have you looked at m_apply() ? It already exists for stuff like this > i.e. functions which act on an mbuf chain, although it doesn't > necessarily expect chain heads. > > cheers > BMS > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From mav at mavhome.dp.ua Fri Dec 12 05:38:44 2008 From: mav at mavhome.dp.ua (Alexander Motin) Date: Fri Dec 12 05:38:51 2008 Subject: ng_bridge + ng_ksocket In-Reply-To: <200812121429.38205.nvass@teledomenet.gr> References: <1229005383.00046904.1228994401@10.7.7.3> <49421EB0.7040205@mavhome.dp.ua> <200812121429.38205.nvass@teledomenet.gr> Message-ID: <49426962.5070809@mavhome.dp.ua> Nikos Vassiliadis wrote: > On Friday 12 December 2008 10:20:00 Alexander Motin wrote: >> Five years ago I had the same problem. In result, I have written a small >> program which monitor interface with libpcap and calls script to >> reconnect ng_ksocket to the new peer address/port when it changes. >> >> The code is old, dirty and was not used for a long time, but if you wish >> to try that way - it is attached. > > It works, but I don't want go to down that road. > I was hopping that I was missing something... > > Would you ever consider such a feature, totally unrelated > to PPP, for mpd? Feature of what? ksocket is just a building brick, not a complete end-user solution. It is just a netgraph wrapper around kernel socket implementation. It may be sufficient for trivial cases, but no more. UDP socket is connectionless, so it does not handle remote address change. If it is connected to some remote address/port it just will not receive any other packet. You need some daemon to handle any additional logic. One simple example I have send to you. Another one is MPD, implementing L2TP and PPP-over-UDP links. Mpd opens separate UDP socket in user-level which catches everything that wasn't caught by existing connected sockets in netgraph and dynamically creates and connects additional UDP sockets in netgraph to handle this traffic. -- Alexander Motin From rrs at lakerest.net Fri Dec 12 05:46:32 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 12 05:46:39 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <494157DF.6030802@FreeBSD.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> Message-ID: <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> Ok: Here is an updated patch it: 1) Fixes style9 issues (I hope.. I went back to vi and tried tabs :-0.. sigh one of these doys I will figure out why my .emacs settings just never cut it :-() 2) move to _t typedef 3) Allow multicast/broadcast to also be tunneled. 4) Binding is now no longer a requirement to set tunneling mode, in fact most protocols had better NOT have bound.. first set options, then bind :-) There was one thing I was a bit leary of for <3>. In the loop for going through all the inp's of UDP that are listening to a m-cast/b-cast I could not release the INP_INFO_LOCK() in other cases I make sure all locks are released when we call into the tunneling protocol. I think this will be ok as long as the tunnelee does not try to use the INP_INFO_LOCK of the UDP world... I know for SCTP this is a non-issue.. but it may be something we want to think about... not sure. If there are no serious objections I will submit this into head.. and followed behind it I will send in the changes so SCTP can be tunneled over this new mechanism :-) R -------------- next part -------------- Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 185928) +++ netinet/udp_usrreq.c (working copy) @@ -488,10 +488,25 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + */ + udp_tunnel_function_t tunnel_func; + + INP_RUNLOCK(last); + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } } last = inp; /* @@ -516,10 +531,25 @@ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } return; } @@ -563,6 +593,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, iphlen); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1180,41 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 185928) +++ netinet/udp_var.h (working copy) @@ -107,6 +107,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 185928) +++ netinet6/udp6_usrreq.c (working copy) @@ -286,9 +286,21 @@ struct mbuf *n; if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { - INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + } else { + INP_RLOCK(last); + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; @@ -317,6 +329,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +379,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); -------------- next part -------------- On Dec 11, 2008, at 1:11 PM, Bruce M. Simpson wrote: > Hi, > > I am missing context of what Max's suggestion was, do you have a > reference to an old email thread? > > Style bugs: > * needs style(9) and whitespace cleanup. > * C typedefs should be suffixed with _t for consistency with other > kernel typedefs. > * Function typedefs usually named like foo_func_t (see other > subsystems) > > Have you looked at m_apply() ? It already exists for stuff like this > i.e. functions which act on an mbuf chain, although it doesn't > necessarily expect chain heads. > > cheers > BMS > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From nrml at att.net Fri Dec 12 05:51:24 2008 From: nrml at att.net (Gabe) Date: Fri Dec 12 05:51:31 2008 Subject: NAT-T + ipsec integration Message-ID: <20081212135124.115368FC24@mx1.freebsd.org> So far so good... Should I be worried that the patch file names have 'test' in them? -----Original Message----- From: Gabe Sent: Thursday, December 11, 2008 5:31 AM To: VANHULLEBUS Yvan Cc: freebsd-net@freebsd.org Subject: RE: NAT-T + ipsec integration Ok recompiling now. Hopefully it works fine. I'll report back. Thanks. -----Original Message----- From: VANHULLEBUS Yvan Sent: Thursday, December 11, 2008 4:39 AM To: Gabe Cc: freebsd-net@freebsd.org Subject: Re: NAT-T + ipsec integration On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > Hello all Hi. > Does anyone know how to enable nat traversal on freebsd? > > I've got a site to site ipsec tunnel setup but clients behind the > nat can't vpn through it. Any help would be appreciated. Actually, you can apply a patch to src/sys and recompile your kernel with IPSEC_NAT_T options. Patches are available here: http://people.freebsd.org/~vanhu/NAT-T/ You can also try to play with Perforce's branch, but it is still work in progress to have a cleaned up version of PFKey interface (it may work, but I just started to set up some testing hosts). To answer the question some people may ask in this thread: the whole patch should be included in TRUNK as soon as PFKey cleanup will be done (which means "implemented + heavilly tested + reviewed"). Yvan. _______________________________________________ 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 nvass at teledomenet.gr Fri Dec 12 06:13:26 2008 From: nvass at teledomenet.gr (Nikos Vassiliadis) Date: Fri Dec 12 06:13:34 2008 Subject: ng_bridge + ng_ksocket In-Reply-To: <49426962.5070809@mavhome.dp.ua> References: <1229005383.00046904.1228994401@10.7.7.3> <200812121429.38205.nvass@teledomenet.gr> <49426962.5070809@mavhome.dp.ua> Message-ID: <200812121612.34002.nvass@teledomenet.gr> On Friday 12 December 2008 15:38:42 Alexander Motin wrote: > You need some daemon to handle any additional logic. One simple example > I have send to you. Another one is MPD, implementing L2TP and > PPP-over-UDP links. Mpd opens separate UDP socket in user-level which > catches everything that wasn't caught by existing connected sockets in > netgraph and dynamically creates and connects additional UDP sockets in > netgraph to handle this traffic. Yes, that's what I meant. If you would consider the possibility of adding L2 over UDP functionality to MPD. I am asking this, since you've already done things like this for MPD and I suspect that there are some bits already in place. Of course a simple "I don't want to" or "no time" would be a fine answer:) OTOH you could also say that ethernet over UDP is conceptually unrelated to PPP, which is what MPD does. Nikos From mav at mavhome.dp.ua Fri Dec 12 06:39:59 2008 From: mav at mavhome.dp.ua (Alexander Motin) Date: Fri Dec 12 06:40:08 2008 Subject: ng_bridge + ng_ksocket In-Reply-To: <200812121612.34002.nvass@teledomenet.gr> References: <1229005383.00046904.1228994401@10.7.7.3> <200812121429.38205.nvass@teledomenet.gr> <49426962.5070809@mavhome.dp.ua> <200812121612.34002.nvass@teledomenet.gr> Message-ID: <494277BD.2030804@mavhome.dp.ua> Nikos Vassiliadis wrote: > On Friday 12 December 2008 15:38:42 Alexander Motin wrote: >> You need some daemon to handle any additional logic. One simple example >> I have send to you. Another one is MPD, implementing L2TP and >> PPP-over-UDP links. Mpd opens separate UDP socket in user-level which >> catches everything that wasn't caught by existing connected sockets in >> netgraph and dynamically creates and connects additional UDP sockets in >> netgraph to handle this traffic. > > Yes, that's what I meant. If you would consider the possibility > of adding L2 over UDP functionality to MPD. I am asking this, > since you've already done things like this for MPD and I suspect > that there are some bits already in place. Of course a simple > "I don't want to" or "no time" would be a fine answer:) There is some L2 over PPP RFC exists which itself can be transported over UDP or whatever else. It surely has additional overhead, but instead gives many of native PPP bonuses like authentication, encryption, compression, etc. I was thinking about implementing it, but I haven't found any other existing implementation and so dropped it. > OTOH you could also say that ethernet over UDP is conceptually > unrelated to PPP, which is what MPD does. Indeed. MPD is a PPP daemon. -- Alexander Motin From vanhu at FreeBSD.org Fri Dec 12 06:52:23 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Dec 12 06:52:35 2008 Subject: NAT-T + ipsec integration In-Reply-To: <20081212135124.115368FC24@mx1.freebsd.org> References: <20081212135124.115368FC24@mx1.freebsd.org> Message-ID: <20081212145300.GA14254@zeninc.net> On Fri, Dec 12, 2008 at 05:51:31AM -0800, Gabe wrote: > So far so good... Should I be worried that the patch file names have 'test' in them? I can rename them if you want ;-) Patch for FreeBSD6 is stable enough to be used in production and to survive non regression test suite at NETASQ. Patch for FreeBSD7 is used by many people AFAIK, including my own IPsec gates which have tunnels up 24h/7. I called those versions "test" when I put them online because I only checked that they compile before releasing them. They have been much more tested since. Yvan. From nrml at att.net Fri Dec 12 06:58:07 2008 From: nrml at att.net (Gabe) Date: Fri Dec 12 06:58:13 2008 Subject: NAT-T + ipsec integration Message-ID: <20081212145806.B11D88FC12@mx1.freebsd.org> Hehehe no I was just wondering. I'm running 7 and the patch installed just fine. -----Original Message----- From: VANHULLEBUS Yvan Sent: Friday, December 12, 2008 6:53 AM To: Gabe Cc: freebsd-net@freebsd.org Subject: Re: RE: NAT-T + ipsec integration On Fri, Dec 12, 2008 at 05:51:31AM -0800, Gabe wrote: > So far so good... Should I be worried that the patch file names have 'test' in them? I can rename them if you want ;-) Patch for FreeBSD6 is stable enough to be used in production and to survive non regression test suite at NETASQ. Patch for FreeBSD7 is used by many people AFAIK, including my own IPsec gates which have tunnels up 24h/7. I called those versions "test" when I put them online because I only checked that they compile before releasing them. They have been much more tested since. Yvan. _______________________________________________ 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 samflanker at gmail.com Fri Dec 12 07:12:38 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Fri Dec 12 07:12:45 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <20081212014011.GG46707@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> <493E1872.9010306@gmail.com> <20081212014011.GG46707@cdnetworks.co.kr> Message-ID: <49427F7A.2020103@gmail.com> Pyun YongHyeon wrote: > > > > > >Thanks. Patch committed to HEAD(r185784). > > > > > > > > MFC? > > > > sis(4) supports two kind of controllers. One was made by SiS and > the other was manufactured by National Semiconductor. So I think we > need test report for NatSemi DP83815 case prior to MFC. > > need a PR? /Vladimir Ermakov From nvass at teledomenet.gr Fri Dec 12 07:17:52 2008 From: nvass at teledomenet.gr (Nikos Vassiliadis) Date: Fri Dec 12 07:17:58 2008 Subject: ng_bridge + ng_ksocket In-Reply-To: <494277BD.2030804@mavhome.dp.ua> References: <1229005383.00046904.1228994401@10.7.7.3> <200812121612.34002.nvass@teledomenet.gr> <494277BD.2030804@mavhome.dp.ua> Message-ID: <200812121716.59610.nvass@teledomenet.gr> Thanks for the answers. Your hard work on MPD is much appreciated. Nikos From brde at optusnet.com.au Fri Dec 12 08:47:58 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Dec 12 08:48:04 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> Message-ID: <20081213030449.F2405@delplex.bde.org> On Fri, 12 Dec 2008, Randall Stewart wrote: > Here is an updated patch it: > > 1) Fixes style9 issues (I hope.. I went back to vi and tried tabs :-0.. sigh > one of > these doys I will figure out why my .emacs settings just never cut it :-() Fraid not. % Index: netinet/udp_usrreq.c % =================================================================== % --- netinet/udp_usrreq.c (revision 185928) % +++ netinet/udp_usrreq.c (working copy) % @@ -488,10 +488,25 @@ % struct mbuf *n; % % n = m_copy(m, 0, M_COPYALL); % - if (n != NULL) % - udp_append(last, ip, n, iphlen + % - sizeof(struct udphdr), &udp_in); % - INP_RUNLOCK(last); % + Extra blank line. % + if (last->inp_ppcb == NULL) { % + if (n != NULL) % + udp_append(last, ip, n, iphlen + % + sizeof(struct udphdr), &udp_in); Line too long. % + INP_RUNLOCK(last); % + } else { % + /* Engage the tunneling protocol "/*" not on a line by itself. % + * we will have to leave the info_lock % + * up, since we are hunting through % + * multiple UDP inp's hope we don't break :-( Line too long. Defeats reasonable indentation of the rest of the comment. Missing punctuation after ":-(". % + */ % + udp_tunnel_function_t tunnel_func; Nested declaration. % + % + INP_RUNLOCK(last); % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; Line too long. Typedef names involving functions normally use `func_t', not `function_t'. This is useful for reducing verboseness and resulting long lines but wouldn't fix the long line in the above, since everything in it is too verbose (in the middle there is an ugly cast whose only effect can be to avoid a warning ...). % @@ -516,10 +531,25 @@ % V_udpstat.udps_noportbcast++; % goto badheadlocked; % } % - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), % - &udp_in); % - INP_RUNLOCK(last); % - INP_INFO_RUNLOCK(&V_udbinfo); % + if (last->inp_ppcb == NULL) { % + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), % + &udp_in); % + INP_RUNLOCK(last); % + INP_INFO_RUNLOCK(&V_udbinfo); % + } else { % + /* Engage the tunneling protocol "/*" not on a line by itself. No comment on further instances of this % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ Long lines are ones longer than 80 characters. Splitting at 48 characters as in the above is not normal. % + udp_tunnel_function_t tunnel_func; Nested declaration. % @@ -563,6 +593,18 @@ % INP_RUNLOCK(inp); % goto badunlocked; % } % + if (inp->inp_ppcb) { % + /* Engage the tunneling protocol % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ More formatting for 48-column terminals. % + udp_tunnel_function_t tunnel_func; Nested declaration. Missing blank line after declarations. % ... % +int % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f) % +{ % + struct inpcb *inp; % + inp = (struct inpcb *)so->so_pcb; Initialization in declaration. Not too bad here, but you don't do it for similar tunnel function pointer conversions. % + % + if (so->so_type != SOCK_DGRAM) { % + /* Not UDP socket... sorry */ Missing punctuation. % Index: netinet/udp_var.h % =================================================================== % --- netinet/udp_var.h (revision 185928) % +++ netinet/udp_var.h (working copy) % @@ -107,6 +107,10 @@ % void udp_input(struct mbuf *, int); % struct inpcb *udp_notify(struct inpcb *inp, int errno); % int udp_shutdown(struct socket *so); % + % + % +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); I noticed this first in the initial patch. It has a style bug density of about 5 per line !-(: - 2 extra blank lines - typedef in the middle of (non-pointer non-typedef) prototypes - unsorted prototypes (at least the old 3 visible on the above are sorted) - new prototypes not indented normally though visible old ones all are - some parameters have names, some not. - style(9) says to always have names in the kernel, but this rule is usually violated - the first of the 3 visible old prototypes violates this rule - the first of the new prototypes violates this rule for the first of its 2 parameters only % #endif % % #endif % Index: netinet6/udp6_usrreq.c % =================================================================== % --- netinet6/udp6_usrreq.c (revision 185928) % +++ netinet6/udp6_usrreq.c (working copy) % @@ -286,9 +286,21 @@ % struct mbuf *n; % % if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { % - INP_RLOCK(last); % - udp6_append(last, n, off, &fromsa); % - INP_RUNLOCK(last); % + if (last->inp_ppcb) { % + /* Engage the tunneling protocol % + * we will have to leave the info_lock % + * up, since we are hunting through % + * multiple UDP inp's hope we don't break :-( % + */ Lines too long -- now formatting for 94-column terminals instead of 48-column ones using cut&pasted&indent. Missing punctuation (cut&paste). % + udp_tunnel_function_t tunnel_func; Nested declaration. Line too long. Missing blank line after declarations. % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; Line too long. % + INP_RUNLOCK(last); % + tunnel_func(m, off); % + } else { % + INP_RLOCK(last); % + udp6_append(last, n, off, &fromsa); Line too long. % @@ -317,6 +329,19 @@ % } % INP_RLOCK(last); % INP_INFO_RUNLOCK(&V_udbinfo); % + if (last->inp_ppcb) { % + /* Engage the tunneling protocol % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ Now formatting for 56-column terminals. % @@ -354,6 +379,18 @@ % } % INP_RLOCK(inp); % INP_INFO_RUNLOCK(&V_udbinfo); % + if (inp->inp_ppcb) { % + /* Engage the tunneling protocol % + * we must make sure all locks % + * are released when we call the % + * tunneling protocol. % + */ Back to formatting for 48-column terminals. There are 6 near-copies of this comment. % + udp_tunnel_function_t tunnel_func; Nested declaration. Missing blank line after declaration. % + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; % + INP_RUNLOCK(inp); % + tunnel_func(m, off); Do you have to hold the lock to access inp->inp_ppcb? Otherwise you can avoid all the nested declarations and just use the pointer once. If the lock is needed, then what happens if the pointer changes after it is accessed? % + return (IPPROTO_DONE); % + } % udp6_append(inp, m, off, &fromsa); % INP_RUNLOCK(inp); % return (IPPROTO_DONE); Bruce From artem at aws-net.org.ua Fri Dec 12 09:16:16 2008 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Fri Dec 12 09:16:24 2008 Subject: NAT-T + ipsec integration In-Reply-To: <20081211123958.GA5332@zeninc.net> References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> Message-ID: <200812121845.20262.artem@aws-net.org.ua> On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: > On Thu, Dec 11, 2008 at 04:02:01AM -0800, Gabe wrote: > > Hello all > > Hi. > > > Does anyone know how to enable nat traversal on freebsd? > > > > I've got a site to site ipsec tunnel setup but clients behind the > > nat can't vpn through it. Any help would be appreciated. > > Actually, you can apply a patch to src/sys and recompile your kernel > with IPSEC_NAT_T options. > Patches are available here: > http://people.freebsd.org/~vanhu/NAT-T/ And what about patches for 6.4-RELEASE? > > > You can also try to play with Perforce's branch, but it is still work > in progress to have a cleaned up version of PFKey interface (it may > work, but I just started to set up some testing hosts). > > > > To answer the question some people may ask in this thread: the whole > patch should be included in TRUNK as soon as PFKey cleanup will be > done (which means "implemented + heavilly tested + reviewed"). > > > > Yvan. > _______________________________________________ > 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" -- ? ? ? ? ? ? Sincerely yours, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net ? | ================================ FreeBSD: The Power to Serve ? - ?http://www.freebsd.org From mamruoc at gmail.com Fri Dec 12 09:18:38 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Fri Dec 12 09:18:45 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <20081212021549.GJ46707@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> Message-ID: <49429CEB.60607@gmail.com> Pyun YongHyeon wrote: > And rebuild kernel and then reboot. You don't need to reinstall > FreeBSD. Oki, I have done that and rebooted, the driver seems to work better now: Dec 12 17:47:16 freebsd kernel: vge0: port 0xf800-0xf8ff mem 0xfdffe000-0xfdffe0ff irq 18 at device 14.0 on pci0 Dec 12 17:47:16 freebsd kernel: vge0: MSIX count : 0 Dec 12 17:47:16 freebsd kernel: vge0: MSI count : 0 Dec 12 17:47:16 freebsd kernel: miibus0: on vge0 Dec 12 17:47:16 freebsd kernel: vge0: Ethernet address: 00:40:63:e9:9a:1c Dec 12 17:47:16 freebsd kernel: vge0: [FILTER] What is the next step to be able to make this fix go into the FreeBSD 7.0 tree? Mam From max at love2party.net Fri Dec 12 09:19:30 2008 From: max at love2party.net (Max Laier) Date: Fri Dec 12 09:19:37 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> References: <200812111412.16757.max@love2party.net> <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> Message-ID: <200812121819.27990.max@love2party.net> On Friday 12 December 2008 13:56:38 Randall Stewart wrote: > On Dec 11, 2008, at 8:12 AM, Max Laier wrote: > > On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: ... > Another thing... kinda weird.. when I have this thing working with > SCTP and I > let the SCTP stack try to initialize the socket right away.. I get bogus > results. The port is actually binding.. but yet it cant be sent to. If I > unbind i.e. close the socket that got created.. then do a sysctl to re- > add > the same port.. all works fine. > > For now I am going to make SCTP NOT do this.. and have to add it to the > sysctl's in /etc/sysctl.conf to add UDP tunneling. > > Only other solution would be a timer in the transport after startup to > do this binding... You can probably do a SYSINIT in SI_SUB_PROTO_DOMAIN around the middle and you should be golden. If it turns out that this is not late enough you can check sys/kernel.h for later SI_SUBs that might be fitting. > I was wondering if I would see a race in the protocol stack > initialization.. basically > my guess is SCTP initializes ahead of UDP.. so its actually a wonder I > did not crash ;-D -- /"\ 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 vanhu at FreeBSD.org Fri Dec 12 09:55:02 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Dec 12 09:55:09 2008 Subject: NAT-T + ipsec integration In-Reply-To: <200812121845.20262.artem@aws-net.org.ua> References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> Message-ID: <20081212175500.GA2573@zeninc.net> On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: > On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: [....] > > Actually, you can apply a patch to src/sys and recompile your kernel > > with IPSEC_NAT_T options. > > Patches are available here: > > http://people.freebsd.org/~vanhu/NAT-T/ > > And what about patches for 6.4-RELEASE? I just not tested on 6.4 (almost all my devices moved to 7.x, and the remaining ones will stay in 6.3 for various reasons), but 6.3 patch should work on 6.4 if it compiles cleanly (I did NOT check every single kernel change between 6.3 and 6.4). If people can test it and see some compile/runtime problems, please report them, I'll try to fix them. Yvan. From jmg at funkthat.com Fri Dec 12 10:47:26 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Fri Dec 12 10:47:33 2008 Subject: strange problem with ifconfig alias In-Reply-To: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> Message-ID: <20081212181246.GG34842@funkthat.com> Vyacheslav Bocharov wrote this message on Thu, Dec 11, 2008 at 16:29 +0200: > I have strange problem with ifconfig: I can't add ip address to interface: Have you followed the instructions in the handbook: http://www.freebsd.org/doc/en/books/handbook/configtuning-virtual-hosts.html > root@chip# ifconfig em1 alias 195.3.245.xx/30 > ifconfig: ioctl (SIOCAIFADDR): File exists If there is already an ip in that range on the interface, you need to use: ifconfig em1 alias 195.3.245.xx/32 Next time include ifconfig -a so we know what addresses and interfaces you have. Makes diagnostics easier. P.S. This question is better targeted to -questions. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From sclark46 at earthlink.net Fri Dec 12 10:50:15 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri Dec 12 10:50:20 2008 Subject: NAT-T + ipsec integration In-Reply-To: <20081212175500.GA2573@zeninc.net> References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> <20081212175500.GA2573@zeninc.net> Message-ID: <4942B264.5020607@earthlink.net> VANHULLEBUS Yvan wrote: > On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: >> On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: > [....] >>> Actually, you can apply a patch to src/sys and recompile your kernel >>> with IPSEC_NAT_T options. >>> Patches are available here: >>> http://people.freebsd.org/~vanhu/NAT-T/ >> And what about patches for 6.4-RELEASE? > > I just not tested on 6.4 (almost all my devices moved to 7.x, and the > remaining ones will stay in 6.3 for various reasons), but 6.3 patch > should work on 6.4 if it compiles cleanly (I did NOT check every > single kernel change between 6.3 and 6.4). > > If people can test it and see some compile/runtime problems, please > report them, I'll try to fix them. > > > > Yvan. > _______________________________________________ > 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" > Are there any restrictions for nat-t on freebsd-6, like number of vpns that can be natted? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From adeepv at gmail.com Fri Dec 12 10:57:02 2008 From: adeepv at gmail.com (Vyacheslav Bocharov) Date: Fri Dec 12 10:57:08 2008 Subject: strange problem with ifconfig alias In-Reply-To: <20081212181246.GG34842@funkthat.com> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> Message-ID: <566611296.20081212205648@gmail.com> >> root@chip# ifconfig em1 alias 195.3.245.xx/30 >> ifconfig: ioctl (SIOCAIFADDR): File exists > If there is already an ip in that range on the interface, you need to use: > ifconfig em1 alias 195.3.245.xx/32 There are no other ip on any interfaces in that range > Next time include ifconfig -a so we know what addresses and interfaces > you have. Makes diagnostics easier. I have included in mail: root@chip# ifconfig |grep 195.3.245. root@chip# -- Vyacheslav mailto:adeepv@gmail.com From bzeeb-lists at lists.zabbadoz.net Fri Dec 12 11:30:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Dec 12 11:30:16 2008 Subject: strange problem with ifconfig alias In-Reply-To: <566611296.20081212205648@gmail.com> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> <566611296.20081212205648@gmail.com> Message-ID: <20081212192435.L97918@maildrop.int.zabbadoz.net> On Fri, 12 Dec 2008, Vyacheslav Bocharov wrote: Hi, >>> root@chip# ifconfig em1 alias 195.3.245.xx/30 >>> ifconfig: ioctl (SIOCAIFADDR): File exists > >> If there is already an ip in that range on the interface, you need to use: >> ifconfig em1 alias 195.3.245.xx/32 > There are no other ip on any interfaces in that range > >> Next time include ifconfig -a so we know what addresses and interfaces >> you have. Makes diagnostics easier. > I have included in mail: > > root@chip# ifconfig |grep 195.3.245. > root@chip# which freebsd version are you using? /bz PS: parameters like alias belong to the end of the command (but that won't help you; just the general advise). -- Bjoern A. Zeeb The greatest risk is not taking one. From rrs at lakerest.net Fri Dec 12 12:08:49 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 12 12:08:57 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <20081213030449.F2405@delplex.bde.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> Message-ID: <8835B402-CD0D-4246-ABD3-F2B1BB230820@lakerest.net> Well tell you what Bruce: How about if I just run the WHOLE file through s9indent... This will fix ALL my problems.. and of course "fix" the rest of the file too.. Unless you think its already in conformance (bet you its not) :-) R On Dec 12, 2008, at 11:47 AM, Bruce Evans wrote: > On Fri, 12 Dec 2008, Randall Stewart wrote: > >> Here is an updated patch it: >> >> 1) Fixes style9 issues (I hope.. I went back to vi and tried >> tabs :-0.. sigh one of >> these doys I will figure out why my .emacs settings just never cut >> it :-() > > Fraid not. > > % Index: netinet/udp_usrreq.c > % =================================================================== > % --- netinet/udp_usrreq.c (revision 185928) > % +++ netinet/udp_usrreq.c (working copy) > % @@ -488,10 +488,25 @@ > % struct mbuf *n; > % % n = m_copy(m, 0, M_COPYALL); > % - if (n != NULL) > % - udp_append(last, ip, n, iphlen + > % - sizeof(struct udphdr), &udp_in); > % - INP_RUNLOCK(last); > % + > > Extra blank line. > > % + if (last->inp_ppcb == NULL) { > % + if (n != NULL) > % + udp_append(last, ip, n, iphlen + > % + sizeof(struct udphdr), &udp_in); > > Line too long. > > % + INP_RUNLOCK(last); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. > > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple UDP > inp's hope we don't break :-( > > Line too long. Defeats reasonable indentation of the rest of the > comment. > > Missing punctuation after ":-(". > > % + */ > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % + > % + INP_RUNLOCK(last); > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > Typedef names involving functions normally use `func_t', not > `function_t'. > This is useful for reducing verboseness and resulting long lines but > wouldn't > fix the long line in the above, since everything in it is too verbose > (in the middle there is an ugly cast whose only effect can be to > avoid a > warning ...). > > % @@ -516,10 +531,25 @@ > % V_udpstat.udps_noportbcast++; > % goto badheadlocked; > % } > % - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % - &udp_in); > % - INP_RUNLOCK(last); > % - INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb == NULL) { > % + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % + &udp_in); > % + INP_RUNLOCK(last); > % + INP_INFO_RUNLOCK(&V_udbinfo); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. No comment on further instances of this > > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Long lines are ones longer than 80 characters. Splitting at 48 > characters > as in the above is not normal. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % @@ -563,6 +593,18 @@ > % INP_RUNLOCK(inp); > % goto badunlocked; > % } > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > More formatting for 48-column terminals. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declarations. > > % ... > % +int > % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t > f) > % +{ > % + struct inpcb *inp; > % + inp = (struct inpcb *)so->so_pcb; > > Initialization in declaration. Not too bad here, but you don't do > it for > similar tunnel function pointer conversions. > > % + > % + if (so->so_type != SOCK_DGRAM) { > % + /* Not UDP socket... sorry */ > > Missing punctuation. > > % Index: netinet/udp_var.h > % =================================================================== > % --- netinet/udp_var.h (revision 185928) > % +++ netinet/udp_var.h (working copy) > % @@ -107,6 +107,10 @@ > % void udp_input(struct mbuf *, int); > % struct inpcb *udp_notify(struct inpcb *inp, int errno); > % int udp_shutdown(struct socket *so); > % + > % + > % +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); > % +int udp_set_kernel_tunneling(struct socket *so, > udp_tunnel_function_t f); > > I noticed this first in the initial patch. It has a style bug > density of > about 5 per line !-(: > > - 2 extra blank lines > - typedef in the middle of (non-pointer non-typedef) prototypes > - unsorted prototypes (at least the old 3 visible on the above are > sorted) > - new prototypes not indented normally though visible old ones all are > - some parameters have names, some not. > - style(9) says to always have names in the kernel, but this rule > is usually > violated > - the first of the 3 visible old prototypes violates this rule > - the first of the new prototypes violates this rule for the first > of its > 2 parameters only > > % #endif > % % #endif > % Index: netinet6/udp6_usrreq.c > % =================================================================== > % --- netinet6/udp6_usrreq.c (revision 185928) > % +++ netinet6/udp6_usrreq.c (working copy) > % @@ -286,9 +286,21 @@ > % struct mbuf *n; > % % if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { > % - INP_RLOCK(last); > % - udp6_append(last, n, off, &fromsa); > % - INP_RUNLOCK(last); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple > UDP inp's hope we don't break :-( > % + */ > > Lines too long -- now formatting for 94-column terminals instead of > 48-column ones using cut&pasted&indent. > > Missing punctuation (cut&paste). > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Line too long. > > Missing blank line after declarations. > > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > % + INP_RUNLOCK(last); > % + tunnel_func(m, off); > % + } else { > % + INP_RLOCK(last); > % + udp6_append(last, n, off, &fromsa); > > Line too long. > > % @@ -317,6 +329,19 @@ > % } > % INP_RLOCK(last); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Now formatting for 56-column terminals. > > % @@ -354,6 +379,18 @@ > % } > % INP_RLOCK(inp); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Back to formatting for 48-column terminals. > > There are 6 near-copies of this comment. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declaration. > > % + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; > % + INP_RUNLOCK(inp); > % + tunnel_func(m, off); > > Do you have to hold the lock to access inp->inp_ppcb? Otherwise you > can > avoid all the nested declarations and just use the pointer once. If > the > lock is needed, then what happens if the pointer changes after it is > accessed? > > % + return (IPPROTO_DONE); > % + } > % udp6_append(inp, m, off, &fromsa); > % INP_RUNLOCK(inp); > % return (IPPROTO_DONE); > > Bruce > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rrs at lakerest.net Fri Dec 12 12:09:54 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 12 12:10:01 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <200812121819.27990.max@love2party.net> References: <200812111412.16757.max@love2party.net> <11F9C4F4-E893-46DA-96C3-1984131159D6@lakerest.net> <200812121819.27990.max@love2party.net> Message-ID: <6CD72FAF-6D22-4BD2-AADD-AFF686539441@lakerest.net> On Dec 12, 2008, at 12:19 PM, Max Laier wrote: > On Friday 12 December 2008 13:56:38 Randall Stewart wrote: >> On Dec 11, 2008, at 8:12 AM, Max Laier wrote: >>> On Thursday 11 December 2008 13:50:39 Randall Stewart wrote: > ... >> Another thing... kinda weird.. when I have this thing working with >> SCTP and I >> let the SCTP stack try to initialize the socket right away.. I get >> bogus >> results. The port is actually binding.. but yet it cant be sent to. >> If I >> unbind i.e. close the socket that got created.. then do a sysctl to >> re- >> add >> the same port.. all works fine. >> >> For now I am going to make SCTP NOT do this.. and have to add it to >> the >> sysctl's in /etc/sysctl.conf to add UDP tunneling. >> >> Only other solution would be a timer in the transport after startup >> to >> do this binding... > > You can probably do a SYSINIT in SI_SUB_PROTO_DOMAIN around the > middle and you > should be golden. If it turns out that this is not late enough you > can check > sys/kernel.h for later SI_SUBs that might be fitting. Hmm, thats a way to go.. but for now I don't mind leaving it default to "off" and have to have someone configure it on in there /etc/sysctl.conf That way its on only when you WANT to allow UDP tunneling :-) R > > >> I was wondering if I would see a race in the protocol stack >> initialization.. basically >> my guess is SCTP initializes ahead of UDP.. so its actually a >> wonder I >> did not crash ;-D > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From adeepv at gmail.com Fri Dec 12 12:27:35 2008 From: adeepv at gmail.com (Vyacheslav Bocharov) Date: Fri Dec 12 12:27:47 2008 Subject: strange problem with ifconfig alias In-Reply-To: <20081212192435.L97918@maildrop.int.zabbadoz.net> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> <566611296.20081212205648@gmail.com> <20081212192435.L97918@maildrop.int.zabbadoz.net> Message-ID: <308254201.20081212222602@gmail.com> ????????????, Bjoern. ?? ?????? 12 ??????? 2008 ?., 21:25:57: > On Fri, 12 Dec 2008, Vyacheslav Bocharov wrote: > Hi, >>>> root@chip# ifconfig em1 alias 195.3.245.xx/30 >>>> ifconfig: ioctl (SIOCAIFADDR): File exists >> >>> If there is already an ip in that range on the interface, you need to use: >>> ifconfig em1 alias 195.3.245.xx/32 >> There are no other ip on any interfaces in that range >> >>> Next time include ifconfig -a so we know what addresses and interfaces >>> you have. Makes diagnostics easier. >> I have included in mail: >> >> root@chip# ifconfig |grep 195.3.245. >> root@chip# > which freebsd version are you using? > /bz > PS: parameters like alias belong to the end of the command (but that > won't help you; just the general advise). FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Wed Dec 10 10:07:04 EET 2008 i386 -- ? ?????????, Vyacheslav mailto:adeepv@gmail.com From rrs at lakerest.net Fri Dec 12 12:27:59 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 12 12:28:06 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <20081213030449.F2405@delplex.bde.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> Message-ID: Bruce: So lets see: 1) I went ahead and fixed the comments.. even added a ! instead of :-( 2) No problem using func_t.. changed to that.. seems nicer :-D 3) Removed an extra cr or two you pointed out.. hopefully got them all. 4) I disagree with you on the cast... its not ugly.. it prevents us from having to have a per_pcb structure for UDP when all we need is one pointer. As I said in my first post.. it seemed like to much overhead, creating a zone for a single pointer... I am not adverse to casts .. but of course I guess I am just an old fart who has been around to many years writing code :-) 5) I ran s9indent.. and of course it found a lot of other things you missed.. but that is the way of s9indent I have found :-D R -------------- next part -------------- A non-text attachment was scrubbed... Name: diff_with_s9 Type: application/octet-stream Size: 41349 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081212/feceae51/diff_with_s9-0001.obj -------------- next part -------------- On Dec 12, 2008, at 11:47 AM, Bruce Evans wrote: > On Fri, 12 Dec 2008, Randall Stewart wrote: > >> Here is an updated patch it: >> >> 1) Fixes style9 issues (I hope.. I went back to vi and tried >> tabs :-0.. sigh one of >> these doys I will figure out why my .emacs settings just never cut >> it :-() > > Fraid not. > > % Index: netinet/udp_usrreq.c > % =================================================================== > % --- netinet/udp_usrreq.c (revision 185928) > % +++ netinet/udp_usrreq.c (working copy) > % @@ -488,10 +488,25 @@ > % struct mbuf *n; > % % n = m_copy(m, 0, M_COPYALL); > % - if (n != NULL) > % - udp_append(last, ip, n, iphlen + > % - sizeof(struct udphdr), &udp_in); > % - INP_RUNLOCK(last); > % + > > Extra blank line. > > % + if (last->inp_ppcb == NULL) { > % + if (n != NULL) > % + udp_append(last, ip, n, iphlen + > % + sizeof(struct udphdr), &udp_in); > > Line too long. > > % + INP_RUNLOCK(last); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. > > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple UDP > inp's hope we don't break :-( > > Line too long. Defeats reasonable indentation of the rest of the > comment. > > Missing punctuation after ":-(". > > % + */ > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % + > % + INP_RUNLOCK(last); > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > Typedef names involving functions normally use `func_t', not > `function_t'. > This is useful for reducing verboseness and resulting long lines but > wouldn't > fix the long line in the above, since everything in it is too verbose > (in the middle there is an ugly cast whose only effect can be to > avoid a > warning ...). > > % @@ -516,10 +531,25 @@ > % V_udpstat.udps_noportbcast++; > % goto badheadlocked; > % } > % - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % - &udp_in); > % - INP_RUNLOCK(last); > % - INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb == NULL) { > % + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), > % + &udp_in); > % + INP_RUNLOCK(last); > % + INP_INFO_RUNLOCK(&V_udbinfo); > % + } else { > % + /* Engage the tunneling protocol > > "/*" not on a line by itself. No comment on further instances of this > > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Long lines are ones longer than 80 characters. Splitting at 48 > characters > as in the above is not normal. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > % @@ -563,6 +593,18 @@ > % INP_RUNLOCK(inp); > % goto badunlocked; > % } > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > More formatting for 48-column terminals. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declarations. > > % ... > % +int > % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t > f) > % +{ > % + struct inpcb *inp; > % + inp = (struct inpcb *)so->so_pcb; > > Initialization in declaration. Not too bad here, but you don't do > it for > similar tunnel function pointer conversions. > > % + > % + if (so->so_type != SOCK_DGRAM) { > % + /* Not UDP socket... sorry */ > > Missing punctuation. > > % Index: netinet/udp_var.h > % =================================================================== > % --- netinet/udp_var.h (revision 185928) > % +++ netinet/udp_var.h (working copy) > % @@ -107,6 +107,10 @@ > % void udp_input(struct mbuf *, int); > % struct inpcb *udp_notify(struct inpcb *inp, int errno); > % int udp_shutdown(struct socket *so); > % + > % + > % +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); > % +int udp_set_kernel_tunneling(struct socket *so, > udp_tunnel_function_t f); > > I noticed this first in the initial patch. It has a style bug > density of > about 5 per line !-(: > > - 2 extra blank lines > - typedef in the middle of (non-pointer non-typedef) prototypes > - unsorted prototypes (at least the old 3 visible on the above are > sorted) > - new prototypes not indented normally though visible old ones all are > - some parameters have names, some not. > - style(9) says to always have names in the kernel, but this rule > is usually > violated > - the first of the 3 visible old prototypes violates this rule > - the first of the new prototypes violates this rule for the first > of its > 2 parameters only > > % #endif > % % #endif > % Index: netinet6/udp6_usrreq.c > % =================================================================== > % --- netinet6/udp6_usrreq.c (revision 185928) > % +++ netinet6/udp6_usrreq.c (working copy) > % @@ -286,9 +286,21 @@ > % struct mbuf *n; > % % if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { > % - INP_RLOCK(last); > % - udp6_append(last, n, off, &fromsa); > % - INP_RUNLOCK(last); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we will have to leave the info_lock > % + * up, since we are hunting through % + * multiple > UDP inp's hope we don't break :-( > % + */ > > Lines too long -- now formatting for 94-column terminals instead of > 48-column ones using cut&pasted&indent. > > Missing punctuation (cut&paste). > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Line too long. > > Missing blank line after declarations. > > % + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; > > Line too long. > > % + INP_RUNLOCK(last); > % + tunnel_func(m, off); > % + } else { > % + INP_RLOCK(last); > % + udp6_append(last, n, off, &fromsa); > > Line too long. > > % @@ -317,6 +329,19 @@ > % } > % INP_RLOCK(last); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (last->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Now formatting for 56-column terminals. > > % @@ -354,6 +379,18 @@ > % } > % INP_RLOCK(inp); > % INP_INFO_RUNLOCK(&V_udbinfo); > % + if (inp->inp_ppcb) { > % + /* Engage the tunneling protocol > % + * we must make sure all locks > % + * are released when we call the > % + * tunneling protocol. > % + */ > > Back to formatting for 48-column terminals. > > There are 6 near-copies of this comment. > > % + udp_tunnel_function_t tunnel_func; > > Nested declaration. > > Missing blank line after declaration. > > % + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; > % + INP_RUNLOCK(inp); > % + tunnel_func(m, off); > > Do you have to hold the lock to access inp->inp_ppcb? Otherwise you > can > avoid all the nested declarations and just use the pointer once. If > the > lock is needed, then what happens if the pointer changes after it is > accessed? > > % + return (IPPROTO_DONE); > % + } > % udp6_append(inp, m, off, &fromsa); > % INP_RUNLOCK(inp); > % return (IPPROTO_DONE); > > Bruce > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From artem at aws-net.org.ua Fri Dec 12 12:42:03 2008 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Fri Dec 12 12:42:10 2008 Subject: NAT-T + ipsec integration In-Reply-To: <20081212175500.GA2573@zeninc.net> References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> <20081212175500.GA2573@zeninc.net> Message-ID: On Fri, 12 Dec 2008, VANHULLEBUS Yvan wrote: > On Fri, Dec 12, 2008 at 06:45:20PM +0200, Artyom Viklenko wrote: >> On Thursday 11 December 2008 14:39:58 VANHULLEBUS Yvan wrote: > [....] >>> Actually, you can apply a patch to src/sys and recompile your kernel >>> with IPSEC_NAT_T options. >>> Patches are available here: >>> http://people.freebsd.org/~vanhu/NAT-T/ >> >> And what about patches for 6.4-RELEASE? > > I just not tested on 6.4 (almost all my devices moved to 7.x, and the > remaining ones will stay in 6.3 for various reasons), but 6.3 patch > should work on 6.4 if it compiles cleanly (I did NOT check every > single kernel change between 6.3 and 6.4). > > If people can test it and see some compile/runtime problems, please > report them, I'll try to fix them. Just applied the patch to 6.4-RELEASE. Kernel was compiles successfully and ipsec-tools (racoon) also was compiled successufully with NAT-T. Racoon started and reported about NAT-T support. So far so good! Will try to run IPSec tunnel may be in couple of weeks. Thanks a lot! -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From jmg at funkthat.com Fri Dec 12 14:43:45 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Fri Dec 12 14:43:52 2008 Subject: strange problem with ifconfig alias In-Reply-To: <566611296.20081212205648@gmail.com> References: <80861bfa0812110629h70527769w5e29f9acd7d0a5cd@mail.gmail.com> <20081212181246.GG34842@funkthat.com> <566611296.20081212205648@gmail.com> Message-ID: <20081212224343.GH34842@funkthat.com> Vyacheslav Bocharov wrote this message on Fri, Dec 12, 2008 at 20:56 +0200: > >> root@chip# ifconfig em1 alias 195.3.245.xx/30 > >> ifconfig: ioctl (SIOCAIFADDR): File exists > > > If there is already an ip in that range on the interface, you need to use: > > ifconfig em1 alias 195.3.245.xx/32 > There are no other ip on any interfaces in that range > > > Next time include ifconfig -a so we know what addresses and interfaces ^^^^^^^^^^^ > > you have. Makes diagnostics easier. > I have included in mail: > > root@chip# ifconfig |grep 195.3.245. > root@chip# This is not ifconfig -a. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From pyunyh at gmail.com Fri Dec 12 17:37:59 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 12 17:38:05 2008 Subject: vlan support trouble in if_sis driver ? In-Reply-To: <49427F7A.2020103@gmail.com> References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> <20081208004802.GB29560@cdnetworks.co.kr> <493CF424.4040206@gmail.com> <20081209043130.GC33723@cdnetworks.co.kr> <493E1872.9010306@gmail.com> <20081212014011.GG46707@cdnetworks.co.kr> <49427F7A.2020103@gmail.com> Message-ID: <20081213013749.GB51320@cdnetworks.co.kr> On Fri, Dec 12, 2008 at 06:12:58PM +0300, Vladimir Ermakov wrote: > Pyun YongHyeon wrote: > > > > > > > >Thanks. Patch committed to HEAD(r185784). > > > > > > > > > > > MFC? > > > > > > >sis(4) supports two kind of controllers. One was made by SiS and > >the other was manufactured by National Semiconductor. So I think we > >need test report for NatSemi DP83815 case prior to MFC. > > > > > > need a PR? No. Since we're about to release 7.1 it would be even better to see whether the patch also fixes the VLAN issue on DP83815. At least I want to see no regression on DP83815. -- Regards, Pyun YongHyeon From pyunyh at gmail.com Fri Dec 12 17:56:33 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 12 17:56:41 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <49429CEB.60607@gmail.com> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> <49429CEB.60607@gmail.com> Message-ID: <20081213015622.GD51320@cdnetworks.co.kr> On Fri, Dec 12, 2008 at 06:18:35PM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >And rebuild kernel and then reboot. You don't need to reinstall > >FreeBSD. > > Oki, > > I have done that and rebooted, the driver seems to work better now: > > Dec 12 17:47:16 freebsd kernel: vge0: > port 0xf800-0xf8ff mem 0xfdffe000-0xfdffe0ff irq 18 at device 14.0 on pci0 > Dec 12 17:47:16 freebsd kernel: vge0: MSIX count : 0 > Dec 12 17:47:16 freebsd kernel: vge0: MSI count : 0 > Dec 12 17:47:16 freebsd kernel: miibus0: on vge0 > Dec 12 17:47:16 freebsd kernel: vge0: Ethernet address: 00:40:63:e9:9a:1c > Dec 12 17:47:16 freebsd kernel: vge0: [FILTER] > > What is the next step to be able to make this fix go into the FreeBSD > 7.0 tree? > I don't know. :-( As I said I no longer have working vge(4) hardware and it's hard to write/test driver without access to the hardware. The code you've tested contains changes related to MII operation mode and critical register configuration as well as other improvements. The driver still needs special handling in several edge cases and more code to track link state transition, interrupt moderation etc. -- Regards, Pyun YongHyeon From smithi at nimnet.asn.au Fri Dec 12 18:55:22 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Dec 12 18:55:28 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> Message-ID: <20081213134248.W7599@sola.nimnet.asn.au> On Fri, 12 Dec 2008, Randall Stewart wrote: > Bruce: > > So lets see: > > 1) I went ahead and fixed the comments.. even added a ! instead of :-( Personally: emoticons ARE punctuation; adding a period is totally anal. > 2) No problem using func_t.. changed to that.. seems nicer :-D I guess submitting patches for style(9) is considered a suicide method? Ian <&^}= From mamruoc at gmail.com Fri Dec 12 19:03:30 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Fri Dec 12 19:03:38 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <20081213015622.GD51320@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> <49429CEB.60607@gmail.com> <20081213015622.GD51320@cdnetworks.co.kr> Message-ID: <494325FF.9040006@gmail.com> Pyun YongHyeon wrote: > I don't know. :-( > As I said I no longer have working vge(4) hardware and it's hard to > write/test driver without access to the hardware. The code you've > tested contains changes related to MII operation mode and critical > register configuration as well as other improvements. The driver > still needs special handling in several edge cases and more code > to track link state transition, interrupt moderation etc. Hm... So that means that FreeBSD from 7.0 does not support this chipset's NIC? I have to go for another *unix then. Thank you for your help anyway, hope the problem get solved sometime in the future. Mam From pyunyh at gmail.com Fri Dec 12 20:01:54 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 12 20:02:01 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <494325FF.9040006@gmail.com> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <494199E2.5050806@gmail.com> <20081212015842.GH46707@cdnetworks.co.kr> <4941C6BF.4080809@gmail.com> <20081212021549.GJ46707@cdnetworks.co.kr> <49429CEB.60607@gmail.com> <20081213015622.GD51320@cdnetworks.co.kr> <494325FF.9040006@gmail.com> Message-ID: <20081213040145.GE51320@cdnetworks.co.kr> On Sat, Dec 13, 2008 at 04:03:27AM +0100, Mam Ruoc wrote: > Pyun YongHyeon wrote: > >I don't know. :-( > >As I said I no longer have working vge(4) hardware and it's hard to > >write/test driver without access to the hardware. The code you've > >tested contains changes related to MII operation mode and critical > >register configuration as well as other improvements. The driver > >still needs special handling in several edge cases and more code > >to track link state transition, interrupt moderation etc. > > Hm... > > So that means that FreeBSD from 7.0 does not support this chipset's NIC? > No, vge(4) supported all known VIA velocity cotrollers when it was written. Newer revisions of controller seem to require some special handling and the datasheet for recent controllers are not available to open source devlopers. > I have to go for another *unix then. > I don't know how well other open source OSes support VIA velocity controllers but the situation would be roughly same. For instance I don't see any special code for newer controllers in Linux. YMMV. > Thank you for your help anyway, hope the problem get solved sometime in > the future. > Yeah, I hope so and thanks for testing! -- Regards, Pyun YongHyeon From peterjeremy at optushome.com.au Fri Dec 12 21:40:29 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Dec 12 21:40:36 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <20081213134248.W7599@sola.nimnet.asn.au> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <20081213134248.W7599@sola.nimnet.asn.au> Message-ID: <20081213054026.GF58682@server.vk2pj.dyndns.org> On 2008-Dec-13 13:55:18 +1100, Ian Smith wrote: >I guess submitting patches for style(9) is considered a suicide method? Not necessarily but you need to have very good justification for any change. It's much easier to read a large corpus of code where the code is all written in one style. I suspect that no-one is happy with everything in style(9) but consistency is seen as more important. -- 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/20081213/65d24d98/attachment.pgp From smithi at nimnet.asn.au Sat Dec 13 01:05:27 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Dec 13 01:05:34 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <20081213054026.GF58682@server.vk2pj.dyndns.org> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <20081213134248.W7599@sola.nimnet.asn.au> <20081213054026.GF58682@server.vk2pj.dyndns.org> Message-ID: <20081213195946.G7599@sola.nimnet.asn.au> On Sat, 13 Dec 2008, Peter Jeremy wrote: > On 2008-Dec-13 13:55:18 +1100, Ian Smith wrote: > >I guess submitting patches for style(9) is considered a suicide method? > > Not necessarily but you need to have very good justification for any > change. It's much easier to read a large corpus of code where the > code is all written in one style. I suspect that no-one is happy > with everything in style(9) but consistency is seen as more important. No doubt. Apologies to all, especially Randall, for a flippant and off-topic post. cheers, Ian From rrs at lakerest.net Sat Dec 13 02:05:54 2008 From: rrs at lakerest.net (Randall Stewart) Date: Sat Dec 13 02:06:00 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <20081213195946.G7599@sola.nimnet.asn.au> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <20081213134248.W7599@sola.nimnet.asn.au> <20081213054026.GF58682@server.vk2pj.dyndns.org> <20081213195946.G7599@sola.nimnet.asn.au> Message-ID: Ian: No problem what so ever... My native style is CLOSE to style(9).. but it often is hard for me to get "all" the little twists. And with SCTP we have 2 other primary developers and a few other contributors that work on the windoz stuff and user space... so we depend on s9indent exclusively.. Being an old-fart its hard to change style... and when emacs does not help me it makes it even worse ;-0 I have noticed over the last few years my style has been evolving closer and closer to style9.. but after 28 years of writing kernel level C code style changes slowly :-0 (old dogs and all that). Actually unless you are looking for excess blank lines, missing "."'s in comments and minor nits... I think I am pretty close to style9.. not that I am perfect (thats why s9indent is a plus ;-D)... I try.. but like all of us I am not perfect by a LONG LONG way (just ask my wife :-D) I will let this hang here for a while.. I have to head up for U of Del for a PHd committee I am on... so I will see if over the next week or so anyone else throws flames out... (I am more concerned about the functioning of the code then the style actually.. but hey I understand some folks are "style nazi's" thats ok... thats probably why s9indent was invented ;-D) R On Dec 13, 2008, at 4:05 AM, Ian Smith wrote: > On Sat, 13 Dec 2008, Peter Jeremy wrote: >> On 2008-Dec-13 13:55:18 +1100, Ian Smith >> wrote: >>> I guess submitting patches for style(9) is considered a suicide >>> method? >> >> Not necessarily but you need to have very good justification for any >> change. It's much easier to read a large corpus of code where the >> code is all written in one style. I suspect that no-one is happy >> with everything in style(9) but consistency is seen as more >> important. > > No doubt. > > Apologies to all, especially Randall, for a flippant and off-topic > post. > > cheers, Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From brde at optusnet.com.au Sat Dec 13 02:42:00 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Dec 13 02:42:07 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <8835B402-CD0D-4246-ABD3-F2B1BB230820@lakerest.net> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> <8835B402-CD0D-4246-ABD3-F2B1BB230820@lakerest.net> Message-ID: <20081213203723.A977@besplex.bde.org> On Fri, 12 Dec 2008, Randall Stewart wrote: > Well tell you what Bruce: > > How about if I just run the WHOLE file through s9indent... > > This will fix ALL my problems.. and of course "fix" the > rest of the file too.. Any automated conversion utility is very likely to introduce more bugs than it fixes. I haven't seen any that even try to work right. You would have to inspect every change and throw out most. With a working-right utility, you wouldn't have to do this since you would direct it to make only changes that you really want, including somehow restricting the changes to your new code. > Unless you think its already in conformance (bet you > its not) :-) According to my (buggy) knfometer utilty (just indent(1) with certain options followed by comparision of the size of the diff with the size of the original file): 94.325% udp_usrreq.c 80.452% udp_var.h 93.528% udp6_usrreq.c Anything above 90% is good and indicates that most of the changes are due to bugs in the conversion utility. In fact, indent seems to be making much the same wrong changes as your s9indent (I see the patch from that in a later reply -- I might respond to that too). Here is what indent does with udp_usrreq.c (the diff is larger than 5.675% of the file since it is -u2 while 5.675% is for a plain diff): % --- udp_usrreq.c.BAK 2008-12-13 09:49:18.398640000 +0000 % +++ udp_usrreq.c 2008-12-13 09:49:18.403640000 +0000 % @@ -99,4 +99,5 @@ % #ifdef VIMAGE_GLOBALS % int udp_blackhole; % + % #endif % Bug in indent. indent knows that it doesn't understand cpp directives so it tries not to touch them, but it still botches #endif by adding a blank line (and by misformatting any comment on #endif). % @@ -107,9 +108,11 @@ % * cause problems (especially for NFS data blocks). % */ % -static int udp_cksum = 1; % +static int udp_cksum = 1; Bug in indent, same as in s9indent. indent doesn't understand the arcane rule followed by the original code here, though I have directed it to indent by 1 tab after declaration-specificers. The problem is that indent knows that there are problems doing this for declaration-specifers longer than 7 characters (since the tab couldn't give the normal indent of 8 characters then), while the above code is happy to indent all the variable names to 16 characters. % + Bug in indent. Not shared by s9indent. The problem is that indent doesn't understand the ugly SYSCTL_INT() in the next statement. It thinks that SYSCTL_INT() is a function definition and has been directed to put a blank line before function definitions. % SYSCTL_INT(_net_inet_udp, UDPCTL_CHECKSUM, checksum, CTLFLAG_RW, &udp_cksum, % 0, "compute udp checksum"); % % int udp_log_in_vain = 0; % + Same bug as above. Now the indentation is unchanged though it is inconsistent with previous indentation, since the declaration-specifier is short. s9indent breaks the indentation here, since it doesn't understand or hasn't been directed that variable names should be indented by a tab (except in auto declarations). % SYSCTL_INT(_net_inet_udp, OID_AUTO, log_in_vain, CTLFLAG_RW, % &udp_log_in_vain, 0, "Log all incoming UDP packets"); % @@ -120,5 +123,6 @@ % % u_long udp_sendspace = 9216; /* really max datagram size */ % - /* 40 1K datagrams */ % + % + /* 40 1K datagrams */ Bug in indent, same as in s9indent. indent doesn't understand that the second comment is part of the first (which is a hard thing to understand), so it makes a mess. % SYSCTL_ULONG(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW, % &udp_sendspace, 0, "Maximum outgoing UDP datagram size"); % @@ -126,9 +130,9 @@ % u_long udp_recvspace = 40 * (1024 + % #ifdef INET6 % - sizeof(struct sockaddr_in6) % + sizeof(struct sockaddr_in6) % #else % - sizeof(struct sockaddr_in) % + sizeof(struct sockaddr_in) % #endif % - ); % +); indent mangles the special formatting here, the same as s9indent. It is following the strict rules here (except the final ");" should be indented by 4 characters too), but the original code has fancy formatting that intentionally breaks the rules. The strict rules are also wrong. indent doesn't really understand initializers in declarations. For function calls, it would start the 4-character continuation indent at the start of the function name, but it doesn't have a corresponding rule for initalizers and indents relative to column 0. % % SYSCTL_ULONG(_net_inet_udp, UDPCTL_RECVSPACE, recvspace, CTLFLAG_RW, % @@ -136,7 +140,8 @@ % % #ifdef VIMAGE_GLOBALS % -struct inpcbhead udb; /* from udp_var.h */ % -struct inpcbinfo udbinfo; % -struct udpstat udpstat; /* from udp_var.h */ % +struct inpcbhead udb; /* from udp_var.h */ % +struct inpcbinfo udbinfo; % +struct udpstat udpstat; /* from udp_var.h */ indent only messes up the fancy indentation of the variable names here. s9indent does this too, and also messes up the indentation of the comments. indent preserves the 40-character indentation of the comments though they might appear to be changed due to mail and markup not aligning the start of the line to a tab position. s9indent changes the comment indentation to 32 characters. I direct indent to use 40 characters (-c41 -cd41) because checking lots of KNF code (all of kern and vi and some others) indicates that 40 characters is slightly more common than 32. udp_usrreq.c apparently uses 40 so knfometer likes it. % ... % @@ -149,7 +154,8 @@ % "UDP statistics (struct udpstat, netinet/udp_var.h)"); % % -static void udp_detach(struct socket *so); % -static int udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, % - struct mbuf *, struct thread *); % +static void udp_detach(struct socket *so); % +static int % +udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, % + struct mbuf *, struct thread *); indent doesn't understand protoytypes and mangles their original perfect KNF formatting unless they are short. It also doesn't understand line splitting, so it doesn't change the splitting point for udp_output() in the above ("struct mbuf *" now fits on the previous line). s9indent has the same bugs. % @@ -219,5 +227,5 @@ % return; % } % -#endif /* IPSEC */ % +#endif /* IPSEC */ Bug documented above. % #ifdef MAC % if (mac_inpcb_check_deliver(inp, n) != 0) { % @@ -272,6 +280,8 @@ % struct ip save_ip; % struct sockaddr_in udp_in; % + % #ifdef IPFIREWALL_FORWARD % struct m_tag *fwd_tag; % + % #endif indent also puts a bogus blank line before ifdef. % % @@ -284,9 +294,8 @@ % * check the checksum with options still present. % */ % - if (iphlen > sizeof (struct ip)) { % + if (iphlen > sizeof(struct ip)) { Here is the first change that is actually correct. % ip_stripoptions(m, (struct mbuf *)0); % iphlen = sizeof(struct ip); % } % - % /* % * Get IP and UDP header together in first mbuf. Always omitting optional blank lines is KNF, but I don't like it before block comments. % ... % @@ -361,5 +369,5 @@ % bzero(((struct ipovly *)ip)->ih_x1, 9); % ((struct ipovly *)ip)->ih_len = uh->uh_ulen; % - uh_sum = in_cksum(m, len + sizeof (struct ip)); % + uh_sum = in_cksum(m, len + sizeof(struct ip)); % bcopy(b, ((struct ipovly *)ip)->ih_x1, 9); % } Actually correct. % @@ -433,8 +441,8 @@ % if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && % imo != NULL) { % - struct sockaddr_in sin; % - struct in_msource *ims; % - int blocked, mode; % - size_t idx; % + struct sockaddr_in sin; % + struct in_msource *ims; % + int blocked, mode; % + size_t idx; % % bzero(&sin, sizeof(struct sockaddr_in)); Correct again. Maybe only FreeBSD indent supports different indentation rules for local declarations. % @@ -466,7 +474,7 @@ % mode = imo->imo_mfilters[idx].imf_fmode; % if ((ims != NULL && % - mode == MCAST_EXCLUDE) || % + mode == MCAST_EXCLUDE) || % (ims == NULL && % - mode == MCAST_INCLUDE)) { % + mode == MCAST_INCLUDE)) { % #ifdef DIAGNOSTIC % if (bootverbose) { % @@ -504,5 +512,5 @@ % */ % if ((last->inp_socket->so_options & % - (SO_REUSEPORT|SO_REUSEADDR)) == 0) % + (SO_REUSEPORT | SO_REUSEADDR)) == 0) % break; % } All correct. % ... % @@ -531,5 +538,5 @@ % if (inp == NULL) { % if (udp_log_in_vain) { % - char buf[4*sizeof "123"]; % + char buf[4 * sizeof "123"]; Correct, but indent doesn't support adding the required parentheses here. % @@ -661,8 +667,7 @@ % n = V_udbinfo.ipi_count; % req->oldidx = 2 * (sizeof xig) % - + (n + n/8) * sizeof(struct xinpcb); % + + (n + n / 8) * sizeof(struct xinpcb); Correct but incomplete. indent doesn't support the style rule that requires the line split to occur after the operation instead of before. % return (0); % } % - % if (req->newptr != 0) % return (EPERM); Example of an optional blank line that should be removed. % [... lots more, mostly correct] % @@ -1278,18 +1276,18 @@ % % struct pr_usrreqs udp_usrreqs = { % - .pru_abort = udp_abort, % - .pru_attach = udp_attach, % - .pru_bind = udp_bind, % - .pru_connect = udp_connect, % - .pru_control = in_control, % - .pru_detach = udp_detach, % - .pru_disconnect = udp_disconnect, % - .pru_peeraddr = in_getpeeraddr, % - .pru_send = udp_send, % - .pru_soreceive = soreceive_dgram, % - .pru_sosend = sosend_dgram, % - .pru_shutdown = udp_shutdown, % - .pru_sockaddr = in_getsockaddr, % - .pru_sosetlabel = in_pcbsosetlabel, % - .pru_close = udp_close, % + .pru_abort = udp_abort, % + .pru_attach = udp_attach, % + .pru_bind = udp_bind, % + .pru_connect = udp_connect, % + .pru_control = in_control, % + .pru_detach = udp_detach, % + .pru_disconnect = udp_disconnect, % + .pru_peeraddr = in_getpeeraddr, % + .pru_send = udp_send, % + .pru_soreceive = soreceive_dgram, % + .pru_sosend = sosend_dgram, % + .pru_shutdown = udp_shutdown, % + .pru_sockaddr = in_getsockaddr, % + .pru_sosetlabel = in_pcbsosetlabel, % + .pru_close = udp_close, % }; indent doesn't understand the fancy formatting in the original code and makes a mess. s9indent has the same bug. To understand this, indent would probably need to understand C99 struct initializers, but indent doesn't even understand C90 prototypes yet. Once indent understands this, it could support a flag for fancy formatting of struct initializers independently of its formatting of other initializers and assignments. Bruce From brde at optusnet.com.au Sat Dec 13 03:28:51 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Dec 13 03:28:58 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> <24BD4A21-E10D-4E09-8C33-3FCF930A0495@lakerest.net> <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <20081213030449.F2405@delplex.bde.org> Message-ID: <20081213214209.L977@besplex.bde.org> On Fri, 12 Dec 2008, Randall Stewart wrote: > 1) I went ahead and fixed the comments.. even added a ! instead of :-( > > 2) No problem using func_t.. changed to that.. seems nicer :-D > > 3) Removed an extra cr or two you pointed out.. hopefully got them all. OK. > 4) I disagree with you on the cast... its not ugly.. it prevents us > from having to have a per_pcb structure for UDP when all we need > is one pointer. As I said in my first post.. it seemed like to much > overhead, creating a zone for a single pointer... I am not adverse to > casts .. but of course I guess I am just an old fart who has been around > to many years writing code :-) This is actually more broken than I first thought. inp_ppcb is "void *" but is abused to hold a function pointer. This gives undefined behaviour with or without the cast. The actual behaviour is apparently to work on all supported machines, but to suppress printing of a diagnostic with the cast. On ia64, function pointers are very different from "void *", but they can still be represented as "void *" after a conversion. I think ia64 function pointers are implemented as something like an integer index into a table of the actual pointers. Since 2^32 function pointers should be enough for anyone, 64-bit "void *" is more than large enough to represent them. If inp_ppcb were a generic function pointer, then a conversion would still be needed, but it doesn't need to be a cast. Simple assignment without the cast must work. However, I think we have warning flags set to such a high level that there would be warnings for the type change done by assignment, and the cast would be needed anyway to suppress the warning. I don't like this. Casts normally do suppress warnings and this hides errors too. Of course, saving space is a valid reason for this hack. > > 5) I ran s9indent.. and of course it found a lot of other things you missed.. > but that > is the way of s9indent I have found :-D Not surprising that it has bugs :-). Apart from the types of errors mentioned in my previous mail, it does the following unformatting: [hard carriage returns removed from diff] % Index: netinet/udp_usrreq.c % =================================================================== % --- netinet/udp_usrreq.c (revision 185928) % +++ netinet/udp_usrreq.c (working copy) % @@ -97,7 +97,8 @@ % */ % % #ifdef VIMAGE_GLOBALS % -int udp_blackhole; % +int udp_blackhole; % + % #endif Hmm, it mangles #endif the same as indent(1), so it seems to be just a wrapper for indent(1), just with slightly worse directives than my knfometer. [% ...] I don't notice many more problems than mentioned in my previous mail. The slightly worse directives are -c33 instead of -c41 and whatever directive it is that breaks the tab indentation for udp_blackhole above. BTW, I used to use that directive in knfometer too. It was needed because most declarations are local, but old FreeBSD indent and gnu indent don't support different formatting for local declarations, so the directive that gave the least mangling was the one that preserved the formatting of local declarations. I eventually modified FreeBSD indent to support the different formatting. Not having this is one of the main problems that makes gnu indent not directly usable for formatting to KNF (gnu indent is generally better but has fewer features -- surprising for a gnu utility). % @@ -387,7 +395,8 @@ % uh->uh_dport = ntohs(next_hop->sin_port); % % /* % - * Remove the tag from the packet. We don't need it anymore. % + * Remove the tag from the packet. We don't need it % + * anymore. % */ % m_tag_delete(m, fwd_tag); % } No need to change this. Another bug in indent is that it has no flexibility for preserving formatting that is good enough. Normally you don't want large block comments reformatted. The line length parameter only works for reformatting comments, but minor changes in it normally lead to complete reformatting of block comments. knfometer uses directives to suppress reformatting of all block comments although this misses some necessary reformatting. % @@ -414,10 +423,11 @@ % inp->inp_faddr.s_addr != ip->ip_src.s_addr) % continue; % /* % - * XXX: Do not check source port of incoming datagram % - * unless inp_connect() has been called to bind the % - * fport part of the 4-tuple; the source could be % - * trying to talk to us with an ephemeral port. % + * XXX: Do not check source port of incoming % + * datagram unless inp_connect() has been called to % + * bind the fport part of the 4-tuple; the source % + * could be trying to talk to us with an ephemeral % + * port. % */ Again, the original formatting was good enough. The programmer may have done right near-justification manually or using a better utility than indent. [... most changes continue to be for correctly formatted block comments] % @@ -488,41 +500,72 @@ % struct mbuf *n; % % n = m_copy(m, 0, M_COPYALL); % - if (n != NULL) % - udp_append(last, ip, n, iphlen + % - sizeof(struct udphdr), &udp_in); % - INP_RUNLOCK(last); % + if (last->inp_ppcb == NULL) { % + if (n != NULL) % + udp_append(last, ip, n, iphlen + % + sizeof(struct udphdr), &udp_in); Still have several too-line lines. indent doesn't support reformatting long lines except in comments. % Index: netinet/udp_var.h % =================================================================== % --- netinet/udp_var.h (revision 185928) % +++ netinet/udp_var.h (working copy) % @@ -38,9 +38,10 @@ % * UDP kernel structures and variables. % */ % struct udpiphdr { % - struct ipovly ui_i; /* overlaid ip structure */ % - struct udphdr ui_u; /* udp header */ % + struct ipovly ui_i; /* overlaid ip structure */ % + struct udphdr ui_u; /* udp header */ % }; indent with suitable directives can avoid this mangling, but neither it nor style(9) know the core rule that the indentation may be excessive (to make struct member names line up despite verbose declaration-specifiers) provided at least 10% of the declaration-specifiers are verbose. % ... % -void udp_ctlinput(int, struct sockaddr *, void *); % -void udp_init(void); % -void udp_input(struct mbuf *, int); % -struct inpcb *udp_notify(struct inpcb *inp, int errno); % -int udp_shutdown(struct socket *so); % +void udp_ctlinput(int, struct sockaddr *, void *); % +void udp_init(void); % +void udp_input(struct mbuf *, int); % +struct inpcb *udp_notify(struct inpcb *inp, int errno); % +int udp_shutdown(struct socket *so); % + % + % +typedef void (*udp_tunnel_func_t) (struct mbuf *, int off); % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); % + % #endif % % #endif Now everything here is a mess. Another bug or two in indent causes it to put the bogus space after "(*udp_tunnel_func_t)" when starting with a perfectly formatted prototype. Bruce From frank at harz.behrens.de Sat Dec 13 03:49:56 2008 From: frank at harz.behrens.de (Frank Behrens) Date: Sat Dec 13 03:50:02 2008 Subject: Problem with new source address selection In-Reply-To: <20081208205426.V80401@maildrop.int.zabbadoz.net> References: <200812031220.mB3CK204015947@post.behrens.de> Message-ID: <200812131149.mBDBnfOa023545@post.behrens.de> Bjoern A. Zeeb wrote on 8 Dec 2008 21:02: > Did you try the patch and did it work for you as expected? If so I'll > add it to my repo and the next jail patch. Meanwhile I can confirm that your patch works well for me on an up-to- date RELENG_7 kernel. Thanks! Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From max at love2party.net Sat Dec 13 11:30:18 2008 From: max at love2party.net (Max Laier) Date: Sat Dec 13 11:30:26 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> Message-ID: <200812132030.15665.max@love2party.net> On Friday 12 December 2008 14:46:30 Randall Stewart wrote: > Ok: > > Here is an updated patch it: > > 1) Fixes style9 issues > 2) move to _t typedef I won't get into this. > 3) Allow multicast/broadcast to also be tunneled. There seems to be an error with your patch. You RUNLOCK twice in some places - should be fixed in my version of the patch (see attached). > 4) Binding is now no longer a requirement to set tunneling mode, in > fact most protocols had better NOT have bound.. first set options, then > bind :-) Yep. > There was one thing I was a bit leary of for <3>. In the loop for > going through all the inp's of UDP that are listening to a m-cast/b-cast > I could not release the INP_INFO_LOCK() in other cases I make sure all > locks are released when we call into the tunneling protocol. I think > this will be ok as long as the tunnelee does not try to use the > INP_INFO_LOCK of the UDP world... I know for SCTP this is a non-issue.. but > it may be something we want to think about... not sure. I added a comment inline. Maybe we should add a flag to the tunnel function prototype, so that the called party can figure out if they need to defer work that is not allowed under the lock (e.g. malloc WAITOK). On top of that, I was wondering if it might make sense to pass in the inp as an argument - so that the tunnel consumer can figure out which tunnel the packet was received on (without relying on data off the wire). In that case I'd leave the inp RLOCK'ed and leave it up the the called party to release the lock if they so desire. > If there are no serious objections I will submit this into head.. and There are some open issues, see above - but in general okay with me. > followed behind it I will send in the changes so SCTP can be tunneled over > this new mechanism :-) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 186046) +++ netinet/udp_var.h (working copy) @@ -110,6 +110,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_function_t)(struct mbuf *, int off); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f); #endif #endif Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 186046) +++ netinet/udp_usrreq.c (working copy) @@ -488,10 +488,29 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + * + * XXXML: Maybe add a flag to the + * prototype so that the tunneling + * can defer work that can't be done + * under the info lock? + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, iphlen); + } } last = inp; /* @@ -516,10 +535,24 @@ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + tunnel_func(m, iphlen); + } return; } @@ -563,6 +596,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, iphlen); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1183,41 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_function_t f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 186046) +++ netinet6/udp6_usrreq.c (working copy) @@ -287,8 +287,20 @@ if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't break :-( + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)last->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + } else { + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; @@ -317,6 +329,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(last); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +379,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* Engage the tunneling protocol + * we must make sure all locks + * are released when we call the + * tunneling protocol. + */ + udp_tunnel_function_t tunnel_func; + tunnel_func = (udp_tunnel_function_t)inp->inp_ppcb; + INP_RUNLOCK(inp); + tunnel_func(m, off); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); From max at love2party.net Sat Dec 13 11:45:19 2008 From: max at love2party.net (Max Laier) Date: Sat Dec 13 11:45:35 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <20081213191345.M97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> Message-ID: <200812132045.17207.max@love2party.net> On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... > This state of having the variables in parallel, global and in the > container struct, will be maintained for another (short) time until > the entire virtualization framework is in. This is needed, so that > all three possible states can be benchmarked from exactly the same > code changeset. > > > For developers comitting new code or changing code it is important to > properly add virtualized variables in the way that: > 1) the globals and externs (if needed) are added/kept in sync as both > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > container struct + the V_ macro. > When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? -- /"\ 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 bz at FreeBSD.org Sat Dec 13 11:54:12 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Dec 13 11:54:19 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <200812131913.mBDJD38C037353@svn.freebsd.org> References: <200812131913.mBDJD38C037353@svn.freebsd.org> Message-ID: <20081213191345.M97918@maildrop.int.zabbadoz.net> On Sat, 13 Dec 2008, Bjoern A. Zeeb wrote: Hi, > Author: bz > Date: Sat Dec 13 19:13:03 2008 > New Revision: 186048 > URL: http://svn.freebsd.org/changeset/base/186048 > > Log: > Second round of putting global variables, which were virtualized > but formerly missed under VIMAGE_GLOBAL. > > Put the extern declarations of the virtualized globals > under VIMAGE_GLOBAL as the globals themsevles are already. > This will help by the time when we are going to remove the globals > entirely. As some of you might have noticed that Marko's last commit for the first time in the series of vimage commits was an actual functional change. By default HEAD is no longer using the globals. With my commit the current set of virtualized variables is assumed to be "clean". This basically means three things: 1) The former globals and their externs are all under #ifdef VIMAGE_GLOBALS 2) The same variables are present in a 'container struct' 3) The initialization of those is done from 'constructor ("init") functions' This state of having the variables in parallel, global and in the container struct, will be maintained for another (short) time until the entire virtualization framework is in. This is needed, so that all three possible states can be benchmarked from exactly the same code changeset. For developers comitting new code or changing code it is important to properly add virtualized variables in the way that: 1) the globals and externs (if needed) are added/kept in sync as both a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate container struct + the V_ macro. When used somewhere in code one has to use the V_foobarbaz version. 2) Any new virtualized globals must not be directly initialized. They have to be initialized from a contructor function (which is usually there already). If you are confused about some of the terms etc. follow the links in the "Some documentation" section on the wiki: http://wiki.freebsd.org/Image The "Vimage Coding - beginners guide / FAQ" tries to answer the 101 questions. For the beaf you'll find the link to a document in perforce with the last question (that you may already know). We'll try to enhance this as we get questions or the integration goes on. In case of questions or suggestions ideally follow-up on freebsd-virtualization@ . /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Sat Dec 13 12:10:07 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Dec 13 12:10:24 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <200812132045.17207.max@love2party.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> Message-ID: <20081213195343.V97918@maildrop.int.zabbadoz.net> On Sat, 13 Dec 2008, Max Laier wrote: > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... >> This state of having the variables in parallel, global and in the >> container struct, will be maintained for another (short) time until >> the entire virtualization framework is in. This is needed, so that >> all three possible states can be benchmarked from exactly the same >> code changeset. >> >> >> For developers comitting new code or changing code it is important to >> properly add virtualized variables in the way that: >> 1) the globals and externs (if needed) are added/kept in sync as both >> a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate >> container struct + the V_ macro. >> When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? Without VIMAGE_GLOBALS is the default; we have been building this for a few days already. The flip had been so smoothly that almost noone had really noticed. Marko has done a really great job! Thus my HEADS UP now after I am confident enough that (almost) all places were caught and clean. In case you want to check yourself you can simply put a file into one or multiple archs conf dir that looks like: ------------------------------------------------------------------------ > cat sys/amd64/conf/LINT-VIMAGE_GLOBALS include LINT ident LINT-VIMAGE_GLOBALS options VIMAGE_GLOBALS ------------------------------------------------------------------------ I am doing that build every other day from now to catch the possible error of a virtualized variable in the container struct w/o the global. But as this is the least problematic case I do not want to commit the kernel configuration as it'll make builds longer for everyone, etc. The more problematic cases that builds cannot catch are: - static initialization of a virtualized 'global'. - a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS I have scripts to identify the latter already. The former will only be caught be either code inspection or "unexpected results" when running. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From imp at bsdimp.com Sat Dec 13 12:27:17 2008 From: imp at bsdimp.com (Warner Losh) Date: Sat Dec 13 12:27:29 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <200812132045.17207.max@love2party.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> Message-ID: <20081213.132425.41724046.imp@bsdimp.com> From: Max Laier Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... > > This state of having the variables in parallel, global and in the > > container struct, will be maintained for another (short) time until > > the entire virtualization framework is in. This is needed, so that > > all three possible states can be benchmarked from exactly the same > > code changeset. > > > > > > For developers comitting new code or changing code it is important to > > properly add virtualized variables in the way that: > > 1) the globals and externs (if needed) are added/kept in sync as both > > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > > container struct + the V_ macro. > > When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. Warner From mav at FreeBSD.org Sat Dec 13 15:33:54 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Dec 13 15:34:03 2008 Subject: m_devget() and const buffer Message-ID: <4944465F.1030102@FreeBSD.org> Hi. Does anybody knows why m_devget() receives non-const char* as first argument? Is there any destructive copy routines used with it? I have searched all the kernel, but haven't found any. May be we could change that? -- Alexander Motin From lev at serebryakov.spb.ru Sun Dec 14 01:58:04 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Sun Dec 14 01:58:10 2008 Subject: MiniPCI WiFi (802.11g/11n) adapter with HostAP support -- please, advice models! Message-ID: <73133587.20081214124019@serebryakov.spb.ru> Hello, Freebsd-net. I need MiniPCI WiFi adapter with HostAP support (so, AFAIU, it should NOT be Intel adapters). WPA2 will be a plus. Could somebody advice exact models (not chipsets!) to look up in price lists and catalogs? Is VIA VT6655GMA00 (VIA MAC/BBP(VT6655) and Airoha Transceiver(AL2230)) supported? Are here any Atheros-based (5212?) MiniPCI cards on marked? Is Atheros 802.11n chipset (as found on TP-Link TL-WN861N 300N) supported? -- // Black Lion AKA Lev Serebryakov From vanhu at FreeBSD.org Sun Dec 14 02:14:49 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Sun Dec 14 02:14:57 2008 Subject: NAT-T + ipsec integration In-Reply-To: <4942B264.5020607@earthlink.net> References: <20081211122828.CF3958FC16@mx1.freebsd.org> <20081211123958.GA5332@zeninc.net> <200812121845.20262.artem@aws-net.org.ua> <20081212175500.GA2573@zeninc.net> <4942B264.5020607@earthlink.net> Message-ID: <20081214101445.GA2617@zeninc.net> On Fri, Dec 12, 2008 at 01:50:12PM -0500, Stephen Clark wrote: [...] > Are there any restrictions for nat-t on freebsd-6, like number of vpns that > can be natted? NAT-T generates quite no more restrictions than non NAT-T tunnels. Number of VPN tunnels may be a little bit lower with NAT-T than without: we do know that PFKey's buffer is the actual limitation when increasing number of SPD/SAD entries, and entries with NAT-T will generate (a few) more data per entry. I don't have exact numbers to provide to you, but expect number of running NAT-T tunnels to be a bit lower than without NAT-T. This is the only limit AFAIK. Yvan. From mamruoc at gmail.com Sun Dec 14 09:26:34 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Sun Dec 14 09:26:40 2008 Subject: Belkin F5D5055 not working in FreeBSD 7.0 Message-ID: <494541C6.2090106@gmail.com> Hi! With problems with my VIA ITX Velocity driver problem, I bought this device. In the supported hardware list of FreeBSD 7.0, this should be supported just fine. I get this on bootup, and the device seems "up", but does not working: axe0: on uhub3 axe0: AX88178, bufsz 1536, boundary 64 miibus0: on axe0 ukphy0: PHY 0 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseT, 1000baseT-FDX auto axe0: using obsoleted if_watchdog interface axe0: Ethernet address: 00:11:50:e7:94:70 axe0: if_start running deferred for Giant Anyboy have the same experience? Mam From bzeeb-lists at lists.zabbadoz.net Sun Dec 14 09:50:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Dec 14 09:50:13 2008 Subject: Problem with new source address selection In-Reply-To: <200812131149.mBDBnfOa023545@post.behrens.de> References: <200812031220.mB3CK204015947@post.behrens.de> <200812131149.mBDBnfOa023545@post.behrens.de> Message-ID: <20081214174833.W97918@maildrop.int.zabbadoz.net> On Sat, 13 Dec 2008, Frank Behrens wrote: > Bjoern A. Zeeb wrote on 8 Dec 2008 21:02: >> Did you try the patch and did it work for you as expected? If so I'll >> add it to my repo and the next jail patch. > > Meanwhile I can confirm that your patch works well for me on an up-to- > date RELENG_7 kernel. Thanks. I added it to HEAD now. Maybe someone else will join the discussion and it will at least be there for the rest of FreeBSD 7, once in_pcbladdr will be MFCed. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From jd at ods.org Sun Dec 14 13:22:47 2008 From: jd at ods.org (Jason DiCioccio) Date: Sun Dec 14 13:22:54 2008 Subject: Steady leak of mbufs + panic() Message-ID: Hey all, I'm running into a strange situation where every ~1.5 days, I will have a kernel panic: Architecture: i386 Architecture Version: 2 Version String: FreeBSD 7.0-RELEASE-p6 #1: Sun Dec 7 17:16:36 EST 2008 geniusj@update.ods.org:/usr/obj/usr/src/sys/UPDATE Panic String: kmem_malloc(16384): kmem_map too small: 536858624 total allocated When tracking down the source of the inflated kmem, I noticed that the mbufs/bytes allocated to network figures in netstat -m were growing steadily up until the crash. Before the crash, bytes allocated to network will be up near 400MB with mbufs reaching nearly 2 million. mbuf clusters will be in the low hundreds, however. This box is running a decent assortment of network protocols and functionality. It's a fairly active DNS server (more active than most), it is running a couple of instances of openvpn (tap), it's using gif for an ipv6 tunnel which is then tunneled over openvpn as well, it's also using BGP over the tunnels with quagga.. The only thing I can think of that changed before this all started happening is that I had added AAAA records for the nameserver (in the registry as well as locally). The inet6 traffic is fairly light, however (with a total of ~1.5MB both in and out in the past 15 hours versus 580MB in and 985MB out for the whole box.). Before I go down the bug report route, I'd like to know if there are accepted conditions where mbufs will grow like this and where I might start looking.. If more information would be helpful, let me know what's needed. Any help would be appreciated. Thanks! Jason DiCioccio From pyunyh at gmail.com Sun Dec 14 16:30:48 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Dec 14 16:30:55 2008 Subject: Belkin F5D5055 not working in FreeBSD 7.0 In-Reply-To: <494541C6.2090106@gmail.com> References: <494541C6.2090106@gmail.com> Message-ID: <20081215003040.GB58724@cdnetworks.co.kr> On Sun, Dec 14, 2008 at 06:26:30PM +0100, Mam Ruoc wrote: > Hi! > > With problems with my VIA ITX Velocity driver problem, I bought this > device. In the supported hardware list of FreeBSD 7.0, this should be > supported just fine. > > I get this on bootup, and the device seems "up", but does not working: > > axe0: 2> on uhub3 > axe0: AX88178, bufsz 1536, boundary 64 > miibus0: on axe0 > ukphy0: PHY 0 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, > 1000baseT, 1000baseT-FDX auto > axe0: using obsoleted if_watchdog interface > axe0: Ethernet address: 00:11:50:e7:94:70 > axe0: if_start running deferred for Giant > > > Anyboy have the same experience? > I have a patch for axe(4) but the patch seem to break AX88172. Try attached patch. Since ukphy(4) was attached to axe(4) I guess you may need a dedicated PHY driver. Show me the output of "devinfo -rv | grep phy". -- Regards, Pyun YongHyeon -------------- next part -------------- Index: sys/dev/usb/if_axe.c =================================================================== --- sys/dev/usb/if_axe.c (revision 183636) +++ sys/dev/usb/if_axe.c (working copy) @@ -162,6 +162,7 @@ static miibus_writereg_t axe_miibus_writereg; static miibus_statchg_t axe_miibus_statchg; +static int axe_get_phyno(struct axe_softc *, int); static int axe_encap(struct axe_softc *, struct mbuf *, int); static void axe_rxeof(usbd_xfer_handle, usbd_private_handle, usbd_status); static void axe_txeof(usbd_xfer_handle, usbd_private_handle, usbd_status); @@ -248,21 +249,10 @@ return(0); AXE_SLEEPLOCKASSERT(sc); -#ifdef notdef - /* - * The chip tells us the MII address of any supported - * PHYs attached to the chip, so only read from those. - */ - if (sc->axe_phyaddrs[0] != AXE_NOPHY && phy != sc->axe_phyaddrs[0]) + if (sc->axe_phyno != phy) return (0); - if (sc->axe_phyaddrs[1] != AXE_NOPHY && phy != sc->axe_phyaddrs[1]) - return (0); -#endif - if (sc->axe_phyaddrs[0] != 0xFF && sc->axe_phyaddrs[0] != phy) - return (0); - AXE_LOCK(sc); axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL); err = axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, (void *)&val); @@ -274,10 +264,18 @@ return(-1); } - if (val && val != 0xffff) - sc->axe_phyaddrs[0] = phy; + val = le16toh(val); + if ((sc->axe_flags & AX772) != 0 && reg == MII_BMSR) { + /* + * BMSR of AX88772 indicates that it supports extended + * capability but the extended status register is + * revered for embedded ethernet PHY. So clear the + * extended capability bit of BMSR. + */ + val &= ~BMSR_EXTCAP; + } - return (le16toh(val)); + return (val); } static int @@ -290,6 +288,10 @@ return(0); AXE_SLEEPLOCKASSERT(sc); + + if (sc->axe_phyno != phy) + return (0); + AXE_LOCK(sc); axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL); val = htole32(val); @@ -310,12 +312,58 @@ { struct axe_softc *sc = device_get_softc(dev); struct mii_data *mii = GET_MII(sc); + struct ifnet *ifp; int val, err; - val = (mii->mii_media_active & IFM_GMASK) == IFM_FDX ? - AXE_MEDIA_FULL_DUPLEX : 0; + ifp = sc->axe_ifp; + if (mii == NULL || ifp == NULL || + (ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; + + sc->axe_link = 0; + if ((mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) == + (IFM_ACTIVE | IFM_AVALID)) { + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_10_T: + sc->axe_link++; +#if 1 + device_printf(dev, "LINK UP 10Mbps\n"); +#endif + break; + case IFM_100_TX: + sc->axe_link++; +#if 1 + device_printf(dev, "LINK UP 100Mbps\n"); +#endif + break; + case IFM_1000_T: + if ((sc->axe_flags & AX178) == 0) + break; + sc->axe_link++; +#if 1 + device_printf(dev, "LINK UP 1000Mbps\n"); +#endif + break; + default: + break; + } + } + + /* Lost link, do nothing. */ + if (sc->axe_link == 0) { +#if 1 + device_printf(dev, "LINK DOWN\n"); +#endif + return; + } + + val = 0; + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) + val |= AXE_MEDIA_FULL_DUPLEX; if (sc->axe_flags & (AX178|AX772)) { val |= AXE_178_MEDIA_RX_EN | AXE_178_MEDIA_MAGIC; + if (sc->axe_flags & AX178) + val |= AXE_178_MEDIA_ENCK; switch (IFM_SUBTYPE(mii->mii_media_active)) { case IFM_1000_T: @@ -343,7 +391,6 @@ struct axe_softc *sc = ifp->if_softc; struct mii_data *mii = GET_MII(sc); - sc->axe_link = 0; if (mii->mii_instance) { struct mii_softc *miisc; LIST_FOREACH(miisc, &mii->mii_phys, mii_list) @@ -456,6 +503,9 @@ axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_PRL | AXE_178_RESET_MAGIC, NULL); usbd_delay_ms(sc->axe_udev, 150); + /* Enable MII/GMII/RGMII interface to work with external PHY. */ + axe_cmd(sc, AXE_CMD_SW_PHY_SELECT, 0, 0, NULL); + usbd_delay_ms(sc->axe_udev, 150); axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, 0, NULL); } @@ -465,7 +515,7 @@ axe_cmd(sc, AXE_CMD_WRITE_GPIO, 0, 0x00b0, NULL); usbd_delay_ms(sc->axe_udev, 40); - if (sc->axe_phyaddrs[1] == AXE_INTPHY) { + if (sc->axe_phyno == AXE_PHY_NO_AX772_EPHY) { /* ask for embedded PHY */ axe_cmd(sc, AXE_CMD_SW_PHY_SELECT, 0, 0x01, NULL); usbd_delay_ms(sc->axe_udev, 10); @@ -516,6 +566,30 @@ return; } +static int +axe_get_phyno(struct axe_softc *sc, int sel) +{ + int phyno; + + phyno = -1; + switch (AXE_PHY_TYPE(sc->axe_phyaddrs[sel])) { + case PHY_TYPE_100_HOME: + case PHY_TYPE_GIG: + phyno = AXE_PHY_NO(sc->axe_phyaddrs[sel]); + break; + case PHY_TYPE_SPECIAL: + /* FALLTHROUGH */ + case PHY_TYPE_RSVD: + /* FALLTHROUGH */ + case PHY_TYPE_NON_SUP: + /* FALLTHROUGH */ + default: + break; + } + + return (phyno); +} + /* * Probe for a AX88172 chip. */ @@ -610,6 +684,18 @@ /* We need the PHYID for the init dance in some cases */ axe_cmd(sc, AXE_CMD_READ_PHYID, 0, 0, (void *)&sc->axe_phyaddrs); +#if 1 + device_printf(sc->axe_dev, "PHYADDR 0x%02x:0x%02x\n", + sc->axe_phyaddrs[0], sc->axe_phyaddrs[1]); +#endif + sc->axe_phyno = axe_get_phyno(sc, AXE_PHY_SEL_PRI); + if (sc->axe_phyno == -1) + sc->axe_phyno = axe_get_phyno(sc, AXE_PHY_SEL_SEC); + if (sc->axe_phyno == -1) { + device_printf(sc->axe_dev, + "no valid PHY address found, assuming PHY address 0\n"); + sc->axe_phyno = 0; + } if (sc->axe_flags & AX178) axe_ax88178_init(sc); @@ -629,12 +715,6 @@ */ axe_cmd(sc, AXE_CMD_READ_IPG012, 0, 0, (void *)&sc->axe_ipgs); - /* - * Work around broken adapters that appear to lie about - * their PHY addresses. - */ - sc->axe_phyaddrs[0] = sc->axe_phyaddrs[1] = 0xFF; - ifp = sc->axe_ifp = if_alloc(IFT_ETHER); if (ifp == NULL) { device_printf(sc->axe_dev, "can not if_alloc()\n"); @@ -999,12 +1079,8 @@ } mii_tick(mii); - if (!sc->axe_link && mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->axe_link++; - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - axe_start(ifp); - } + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + axe_start(ifp); sc->axe_stat_ch = timeout(axe_tick, sc, hz); @@ -1122,6 +1198,7 @@ { struct axe_softc *sc = xsc; struct ifnet *ifp = sc->axe_ifp; + struct mii_data *mii = GET_MII(sc); struct axe_chain *c; usbd_status err; int i; @@ -1223,6 +1300,9 @@ usbd_transfer(c->axe_xfer); } + sc->axe_link = 0; + mii_mediachg(mii); + ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; Index: sys/dev/usb/if_axereg.h =================================================================== --- sys/dev/usb/if_axereg.h (revision 183636) +++ sys/dev/usb/if_axereg.h (working copy) @@ -134,9 +134,24 @@ #define AXE_178_RXCMD_MFB_8192 0x0200 /* 8K max frame burst */ #define AXE_178_RXCMD_MFB_16384 0x0300 /* 16K max frame burst*/ -#define AXE_NOPHY 0xE0 -#define AXE_INTPHY 0x10 +#define AXE_PHY_SEL_PRI 1 +#define AXE_PHY_SEL_SEC 0 +#define AXE_PHY_TYPE_MASK 0xE0 +#define AXE_PHY_TYPE_SHIFT 5 +#define AXE_PHY_TYPE(x) \ + (((x) & AXE_PHY_TYPE_MASK) >> AXE_PHY_TYPE_SHIFT) +#define PHY_TYPE_100_HOME 0 /* 10/100 or 1M HOME PHY */ +#define PHY_TYPE_GIG 1 /* Gigabit PHY */ +#define PHY_TYPE_SPECIAL 4 /* Special case */ +#define PHY_TYPE_RSVD 5 /* Reserved */ +#define PHY_TYPE_NON_SUP 7 /* Non-supported PHY */ + +#define AXE_PHY_NO_MASK 0x1F +#define AXE_PHY_NO(x) ((x) & AXE_PHY_NO_MASK) + +#define AXE_PHY_NO_AX772_EPHY 0x10 /* Embedded 10/100 PHY of AX88772 */ + #define AXE_TIMEOUT 1000 #define AXE_172_BUFSZ 1536 #define AXE_178_MIN_BUFSZ 2048 @@ -236,6 +251,7 @@ int axe_link; unsigned char axe_ipgs[3]; unsigned char axe_phyaddrs[2]; + int axe_phyno; struct timeval axe_rx_notice; struct usb_task axe_tick_task; int axe_bufsz; From espartano.mail at gmail.com Sun Dec 14 18:48:03 2008 From: espartano.mail at gmail.com (Espartano) Date: Sun Dec 14 18:48:09 2008 Subject: MiniPCI WiFi (802.11g/11n) adapter with HostAP support -- please, advice models! In-Reply-To: <73133587.20081214124019@serebryakov.spb.ru> References: <73133587.20081214124019@serebryakov.spb.ru> Message-ID: On Sun, Dec 14, 2008 at 3:40 AM, Lev Serebryakov wrote: > Hello, Freebsd-net. > > I need MiniPCI WiFi adapter with HostAP support (so, AFAIU, it > should NOT be Intel adapters). WPA2 will be a plus. > > Could somebody advice exact models (not chipsets!) to look up in > price lists and catalogs? > You can buy a Wistron CM9 Atheros 802.11a/b/g miniPCI wireless card to acomplish an AP, here is the url to see the Specifications: http://www.pcengines.ch/cm9.htm if you want to buy this MiniPci card you can do it in this page: http://www.pcengines.ch/order1.php search for the cm9 key word. already i am using this MiniPCI card over FreeBSD 7.0 to acomplish an AP and the card work very fine. :) > Is VIA VT6655GMA00 (VIA MAC/BBP(VT6655) and Airoha > Transceiver(AL2230)) supported? > > Are here any Atheros-based (5212?) MiniPCI cards on marked? > > Is Atheros 802.11n chipset (as found on TP-Link TL-WN861N 300N) supported? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > 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" > -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From qingli at FreeBSD.org Sun Dec 14 22:34:13 2008 From: qingli at FreeBSD.org (Qing Li) Date: Sun Dec 14 22:34:19 2008 Subject: HEADSUP: arp-v2 has been committed Message-ID: <200812150634.mBF6YDVC060565@freefall.freebsd.org> Hi All, The arp-v2 changes have been committed into HEAD. Please report problems to me and Kip Macy. -- Qing From lev at FreeBSD.org Sun Dec 14 23:30:57 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Sun Dec 14 23:31:04 2008 Subject: ath: is here full list of supported chipsets and chipsets comparsion? Message-ID: <1988001541.20081215103053@serebryakov.spb.ru> Hello, All. `man ath' on FreeBSD 7.1-PRE speaks only about WPA2 in AR5212 and not-supported AR5005VL. But in "current" cars here are many other chipsets -- 5213A, 5414, etc... And Atheros site is not very helpful now -- there are not 5212, 5213A, 5414 chipsets in both areas "WLAN for Home, Office and Metro Wi-Fi" and "WLAN for Mobile" (BTW, link to http://customerproducts.atheros.com/ doesn't work anymore). Is here full list of supported chipsets, and, maybe, some table with chipsets features (AES, WPA2, AP mode, etc)? -- // Black Lion AKA Lev Serebryakov From yonyossef.lists at gmail.com Sun Dec 14 23:57:33 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Sun Dec 14 23:57:39 2008 Subject: Detecting network memory leaks using netstat -m Message-ID: <000001c95e8a$c7f1cc20$220f000a@mtl.com> Hi All, I'm trying to find out whether my ethernet driver is leaking. I just found out about netstat -m, but I don't understand some of it's output. Can somebody explain me what is "mbuf+clusters out of packet secondary zone in use" ? My output shows it raised significantly during equilibrium after several stress runs: BEFORE 16641/217734/234375 mbufs in use (current/cache/total) 16640/217766/234406/262144 mbuf clusters in use (current/cache/total/max) 256/1664 mbuf+clusters out of packet secondary zone in use (current/cache) AFTER 625083/86562/711645 mbufs in use (current/cache/total) 180264/81880/262144/262144 mbuf clusters in use (current/cache/total/max) 160420/311 mbuf+clusters out of packet secondary zone in use (current/cache) Thanks Yony From dustah at gmail.com Mon Dec 15 01:46:25 2008 From: dustah at gmail.com (Denis Mysenko) Date: Mon Dec 15 01:46:32 2008 Subject: PPP / Routing table Message-ID: Hello everybody! I got stuck here with PPP + Poptop :( I use Poptop 1.3.4 on FreeBSD 7.1-PRERELEASE for a VPN server. As far as I understand, the problem is related either to userland ppp or to FreeBSD itself and not to Poptop. So here it is: There is a Poptop server running for several VPN clients, MPPE is enabled for PPP. When somebody connects, tunnel interface is created and corresponding entry in the routing table is made, like this one: UGH 0 0 tun0 Everything works fine, both with MPPE turned on and off. The problem starts when second client connects to Poptop! New tunnel interface, let's say tun1, is created correctly, with proper IP address. However, routing table is updated with incorrect entry: UGH 0 0 tun0 As we can see, FreeBSD added a routing entry going through the same tunnel interface - of the previous client! So obviously new VPN connection doesn't work. What is strange - is that it happens only when second client turns on MPPE. With MPPE turned off - everything works fine. I was playing a lot with different parameters and once I got everything working, but not anymore :) Since I don't see any logical reason - I cannot recover the proper config. As far as I understand, so far, PPP creates a tunnel interface and then FreeBSD, and not PPP, adds a routing table entry since a new network interface was added - am I true? Local IP (my side of the PtP) for all tunnel devices is the same - let's say 192.168.0.1. So as I see it, when detecting corresponding interface FreeBSD chooses the first tunnel interface because it has the same local IP. The question is - why does MPPE affect this process? And it used to work half a day ago anyway. Please - if anybody has any idea - could you help me!? :) -- Sincerely, -- Denis Mysenko, CCNA, MCP, MCSA Technologies of the Smart City Ltd Phone: +7 903 913-2651 ICQ: 555955 From max at love2party.net Mon Dec 15 02:13:03 2008 From: max at love2party.net (Max Laier) Date: Mon Dec 15 02:13:11 2008 Subject: PPP / Routing table In-Reply-To: References: Message-ID: <200812151112.59847.max@love2party.net> On Monday 15 December 2008 10:17:38 Denis Mysenko wrote: > Hello everybody! > > I got stuck here with PPP + Poptop :( I use Poptop 1.3.4 on FreeBSD > 7.1-PRERELEASE for a VPN server. > > As far as I understand, the problem is related either to userland ppp or to > FreeBSD itself and not to Poptop. So here it is: > > There is a Poptop server running for several VPN clients, MPPE is enabled > for PPP. When somebody connects, tunnel interface is created and > corresponding entry in the routing table is made, like this one: > UGH 0 0 tun0 > > Everything works fine, both with MPPE turned on and off. The problem starts > when second client connects to Poptop! New tunnel interface, let's say > tun1, is created correctly, with proper IP address. However, routing table > is updated with incorrect entry: > UGH 0 0 tun0 > > As we can see, FreeBSD added a routing entry going through the same tunnel > interface - of the previous client! So obviously new VPN connection doesn't > work. What is strange - is that it happens only when second client turns on > MPPE. With MPPE turned off - everything works fine. > > I was playing a lot with different parameters and once I got everything > working, but not anymore :) Since I don't see any logical reason - I cannot > recover the proper config. > > As far as I understand, so far, PPP creates a tunnel interface and then > FreeBSD, and not PPP, adds a routing table entry since a new network > interface was added - am I true? Local IP (my side of the PtP) for all > tunnel devices is the same - let's say 192.168.0.1. So as I see it, when > detecting corresponding interface FreeBSD chooses the first tunnel > interface because it has the same local IP. The question is - why does MPPE > affect this process? And it used to work half a day ago anyway. > > Please - if anybody has any idea - could you help me!? :) Looks to me as if poptop (which I am not familiar with) tries to do something clever and fails miserably. # netstat -rnfinet | grep 10 # ifconfig tun0 create 10.0.1.1 10.0.1.2 # ifconfig tun1 create 10.0.1.1 10.0.1.3 # netstat -rnfinet | grep 10 10.0.1.2 10.0.1.1 UH 0 0 tun0 10.0.1.3 10.0.1.1 UH 0 0 tun1 It is also unclear to me why you'd see RTF_GATEWAY on ptp routes. It might help to ktrace poptop to see what kind of ioctl it is issuing. -- /"\ 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 info at chevron.com.sg Mon Dec 15 03:00:10 2008 From: info at chevron.com.sg (Chevron Texaco Oil and Gas Company) Date: Mon Dec 15 03:00:17 2008 Subject: CONTACT OUR ZONE F BRANCH OFFICE Message-ID: <200812151041.mBFAfgBm017744@vux25.mgt.hosting.dc2.netsol.com> Attn: Dear Email Owner. I am Mrs. Chin Wool, the Company's secretary to Chevron Texaco Oil and Gas Company In Singapore (ASIA DISTRICT). If this email address is yours, congratulation to you, as we have a life transforming news for you. For more information kindly contact our Zone F,United Kingdom branch. Mr Peter Hamilton. email:peterhamilton33@live.com Yours Faithfully, Chin Wool (Mrs) For the Chief Executive Officer (CEO), Chevron Texaco Oil and Gas Company, Singapore, Asia. From bugmaster at FreeBSD.org Mon Dec 15 03:06:56 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 15 03:08:40 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200812151106.mBFB6tho004409@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/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/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 kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/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 199 problems total. From keramida at ceid.upatras.gr Mon Dec 15 05:57:13 2008 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Dec 15 05:57:44 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812150634.mBF6YDVC060565@freefall.freebsd.org> (Qing Li's message of "Mon, 15 Dec 2008 06:34:13 GMT") References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> Message-ID: <873agpk11i.fsf@kobe.laptop> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > Hi All, > > The arp-v2 changes have been committed into HEAD. > Please report problems to me and Kip Macy. Thanks! I've just updated my installation here to the new kernel and userland and it seems to work fine so far. At least, ARP and IPv4 seems to work without any noticeable problem the last few hours :-) I have one minor question though (still reading through the diff, so I am not sure if this is `normal'). The new netstat output includes a `Use' column that seems to be ever increasing: : % netstat -rn -f inet : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : default 192.168.1.1 UGS 0 5338 re0 : 127.0.0.1 link#4 UH 0 1292 lo0 : 192.168.1.0/24 link#2 U 0 2 re0 : : % netstat -rn -f inet : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : default 192.168.1.1 UGS 0 5365 re0 : 127.0.0.1 link#4 UH 0 1337 lo0 : 192.168.1.0/24 link#2 U 0 2 re0 : : % netstat -rn -f inet : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : default 192.168.1.1 UGS 0 5409 re0 : 127.0.0.1 link#4 UH 0 1375 lo0 : 192.168.1.0/24 link#2 U 0 2 re0 Is this expected, or does it look like a leak? From yonyossef.lists at gmail.com Mon Dec 15 06:07:21 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Mon Dec 15 06:07:29 2008 Subject: About netstat -m: What is "mbuf+clusters out of packet secondary zone in use" ? Message-ID: <000501c95ebe$709bddb0$220f000a@mtl.com> Hi All, I'm testing an Ethernet driver on FreeBSD 6.3. Running netstat -m during an ethernt stress test I see that the "mbuf+clusters out of packet secondary zone in use" number is growing gradualy. Problem is it never goes down after I stop the test, so it's pushing the "mbufs in use" up until the following stress test iterations reach the OS limit. What does this number mean? 506391/126009/632400 mbufs in use (current/cache/total) 141035/121109/262144/262144 mbuf clusters in use (current/cache/total/max) 131054/610 mbuf+clusters out of packet secondary zone in use (current/cache) Thanks Yony From sam at freebsd.org Mon Dec 15 10:15:45 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 15 10:15:51 2008 Subject: ath: is here full list of supported chipsets and chipsets comparsion? In-Reply-To: <1988001541.20081215103053@serebryakov.spb.ru> References: <1988001541.20081215103053@serebryakov.spb.ru> Message-ID: <49469ED0.5070308@freebsd.org> Lev Serebryakov wrote: > Hello, All. > > `man ath' on FreeBSD 7.1-PRE speaks only about WPA2 in AR5212 and > not-supported AR5005VL. But in "current" cars here are many other > chipsets -- 5213A, 5414, etc... And Atheros site is not very helpful > now -- there are not 5212, 5213A, 5414 chipsets in both areas "WLAN > for Home, Office and Metro Wi-Fi" and "WLAN for Mobile" (BTW, link to > http://customerproducts.atheros.com/ doesn't work anymore). > > Is here full list of supported chipsets, and, maybe, some table with > chipsets features (AES, WPA2, AP mode, etc)? > > HEAD supports most PCI/cardbus parts. The main exceptions are the 9280 and 9285. The ath9k driver for linux supports them and anyone can add support using that. 11n parts only support legacy operation though w/ ~10 line change to the driver you can get 11n RX + legacy TX. RELENG_7 has a much older hal and lacks support for many cards. I recommend using HEAD if wireless support is important to you. No ETA on an update by me--others are welcome to supply the changes. All ath cards support all features you listed (except for the 5210 which you're unlikely to care about). Sam From rwatson at FreeBSD.org Mon Dec 15 10:29:50 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Dec 15 10:29:56 2008 Subject: About netstat -m: What is "mbuf+clusters out of packet secondary zone in use" ? In-Reply-To: <000501c95ebe$709bddb0$220f000a@mtl.com> References: <000501c95ebe$709bddb0$220f000a@mtl.com> Message-ID: On Mon, 15 Dec 2008, Yony Yossef wrote: > I'm testing an Ethernet driver on FreeBSD 6.3. > > Running netstat -m during an ethernt stress test I see that the > "mbuf+clusters out of packet secondary zone in use" number is growing > gradualy. Problem is it never goes down after I stop the test, so it's > pushing the "mbufs in use" up until the following stress test iterations > reach the OS limit. What does this number mean? It seems likely that one of two things is happening: (1) a leak of mbuf + clusters (2) a bug in stats on mbuf + clusters Could you paste the output of "vmstat -z | grep -i mbuf" into an e-mail? That's the underlying vm stats from the zone used to generate netstat -m output, and might shed more light on things. Robert N M Watson Computer Laboratory University of Cambridge > > > 506391/126009/632400 mbufs in use (current/cache/total) > 141035/121109/262144/262144 mbuf clusters in use (current/cache/total/max) > 131054/610 mbuf+clusters out of packet secondary zone in use (current/cache) > > > Thanks > Yony > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From pluknet at gmail.com Mon Dec 15 10:45:12 2008 From: pluknet at gmail.com (pluknet) Date: Mon Dec 15 10:45:19 2008 Subject: About netstat -m: What is "mbuf+clusters out of packet secondary zone in use" ? In-Reply-To: <000501c95ebe$709bddb0$220f000a@mtl.com> References: <000501c95ebe$709bddb0$220f000a@mtl.com> Message-ID: 2008/12/15 Yony Yossef : > Hi All, > > I'm testing an Ethernet driver on FreeBSD 6.3. > > Running netstat -m during an ethernt stress test I see that the > "mbuf+clusters out of packet secondary zone in use" number is growing > gradualy. > Problem is it never goes down after I stop the test, so it's pushing the > "mbufs in use" up until the following stress test iterations reach the OS > limit. > What does this number mean? > > > 506391/126009/632400 mbufs in use (current/cache/total) > 141035/121109/262144/262144 mbuf clusters in use (current/cache/total/max) > 131054/610 mbuf+clusters out of packet secondary zone in use (current/cache) > Can you say what the ethernet stress test do you use? -- wbr, pluknet From rwatson at FreeBSD.org Mon Dec 15 11:23:25 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Dec 15 11:23:32 2008 Subject: About netstat -m: What is "mbuf+clusters out of packet secondary zone in use" ? In-Reply-To: References: <000501c95ebe$709bddb0$220f000a@mtl.com> Message-ID: On Mon, 15 Dec 2008, Robert Watson wrote: > On Mon, 15 Dec 2008, Yony Yossef wrote: > >> I'm testing an Ethernet driver on FreeBSD 6.3. >> >> Running netstat -m during an ethernt stress test I see that the >> "mbuf+clusters out of packet secondary zone in use" number is growing >> gradualy. Problem is it never goes down after I stop the test, so it's >> pushing the "mbufs in use" up until the following stress test iterations >> reach the OS limit. What does this number mean? I realized that I didn't quite answer your question here, so to be more specific: the FreeBSD mbuf allocator has a number of slab allocator zones it can draw from, depending on the type of request. These are enumerated in the vmstat -z output: robert@fledge:~> vmstat -z | head -1 ; vmstat -z | grep -i mbuf ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256, 0, 262, 222, 202448978, 0 mbuf: 256, 0, 9, 527, 686757049, 0 mbuf_cluster: 2048, 25600, 484, 304, 4017957, 0 mbuf_jumbo_pagesize: 4096, 12800, 7, 298, 18924376, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 406, 8873247, 0 The 'mbuf' zone allocates simple mbufs from a cache. The various cluster zones allocate cluster storage of various sizes, from the 2k default cluster size up to various jumbo sizes used when sending large amounts of data or when jumbograms are configured for a network interface that supports them. The mbuf_packet (mbuf+cluster) zone is a special zone allocating mbufs with pre-attached clusters, which was an optimization that seemed to help a lot a few years ago. In particular, you don't have to enter the memory allocator twice in order to find an mbuf with a cluster. There are some downsides, not least more complicated book-keeping, and some issues with how to account for and manage memory across the various caches. Notice that all mbuf_packet FREE (cached) clusters are billed as used clusters for the mbuf_cluster zone, as while UMA knows that mbuf_packet counts as a regular mbuf allocation, it doesn't know about the cluster hooked off it; netstat -m adjusts the reported cluster allocation for this before printing stats. Recently, we've been discussing moving to a variable-size mbuf scheme supporting large mbuf sizes with embedded storage, which seems to improve memory efficient quite a bit. There are some downsides -- one issue is that it somewhat complicates reference-counted cluster use (although not much); another is that data is no longer page-aligned which will make page-flipping less convenient on the receiver. Currently, if the hardware supports header-spitting, you can imagine the data going fairly easily into appropriately sized clusters (especially if the hardware supports LRO directly), and then flipping the pages into user memory on receive. With mbufs stuck on the front end of the page, not so much. Robert N M Watson Computer Laboratory University of Cambridge > > It seems likely that one of two things is happening: > > (1) a leak of mbuf + clusters > (2) a bug in stats on mbuf + clusters > > Could you paste the output of "vmstat -z | grep -i mbuf" into an e-mail? > That's the underlying vm stats from the zone used to generate netstat -m > output, and might shed more light on things. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> >> 506391/126009/632400 mbufs in use (current/cache/total) >> 141035/121109/262144/262144 mbuf clusters in use (current/cache/total/max) >> 131054/610 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> >> >> Thanks >> Yony >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > 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 Dec 15 12:00:24 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Dec 15 12:00:32 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <873agpk11i.fsf@kobe.laptop> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> Message-ID: The increase in "Use" count is not a leak. Before the arp-v2 commit, the counter increment occurs in the ARP entry for the gateway, but "rt_gwroute" is no longer necessary and has been removed. The outgoing interface is known from the default route entry, and because the gateway is on-link, an ARP search is made in that interface. The side effect is the "Use" count is increased in the default route entry. You will also notice a similar behavior when you access on-link hosts, i.e., the "Use" count for the interface route 192.169.1.0/24 will go up for every outgoing packet. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Giorgos Keramidas > Sent: Monday, December 15, 2008 5:42 AM > To: Qing Li > Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org > Subject: Re: HEADSUP: arp-v2 has been committed > > On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > > Hi All, > > > > The arp-v2 changes have been committed into HEAD. > > Please report problems to me and Kip Macy. > > Thanks! I've just updated my installation here to the new kernel and > userland and it seems to work fine so far. At least, ARP and IPv4 > seems > to work without any noticeable problem the last few hours :-) > > I have one minor question though (still reading through the diff, so I > am not sure if this is `normal'). > > The new netstat output includes a `Use' column that seems to be ever > increasing: > > : % netstat -rn -f inet > : Routing tables > : > : Internet: > : Destination Gateway Flags Refs Use Netif > Expire > : default 192.168.1.1 UGS 0 5338 re0 > : 127.0.0.1 link#4 UH 0 1292 lo0 > : 192.168.1.0/24 link#2 U 0 2 re0 > : > : % netstat -rn -f inet > : Routing tables > : > : Internet: > : Destination Gateway Flags Refs Use Netif > Expire > : default 192.168.1.1 UGS 0 5365 re0 > : 127.0.0.1 link#4 UH 0 1337 lo0 > : 192.168.1.0/24 link#2 U 0 2 re0 > : > : % netstat -rn -f inet > : Routing tables > : > : Internet: > : Destination Gateway Flags Refs Use Netif > Expire > : default 192.168.1.1 UGS 0 5409 re0 > : 127.0.0.1 link#4 UH 0 1375 lo0 > : 192.168.1.0/24 link#2 U 0 2 re0 > > Is this expected, or does it look like a leak? > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From lev at serebryakov.spb.ru Mon Dec 15 12:27:34 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Mon Dec 15 12:27:46 2008 Subject: ath: is here full list of supported chipsets and chipsets comparsion? In-Reply-To: <49469ED0.5070308@freebsd.org> References: <1988001541.20081215103053@serebryakov.spb.ru> <49469ED0.5070308@freebsd.org> Message-ID: <1125132021.20081215232730@serebryakov.spb.ru> Hello, Sam. You wrote 15 ??????? 2008 ?., 21:15:44: > RELENG_7 has a much older hal and lacks support for many cards. I > recommend using HEAD if wireless support is important to you. No ETA on > an update by me--others are welcome to supply the changes. As far as I understand, HEAD uses new HAL, so update is not simple one... Or is RELENG_7 HAL build from same (Ok, previous version) sources, as used in HEAD and HAL itself could be ported? (I understand, that ath DRIVER could not be backported, because all massive wlan changes). And using HEAD in production... Hmm. Is it good idea? Are current MiniPCI versions (AR5006[suffix]) supported by RELENG_7 HAL? -- // Black Lion AKA Lev Serebryakov From marius at FreeBSD.org Mon Dec 15 13:10:51 2008 From: marius at FreeBSD.org (marius@FreeBSD.org) Date: Mon Dec 15 13:10:57 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200812152110.mBFLAnlN081251@freefall.freebsd.org> Synopsis: [bge] Network packets corrupted when bge card is in 64-bit PCI slot State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Mon Dec 15 21:08:02 UTC 2008 State-Changed-Why: Close, a workaround for the hardware bug was committed to head (r185812), stable/7 (r186134), releng/7.1 (r186135) and stable/6 (186136). http://www.freebsd.org/cgi/query-pr.cgi?pr=128833 From morganw at chemikals.org Mon Dec 15 14:37:29 2008 From: morganw at chemikals.org (Wes Morgan) Date: Mon Dec 15 14:37:35 2008 Subject: ath: is here full list of supported chipsets and chipsets comparsion? In-Reply-To: <49469ED0.5070308@freebsd.org> References: <1988001541.20081215103053@serebryakov.spb.ru> <49469ED0.5070308@freebsd.org> Message-ID: On Mon, 15 Dec 2008, Sam Leffler wrote: > Lev Serebryakov wrote: >> Hello, All. >> >> `man ath' on FreeBSD 7.1-PRE speaks only about WPA2 in AR5212 and >> not-supported AR5005VL. But in "current" cars here are many other >> chipsets -- 5213A, 5414, etc... And Atheros site is not very helpful >> now -- there are not 5212, 5213A, 5414 chipsets in both areas "WLAN >> for Home, Office and Metro Wi-Fi" and "WLAN for Mobile" (BTW, link to >> http://customerproducts.atheros.com/ doesn't work anymore). >> >> Is here full list of supported chipsets, and, maybe, some table with >> chipsets features (AES, WPA2, AP mode, etc)? >> >> > HEAD supports most PCI/cardbus parts. The main exceptions are the 9280 and > 9285. The ath9k driver for linux supports them and anyone can add support > using that. 11n parts only support legacy operation though w/ ~10 line > change to the driver you can get 11n RX + legacy TX. > > RELENG_7 has a much older hal and lacks support for many cards. I recommend > using HEAD if wireless support is important to you. No ETA on an update by > me--others are welcome to supply the changes. > > All ath cards support all features you listed (except for the 5210 which > you're unlikely to care about). Sam, I just updated my system from -stable to -current this weekend, and I'm noticing a lot more issues with the ath driver losing its association much more frequently, sometimes failing to reassociate altogether. The strange part is that tcpdump shows packets being received from the network just fine, but nothing seems to be transmitted (although I have not stepped over to my file server to verify this). A manual unload / reload of the module "solves" the problem, but I get a warning about a memory leak. Code-wise, the only difference since the "open sourcing" is simply that we now have the code, correct? From sam at freebsd.org Mon Dec 15 15:01:43 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 15 15:01:55 2008 Subject: ath: is here full list of supported chipsets and chipsets comparsion? In-Reply-To: References: <1988001541.20081215103053@serebryakov.spb.ru> <49469ED0.5070308@freebsd.org> Message-ID: <4946E1D3.5090005@freebsd.org> Wes Morgan wrote: > On Mon, 15 Dec 2008, Sam Leffler wrote: > >> Lev Serebryakov wrote: >>> Hello, All. >>> >>> `man ath' on FreeBSD 7.1-PRE speaks only about WPA2 in AR5212 and >>> not-supported AR5005VL. But in "current" cars here are many other >>> chipsets -- 5213A, 5414, etc... And Atheros site is not very helpful >>> now -- there are not 5212, 5213A, 5414 chipsets in both areas "WLAN >>> for Home, Office and Metro Wi-Fi" and "WLAN for Mobile" (BTW, link to >>> http://customerproducts.atheros.com/ doesn't work anymore). >>> >>> Is here full list of supported chipsets, and, maybe, some table with >>> chipsets features (AES, WPA2, AP mode, etc)? >>> >>> >> HEAD supports most PCI/cardbus parts. The main exceptions are the >> 9280 and 9285. The ath9k driver for linux supports them and anyone >> can add support using that. 11n parts only support legacy operation >> though w/ ~10 line change to the driver you can get 11n RX + legacy TX. >> >> RELENG_7 has a much older hal and lacks support for many cards. I >> recommend using HEAD if wireless support is important to you. No ETA >> on an update by me--others are welcome to supply the changes. >> >> All ath cards support all features you listed (except for the 5210 >> which you're unlikely to care about). > > Sam, > > I just updated my system from -stable to -current this weekend, and > I'm noticing a lot more issues with the ath driver losing its > association much more frequently, sometimes failing to reassociate > altogether. The strange part is that tcpdump shows packets being > received from the network just fine, but nothing seems to be > transmitted (although I have not stepped over to my file server to > verify this). A manual unload / reload of the module "solves" the > problem, but I get a warning about a memory leak. I see no relevant PR's. I cannot fix problems w/o information. > > Code-wise, the only difference since the "open sourcing" is simply > that we now have the code, correct? Only difference between what? The code in the tree is my latest work. If there are problems I will do my best to fix them given sufficient information and/or the ability to reproduce the problem. Sam From dustah at gmail.com Mon Dec 15 22:52:28 2008 From: dustah at gmail.com (Denis Mysenko) Date: Mon Dec 15 22:52:34 2008 Subject: PPP / Routing table In-Reply-To: <200812151112.59847.max@love2party.net> References: <200812151112.59847.max@love2party.net> Message-ID: On Mon, Dec 15, 2008 at 1:12 PM, Max Laier wrote: > > It is also unclear to me why you'd see RTF_GATEWAY on ptp routes. It might > help to ktrace poptop to see what kind of ioctl it is issuing. > > Actually, as far as I understand (and according to kdump as well) - Poptop has nothing to do with interfaces or VPN itself - Poptop simply connects userland ppp with connected users, the rest is the task of ppp. So either this is a problem of ppp or OS/kernel. So I did ktrace on ppp, ppp reads ppp.secret file to get necessary IP address and issues the following call: CALL ioctl(0x1,SIOCAIFADDR, 0xbfbfdaac) And also these two calls: CALL __sysctl(0xbfbfda50,0x6,0,0xbfbfda78,0,0) CALL __sysctl(0xbfbfda50,0x6,0x8127800,0xbfbfda78,0,0) At the end of the link establishment process, ppp also issues these two calls: CALL ioctl(0x1,SIOCGIFFLAGS,0xbfbfdf8c) CALL ioctl(0x1,SIOCSIFFLAGS,0xbfbfdf8c) I compared two ktrace log files - from successful and from unsuccessful VPN connections and these ioctl() calls are equal. I ran through sources of ppp, these calls are issued by ipip.c and iface.c - initially to set up interface and then to change it's flags. Interface is chosen correctly for these calls. Another interesting thing, probably related to the last two calls, is when the second client connects to the Poptop server, initial routing table of FreeBSD contains a good entry with correct tunnel interface and UH flags, then entry flags are updated to UGH, then entry interface is updated to incorrect tunnel of the previous client. Just a note - ppp.log contains correct tunnel interfaces for all clients, as well as correct IP addresses in IPCP part. -- Sincerely, -- Denis Mysenko, CCNA, MCP, MCSA Technologies of the Smart City Ltd Phone: +7 903 913-2651 ICQ: 555955 From nrml at att.net Tue Dec 16 01:56:16 2008 From: nrml at att.net (Gabe) Date: Tue Dec 16 01:56:21 2008 Subject: FreeBSD network failover Message-ID: <20081216095615.A5AAE8FC16@mx1.freebsd.org> I have a nat'd box which obviously has an internal and external ip address. The box has a third interface which is configured to a DSL connection. My goal is for that interface to be activated if the external side fails so that outbound traffic still flows. Any of you know of a way to accomplish this regardless of the type of failure. I looked into CARP but I am not convinced that this would do what I need it to. /gabe From randy at psg.com Tue Dec 16 02:16:11 2008 From: randy at psg.com (Randy Bush) Date: Tue Dec 16 02:16:17 2008 Subject: FreeBSD network failover In-Reply-To: <20081216095615.A5AAE8FC16@mx1.freebsd.org> References: <20081216095615.A5AAE8FC16@mx1.freebsd.org> Message-ID: <49477FE8.4070903@psg.com> On 08.12.16 18:56, Gabe wrote: > I have a nat'd box which obviously has an internal and external ip > address. The box has a third interface which is configured to a DSL > connection. My goal is for that interface to be activated if the > external side fails so that outbound traffic still flows. Any of you > know of a way to accomplish this regardless of the type of failure. what routing protocols are involved? randy From yonyossef.lists at gmail.com Tue Dec 16 02:19:22 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Tue Dec 16 02:19:28 2008 Subject: About netstat -m: What is "mbuf+clusters out of packet secondary zone in use" ? In-Reply-To: References: <000501c95ebe$709bddb0$220f000a@mtl.com> Message-ID: <000b01c95f67$c06737f0$220f000a@mtl.com> > > Hi All, > > > > I'm testing an Ethernet driver on FreeBSD 6.3. > > > > Running netstat -m during an ethernt stress test I see that the > > "mbuf+clusters out of packet secondary zone in use" number > is growing > > gradualy. > > Problem is it never goes down after I stop the test, so > it's pushing > > the "mbufs in use" up until the following stress test > iterations reach > > the OS limit. > > What does this number mean? > > > > > > 506391/126009/632400 mbufs in use (current/cache/total) > > 141035/121109/262144/262144 mbuf clusters in use > > (current/cache/total/max) 131054/610 mbuf+clusters out of packet > > secondary zone in use (current/cache) > > > > Can you say what the ethernet stress test do you use? > I'm using a bi-directional test running multiple processes of this ping command: /sbin/ping -c 5000 -i 0.0001 -s 65507 -l 100 From yonyossef.lists at gmail.com Tue Dec 16 02:42:17 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Tue Dec 16 02:42:23 2008 Subject: About netstat -m: What is "mbuf+clusters out of packet secondary zone in use" ? In-Reply-To: References: <000501c95ebe$709bddb0$220f000a@mtl.com> Message-ID: <000c01c95f6a$f52d0430$220f000a@mtl.com> > > I'm testing an Ethernet driver on FreeBSD 6.3. > > > > Running netstat -m during an ethernt stress test I see that the > > "mbuf+clusters out of packet secondary zone in use" number > is growing > > gradualy. Problem is it never goes down after I stop the > test, so it's > > pushing the "mbufs in use" up until the following stress test > > iterations reach the OS limit. What does this number mean? > > It seems likely that one of two things is happening: > > (1) a leak of mbuf + clusters > (2) a bug in stats on mbuf + clusters > > Could you paste the output of "vmstat -z | grep -i mbuf" into > an e-mail? > That's the underlying vm stats from the zone used to generate > netstat -m output, and might shed more light on things. Thanks Robert. Here's the dump. In the beginning of the test this is the status: Tue Dec 16 10:34:15 UTC 2008 4353/1152/5505 mbufs in use (current/cache/total) 4352/706/5058/65536 mbuf clusters in use (current/cache/total/max) 256/640 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 9792K/1700K/11492K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256, 0, 256, 640, 12466, 0 mbuf: 256, 0, 4097, 512, 26854, 0 mbuf_cluster: 2048, 65536, 4992, 66, 4992, 0 mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 0, 0, 0, 0, 0 After a while the mbuf+clusters is growing. This output was taken a long time after the test ended: Tue Dec 16 10:38:58 UTC 2008 12873/62142/75015 mbufs in use (current/cache/total) 6780/58756/65536/65536 mbuf clusters in use (current/cache/total/max) 2337/542 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 16778K/133047K/149825K bytes allocated to network (current/cache/total) 0/77/15 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256, 0, 2337, 542, 1939590, 15 mbuf: 256, 0, 10536, 61600, 10221115, 0 mbuf_cluster: 2048, 65536, 7322, 58214, 3316319, 77 mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 0, 0, 0, 0, 0 From nrml at att.net Tue Dec 16 02:48:41 2008 From: nrml at att.net (Gabe) Date: Tue Dec 16 02:48:48 2008 Subject: FreeBSD network failover Message-ID: <20081216104840.E75D18FC17@mx1.freebsd.org> On 08.12.16 18:56, Gabe wrote: > I have a nat'd box which obviously has an internal and external ip > address. The box has a third interface which is configured to a DSL > connection. My goal is for that interface to be activated if the > external side fails so that outbound traffic still flows. Any of you > know of a way to accomplish this regardless of the type of failure. > what routing protocols are involved? > randy Its just IP and nat and there is an IPSec tunnel in place. I need to know that if the ISP goes out the DSL connection will be able to do certain things, like say sending an email to a pager letting us know that the main connection went down. From randy at psg.com Tue Dec 16 02:57:14 2008 From: randy at psg.com (Randy Bush) Date: Tue Dec 16 02:57:22 2008 Subject: FreeBSD network failover Message-ID: <49478988.2070208@psg.com> >>> I have a nat'd box which obviously has an internal and external ip >>> address. The box has a third interface which is configured to a >>> DSL connection. My goal is for that interface to be activated if >>> the external side fails so that outbound traffic still flows. Any >>> of you know of a way to accomplish this regardless of the type of >>> failure. >> what routing protocols are involved? > Its just IP and nat and there is an IPSec tunnel in place. I need to > know that if the ISP goes out the DSL connection will be able to do > certain things, like say sending an email to a pager letting us know > that the main connection went down. freebsd does not allow metrics on static routes, which would be the 'normal' hack. i.e. you can not have two default routes with different weights. so you may be left with a scripted hack which pings, or otherwise checks, the next hops of the two exits and adds/deletes default routes appropriately. randy From syrinx at freebsd.org Tue Dec 16 05:08:35 2008 From: syrinx at freebsd.org (Shteryana Shopova) Date: Tue Dec 16 05:08:42 2008 Subject: FreeBSD network failover In-Reply-To: <49478988.2070208@psg.com> References: <49478988.2070208@psg.com> Message-ID: <61b573980812160441m68027f88ic67d5eb532b4c311@mail.gmail.com> Maybe try lagg(4) in Failover mode? On Tue, Dec 16, 2008 at 12:57 PM, Randy Bush wrote: >>>> I have a nat'd box which obviously has an internal and external ip >>>> address. The box has a third interface which is configured to a >>>> DSL connection. My goal is for that interface to be activated if >>>> the external side fails so that outbound traffic still flows. Any >>>> of you know of a way to accomplish this regardless of the type of >>>> failure. > From dustah at gmail.com Tue Dec 16 05:49:33 2008 From: dustah at gmail.com (Denis Mysenko) Date: Tue Dec 16 05:49:40 2008 Subject: PPP / Routing table In-Reply-To: References: <200812151112.59847.max@love2party.net> Message-ID: I guess I found the source of the problem - it is route_Add() function from route.c (a part of /usr/sbin/ppp) which modifies routing table of the machine upon a new connection. As a quick solution, I created a ppp.linkup file: /sbin/route del $1 /sbin/route add -host $1 -iface $2 that deletes incorrect route entry and adds a new one with UH (no RTF_GATEWAY anymore) flags and proper destination interface. But it would be much nicer to have this problem fixed in ppp instead... :) -- Sincerely, -- Denis Mysenko, CCNA, MCP, MCSA Technologies of the Smart City Ltd Phone: +7 903 913-2651 ICQ: 555955 From nrml at att.net Tue Dec 16 06:13:52 2008 From: nrml at att.net (Gabe) Date: Tue Dec 16 06:13:59 2008 Subject: FreeBSD network failover Message-ID: <20081216141352.0A09D8FC19@mx1.freebsd.org> >Maybe try lagg(4) in Failover mode? On Tue, Dec 16, 2008 at 12:57 PM, Randy Bush wrote: >>>> I have a nat'd box which obviously has an internal and external ip >>>> address. The box has a third interface which is configured to a >>>> DSL connection. My goal is for that interface to be activated if >>>> the external side fails so that outbound traffic still flows. Any >>>> of you know of a way to accomplish this regardless of the type of >>>> failure. > Lagg wouldn't work on my setup because the dsl connection would be almost completely independent. Unless you can provide an example. /gabe From valentin.bud at gmail.com Tue Dec 16 07:06:29 2008 From: valentin.bud at gmail.com (Valentin Bud) Date: Tue Dec 16 07:06:36 2008 Subject: FreeBSD network failover In-Reply-To: <20081216141352.0A09D8FC19@mx1.freebsd.org> References: <20081216141352.0A09D8FC19@mx1.freebsd.org> Message-ID: <139b44430812160636s798ab039xee7f15229eb2a077@mail.gmail.com> On Tue, Dec 16, 2008 at 4:14 PM, Gabe wrote: > >Maybe try lagg(4) in Failover mode? > > On Tue, Dec 16, 2008 at 12:57 PM, Randy Bush wrote: > >>>> I have a nat'd box which obviously has an internal and external ip > >>>> address. The box has a third interface which is configured to a > >>>> DSL connection. My goal is for that interface to be activated if > >>>> the external side fails so that outbound traffic still flows. Any > >>>> of you know of a way to accomplish this regardless of the type of > >>>> failure. > > > > Lagg wouldn't work on my setup because the dsl connection would be almost > completely independent. Unless you can provide an example. Hello Gabe, You could use monit (http://mmonit.com/monit/) for example to monitor the default gateway with a ping and if it fails to exec a specific script in which you set up routes, send email and such and of course to (re)set the default stuff when the (default) connection is back online. There might be other tools designed especially for this so the others can point you in a better direction. a great day, v > > > /gabe > _______________________________________________ > 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 ndenev at gmail.com Tue Dec 16 08:15:03 2008 From: ndenev at gmail.com (Nikolay Denev) Date: Tue Dec 16 08:15:10 2008 Subject: FreeBSD network failover In-Reply-To: <20081216095615.A5AAE8FC16@mx1.freebsd.org> References: <20081216095615.A5AAE8FC16@mx1.freebsd.org> Message-ID: <4B08B02F-74F5-4250-AF04-23A9C5D8888A@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16 Dec, 2008, at 11:56 , Gabe wrote: > I have a nat'd box which obviously has an internal and external ip > address. The box has a third interface which is configured to a DSL > connection. My goal is for that interface to be activated if the > external side fails so that outbound traffic still flows. Any of you > know of a way to accomplish this regardless of the type of failure. > > I looked into CARP but I am not convinced that this would do what I > need it to. > > /gabe > _______________________________________________ > 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" > pfSense for example accomplishes this by using pf(4) with slbd (/usr/ ports/net/slbd). - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAklHzmcACgkQHNAJ/fLbfrk48ACdFti+w9eDl/poxMokZuylY+0c ecUAn2mcmtGj1X/9wAOyb2ORA34if8nB =nei8 -----END PGP SIGNATURE----- From shteryana at gmail.com Tue Dec 16 08:49:55 2008 From: shteryana at gmail.com (Shteryana Shopova) Date: Tue Dec 16 08:50:01 2008 Subject: FreeBSD network failover In-Reply-To: <20081216141352.0A09D8FC19@mx1.freebsd.org> References: <20081216141352.0A09D8FC19@mx1.freebsd.org> Message-ID: <61b573980812160849q54377584n8bf15b8858110ba6@mail.gmail.com> On Tue, Dec 16, 2008 at 4:14 PM, Gabe wrote: >>Maybe try lagg(4) in Failover mode? > Lagg wouldn't work on my setup because the dsl connection would be almost completely independent. Unless you can provide an example. > Bind the two connection to the lagg, configure both IPs on the lagg and add some script that monitors the link status (or connectivity) of the primary connection and changes the default route/primary link status accordingly. I am not sure this will work (can't test it atm) but you might at least try it. cheers, Shteryana From sem at FreeBSD.org Tue Dec 16 09:04:29 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Tue Dec 16 09:05:00 2008 Subject: bsnmpd & 64bits counters problem Message-ID: <4947D7A9.2050407@FreeBSD.org> Hello. Some weird thing has happened with 64bit counters: % snmpwalk -v2c -cpublic localhost ifInOctets IF-MIB::ifInOctets.1 = Counter32: 4107815474 ... IF-MIB::ifInOctets.16 = Counter32: 2894713654 % snmpwalk -v2c -cpublic localhost ifHCInOctets IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 ... IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 There are all 16 32bits counters but only 4 64bits. That's less than physical interfaces on this router (em0-em5). 7.1-PRERELEASE -- Dixi. Sem. From sem at FreeBSD.org Tue Dec 16 09:16:17 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Tue Dec 16 09:16:23 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <4947D7A9.2050407@FreeBSD.org> References: <4947D7A9.2050407@FreeBSD.org> Message-ID: <4947E260.6070509@FreeBSD.org> Sergey Matveychuk wrote: > Hello. > > Some weird thing has happened with 64bit counters: > > % snmpwalk -v2c -cpublic localhost ifInOctets > IF-MIB::ifInOctets.1 = Counter32: 4107815474 > ... > IF-MIB::ifInOctets.16 = Counter32: 2894713654 > > % snmpwalk -v2c -cpublic localhost ifHCInOctets > IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 > ... > IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 > > There are all 16 32bits counters but only 4 64bits. That's less than > physical interfaces on this router (em0-em5). > > 7.1-PRERELEASE > Looks like this is a reason: # ifconfig em4 em4: flags=8802 metric 0 mtu 1500 options=19b ether 00:15:17:80:f5:ee media: Ethernet autoselect status: no carrier # ifconfig em5 em5: flags=8802 metric 0 mtu 1500 options=19b ether 00:15:17:80:f5:ef media: Ethernet autoselect status: no carrier No 64bits counters returned for interfaces bellow them. -- Dixi. Sem. From hartmut.brandt at dlr.de Tue Dec 16 09:18:20 2008 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Tue Dec 16 09:18:28 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <4947D7A9.2050407@FreeBSD.org> References: <4947D7A9.2050407@FreeBSD.org> Message-ID: <20081216181850.O74416@beagle.kn.op.dlr.de> On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SM>Hello. SM> SM>Some weird thing has happened with 64bit counters: SM> SM>% snmpwalk -v2c -cpublic localhost ifInOctets SM>IF-MIB::ifInOctets.1 = Counter32: 4107815474 SM>... SM>IF-MIB::ifInOctets.16 = Counter32: 2894713654 SM> SM>% snmpwalk -v2c -cpublic localhost ifHCInOctets SM>IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 SM>... SM>IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 SM> SM>There are all 16 32bits counters but only 4 64bits. That's less than physical SM>interfaces on this router (em0-em5). SM> SM>7.1-PRERELEASE The highspeed counters are only there if this is a high-speed interface. High speed means that the baudrate in the interface MIB (the one in the kernel) must be larger than 20Mbaud. harti From sem at FreeBSD.org Tue Dec 16 10:06:03 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Tue Dec 16 10:06:10 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <20081216181850.O74416@beagle.kn.op.dlr.de> References: <4947D7A9.2050407@FreeBSD.org> <20081216181850.O74416@beagle.kn.op.dlr.de> Message-ID: <4947EE0B.9050902@FreeBSD.org> Harti Brandt wrote: > On Tue, 16 Dec 2008, Sergey Matveychuk wrote: > > SM>Hello. > SM> > SM>Some weird thing has happened with 64bit counters: > SM> > SM>% snmpwalk -v2c -cpublic localhost ifInOctets > SM>IF-MIB::ifInOctets.1 = Counter32: 4107815474 > SM>... > SM>IF-MIB::ifInOctets.16 = Counter32: 2894713654 > SM> > SM>% snmpwalk -v2c -cpublic localhost ifHCInOctets > SM>IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 > SM>... > SM>IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 > SM> > SM>There are all 16 32bits counters but only 4 64bits. That's less than physical > SM>interfaces on this router (em0-em5). > SM> > SM>7.1-PRERELEASE > > The highspeed counters are only there if this is a high-speed interface. > High speed means that the baudrate in the interface MIB (the one in the > kernel) must be larger than 20Mbaud. Well, these is lagg interfaces: lagg0: flags=8843 metric 0 mtu 9000 options=19b ether 00:30:48:67:d4:68 media: Ethernet autoselect status: active laggproto lacp laggport: em2 flags=1c laggport: em0 flags=1c There is no baudrate on them. But they are really high-speed however. -- Dixi. Sem. From bms at incunabulum.net Tue Dec 16 10:08:41 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Dec 16 10:08:57 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <20081216181850.O74416@beagle.kn.op.dlr.de> References: <4947D7A9.2050407@FreeBSD.org> <20081216181850.O74416@beagle.kn.op.dlr.de> Message-ID: <4947EEA5.6050501@incunabulum.net> Harti Brandt wrote: > The highspeed counters are only there if this is a high-speed interface. > High speed means that the baudrate in the interface MIB (the one in the > kernel) must be larger than 20Mbaud. > Does it look at the if_baudrate member? em(4) and other drivers will set if_baudrate according to the speed detected from Ethernet link beat, this could be creating a situation where bsnmpd is not exposing the high-speed counters at runtime? I imagine this could really confuse an SNMP-oriented Network Management System such as Nagios or OpenNMS. cheers BMS From hartmut.brandt at dlr.de Tue Dec 16 10:10:23 2008 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Tue Dec 16 10:10:30 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <4947EE0B.9050902@FreeBSD.org> References: <4947D7A9.2050407@FreeBSD.org> <20081216181850.O74416@beagle.kn.op.dlr.de> <4947EE0B.9050902@FreeBSD.org> Message-ID: <20081216190932.I74416@beagle.kn.op.dlr.de> On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SM>Harti Brandt wrote: SM>> On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SM>> SM>> SM>Hello. SM>> SM> SM>> SM>Some weird thing has happened with 64bit counters: SM>> SM> SM>> SM>% snmpwalk -v2c -cpublic localhost ifInOctets SM>> SM>IF-MIB::ifInOctets.1 = Counter32: 4107815474 SM>> SM>... SM>> SM>IF-MIB::ifInOctets.16 = Counter32: 2894713654 SM>> SM> SM>> SM>% snmpwalk -v2c -cpublic localhost ifHCInOctets SM>> SM>IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 SM>> SM>... SM>> SM>IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 SM>> SM> SM>> SM>There are all 16 32bits counters but only 4 64bits. That's less than SM>> physical SM>> SM>interfaces on this router (em0-em5). SM>> SM> SM>> SM>7.1-PRERELEASE SM>> SM>> The highspeed counters are only there if this is a high-speed interface. SM>> High speed means that the baudrate in the interface MIB (the one in the SM>> kernel) must be larger than 20Mbaud. SM> SM>Well, these is lagg interfaces: SM>lagg0: flags=8843 metric 0 mtu 9000 SM> options=19b SM> ether 00:30:48:67:d4:68 SM> media: Ethernet autoselect SM> status: active SM> laggproto lacp SM> laggport: em2 flags=1c SM> laggport: em0 flags=1c SM> SM>There is no baudrate on them. But they are really high-speed however. All interfaces have a baudrate. Its in net/if.h ifi_baudrate. We had the problem in the past with other interface types. 'virtual' interfaces must take care to somehow propagate the rate of the underlying physical interfaces up to the virtual one. harti From bms at incunabulum.net Tue Dec 16 10:11:20 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Dec 16 10:11:26 2008 Subject: FreeBSD network failover In-Reply-To: <49478988.2070208@psg.com> References: <49478988.2070208@psg.com> Message-ID: <4947EF45.3060203@incunabulum.net> Randy Bush wrote: > ... > freebsd does not allow metrics on static routes, which would be the > 'normal' hack. i.e. you can not have two default routes with > different weights. If you look in my 1 currently owned PRs: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71474 ...this ticket contains a description of how to implement floating statics in a hopefully non-sucky way, which is a stepping-stone to being able to deal with metrics in a sensible way. cheers BMS From hartmut.brandt at dlr.de Tue Dec 16 10:20:42 2008 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Tue Dec 16 10:20:59 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <4947EEA5.6050501@incunabulum.net> References: <4947D7A9.2050407@FreeBSD.org> <20081216181850.O74416@beagle.kn.op.dlr.de> <4947EEA5.6050501@incunabulum.net> Message-ID: <20081216191244.C74416@beagle.kn.op.dlr.de> On Tue, 16 Dec 2008, Bruce Simpson wrote: BS>Harti Brandt wrote: BS>> The highspeed counters are only there if this is a high-speed interface. BS>> High speed means that the baudrate in the interface MIB (the one in the BS>> kernel) must be larger than 20Mbaud. BS>> BS> BS>Does it look at the if_baudrate member? BS> BS>em(4) and other drivers will set if_baudrate according to the speed detected BS>from Ethernet link beat, this could be creating a situation where bsnmpd is BS>not exposing the high-speed counters at runtime? BS> BS>I imagine this could really confuse an SNMP-oriented Network Management BS>System such as Nagios or OpenNMS. Yes, it looks at ifi_baudrate. The reason is that the HC counters are mandatory only for interfaces with > 20MBit/second according to the compliance statememnt of the MIB. The HC counters come add additional cost, because the daemon has to poll the kernel's 32 bit counters and detect wrap arounds. So the daemon adapts dynamically based on the interface with the highest speed. And in any case, network management tools must be prepared to handle both cases. See also RFC2233: For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be used. harti From thompsa at FreeBSD.org Tue Dec 16 10:46:20 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Dec 16 10:46:28 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <20081216190932.I74416@beagle.kn.op.dlr.de> References: <4947D7A9.2050407@FreeBSD.org> <20081216181850.O74416@beagle.kn.op.dlr.de> <4947EE0B.9050902@FreeBSD.org> <20081216190932.I74416@beagle.kn.op.dlr.de> Message-ID: <20081216182749.GE3082@citylink.fud.org.nz> On Tue, Dec 16, 2008 at 07:12:24PM +0100, Harti Brandt wrote: > On Tue, 16 Dec 2008, Sergey Matveychuk wrote: > SM>> > SM>> The highspeed counters are only there if this is a high-speed interface. > SM>> High speed means that the baudrate in the interface MIB (the one in the > SM>> kernel) must be larger than 20Mbaud. > SM> > SM>Well, these is lagg interfaces: > SM>lagg0: flags=8843 metric 0 mtu 9000 > SM> options=19b > SM> ether 00:30:48:67:d4:68 > SM> media: Ethernet autoselect > SM> status: active > SM> laggproto lacp > SM> laggport: em2 flags=1c > SM> laggport: em0 flags=1c > SM> > SM>There is no baudrate on them. But they are really high-speed however. > > All interfaces have a baudrate. Its in net/if.h ifi_baudrate. We had the > problem in the past with other interface types. 'virtual' interfaces must > take care to somehow propagate the rate of the underlying physical > interfaces up to the virtual one. This patch should fix it for the lacp case. What is the correct value to use for a collection of interfaces with possibly different speeds? highest/lowest? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: ieee8023ad_lacp.diff Type: text/x-diff Size: 731 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081216/1cc89a2b/ieee8023ad_lacp.bin From mksmith at adhost.com Tue Dec 16 11:04:07 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue Dec 16 11:04:13 2008 Subject: FreeBSD network failover In-Reply-To: <20081216141352.0A09D8FC19@mx1.freebsd.org> References: <20081216141352.0A09D8FC19@mx1.freebsd.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031605272E7E@ad-exh01.adhost.lan> > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On > Behalf Of Gabe > Sent: Tuesday, December 16, 2008 6:14 AM > To: freebsd-net@freebsd.org > Subject: RE: FreeBSD network failover > > >Maybe try lagg(4) in Failover mode? > > On Tue, Dec 16, 2008 at 12:57 PM, Randy Bush wrote: > >>>> I have a nat'd box which obviously has an internal and external ip > >>>> address. The box has a third interface which is configured to a > >>>> DSL connection. My goal is for that interface to be activated if > >>>> the external side fails so that outbound traffic still flows. Any > >>>> of you know of a way to accomplish this regardless of the type of > >>>> failure. > > > > Lagg wouldn't work on my setup because the dsl connection would be almost > completely independent. Unless you can provide an example. > > /gabe How about PF with ifstated? Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081216/5f1b9c5c/PGP.pgp From max at love2party.net Tue Dec 16 11:08:02 2008 From: max at love2party.net (Max Laier) Date: Tue Dec 16 11:08:10 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <20081216182749.GE3082@citylink.fud.org.nz> References: <4947D7A9.2050407@FreeBSD.org> <20081216190932.I74416@beagle.kn.op.dlr.de> <20081216182749.GE3082@citylink.fud.org.nz> Message-ID: <200812162008.00654.max@love2party.net> On Tuesday 16 December 2008 19:27:49 Andrew Thompson wrote: > On Tue, Dec 16, 2008 at 07:12:24PM +0100, Harti Brandt wrote: > > On Tue, 16 Dec 2008, Sergey Matveychuk wrote: > > SM>> > > SM>> The highspeed counters are only there if this is a high-speed > > interface. SM>> High speed means that the baudrate in the interface MIB > > (the one in the SM>> kernel) must be larger than 20Mbaud. > > SM> > > SM>Well, these is lagg interfaces: > > SM>lagg0: flags=8843 metric 0 mtu > > 9000 SM> > > options=19b SM> > > ether 00:30:48:67:d4:68 > > SM> media: Ethernet autoselect > > SM> status: active > > SM> laggproto lacp > > SM> laggport: em2 flags=1c > > SM> laggport: em0 flags=1c > > SM> > > SM>There is no baudrate on them. But they are really high-speed however. > > > > All interfaces have a baudrate. Its in net/if.h ifi_baudrate. We had the > > problem in the past with other interface types. 'virtual' interfaces must > > take care to somehow propagate the rate of the underlying physical > > interfaces up to the virtual one. > > This patch should fix it for the lacp case. What is the correct value to > use for a collection of interfaces with possibly different speeds? > highest/lowest? If aggregation is used you should add the individual speeds (as this is the highest rate at which the interface counter could be increased). If it's in failover you should propagate the speed of the active interface. When in doubt, always report the highest value - at least for the purpose discussed here. -- /"\ 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 need4spam at bk.ru Tue Dec 16 11:23:28 2008 From: need4spam at bk.ru (Alexey Ivanov) Date: Tue Dec 16 11:24:08 2008 Subject: BCM43XX Wireless drivers Message-ID: In my notebook i have ndis0@pci0:48:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 broadcom wireless 1490 (dell)' class = network cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit cap 10[d0] = PCI-Express 1 endpoint and as i know it's currently not supported by FreeBSD. I've downloaded http://paradox.lissyara.su/bwi.01.tar.bz2 (it's sources from some p4 branch that is actually dragonflybsd bwi driver port) but still no luck, cause all modern broadcom cards need v4 firmware. I also extracted/built v4_150 broadcom firmware (http://opticomspb.ru/~savetherbtz/freebsd/bwi/bwifw_v4_150.tar.bz2) and found site with it's cpecs http://bcm-v4.sipsolutions.net/ on which Linux driver is based But with my knowledge of C i can't write driver =( FreeBSD forums thread here http://forums.freebsd.org/showthread.php?t=170 Is there any work going that way? Or Broadcom Wi-fi will always be unsupported on FreBSD. From glen.j.barber at gmail.com Tue Dec 16 11:35:16 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Tue Dec 16 11:35:23 2008 Subject: BCM43XX Wireless drivers In-Reply-To: References: Message-ID: <4ad871310812161132y5313006buea7e0c5033ea3041@mail.gmail.com> On Tue, Dec 16, 2008 at 12:49 PM, Alexey Ivanov wrote: > In my notebook i have > > ndis0@pci0:48:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 broadcom wireless 1490 (dell)' > class = network > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit > cap 10[d0] = PCI-Express 1 endpoint > > and as i know it's currently not supported by FreeBSD. > I've downloaded http://paradox.lissyara.su/bwi.01.tar.bz2 (it's sources from some p4 branch that is actually dragonflybsd bwi driver port) but still no luck, cause all modern broadcom cards need v4 firmware. > I also extracted/built v4_150 broadcom firmware (http://opticomspb.ru/~savetherbtz/freebsd/bwi/bwifw_v4_150.tar.bz2) and found site with it's cpecs http://bcm-v4.sipsolutions.net/ on which Linux driver is based > > But with my knowledge of C i can't write driver =( > FreeBSD forums thread here http://forums.freebsd.org/showthread.php?t=170 > > Is there any work going that way? Or Broadcom Wi-fi will always be unsupported on FreBSD. Until broadcom releases the specs on their hardware, NDIS is our only solution. I used the .INF and .SYS files from my WinXP driver disk for my Dell laptop (Inspiron b120) and ndisgen. Besides no LED light when the card is active, it works (but is a pain sometimes). Also, it supports WPA/WEP. My suggestion is a USB adapter (preferably Atheros). Regards. -- Glen Barber "If you have any trouble sounding condescending, find a Unix user to show you how it's done." --Scott Adams From fernercc at gmail.com Tue Dec 16 12:33:22 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Tue Dec 16 12:33:28 2008 Subject: working directory within kernel code Message-ID: <1229437998.4942.2.camel@mobiliare.Belkin> I am trying to determine the current working directory when a system call is issued. im interested in determining this from a kernel module. however, because system calls are only given a thread* and a void*, which gets casted, is there any way i find out the cwd? thanks. -- Cilloniz Bicchi, Ferner Research Assistant Dept. of Computer Sciences The University of Texas at Austin http://www.cs.utexas.edu/~fernercc fernercc@cs.utexas.edu From ivoras at freebsd.org Tue Dec 16 13:02:22 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Dec 16 13:02:30 2008 Subject: 6to4 in 6.3-R? Message-ID: Hi, I'm toying around with IPv6 and one thing I'd like to try is to set up an stf tunnel. The other types, like freenet6 and what sixxs uses work without problems, but on a 7-stable machine. I've followed various documents (like http://www.kfu.com/~nsayer/6to4/ but most are very similar) and it apparently boils down to the following in /etc/rc.conf: ipv6_enable="YES" ipv6_defaultrouter="2002:c058:6301::" stf_interface_ipv4addr="my.permanent.ipv4.addr" The interface comes up ok: stf0: flags=1 mtu 1280 inet6 2002:a135:xxyy::1 prefixlen 16 but attempts to ping outside result in errors: > ping6 www.freebsd.org PING6(56=40+8+8 bytes) 2002:a135:xxyy::1 --> 2001:4f8:fff6::21 ping6: sendmsg: Permission denied ping6: wrote www.freebsd.org 16 chars, ret=-1 ping6: sendmsg: Permission denied ping6: wrote www.freebsd.org 16 chars, ret=-1 ^C --- www.freebsd.org ping6 statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss It can ping6 itself. I have ipfw here but a very early rule says "allow ipv6 from any to any". It's triggered, judging by the packet counts, but apparently only in one direction (in the above example, only 2 packets would be accounted for). I think it's either broken (I can't try spf on the 7-stable machine) or, more likely, I'm missing something since I'm new to ipv6. Any ideas? -------------- 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/20081216/8aff9119/signature.pgp From randy at psg.com Tue Dec 16 13:21:45 2008 From: randy at psg.com (Randy Bush) Date: Tue Dec 16 13:21:51 2008 Subject: FreeBSD network failover In-Reply-To: <4947EF45.3060203@incunabulum.net> References: <49478988.2070208@psg.com> <4947EF45.3060203@incunabulum.net> Message-ID: <49481BE5.7030101@psg.com> On 08.12.17 03:11, Bruce Simpson wrote: > Randy Bush wrote: >> ... >> freebsd does not allow metrics on static routes, which would be the >> 'normal' hack. i.e. you can not have two default routes with different >> weights. > > If you look in my 1 currently owned PRs: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71474 > > ...this ticket contains a description of how to implement floating > statics in a hopefully non-sucky way, which is a stepping-stone to being > able to deal with metrics in a sensible way. yep. don't wrap it, i'll eat it here. :) randy From julian at elischer.org Tue Dec 16 13:39:59 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Dec 16 13:40:05 2008 Subject: working directory within kernel code In-Reply-To: <1229437998.4942.2.camel@mobiliare.Belkin> References: <1229437998.4942.2.camel@mobiliare.Belkin> Message-ID: <49481985.3080101@elischer.org> Ferner Cilloniz wrote: > I am trying to determine the current working directory when a system > call is issued. im interested in determining this from a kernel module. > > however, because system calls are only given a thread* and a void*, > which gets casted, is there any way i find out the cwd? > > thanks. > (why 'net@' ?) (try hackers@) it depends if you want the NAME of the working directory or a pointer to it's vnode, (or something similar). From thompsa at FreeBSD.org Tue Dec 16 14:07:26 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Dec 16 14:07:33 2008 Subject: bsnmpd & 64bits counters problem In-Reply-To: <200812162008.00654.max@love2party.net> References: <4947D7A9.2050407@FreeBSD.org> <20081216190932.I74416@beagle.kn.op.dlr.de> <20081216182749.GE3082@citylink.fud.org.nz> <200812162008.00654.max@love2party.net> Message-ID: <20081216220719.GA19787@citylink.fud.org.nz> On Tue, Dec 16, 2008 at 08:08:00PM +0100, Max Laier wrote: > On Tuesday 16 December 2008 19:27:49 Andrew Thompson wrote: > > On Tue, Dec 16, 2008 at 07:12:24PM +0100, Harti Brandt wrote: > > > On Tue, 16 Dec 2008, Sergey Matveychuk wrote: > > > SM>> > > > SM>> The highspeed counters are only there if this is a high-speed > > > interface. SM>> High speed means that the baudrate in the interface MIB > > > (the one in the SM>> kernel) must be larger than 20Mbaud. > > > SM> > > > SM>Well, these is lagg interfaces: > > > SM>lagg0: flags=8843 metric 0 mtu > > > 9000 SM> > > > options=19b SM> > > > ether 00:30:48:67:d4:68 > > > SM> media: Ethernet autoselect > > > SM> status: active > > > SM> laggproto lacp > > > SM> laggport: em2 flags=1c > > > SM> laggport: em0 flags=1c > > > SM> > > > SM>There is no baudrate on them. But they are really high-speed however. > > > > > > All interfaces have a baudrate. Its in net/if.h ifi_baudrate. We had the > > > problem in the past with other interface types. 'virtual' interfaces must > > > take care to somehow propagate the rate of the underlying physical > > > interfaces up to the virtual one. > > > > This patch should fix it for the lacp case. What is the correct value to > > use for a collection of interfaces with possibly different speeds? > > highest/lowest? > > If aggregation is used you should add the individual speeds (as this is the > highest rate at which the interface counter could be increased). If it's in > failover you should propagate the speed of the active interface. When in > doubt, always report the highest value - at least for the purpose discussed > here. Patch updated, should work as you described. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: lagg_baud.diff Type: text/x-diff Size: 1801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081216/1c12f86f/lagg_baud.bin From steve at ibctech.ca Tue Dec 16 19:33:24 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Dec 16 19:33:30 2008 Subject: loopback creation at boot Message-ID: <494872FE.8070801@ibctech.ca> Hi all, I'm curious to know if the creation of additional 'lo' interfaces is possible at boot via the traditional /etc/rc.conf as of yet. Forgive me if I've missed anything regarding this. I'm still trying to blend some functionality between FBSD and Quagga for certain routing functions. This is just attempting to get feedback here, knowing full well that this is not a Quagga list: - IPv6 addresses can't be assigned via Quagga to a NIC (Quagga issue AFAICT) -'disc' interfaces can't be `created' via Quagga (Quagga issue AFAICT) - apparently, 'disc' interfaces can not be created via /etc/rc.conf - IPv4 addresses CAN be assigned to available NIC(s) via Quagga - loopback interfaces can NOT be created via Quagga, or via FreeBSD boot procedure (other than lo0) Can anyone provide any feedback or procedural guidance on how I can (for example): - ensure that lo1, lo2-lo14 are created at boot - ensure that disc0 is created at boot, with an assigned IPv4 and IPv6 address The situation is thus: I have a couple of edge routers that I've converted from Cisco to FreeBSD & Quagga for testing, with BGP as the primary routing protocol. Upon the rare situation that the router has to reboot, manual configuration (ie. addition) of the missing virtual NICs must be performed prior to numerous BGP sessions coming up. The issue is not with the assignment of numbers... those were examples to stir imagination and ideas for those who have been there. The real trouble is having the interfaces available during boot, so I can get numbers assigned to them by the system. The lo interfaces are straight forward. The disc (null) interface is used for pull-up routes for my IPv4 and IPv6 allocations, and for routes learnt via Cymru BOGONS. Any guidance welcome. Steve From kmacy at freebsd.org Tue Dec 16 19:41:08 2008 From: kmacy at freebsd.org (Kip Macy) Date: Tue Dec 16 19:41:15 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812170332.mBH3WRbR092071@lava.sentex.ca> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <200812170332.mBH3WRbR092071@lava.sentex.ca> Message-ID: <3c1674c90812161941r747e3151m6d0d053b7f7e62ba@mail.gmail.com> This was caused by a change I made today. Evidently we're trying to acquire a shared lock while holding an exclusive lock. I will take a look. -Kip On Wed, Dec 17, 2008 at 3:32 AM, Mike Tancsa wrote: > At 01:34 AM 12/15/2008, Qing Li wrote: > >> Hi All, >> >> The arp-v2 changes have been committed into HEAD. >> Please report problems to me and Kip Macy. > > Not sure if its related or not, but if I create and destroy a lagg port, I > get a panic > e.g. > > > 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport igb1 > 0[current]# > 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport igb1 > ifconfig: SIOCSLAGGPORT: Device busy > 1[current]# ifconfig lagg0 destroy > > > panic: _rw_rlock (ifnet): wlock already held @ /usr/src/sys/net/if.c:200 > cpuid = 3 > KDB: enter: panic > [thread pid 1239 tid 100065 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> bt > Tracing pid 1239 tid 100065 td 0xc45f1b40 > kdb_enter(3232454813,3232454813,3232453528,3866974928,3,...) at kdb_enter+58 > panic(3232453528,3232060900,3232514293,3232513870,200,...) at panic+310 > _rw_rlock(3235193604,3232513870,200,3292329984,3866975012,...) at > _rw_rlock+118 > ifnet_byindex(6,3232513870,498,3297629696,3292329984,...) at > ifnet_byindex+39 > if_free_type(3292329984,6,279,3229646306,0,...) at if_free_type+156 > lagg_clone_destroy(3292329984,3292329984,3292329984,3299962240,3866975112,...) > at lagg_clone_destroy+146 > ifc_simple_destroy(3299962240,3292329984,3232515110,213,45,...) at > ifc_simple_destroy+39 > if_clone_destroyif(3299962240,3292329984,3232515110,191,0,...) at > if_clone_destroyif+225 > if_clone_destroy(3292314144,412,3235009472,3294567396,3235009472,...) at > if_clone_destroy+162 > ifioctl(3296010632,2149607801,3292314144,3294567232,2149607801,...) at > ifioctl+278 > soo_ioctl(3294877664,2149607801,3292314144,3297629184,3294567232,...) at > soo_ioctl+919 > kern_ioctl(3294567232,3,2149607801,3292314144,8000192,...) at kern_ioctl+477 > ioctl(3294567232,3866975480,12,3232296124,3233288592,...) at ioctl+308 > syscall(3866975544) at syscall+675 > Xint0x80_syscall() at Xint0x80_syscall+32 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 672834707, esp = 3217024108, > ebp = 3217024136 --- > db> > db> show alllocks > Process 1239 (ifconfig) thread 0xc45f1b40 (100065) > exclusive rw ifnet (ifnet) r = 0 (0xc0d52304) locked @ > /usr/src/sys/net/if.c:498 > Process 1135 (sshd) thread 0xc462e000 (100113) > exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc475920c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > Process 0 (kernel) thread 0xc4382900 (100042) > exclusive sleep mutex igb1 (IGB Core Lock) r = 0 (0xc43622dc) locked @ > /usr/src/sys/dev/e1000/if_igb.c:1224 > db> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From mike at sentex.net Tue Dec 16 19:46:04 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 16 19:46:11 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812150634.mBF6YDVC060565@freefall.freebsd.org> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> Message-ID: <200812170332.mBH3WRbR092071@lava.sentex.ca> At 01:34 AM 12/15/2008, Qing Li wrote: >Hi All, > >The arp-v2 changes have been committed into HEAD. >Please report problems to me and Kip Macy. Not sure if its related or not, but if I create and destroy a lagg port, I get a panic e.g. 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport igb1 0[current]# 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport igb1 ifconfig: SIOCSLAGGPORT: Device busy 1[current]# ifconfig lagg0 destroy panic: _rw_rlock (ifnet): wlock already held @ /usr/src/sys/net/if.c:200 cpuid = 3 KDB: enter: panic [thread pid 1239 tid 100065 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 1239 tid 100065 td 0xc45f1b40 kdb_enter(3232454813,3232454813,3232453528,3866974928,3,...) at kdb_enter+58 panic(3232453528,3232060900,3232514293,3232513870,200,...) at panic+310 _rw_rlock(3235193604,3232513870,200,3292329984,3866975012,...) at _rw_rlock+118 ifnet_byindex(6,3232513870,498,3297629696,3292329984,...) at ifnet_byindex+39 if_free_type(3292329984,6,279,3229646306,0,...) at if_free_type+156 lagg_clone_destroy(3292329984,3292329984,3292329984,3299962240,3866975112,...) at lagg_clone_destroy+146 ifc_simple_destroy(3299962240,3292329984,3232515110,213,45,...) at ifc_simple_destroy+39 if_clone_destroyif(3299962240,3292329984,3232515110,191,0,...) at if_clone_destroyif+225 if_clone_destroy(3292314144,412,3235009472,3294567396,3235009472,...) at if_clone_destroy+162 ifioctl(3296010632,2149607801,3292314144,3294567232,2149607801,...) at ifioctl+278 soo_ioctl(3294877664,2149607801,3292314144,3297629184,3294567232,...) at soo_ioctl+919 kern_ioctl(3294567232,3,2149607801,3292314144,8000192,...) at kern_ioctl+477 ioctl(3294567232,3866975480,12,3232296124,3233288592,...) at ioctl+308 syscall(3866975544) at syscall+675 Xint0x80_syscall() at Xint0x80_syscall+32 --- syscall (54, FreeBSD ELF32, ioctl), eip = 672834707, esp = 3217024108, ebp = 3217024136 --- db> db> show alllocks Process 1239 (ifconfig) thread 0xc45f1b40 (100065) exclusive rw ifnet (ifnet) r = 0 (0xc0d52304) locked @ /usr/src/sys/net/if.c:498 Process 1135 (sshd) thread 0xc462e000 (100113) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc475920c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 0 (kernel) thread 0xc4382900 (100042) exclusive sleep mutex igb1 (IGB Core Lock) r = 0 (0xc43622dc) locked @ /usr/src/sys/dev/e1000/if_igb.c:1224 db> From alfred at freebsd.org Tue Dec 16 20:00:36 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Dec 16 20:00:42 2008 Subject: working directory within kernel code In-Reply-To: <1229437998.4942.2.camel@mobiliare.Belkin> References: <1229437998.4942.2.camel@mobiliare.Belkin> Message-ID: <20081217034114.GU18389@elvis.mu.org> * Ferner Cilloniz [081216 12:33] wrote: > I am trying to determine the current working directory when a system > call is issued. im interested in determining this from a kernel module. > > however, because system calls are only given a thread* and a void*, > which gets casted, is there any way i find out the cwd? thread should point to proc which should have a "current dir" vnode in it, or a pointer to a struct that has it... keep poking around. -Alfred From kmacy at freebsd.org Tue Dec 16 20:34:38 2008 From: kmacy at freebsd.org (Kip Macy) Date: Tue Dec 16 20:34:51 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812170332.mBH3WRbR092071@lava.sentex.ca> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <200812170332.mBH3WRbR092071@lava.sentex.ca> Message-ID: <3c1674c90812162034s432c6d1by92dd3b566b715688@mail.gmail.com> Try changeid 186209. Thanks, Kip On Wed, Dec 17, 2008 at 3:32 AM, Mike Tancsa wrote: > At 01:34 AM 12/15/2008, Qing Li wrote: > >> Hi All, >> >> The arp-v2 changes have been committed into HEAD. >> Please report problems to me and Kip Macy. > > Not sure if its related or not, but if I create and destroy a lagg port, I > get a panic > e.g. > > > 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport igb1 > 0[current]# > 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport igb1 > ifconfig: SIOCSLAGGPORT: Device busy > 1[current]# ifconfig lagg0 destroy > > > panic: _rw_rlock (ifnet): wlock already held @ /usr/src/sys/net/if.c:200 > cpuid = 3 > KDB: enter: panic > [thread pid 1239 tid 100065 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> bt > Tracing pid 1239 tid 100065 td 0xc45f1b40 > kdb_enter(3232454813,3232454813,3232453528,3866974928,3,...) at kdb_enter+58 > panic(3232453528,3232060900,3232514293,3232513870,200,...) at panic+310 > _rw_rlock(3235193604,3232513870,200,3292329984,3866975012,...) at > _rw_rlock+118 > ifnet_byindex(6,3232513870,498,3297629696,3292329984,...) at > ifnet_byindex+39 > if_free_type(3292329984,6,279,3229646306,0,...) at if_free_type+156 > lagg_clone_destroy(3292329984,3292329984,3292329984,3299962240,3866975112,...) > at lagg_clone_destroy+146 > ifc_simple_destroy(3299962240,3292329984,3232515110,213,45,...) at > ifc_simple_destroy+39 > if_clone_destroyif(3299962240,3292329984,3232515110,191,0,...) at > if_clone_destroyif+225 > if_clone_destroy(3292314144,412,3235009472,3294567396,3235009472,...) at > if_clone_destroy+162 > ifioctl(3296010632,2149607801,3292314144,3294567232,2149607801,...) at > ifioctl+278 > soo_ioctl(3294877664,2149607801,3292314144,3297629184,3294567232,...) at > soo_ioctl+919 > kern_ioctl(3294567232,3,2149607801,3292314144,8000192,...) at kern_ioctl+477 > ioctl(3294567232,3866975480,12,3232296124,3233288592,...) at ioctl+308 > syscall(3866975544) at syscall+675 > Xint0x80_syscall() at Xint0x80_syscall+32 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 672834707, esp = 3217024108, > ebp = 3217024136 --- > db> > db> show alllocks > Process 1239 (ifconfig) thread 0xc45f1b40 (100065) > exclusive rw ifnet (ifnet) r = 0 (0xc0d52304) locked @ > /usr/src/sys/net/if.c:498 > Process 1135 (sshd) thread 0xc462e000 (100113) > exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc475920c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > Process 0 (kernel) thread 0xc4382900 (100042) > exclusive sleep mutex igb1 (IGB Core Lock) r = 0 (0xc43622dc) locked @ > /usr/src/sys/dev/e1000/if_igb.c:1224 > db> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From remko at FreeBSD.org Tue Dec 16 22:58:28 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Tue Dec 16 22:58:35 2008 Subject: kern/129647: [if_rl]: if_rl breakage Message-ID: <200812170658.mBH6wS1w075146@freefall.freebsd.org> Old Synopsis: if_rl breakage New Synopsis: [if_rl]: if_rl breakage Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Dec 17 06:58:06 UTC 2008 Responsible-Changed-Why: reassign to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=129647 From yongari at FreeBSD.org Tue Dec 16 23:37:43 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Dec 16 23:37:49 2008 Subject: kern/129647: [if_rl]: if_rl breakage Message-ID: <200812170737.mBH7bhoD031570@freefall.freebsd.org> Synopsis: [if_rl]: if_rl breakage Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Dec 17 07:36:29 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=129647 From ume at freebsd.org Wed Dec 17 01:05:31 2008 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Wed Dec 17 01:05:37 2008 Subject: [help]strange problem about gethostbyname/getaddrinfo In-Reply-To: References: Message-ID: Hi, >>>>> On Wed, 10 Dec 2008 13:48:51 +0800 >>>>> "=?GB2312?B?s8LQocn6?=" said: stutiredboy> hi,all,we have a project which must resolv some domains in the server stutiredboy> process stutiredboy> our system in FreeBSD 6.2 or 6.3, the server process may open 7000+ stutiredboy> sockets,not fork Umm, it seems your system is slightly old. I believe 6.3-RELEASE is okay. But, there was a bug on 6.2 and earlier that rejected file descriptors higher than FD_SETSIZE even when using kevent(2). http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/resolv/res_send.c#rev1.2.2.5 Perhaps, it is your case. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From bms at incunabulum.net Wed Dec 17 02:49:48 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 17 02:49:58 2008 Subject: loopback creation at boot In-Reply-To: <494872FE.8070801@ibctech.ca> References: <494872FE.8070801@ibctech.ca> Message-ID: <4948D949.8040500@incunabulum.net> Steve Bertrand wrote: > ... > Can anyone provide any feedback or procedural guidance on how I can (for > example): > > - ensure that lo1, lo2-lo14 are created at boot > - ensure that disc0 is created at boot, with an assigned IPv4 and IPv6 > address You should be able to do this by putting them into the 'cloned_interfaces' variable in rc.conf; see the man page. Then configuring them should be as simple as using the usual rc.conf mechanisms. cheers BMS From freebsdlists at bsdunix.ch Wed Dec 17 03:09:46 2008 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Wed Dec 17 03:09:54 2008 Subject: loopback creation at boot In-Reply-To: <494872FE.8070801@ibctech.ca> References: <494872FE.8070801@ibctech.ca> Message-ID: Hi Steve Am 17.12.2008 um 04:33 schrieb Steve Bertrand: > Hi all, > > I'm curious to know if the creation of additional 'lo' interfaces is > possible at boot via the traditional /etc/rc.conf as of yet. > > Forgive me if I've missed anything regarding this. > > I'm still trying to blend some functionality between FBSD and Quagga > for > certain routing functions. > > This is just attempting to get feedback here, knowing full well that > this is not a Quagga list: > > - IPv6 addresses can't be assigned via Quagga to a NIC (Quagga issue > AFAICT) > -'disc' interfaces can't be `created' via Quagga (Quagga issue AFAICT) > - apparently, 'disc' interfaces can not be created via /etc/rc.conf > - IPv4 addresses CAN be assigned to available NIC(s) via Quagga > - loopback interfaces can NOT be created via Quagga, or via FreeBSD > boot > procedure (other than lo0) > > Can anyone provide any feedback or procedural guidance on how I can > (for > example): > > - ensure that lo1, lo2-lo14 are created at boot > - ensure that disc0 is created at boot, with an assigned IPv4 and IPv6 > address cloned_interfaces="lo1 lo2 lo3" ifconfig_lo1="up" ifconfig_lo2="up" ifconfig_lo3="up" Regards Thomas From ottk at zzz.ee Wed Dec 17 05:37:04 2008 From: ottk at zzz.ee (Ott =?iso-8859-1?q?K=F6stner?=) Date: Wed Dec 17 05:37:15 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: <200812171506.58607.ottk@zzz.ee> References: <200812171506.58607.ottk@zzz.ee> Message-ID: <200812171520.02823.ottk@zzz.ee> Ferdinand Goldmann wrote: > > Hi there, > > > > I just upgraded a FreeBSD 6.x machine to FreeBSD 6.3-STABLE, and now I'm > > seeing this same problem which has already been reported in different > > postings: > > > > named[51769]: socket: too many open file descriptors > > last message repeated 147 times > > I am following up to my own posting, which was kind of stupid really because I > obviously made some mistakes. > > I have now done the following: > > # cd /usr/src/lib/bind > > Edited config.mk: > CFLAGS+= -DVERSION='"${BIND_VERSION}"' -DFD_SETSIZE=4096 > > recompiled bind library and named according to advisory on freebsd-security: > > # make obj && make depend && make && make install > # cd /usr/src/usr.sbin/named > # make obj && make depend && make && make install > > I'm crossing my fingers, but it seems to have done the trick. Monitoring > system usage with sockstat, I have seen values of almost up to 1400 being used > by named without the 'too many open file descriptors' appearing in the logs. > > Sorry for my slightly nervous previous posting ... > > Regards, > Ferdinand > Hello List! I have faced the same kind of problem, and nothing seems to help... Trying to run Grub Next Generation Python Client (http://grub.org/?q=en/node/204) on my FreeDSD 7.1 box with as many threads as possible. named seems to limit tha number of Grubng threads I can run, because of exessive name service usage of web crawler. I have recompiled bind with 'CFLAGS+= -DFD_SETSIZE=4096', but this does not help. Also, 'sockstat |grep -c named' does now show too big numbers. Namely, around 20 with 60 Grubng threads and around 100 with 100 threads (never exeeding 1500). But with 100 threads 'named' becomes unresponsive. Messages appear in the log: named[63198]: socket: too many open file descriptors last message repeated 26 times Bind version is: BIND 9.4.2-P2 Any ideas? Best regards, O.K. -- M??da oma inteneti kiirust / Test Your Internet speed http://speedtest.zzz.ee/ From touraine at users.sourceforge.net Wed Dec 17 05:40:24 2008 From: touraine at users.sourceforge.net (Damien Touraine) Date: Wed Dec 17 05:40:32 2008 Subject: link state change without reason ... Message-ID: <4948FECD.20304@users.sourceforge.net> Hi, I have a big server that has 3 network cards (2 Intel(R) PRO/1000 Gigabit Ethernet adapter and 1 3Com Etherlink XL and Fast Etherlink XL Ethernet). I have trouble with the cards : several times per hour, the interface goes down and up with the following dmesg signal : Dec 17 07:06:22 picpus kernel: em1: link state changed to DOWN Dec 17 07:06:37 picpus kernel: em1: link state changed to UP It appears on em1, xl0 but don't seem to be on em0. Do you think that sysctl "net.link.ether.inet.log_arp_wrong_iface=1" should impact on this problem ? Regards, Damien Touraine From mike at sentex.net Wed Dec 17 07:44:29 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Dec 17 07:44:51 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <3c1674c90812162034s432c6d1by92dd3b566b715688@mail.gmail.co m> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <200812170332.mBH3WRbR092071@lava.sentex.ca> <3c1674c90812162034s432c6d1by92dd3b566b715688@mail.gmail.com> Message-ID: <200812171544.mBHFiQiR095196@lava.sentex.ca> At 11:34 PM 12/16/2008, Kip Macy wrote: >Try changeid 186209. Thanks, no panic now! ---Mike From Jinmei_Tatuya at isc.org Wed Dec 17 10:40:57 2008 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Wed Dec 17 10:41:03 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: <200812171520.02823.ottk@zzz.ee> References: <200812171506.58607.ottk@zzz.ee> <200812171520.02823.ottk@zzz.ee> Message-ID: At Wed, 17 Dec 2008 15:20:02 +0200, Ott K?stner wrote: > named[63198]: socket: too many open file descriptors > last message repeated 26 times > > Bind version is: BIND 9.4.2-P2 Please try BIND 9.4.3. Even with all attempts to mitigate the trouble and with tweaking parameters, 9.4.2-P2 still has a fundamental limitation on performance. It should work for the vast majority of users, but you really need 9.4.3 if your server is very busy. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From OttK at zzz.ee Wed Dec 17 10:57:25 2008 From: OttK at zzz.ee (=?UTF-8?B?T3R0IEvDtnN0bmVy?=) Date: Wed Dec 17 10:57:33 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: References: <200812171506.58607.ottk@zzz.ee> <200812171520.02823.ottk@zzz.ee> Message-ID: <49494B8E.7010205@zzz.ee> JINMEI Tatuya / ???? wrote: > At Wed, 17 Dec 2008 15:20:02 +0200, > Ott K?stner wrote: > > >> named[63198]: socket: too many open file descriptors >> last message repeated 26 times >> >> Bind version is: BIND 9.4.2-P2 >> > > Please try BIND 9.4.3. Even with all attempts to mitigate the trouble > and with tweaking parameters, 9.4.2-P2 still has a fundamental > limitation on performance. It should work for the vast majority of > users, but you really need 9.4.3 if your server is very busy. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > Thank You for your advice. Unfortunatelly there is no FreeBSD port of BIND 9.4.3 available at the moment. Hope this will appear soon... Best regards, O.K. From artem at aws-net.org.ua Wed Dec 17 11:28:07 2008 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Wed Dec 17 11:28:15 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: <49494B8E.7010205@zzz.ee> References: <200812171506.58607.ottk@zzz.ee> <200812171520.02823.ottk@zzz.ee> <49494B8E.7010205@zzz.ee> Message-ID: <494952BE.3080305@aws-net.org.ua> Ott K?stner ?????: > JINMEI Tatuya / ???? wrote: >> At Wed, 17 Dec 2008 15:20:02 +0200, >> Ott K?stner wrote: >> >> >>> named[63198]: socket: too many open file descriptors >>> last message repeated 26 times >>> >>> Bind version is: BIND 9.4.2-P2 >>> >> >> Please try BIND 9.4.3. Even with all attempts to mitigate the trouble >> and with tweaking parameters, 9.4.2-P2 still has a fundamental >> limitation on performance. It should work for the vast majority of >> users, but you really need 9.4.3 if your server is very busy. >> >> --- >> JINMEI, Tatuya >> Internet Systems Consortium, Inc. >> > Thank You for your advice. > > Unfortunatelly there is no FreeBSD port of BIND 9.4.3 available at the > moment. Hope this will appear soon... > BIND 9.5.0-P2 already in ports and seems working well. Giv it a try. > > Best regards, > O.K. > > > _______________________________________________ > 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 Jinmei_Tatuya at isc.org Wed Dec 17 11:36:10 2008 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Wed Dec 17 11:36:16 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: <494952BE.3080305@aws-net.org.ua> References: <200812171506.58607.ottk@zzz.ee> <200812171520.02823.ottk@zzz.ee> <49494B8E.7010205@zzz.ee> <494952BE.3080305@aws-net.org.ua> Message-ID: At Wed, 17 Dec 2008 21:27:58 +0200, Artyom Viklenko wrote: > BIND 9.5.0-P2 already in ports and seems working well. > Giv it a try. In this context 9.5.0-P2 won't help. All 9.x.y-P[12] versions have the same problem. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From oxy at field.hu Wed Dec 17 11:40:58 2008 From: oxy at field.hu (oxy) Date: Wed Dec 17 11:41:04 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: <49494B8E.7010205@zzz.ee> References: <200812171506.58607.ottk@zzz.ee> <200812171520.02823.ottk@zzz.ee> <49494B8E.7010205@zzz.ee> Message-ID: <494951B2.5010207@field.hu> I had the same with apache2.. here is the method what i used: edit these files: /usr/src/sys/sys/select.h /usr/include/sys/select.h change this: #define FD_SETSIZE 1024U to this: #define FD_SETSIZE 4096U cd /usr/src && make buildworld && make installworld && reboot after this i got rid of these messages.. Ott K?stner ?rta: > JINMEI Tatuya / ???? wrote: >> At Wed, 17 Dec 2008 15:20:02 +0200, >> Ott K?stner wrote: >> >> >>> named[63198]: socket: too many open file descriptors >>> last message repeated 26 times >>> >>> Bind version is: BIND 9.4.2-P2 >>> >> >> Please try BIND 9.4.3. Even with all attempts to mitigate the trouble >> and with tweaking parameters, 9.4.2-P2 still has a fundamental >> limitation on performance. It should work for the vast majority of >> users, but you really need 9.4.3 if your server is very busy. >> >> --- >> JINMEI, Tatuya >> Internet Systems Consortium, Inc. >> > Thank You for your advice. > > Unfortunatelly there is no FreeBSD port of BIND 9.4.3 available at the > moment. Hope this will appear soon... > > > Best regards, > O.K. > > > _______________________________________________ > 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 lev at serebryakov.spb.ru Wed Dec 17 11:57:17 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed Dec 17 11:57:32 2008 Subject: ifconfig add route " " to table -- why? Message-ID: <976792756.20081217225711@serebryakov.spb.ru> Hello, Freebsd-net. Why does adding address and destination for point-to-point interface add route for destination address? It is not always right. For example, many providers have VPN concentrator address same as "remote end" address and this default create loop -- VPN packets (TCP, UDP or GRE ones)goes into tunnel itself, ooops, host locked up... It could be fixed by deleting route right after tunnel creation via if-up script. But second problem doesn't have good solution, read ahead... Another problem, created by this default, is like this: if we have routing record for other tunnel end already (because it IS VPN server and we NEED routing to it to CREATE tunnel!), me can not assign tunnel interface address and connection fails :( I don't see any workaround for this :( -- // Black Lion AKA Lev Serebryakov From uwe at grohnwaldt.eu Wed Dec 17 12:08:04 2008 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Wed Dec 17 12:08:18 2008 Subject: [Fwd: em0 disappeared] Message-ID: <494954FD.8050708@grohnwaldt.eu> hi, i've forgotten the cc, sry. chers, uwe -------------- next part -------------- An embedded message was scrubbed... From: Uwe Grohnwaldt Subject: em0 disappeared Date: Wed, 17 Dec 2008 20:34:49 +0100 Size: 7571 Url: http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081217/80d75620/em0disappeared.eml From ps at mu.org Wed Dec 17 12:49:27 2008 From: ps at mu.org (Paul Saab) Date: Wed Dec 17 12:49:34 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <494954FD.8050708@grohnwaldt.eu> References: <494954FD.8050708@grohnwaldt.eu> Message-ID: <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> does dmesg show the device failing to attach? On Wed, Dec 17, 2008 at 11:37 AM, Uwe Grohnwaldt wrote: > hi, > > i've forgotten the cc, sry. > > chers, > uwe > > howdy, > > miwi and me tried to update a freebsd-current server to the todays src. > after the update my em0-device disappeared. information about the old image: > > uname -a > FreeBSD amd.miwibox.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Jul 25 > 11:01:22 CEST 2008 root@xizor.skywalkers.local:/usr/obj/usr/src/sys/GENERIC > amd64 > > pciconf > em0@pci0:4:7:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' > class = network subclass = ethernet > > > after the update there is no em-device: > pciconf -lv: > > # amd# pciconf -lv | more > # none0@pci0:0:0:0: class=0x050000 card=0x10c51734 chip=0x02f010de > rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Host Bridge' > # class = memory > # subclass = RAM > # none1@pci0:0:0:1: class=0x050000 card=0x10c51734 chip=0x02fa10de > rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 0' > # class = memory > # subclass = RAM > # none2@pci0:0:0:2: class=0x050000 card=0x10c51734 chip=0x02fe10de > rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 1' > # class = memory > # subclass = RAM > # none3@pci0:0:0:3: class=0x050000 card=0x10c51734 chip=0x02f810de > rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 5' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 4' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Host Bridge' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 3' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 2' > # class = memory > # subclass = RAM > # hdr=0x01 > # vendor = 'Nvidia Corp' > # device = 'C51 PCIe Bridge' > # class = bridge > # subclass = PCI-PCI > # hdr=0x01 > # vendor = 'Nvidia Corp' > # device = 'C51 PCIe Bridge' > # class = bridge > # subclass = PCI-PCI > # hdr=0x00 > # vendor = 'Nvidia Corp' > # rocessor)' > # class = display > # subclass = VGA > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Host Bridge' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 LPC Bridge' > # class = bridge > # subclass = PCI-ISA > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI System > Management' > # class = serial bus > # subclass = SMBus > # ohci0@pci0:0:11:0: class=0x0c0310 card=0x10c61734 chip=0x026d10de > rev=0xa3 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 USB Controller' > # class = serial bus > # subclass = USB > # ehci0@pci0:0:11:1: class=0x0c0320 card=0x10c61734 chip=0x026e10de > rev=0xa3 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 USB Controller' > # class = serial bus > # subclass = USB > # atapci0@pci0:0:13:0: class=0x01018a card=0x10c61734 chip=0x026510de > rev=0xf1 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Parallel ATA Controller' > # class = mass storage > # subclass = ATA > # atapci1@pci0:0:14:0: class=0x010185 card=0x10c61734 chip=0x026610de > rev=0xf1 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Serial ATA Controller' > # class = mass storage > # subclass = ATA > # atapci2@pci0:0:15:0: class=0x010185 card=0x10c61734 chip=0x026710de > rev=0xf1 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Serial ATA Controller' > # class = mass storage > # subclass = ATA > # pcib3@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de > rev=0xa2 hdr=0x01 > # vendor = 'Nvidia Corp' > # device = 'MCP51 PCI Bridge' > # class = bridge > # subclass = PCI-PCI > # hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron HyperTransport Technology > Configuration' > # class = bridge > # subclass = HOST-PCI > # hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron Address Map' > # class = bridge > # subclass = HOST-PCI > # hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron DRAM Controller' > # class = bridge > # subclass = HOST-PCI > # hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron Miscellaneous Control' > # class = bridge > # subclass = HOST-PCI > # amd# > > > moreover i have a lspci from the rescue-linux: > # 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) > # 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) > # 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) > # 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) > # 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) > # 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) > # 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) > # 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) > # 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) > # 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) > # 00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express > Bridge (rev a2) > # 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) > # 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) > # 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) > # 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) > # 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) > # 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) > # 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller > (rev f1) > # 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller > (rev f1) > # 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) > # 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > # 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > # 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller > # 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > # 04:07.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet > Controller (rev 05) > > has anybody an idea? > > cheers, > uwe > > > _______________________________________________ > 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 uwe at grohnwaldt.eu Wed Dec 17 12:56:43 2008 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Wed Dec 17 12:57:01 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> Message-ID: <49496783.1090805@grohnwaldt.eu> with latest src, there were no messages about if_em in dmesg. miwi built src from 2008-07-27 - there the device was active. Paul Saab wrote: > does dmesg show the device failing to attach? > > On Wed, Dec 17, 2008 at 11:37 AM, Uwe Grohnwaldt > wrote: > > hi, > > i've forgotten the cc, sry. > > chers, > uwe > > howdy, > > miwi and me tried to update a freebsd-current server to the todays > src. after the update my em0-device disappeared. information about > the old image: > > uname -a > FreeBSD amd.miwibox.org 8.0-CURRENT > FreeBSD 8.0-CURRENT #0: Fri Jul 25 11:01:22 CEST 2008 > root@xizor.skywalkers.local:/usr/obj/usr/src/sys/GENERIC amd64 > > pciconf > em0@pci0:4:7:0: class=0x020000 card=0x13768086 chip=0x107c8086 > rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = > 'PRO/1000 GT' class = network subclass = ethernet > > > after the update there is no em-device: > pciconf -lv: > > # amd# pciconf -lv | more > # none0@pci0:0:0:0: class=0x050000 card=0x10c51734 > chip=0x02f010de rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Host Bridge' > # class = memory > # subclass = RAM > # none1@pci0:0:0:1: class=0x050000 card=0x10c51734 > chip=0x02fa10de rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 0' > # class = memory > # subclass = RAM > # none2@pci0:0:0:2: class=0x050000 card=0x10c51734 > chip=0x02fe10de rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 1' > # class = memory > # subclass = RAM > # none3@pci0:0:0:3: class=0x050000 card=0x10c51734 > chip=0x02f810de rev=0xa2 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 5' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 4' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Host Bridge' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 3' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'C51 Memory Controller 2' > # class = memory > # subclass = RAM > # hdr=0x01 > # vendor = 'Nvidia Corp' > # device = 'C51 PCIe Bridge' > # class = bridge > # subclass = PCI-PCI > # hdr=0x01 > # vendor = 'Nvidia Corp' > # device = 'C51 PCIe Bridge' > # class = bridge > # subclass = PCI-PCI > # hdr=0x00 > # vendor = 'Nvidia Corp' > # rocessor)' > # class = display > # subclass = VGA > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Host Bridge' > # class = memory > # subclass = RAM > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 LPC Bridge' > # class = bridge > # subclass = PCI-ISA > # hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI > System Management' > # class = serial bus > # subclass = SMBus > # ohci0@pci0:0:11:0: class=0x0c0310 card=0x10c61734 > chip=0x026d10de rev=0xa3 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 USB Controller' > # class = serial bus > # subclass = USB > # ehci0@pci0:0:11:1: class=0x0c0320 card=0x10c61734 > chip=0x026e10de rev=0xa3 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 USB Controller' > # class = serial bus > # subclass = USB > # atapci0@pci0:0:13:0: class=0x01018a card=0x10c61734 > chip=0x026510de rev=0xf1 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Parallel ATA Controller' > # class = mass storage > # subclass = ATA > # atapci1@pci0:0:14:0: class=0x010185 card=0x10c61734 > chip=0x026610de rev=0xf1 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Serial ATA Controller' > # class = mass storage > # subclass = ATA > # atapci2@pci0:0:15:0: class=0x010185 card=0x10c61734 > chip=0x026710de rev=0xf1 hdr=0x00 > # vendor = 'Nvidia Corp' > # device = 'MCP51 Serial ATA Controller' > # class = mass storage > # subclass = ATA > # pcib3@pci0:0:16:0: class=0x060401 card=0xcb8410de > chip=0x026f10de rev=0xa2 hdr=0x01 > # vendor = 'Nvidia Corp' > # device = 'MCP51 PCI Bridge' > # class = bridge > # subclass = PCI-PCI > # hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 > chip=0x11001022 rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron HyperTransport > Technology Configuration' > # class = bridge > # subclass = HOST-PCI > # hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 > chip=0x11011022 rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron Address Map' > # class = bridge > # subclass = HOST-PCI > # hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 > chip=0x11021022 rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron DRAM Controller' > # class = bridge > # subclass = HOST-PCI > # hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 > chip=0x11031022 rev=0x00 hdr=0x00 > # vendor = 'Advanced Micro Devices (AMD)' > # device = '(K8) Athlon 64/Opteron Miscellaneous Control' > # class = bridge > # subclass = HOST-PCI > # amd# > > > moreover i have a lspci from the rescue-linux: > # 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) > # 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 > (rev a2) > # 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 > (rev a2) > # 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 > (rev a2) > # 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 > (rev a2) > # 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) > # 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 > (rev a2) > # 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 > (rev a2) > # 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge > (rev a1) > # 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge > (rev a1) > # 00:05.0 VGA compatible controller: nVidia Corporation C51 PCI > Express Bridge (rev a2) > # 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) > # 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) > # 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) > # 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller > (rev a3) > # 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller > (rev a3) > # 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) > # 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA > Controller (rev f1) > # 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA > Controller (rev f1) > # 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) > # 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 > [Athlon64/Opteron] HyperTransport Technology Configuration > # 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 > [Athlon64/Opteron] Address Map > # 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 > [Athlon64/Opteron] DRAM Controller > # 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 > [Athlon64/Opteron] Miscellaneous Control > # 04:07.0 Ethernet controller: Intel Corporation 82541PI Gigabit > Ethernet Controller (rev 05) > > has anybody an idea? > > cheers, > uwe > > > _______________________________________________ > 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 ps at mu.org Wed Dec 17 12:59:19 2008 From: ps at mu.org (Paul Saab) Date: Wed Dec 17 12:59:26 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <49496783.1090805@grohnwaldt.eu> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> Message-ID: <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> are you looking for if_em or em? On Wed, Dec 17, 2008 at 12:56 PM, Uwe Grohnwaldt wrote: > with latest src, there were no messages about if_em in dmesg. miwi built > src from 2008-07-27 - there the device was active. > > Paul Saab wrote: > >> does dmesg show the device failing to attach? >> >> On Wed, Dec 17, 2008 at 11:37 AM, Uwe Grohnwaldt >> wrote: >> >> hi, >> >> i've forgotten the cc, sry. >> >> chers, >> uwe >> >> howdy, >> >> miwi and me tried to update a freebsd-current server to the todays >> src. after the update my em0-device disappeared. information about >> the old image: >> >> uname -a >> FreeBSD amd.miwibox.org 8.0-CURRENT >> >> FreeBSD 8.0-CURRENT #0: Fri Jul 25 11:01:22 CEST 2008 >> root@xizor.skywalkers.local:/usr/obj/usr/src/sys/GENERIC amd64 >> >> pciconf >> em0@pci0:4:7:0: class=0x020000 card=0x13768086 chip=0x107c8086 >> rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = >> 'PRO/1000 GT' class = network subclass = ethernet >> >> >> after the update there is no em-device: >> pciconf -lv: >> >> # amd# pciconf -lv | more >> # none0@pci0:0:0:0: class=0x050000 card=0x10c51734 >> chip=0x02f010de rev=0xa2 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Host Bridge' >> # class = memory >> # subclass = RAM >> # none1@pci0:0:0:1: class=0x050000 card=0x10c51734 >> chip=0x02fa10de rev=0xa2 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Memory Controller 0' >> # class = memory >> # subclass = RAM >> # none2@pci0:0:0:2: class=0x050000 card=0x10c51734 >> chip=0x02fe10de rev=0xa2 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Memory Controller 1' >> # class = memory >> # subclass = RAM >> # none3@pci0:0:0:3: class=0x050000 card=0x10c51734 >> chip=0x02f810de rev=0xa2 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Memory Controller 5' >> # class = memory >> # subclass = RAM >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Memory Controller 4' >> # class = memory >> # subclass = RAM >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Host Bridge' >> # class = memory >> # subclass = RAM >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Memory Controller 3' >> # class = memory >> # subclass = RAM >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'C51 Memory Controller 2' >> # class = memory >> # subclass = RAM >> # hdr=0x01 >> # vendor = 'Nvidia Corp' >> # device = 'C51 PCIe Bridge' >> # class = bridge >> # subclass = PCI-PCI >> # hdr=0x01 >> # vendor = 'Nvidia Corp' >> # device = 'C51 PCIe Bridge' >> # class = bridge >> # subclass = PCI-PCI >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # rocessor)' >> # class = display >> # subclass = VGA >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 Host Bridge' >> # class = memory >> # subclass = RAM >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 LPC Bridge' >> # class = bridge >> # subclass = PCI-ISA >> # hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI >> System Management' >> # class = serial bus >> # subclass = SMBus >> # ohci0@pci0:0:11:0: class=0x0c0310 card=0x10c61734 >> chip=0x026d10de rev=0xa3 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 USB Controller' >> # class = serial bus >> # subclass = USB >> # ehci0@pci0:0:11:1: class=0x0c0320 card=0x10c61734 >> chip=0x026e10de rev=0xa3 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 USB Controller' >> # class = serial bus >> # subclass = USB >> # atapci0@pci0:0:13:0: class=0x01018a card=0x10c61734 >> chip=0x026510de rev=0xf1 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 Parallel ATA Controller' >> # class = mass storage >> # subclass = ATA >> # atapci1@pci0:0:14:0: class=0x010185 card=0x10c61734 >> chip=0x026610de rev=0xf1 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 Serial ATA Controller' >> # class = mass storage >> # subclass = ATA >> # atapci2@pci0:0:15:0: class=0x010185 card=0x10c61734 >> chip=0x026710de rev=0xf1 hdr=0x00 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 Serial ATA Controller' >> # class = mass storage >> # subclass = ATA >> # pcib3@pci0:0:16:0: class=0x060401 card=0xcb8410de >> chip=0x026f10de rev=0xa2 hdr=0x01 >> # vendor = 'Nvidia Corp' >> # device = 'MCP51 PCI Bridge' >> # class = bridge >> # subclass = PCI-PCI >> # hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 >> chip=0x11001022 rev=0x00 hdr=0x00 >> # vendor = 'Advanced Micro Devices (AMD)' >> # device = '(K8) Athlon 64/Opteron HyperTransport >> Technology Configuration' >> # class = bridge >> # subclass = HOST-PCI >> # hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 >> chip=0x11011022 rev=0x00 hdr=0x00 >> # vendor = 'Advanced Micro Devices (AMD)' >> # device = '(K8) Athlon 64/Opteron Address Map' >> # class = bridge >> # subclass = HOST-PCI >> # hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 >> chip=0x11021022 rev=0x00 hdr=0x00 >> # vendor = 'Advanced Micro Devices (AMD)' >> # device = '(K8) Athlon 64/Opteron DRAM Controller' >> # class = bridge >> # subclass = HOST-PCI >> # hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 >> chip=0x11031022 rev=0x00 hdr=0x00 >> # vendor = 'Advanced Micro Devices (AMD)' >> # device = '(K8) Athlon 64/Opteron Miscellaneous Control' >> # class = bridge >> # subclass = HOST-PCI >> # amd# >> >> >> moreover i have a lspci from the rescue-linux: >> # 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) >> # 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 >> (rev a2) >> # 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 >> (rev a2) >> # 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 >> (rev a2) >> # 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 >> (rev a2) >> # 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) >> # 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 >> (rev a2) >> # 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 >> (rev a2) >> # 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge >> (rev a1) >> # 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge >> (rev a1) >> # 00:05.0 VGA compatible controller: nVidia Corporation C51 PCI >> Express Bridge (rev a2) >> # 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) >> # 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) >> # 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) >> # 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller >> (rev a3) >> # 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller >> (rev a3) >> # 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) >> # 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA >> Controller (rev f1) >> # 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA >> Controller (rev f1) >> # 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) >> # 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 >> [Athlon64/Opteron] HyperTransport Technology Configuration >> # 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 >> [Athlon64/Opteron] Address Map >> # 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 >> [Athlon64/Opteron] DRAM Controller >> # 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 >> [Athlon64/Opteron] Miscellaneous Control >> # 04:07.0 Ethernet controller: Intel Corporation 82541PI Gigabit >> Ethernet Controller (rev 05) >> >> has anybody an idea? >> >> cheers, >> uwe >> >> >> _______________________________________________ >> 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 Wed Dec 17 13:02:05 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Dec 17 13:02:12 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> Message-ID: <20081217210718.GA73545@onelab2.iet.unipi.it> On Wed, Dec 17, 2008 at 12:59:17PM -0800, Paul Saab wrote: > are you looking for if_em or em? also, wasn't the em driver renamed to ixgb or something like that ? cheers luigi From ps at mu.org Wed Dec 17 13:03:20 2008 From: ps at mu.org (Paul Saab) Date: Wed Dec 17 13:03:26 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <20081217210718.GA73545@onelab2.iet.unipi.it> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> Message-ID: <5c0ff6a70812171303r47e989f8r7efd4ba068c458ce@mail.gmail.com> On Wed, Dec 17, 2008 at 1:07 PM, Luigi Rizzo wrote: > On Wed, Dec 17, 2008 at 12:59:17PM -0800, Paul Saab wrote: > > are you looking for if_em or em? > > also, wasn't the em driver renamed to ixgb or something like that ? > No... Maybe you need igb in your kernel as well? From uwe at grohnwaldt.eu Wed Dec 17 13:54:14 2008 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Wed Dec 17 13:54:22 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <20081217210718.GA73545@onelab2.iet.unipi.it> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> Message-ID: <494974F7.7080408@grohnwaldt.eu> there is nothing mentioned about the network-interface neither in dmesg nor in pciconf. in my kernelconfig there are the entries: device em device igb device ixgb with the old kernel everything works. Luigi Rizzo wrote: > On Wed, Dec 17, 2008 at 12:59:17PM -0800, Paul Saab wrote: > >> are you looking for if_em or em? >> > > also, wasn't the em driver renamed to ixgb or something like that ? > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From jfvogel at gmail.com Wed Dec 17 14:09:47 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Dec 17 14:09:53 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <494974F7.7080408@grohnwaldt.eu> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> <494974F7.7080408@grohnwaldt.eu> Message-ID: <2a41acea0812171409w33e49c2fq3851761a09b7aead@mail.gmail.com> This is odd, that device is old, its not in igb, the support looks to me like its there in the code, its an 82541GI_LF. I am on vacation, and snowed in even if i weren't :) But I will look into it. Can you please try using the RC version of 7.1 to see if it has the same problem?? Jack On Wed, Dec 17, 2008 at 1:53 PM, Uwe Grohnwaldt wrote: > there is nothing mentioned about the network-interface neither in dmesg nor > in pciconf. > in my kernelconfig there are the entries: > device em > device igb > device ixgb > > with the old kernel everything works. > > Luigi Rizzo wrote: > >> On Wed, Dec 17, 2008 at 12:59:17PM -0800, Paul Saab wrote: >> >> >>> are you looking for if_em or em? >>> >>> >> >> also, wasn't the em driver renamed to ixgb or something like that ? >> >> cheers >> luigi >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> >> > > From oberman at es.net Wed Dec 17 14:38:37 2008 From: oberman at es.net (Kevin Oberman) Date: Wed Dec 17 14:38:43 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: Your message of "Wed, 17 Dec 2008 22:07:18 +0100." <20081217210718.GA73545@onelab2.iet.unipi.it> Message-ID: <20081217222742.693CC4500F@ptavv.es.net> > Date: Wed, 17 Dec 2008 22:07:18 +0100 > From: Luigi Rizzo > Sender: owner-freebsd-current@freebsd.org > > On Wed, Dec 17, 2008 at 12:59:17PM -0800, Paul Saab wrote: > > are you looking for if_em or em? > > also, wasn't the em driver renamed to ixgb or something like that ? em is still if_em, but the igb driver now supports a new Intel chip, the 82575, which was supported by em in 7.0. It will be supported by the igb driver in 7.1 as will all new Intel GigE chips. -- 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/20081217/22bec004/attachment.pgp From maksim.yevmenkin at gmail.com Wed Dec 17 16:14:41 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Dec 17 16:14:48 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <494974F7.7080408@grohnwaldt.eu> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> <494974F7.7080408@grohnwaldt.eu> Message-ID: On Wed, Dec 17, 2008 at 1:53 PM, Uwe Grohnwaldt wrote: > there is nothing mentioned about the network-interface neither in dmesg nor > in pciconf. > in my kernelconfig there are the entries: > device em > device igb > device ixgb > > with the old kernel everything works. > i actually had somewhat similar problem only with onboard bge nics on older tyan motherboards. when i upgraded from 7.x to current (amd64 arch) both onboard bge nics disappeared. i had to go to the bios screen and set "installed os" (or something like that) to "linux". other choices were "windows" and "other" (default). thanks, max From uwe at grohnwaldt.eu Wed Dec 17 16:35:05 2008 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Wed Dec 17 16:35:12 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <2a41acea0812171409w33e49c2fq3851761a09b7aead@mail.gmail.com> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> <494974F7.7080408@grohnwaldt.eu> <2a41acea0812171409w33e49c2fq3851761a09b7aead@mail.gmail.com> Message-ID: <49499AB2.7070100@grohnwaldt.eu> We tried 7.1RC and the card works fine. Jack Vogel wrote: > This is odd, that device is old, its not in igb, the support looks to me > like its > there in the code, its an 82541GI_LF. > > I am on vacation, and snowed in even if i weren't :) But I will look into > it. > Can you please try using the RC version of 7.1 to see if it has the same > problem?? > > Jack > > > On Wed, Dec 17, 2008 at 1:53 PM, Uwe Grohnwaldt wrote: > > >> there is nothing mentioned about the network-interface neither in dmesg nor >> in pciconf. >> in my kernelconfig there are the entries: >> device em >> device igb >> device ixgb >> >> with the old kernel everything works. >> >> Luigi Rizzo wrote: >> >> >>> On Wed, Dec 17, 2008 at 12:59:17PM -0800, Paul Saab wrote: >>> >>> >>> >>>> are you looking for if_em or em? >>>> >>>> >>>> >>> also, wasn't the em driver renamed to ixgb or something like that ? >>> >>> cheers >>> luigi >>> >>> From uwe at grohnwaldt.eu Wed Dec 17 16:46:04 2008 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Wed Dec 17 16:46:11 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> <494974F7.7080408@grohnwaldt.eu> Message-ID: <49499D47.5040509@grohnwaldt.eu> Maksim Yevmenkin wrote: > On Wed, Dec 17, 2008 at 1:53 PM, Uwe Grohnwaldt wrote: > >> there is nothing mentioned about the network-interface neither in dmesg nor >> in pciconf. >> in my kernelconfig there are the entries: >> device em >> device igb >> device ixgb >> >> with the old kernel everything works. >> >> > > i actually had somewhat similar problem only with onboard bge nics on > older tyan motherboards. when i upgraded from 7.x to current (amd64 > arch) both onboard bge nics disappeared. i had to go to the bios > screen and set "installed os" (or something like that) to "linux". > other choices were "windows" and "other" (default). > > thanks, > max > The problem is: it is a rented Strato-Server. So I have no access to the bios. The box is used to be a new Tinderbox for miwi so he needs a running fbsd-current. we would realy appreciate a fix and will test it, of course. chers, Uwe From linimon at FreeBSD.org Wed Dec 17 16:46:53 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Dec 17 16:46:59 2008 Subject: kern/129719: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL Message-ID: <200812180046.mBI0kqIo005702@freefall.freebsd.org> Old Synopsis: Panic during shutdown, tcp_ctloutput: inp == NULL New Synopsis: [tcp] [panic] Panic during shutdown, tcp_ctloutput: inp == NULL Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 18 00:46:25 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129719 From ume at freebsd.org Thu Dec 18 10:18:44 2008 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Thu Dec 18 10:18:55 2008 Subject: 6to4 in 6.3-R? In-Reply-To: References: Message-ID: Hi, >>>>> On Tue, 16 Dec 2008 22:01:59 +0100 >>>>> Ivan Voras said: ivoras> > ping6 www.freebsd.org ivoras> PING6(56=40+8+8 bytes) 2002:a135:xxyy::1 --> 2001:4f8:fff6::21 ivoras> ping6: sendmsg: Permission denied ivoras> ping6: wrote www.freebsd.org 16 chars, ret=-1 ivoras> ping6: sendmsg: Permission denied ivoras> ping6: wrote www.freebsd.org 16 chars, ret=-1 ivoras> ^C ivoras> --- www.freebsd.org ping6 statistics --- ivoras> 2 packets transmitted, 0 packets received, 100.0% packet loss ivoras> It can ping6 itself. I have ipfw here but a very early rule says "allow ivoras> ipv6 from any to any". It's triggered, judging by the packet counts, but ivoras> apparently only in one direction (in the above example, only 2 packets ivoras> would be accounted for). Though "allow ipv6 from any to any" allows native IPv6 traffic, it doesn't allow IPv6 over IPv4 traffic e.g. 6to4. I suspect you don't have a rule to allow 6to4 traffic. Please try the following rule, and see the result: allow ip4 from any to any proto ipv6 Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From ivoras at freebsd.org Thu Dec 18 12:06:41 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 12:06:47 2008 Subject: 6to4 in 6.3-R? In-Reply-To: References: Message-ID: Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Tue, 16 Dec 2008 22:01:59 +0100 >>>>>> Ivan Voras said: > > ivoras> > ping6 www.freebsd.org > ivoras> PING6(56=40+8+8 bytes) 2002:a135:xxyy::1 --> 2001:4f8:fff6::21 > ivoras> ping6: sendmsg: Permission denied > ivoras> ping6: wrote www.freebsd.org 16 chars, ret=-1 > ivoras> ping6: sendmsg: Permission denied > ivoras> ping6: wrote www.freebsd.org 16 chars, ret=-1 > ivoras> ^C > ivoras> --- www.freebsd.org ping6 statistics --- > ivoras> 2 packets transmitted, 0 packets received, 100.0% packet loss > > ivoras> It can ping6 itself. I have ipfw here but a very early rule says "allow > ivoras> ipv6 from any to any". It's triggered, judging by the packet counts, but > ivoras> apparently only in one direction (in the above example, only 2 packets > ivoras> would be accounted for). > > Though "allow ipv6 from any to any" allows native IPv6 traffic, it > doesn't allow IPv6 over IPv4 traffic e.g. 6to4. I suspect you don't > have a rule to allow 6to4 traffic. Please try the following rule, and > see the result: > > allow ip4 from any to any proto ipv6 You are very much correct - I forgot to allow the inner protocol! Thanks! -------------- 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/20081218/50b6cb9e/signature.pgp From ivoras at freebsd.org Thu Dec 18 12:59:12 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 12:59:18 2008 Subject: IPv6 routing help? Message-ID: Hi, I'm experimenting with IPv6 and have 6to4 running on a machine (thanks to Hajimu UMEMOTO). I'm now trying to configure another system on a LAN, running Linux, to use the 6to4 one as a IPv6 router. I've configured ipv6 forwarding on the router, and started rtadvd. The client machine apparently sees the route and has autoconfigured the following: # ip -6 route show fe80::/64 dev eth0 metric 256 expires -205814sec mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::250:8bff:feeb:8401 dev eth0 proto kernel metric 1024 expires 1396sec mtu 1500 advmss 1440 hoplimit 64 The last line correctly lists the link-local ipv6 address of the router. This looks ok, except attempts to actually use ping6 on this address fail: # ping6 fe80::250:8bff:feeb:8401 connect: Invalid argument But, pinging the router's external IPv6 address works from the client: # ping6 2002:xxyy:xxyy::1 PING 2002:xxyy:xxyy::1(2002:xxyy:xxyy::1) 56 data bytes 64 bytes from 2002:xxyy:xxyy::1: icmp_seq=1 ttl=64 time=0.492 ms 64 bytes from 2002:xxyy:xxyy::1: icmp_seq=2 ttl=64 time=0.501 ms --- 2002:xxyy:xxyy::1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.492/0.496/0.501/0.022 ms But pinging any outside address fails: # ping6 www.freebsd.org PING www.freebsd.org(www.freebsd.org) 56 data bytes From fe80::250:8bff:feeb:8401 icmp_seq=1 Destination unreachable: Beyond scope of source address From fe80::250:8bff:feeb:8401 icmp_seq=2 Destination unreachable: Beyond scope of source address --- www.freebsd.org ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms As far as I understand ipv6 (very little), this basically says the router told the client it can't send packets to outside addresses with source addresses that are link-local. Is this correct? However, adding an ipv6 address to the client, in this case 2002:xxyy:xxyy::10/64 doesn't help and breaks even pinging the router's external address. It looks to me like I'm missing something important in the relation between the link-local and the global addresses, but what? -------------- 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/20081218/a7da4e9b/signature.pgp From steve at ibctech.ca Thu Dec 18 13:39:49 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Dec 18 13:39:55 2008 Subject: IPv6 routing help? In-Reply-To: References: Message-ID: <494AC323.9070007@ibctech.ca> Ivan Voras wrote: > As far as I understand ipv6 (very little), this basically says the > router told the client it can't send packets to outside addresses with > source addresses that are link-local. Is this correct? I don't know much about 6to4. All of my IPv6 is native, but what you are saying appears correct. It is almost like a translation at the router should be happening, but it is not. > However, adding an ipv6 address to the client, in this case > 2002:xxyy:xxyy::10/64 doesn't help and breaks even pinging the router's > external address. It looks to me like I'm missing something important in > the relation between the link-local and the global addresses, but what? In this case, you are implementing the same IP prefix on both sides of the router, which won't work. Try to ping6 www.freebsd.org from the router itself. If that works, the issue is most certainly the router. If this is the case, hopefully someone with more 6to4 experience can explain why your router is not doing the expected thing. Steve From steve at ibctech.ca Thu Dec 18 13:43:26 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Dec 18 13:43:34 2008 Subject: IPv6 routing help? In-Reply-To: References: Message-ID: <494AC3FD.8040402@ibctech.ca> Ivan Voras wrote: > The last line correctly lists the link-local ipv6 address of the router. > This looks ok, except attempts to actually use ping6 on this address fail: > > # ping6 fe80::250:8bff:feeb:8401 > connect: Invalid argument Oh, and I've found in the past that FreeBSD requires you to add the interface name with a % sign after the v6 address when trying to communicate via link-local: #ping6 fe80::1%lo0 PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1%lo0 16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.224 ms 16 bytes from fe80::1%lo0, icmp_seq=1 hlim=64 time=0.131 ms ^C ...but when communicating to a global unique, you do not: #ping6 2607:f118::b6 PING6(56=40+8+8 bytes) 2607:f118::b6 --> 2607:f118::b6 16 bytes from 2607:f118::b6, icmp_seq=0 hlim=64 time=0.234 ms ^C Steve From ivoras at freebsd.org Thu Dec 18 13:55:28 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 13:55:41 2008 Subject: IPv6 routing help? In-Reply-To: <494AC3FD.8040402@ibctech.ca> References: <494AC3FD.8040402@ibctech.ca> Message-ID: Steve Bertrand wrote: > Ivan Voras wrote: > >> The last line correctly lists the link-local ipv6 address of the router. >> This looks ok, except attempts to actually use ping6 on this address fail: >> >> # ping6 fe80::250:8bff:feeb:8401 >> connect: Invalid argument > > Oh, and I've found in the past that FreeBSD requires you to add the > interface name with a % sign after the v6 address when trying to > communicate via link-local: > > #ping6 fe80::1%lo0 > > PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1%lo0 > 16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.224 ms > 16 bytes from fe80::1%lo0, icmp_seq=1 hlim=64 time=0.131 ms > ^C Thanks, it looks like Linux wants it also. Pinging fe80::250:8bff:feeb:8401%eth0 works as expected. -------------- 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/20081218/29984e49/signature.pgp From ivoras at freebsd.org Thu Dec 18 14:08:31 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 14:08:38 2008 Subject: IPv6 routing help? In-Reply-To: <494AC323.9070007@ibctech.ca> References: <494AC323.9070007@ibctech.ca> Message-ID: Steve Bertrand wrote: > Ivan Voras wrote: > >> As far as I understand ipv6 (very little), this basically says the >> router told the client it can't send packets to outside addresses with >> source addresses that are link-local. Is this correct? > > I don't know much about 6to4. All of my IPv6 is native, but what you are > saying appears correct. > > It is almost like a translation at the router should be happening, but > it is not. Yes. >> However, adding an ipv6 address to the client, in this case >> 2002:xxyy:xxyy::10/64 doesn't help and breaks even pinging the router's >> external address. It looks to me like I'm missing something important in >> the relation between the link-local and the global addresses, but what? > > In this case, you are implementing the same IP prefix on both sides of > the router, which won't work. I don't follow you - is something significantly different than ipv4? > Try to ping6 www.freebsd.org from the router itself. If that works, the > issue is most certainly the router. If this is the case, hopefully > someone with more 6to4 experience can explain why your router is not > doing the expected thing. IPv6 from and to the "router" (it's actually an ordinary machine doing lots of stuff) works for all purposes. -------------- 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/20081218/347dccb2/signature.pgp From max at love2party.net Thu Dec 18 15:33:04 2008 From: max at love2party.net (Max Laier) Date: Thu Dec 18 15:33:11 2008 Subject: IPv6 routing help? In-Reply-To: References: <494AC323.9070007@ibctech.ca> Message-ID: <200812190033.01630.max@love2party.net> On Thursday 18 December 2008 23:08:12 Ivan Voras wrote: > Steve Bertrand wrote: > > Ivan Voras wrote: > >> As far as I understand ipv6 (very little), this basically says the > >> router told the client it can't send packets to outside addresses with > >> source addresses that are link-local. Is this correct? > > > > I don't know much about 6to4. All of my IPv6 is native, but what you are > > saying appears correct. > > > > It is almost like a translation at the router should be happening, but > > it is not. > > Yes. No! IPv6 gets rid of all the translation madness! > >> However, adding an ipv6 address to the client, in this case > >> 2002:xxyy:xxyy::10/64 doesn't help and breaks even pinging the router's > >> external address. It looks to me like I'm missing something important in > >> the relation between the link-local and the global addresses, but what? > > > > In this case, you are implementing the same IP prefix on both sides of > > the router, which won't work. > > I don't follow you - is something significantly different than ipv4? What you need to do is something like the following: On the interface you are running rtadvd you need a global address out of your stf prefix, e.g. 2002:aabb:ccdd:1::/64. Once you do that, everything else should just fall into place. The client will configure an address out of that prefix and adds a route via 2002:aabb:ccdd:1::/64. This should get you going. > > Try to ping6 www.freebsd.org from the router itself. If that works, the > > issue is most certainly the router. If this is the case, hopefully > > someone with more 6to4 experience can explain why your router is not > > doing the expected thing. > > IPv6 from and to the "router" (it's actually an ordinary machine doing > lots of stuff) works for all purposes. -- /"\ 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 steve at ibctech.ca Thu Dec 18 15:39:46 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Dec 18 15:39:53 2008 Subject: IPv6 routing help? In-Reply-To: References: <494AC323.9070007@ibctech.ca> Message-ID: <494ADF40.3060903@ibctech.ca> Ivan Voras wrote: > Steve Bertrand wrote: >> Ivan Voras wrote: >> >>> As far as I understand ipv6 (very little), this basically says the >>> router told the client it can't send packets to outside addresses with >>> source addresses that are link-local. Is this correct? >> I don't know much about 6to4. All of my IPv6 is native, but what you are >> saying appears correct. >> >> It is almost like a translation at the router should be happening, but >> it is not. > > Yes. > >>> However, adding an ipv6 address to the client, in this case >>> 2002:xxyy:xxyy::10/64 doesn't help and breaks even pinging the router's >>> external address. It looks to me like I'm missing something important in >>> the relation between the link-local and the global addresses, but what? >> In this case, you are implementing the same IP prefix on both sides of >> the router, which won't work. > > I don't follow you - is something significantly different than ipv4? Err, no. IPv4 and IPv6 are systematically the same. You stated in the original post that you have, on the router, as its 'outside' address: 2002:xxyy:xxyy::1 Then, in a subsequent post, you stated that you assigned: 2002:xxyy:xxyy::10 to the client, which I expect is attached to the *inside* interface on the router. Therefore, you would have 2002:xxyy:xxyy::/64 networks on BOTH the inside, and outside interfaces. I think what you need to do is configure a separate global /64 prefix on the INSIDE interface of your router (and the network clients), that is different from the /64 on the outside, as opposed to using link-local addressing. However, I have no idea if this needs to be globally routable or not. As I've said, I know pretty much nothing of 6to4. Some tunnel brokers can provide you with both a global unique address for the 'WAN' side of your router, and then route you a /48 that can be used inside of your network. Steve From ivoras at freebsd.org Thu Dec 18 15:45:33 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 15:45:40 2008 Subject: IPv6 routing help? In-Reply-To: <494ADF40.3060903@ibctech.ca> References: <494AC323.9070007@ibctech.ca> <494ADF40.3060903@ibctech.ca> Message-ID: Steve Bertrand wrote: > Ivan Voras wrote: >> Steve Bertrand wrote: >>> Ivan Voras wrote: >>> >>>> As far as I understand ipv6 (very little), this basically says the >>>> router told the client it can't send packets to outside addresses with >>>> source addresses that are link-local. Is this correct? >>> I don't know much about 6to4. All of my IPv6 is native, but what you are >>> saying appears correct. >>> >>> It is almost like a translation at the router should be happening, but >>> it is not. >> Yes. >> >>>> However, adding an ipv6 address to the client, in this case >>>> 2002:xxyy:xxyy::10/64 doesn't help and breaks even pinging the router's >>>> external address. It looks to me like I'm missing something important in >>>> the relation between the link-local and the global addresses, but what? >>> In this case, you are implementing the same IP prefix on both sides of >>> the router, which won't work. >> I don't follow you - is something significantly different than ipv4? > > Err, no. IPv4 and IPv6 are systematically the same. > > You stated in the original post that you have, on the router, as its > 'outside' address: > > 2002:xxyy:xxyy::1 > > Then, in a subsequent post, you stated that you assigned: > > 2002:xxyy:xxyy::10 to the client, which I expect is attached to the > *inside* interface on the router. Yes, I managed to get confused by the link-local address again. You're right. -------------- 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/20081218/c204ff07/signature.pgp From ivoras at freebsd.org Thu Dec 18 16:12:17 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Dec 18 16:12:23 2008 Subject: IPv6 routing help? In-Reply-To: <200812190033.01630.max@love2party.net> References: <494AC323.9070007@ibctech.ca> <200812190033.01630.max@love2party.net> Message-ID: Max Laier wrote: > On the interface you are running rtadvd you need a global address out of your > stf prefix, e.g. 2002:aabb:ccdd:1::/64. Once you do that, everything else > should just fall into place. The client will configure an address out of that > prefix and adds a route via 2002:aabb:ccdd:1::/64. This should get you going. Thanks, I understand now what I was doing wrong before. Actually 6to4 is very elegant. Another related question: if I understand it correctly, rtadvd should also be used for address autoconfiguration (like DHCP for IPv6, but not actually DHCP). I have it running with defaults (they look like they should do the right thing) and apparently it works as the client got the link-local address of the router as it's default IPv6 route, but I expected it would also automagically pick up the 2002:aabb:ccdd:1::/64 network when I assigned an address from it on the router and autoconfigure its own address. Maybe I'm expecting too much of it? -------------- 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/20081219/276b4254/signature.pgp From max at love2party.net Thu Dec 18 16:17:45 2008 From: max at love2party.net (Max Laier) Date: Thu Dec 18 16:17:52 2008 Subject: IPv6 routing help? In-Reply-To: References: <200812190033.01630.max@love2party.net> Message-ID: <200812190117.43337.max@love2party.net> On Friday 19 December 2008 01:11:51 Ivan Voras wrote: > Max Laier wrote: > > On the interface you are running rtadvd you need a global address out of > > your stf prefix, e.g. 2002:aabb:ccdd:1::/64. Once you do that, > > everything else should just fall into place. The client will configure > > an address out of that prefix and adds a route via 2002:aabb:ccdd:1::/64. > > This should get you going. > > Thanks, I understand now what I was doing wrong before. Actually 6to4 is > very elegant. > > Another related question: if I understand it correctly, rtadvd should > also be used for address autoconfiguration (like DHCP for IPv6, but not > actually DHCP). I have it running with defaults (they look like they > should do the right thing) and apparently it works as the client got the > link-local address of the router as it's default IPv6 route, but I > expected it would also automagically pick up the 2002:aabb:ccdd:1::/64 > network when I assigned an address from it on the router and > autoconfigure its own address. Maybe I'm expecting too much of it? It will, provided you properly assign an address on the NIC that is running rtadvd. -- /"\ 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 linimon at FreeBSD.org Thu Dec 18 20:46:32 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Dec 18 20:46:50 2008 Subject: kern/129750: [ath] Atheros AR5006 exits on "cannot map register space" & "ath0 attach returned 6" Message-ID: <200812190446.mBJ4kWeU091603@freefall.freebsd.org> Old Synopsis: Atheros AR5006 exists on "cannot map register space" & "ath0 attach returned 6" New Synopsis: [ath] Atheros AR5006 exits on "cannot map register space" & "ath0 attach returned 6" Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Dec 19 04:46:16 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129750 From peterjeremy at optushome.com.au Thu Dec 18 23:38:50 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Dec 18 23:38:57 2008 Subject: ath: is here full list of supported chipsets and chipsets comparsion? In-Reply-To: <1125132021.20081215232730@serebryakov.spb.ru> References: <1988001541.20081215103053@serebryakov.spb.ru> <49469ED0.5070308@freebsd.org> <1125132021.20081215232730@serebryakov.spb.ru> Message-ID: <20081219073842.GB21468@server.vk2pj.dyndns.org> On 2008-Dec-15 23:27:30 +0300, Lev Serebryakov wrote: > And using HEAD in production... Hmm. Is it good idea? That's really an individual decision. If you have the time, expertise and facilities to adequately regression test a HEAD snapshot using something similar to your production workload, and are willing to help resolve any problems you encounter, then there's no particular reason why you shouldn't run HEAD in production. Looking at it another way, the more people who stress 8-CURRENT in strange and varied ways (and help fix any problems they encounter), the better 8-RELEASE will be when it eventuates. -- 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/20081219/b3ebcd79/attachment.pgp From indul at citromail.hu Fri Dec 19 02:36:41 2008 From: indul at citromail.hu (Lazar Szilard) Date: Fri Dec 19 02:36:51 2008 Subject: proxy Message-ID: <20081219100959.8838.qmail@server16.citromail.hu> hi, I have a beginner quieston. I use FreeBSD 7.1-RC1 without X on my notebook. How can I configure my network to 1. use proxy to http or ftp connections (proxy address: (10.0.1.1:8080) or (on another place, with stong restrictions, but port 22 is open) 2. use ssh tunnel (in windows I've used socks5 proxy trough my server: ssh -D 7777 user@host.tld) where can I set these settings? best regards, indul Hirdet?s (x) mindenidok.hu Kedvenceid ?s VIP legek egy helyen. Mutasd meg, miben vagy kir?ly! Regisztr?lj, szavazz, ?p?ts saj?t list?t! Az els? 50 decemberi listaszerz? b?gr?t kap! mindenidok.hu. A legport?l. // From tevans.uk at googlemail.com Fri Dec 19 03:32:46 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Dec 19 03:32:52 2008 Subject: proxy In-Reply-To: <20081219100959.8838.qmail@server16.citromail.hu> References: <20081219100959.8838.qmail@server16.citromail.hu> Message-ID: <1229686389.41849.19.camel@strangepork.mintel.co.uk> On Fri, 2008-12-19 at 11:09 +0100, Lazar Szilard wrote: > hi, > > > > I have a beginner quieston. > > I use FreeBSD 7.1-RC1 without X on my notebook. > > How can I configure my network to > > 1. use proxy to http or ftp connections (proxy address: (10.0.1.1:8080) > > or (on another place, with stong restrictions, but port 22 is open) > > 2. use ssh tunnel (in windows I've used socks5 proxy trough my server: ssh -D 7777 user@host.tld) > > > > where can I set these settings? > > best regards, > > indul > > To use a proxy with most applications, it is simply necessary to set the appropriate environment variables. Eg, I have a squid proxy running on the server 'proxy', port 3128, so I put the following in my .bashrc: export HTTP_PROXY=proxy:3128 export http_proxy=http://proxy:3128/ export ftp_proxy=http://proxy:3128/ To use an ssh tunnel, you already have the command right there.. I use a tiny rc script to manage my ssh tunnels, it is attached. Put in /usr/local/etc/rc.d and add the following settings to /etc/rc.conf proxy_tunnel_enable="YES" proxy_tunnel_remote_user="someone@somehost" You should also set up passwordless ssh authentication for root to the user@host you wish to use for proxying to, and then simply change your local users proxy settings. From noah at webclipping.com Fri Dec 19 03:46:12 2008 From: noah at webclipping.com (Noah Silverman) Date: Fri Dec 19 03:46:19 2008 Subject: Surf outside Internet through VPN Message-ID: Hello, I want to find a way to pass ALL traffic from my laptop THROUGH my office VPN and then out to the Internet. This is a "road warrior" setup. This gives me a few benefits: 1) I can check my email securely through VPN. 2) No matter where I am, I will always have the external IP of my VPN server when accessing the web. I have setup a VPN. Was able to get it working with either tun or tap interfaces. That part seems OK. Now what?? (I can see and connect to the VPN server with '10.0.8.1' easily. I can't see or connect to the outside world.) Do I need to add some kind of special route in the routing table? Would this be better as a tun or using a bridge through tap? Thanks, -N From freebsd at bitfreak.org Fri Dec 19 04:48:27 2008 From: freebsd at bitfreak.org (Darren Pilgrim) Date: Fri Dec 19 04:48:33 2008 Subject: Surf outside Internet through VPN In-Reply-To: References: Message-ID: <494B93E3.5020202@bitfreak.org> Noah Silverman wrote: > I want to find a way to pass ALL traffic from my laptop THROUGH my > office VPN and then out to the Internet. This is a "road warrior" > setup. This gives me a few benefits: 1) I can check my email securely > through VPN. 2) No matter where I am, I will always have the external > IP of my VPN server when accessing the web. > > I have setup a VPN. Was able to get it working with either tun or tap > interfaces. That part seems OK. > > Now what?? (I can see and connect to the VPN server with '10.0.8.1' > easily. I can't see or connect to the outside world.) Do I need to > add some kind of special route in the routing table? If you can talk to arbitrary hosts on your office network--not just the VPN server--setting your default router to the office's gateway will achieve what you want. From vanhu at FreeBSD.org Fri Dec 19 05:00:59 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Dec 19 05:01:05 2008 Subject: Surf outside Internet through VPN In-Reply-To: References: Message-ID: <20081219130344.GA38912@zeninc.net> On Fri, Dec 19, 2008 at 03:23:57AM -0800, Noah Silverman wrote: > Hello, Hi. > I want to find a way to pass ALL traffic from my laptop THROUGH my > office VPN and then out to the Internet. This is a "road warrior" > setup. This gives me a few benefits: 1) I can check my email securely > through VPN. 2) No matter where I am, I will always have the external > IP of my VPN server when accessing the web. > > I have setup a VPN. Was able to get it working with either tun or tap > interfaces. That part seems OK. Ok, I'll guess you're using an IPsec VPN. > Now what?? (I can see and connect to the VPN server with '10.0.8.1' > easily. I can't see or connect to the outside world.) Do I need to > add some kind of special route in the routing table? > > Would this be better as a tun or using a bridge through tap? If you're using a tun interface and can access your remote gate through the tunnel, you may just have to add a default route to this remote gate (warning: ensure you still have some static routes to access the public IP of the gate, so your tunnel won't match the default route, which is reachable through the tunnel....). You can also just use "simple" IPsec without gif, and you'll have SPD entries like: spdadd myip 0.0.0.0/0 any -P out ipsec esp/tunnel/mypublicIP-GatepublicIP/unique; for outgoing traffic (and the reverse SPD entry for incoming traffic). Please note that, for IPsec (and for IKE negociations), 0.0.0.0/0 does NOT means "any IP", it does REALLY means "the network with base address 0.0.0.0 and 0 bits of netmask". Yvan. From dunc at lemonia.org Fri Dec 19 05:30:14 2008 From: dunc at lemonia.org (Dunc) Date: Fri Dec 19 05:30:21 2008 Subject: Surf outside Internet through VPN In-Reply-To: <494B93E3.5020202@bitfreak.org> References: <494B93E3.5020202@bitfreak.org> Message-ID: <494B9A10.4020402@lemonia.org> Darren Pilgrim wrote: > Noah Silverman wrote: >> I want to find a way to pass ALL traffic from my laptop THROUGH my >> office VPN and then out to the Internet. This is a "road warrior" >> setup. This gives me a few benefits: 1) I can check my email >> securely through VPN. 2) No matter where I am, I will always have >> the external IP of my VPN server when accessing the web. >> >> I have setup a VPN. Was able to get it working with either tun or >> tap interfaces. That part seems OK. >> >> Now what?? (I can see and connect to the VPN server with '10.0.8.1' >> easily. I can't see or connect to the outside world.) Do I need to >> add some kind of special route in the routing table? > > If you can talk to arbitrary hosts on your office network--not just > the VPN server--setting your default router to the office's gateway > will achieve what you want. > _______________________________________________ If you meant the internal address of the office's gateway, then changing the default route to that means that you will no longer be able to reach the public IP of the VPN peer. What you need to do is, i) Add a host route to the VPN peer address, via your current default gateway on whatever network you happen to be on ii) Change your default route to be something on your office net that is willing to router traffic out the Internet for you. This potentially could the internal address of your office firewall, if it knows how to route back to you via the VPN terminating box. Alternatively just the other end of your tunnel, I'm guessing from the above that it's '10.0.8.1' If you're using OpenVPN, then the "redirect-gateway" directive tries to do the above for you. Cheers, Dunc From vova at fbsd.ru Fri Dec 19 05:33:02 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Dec 19 05:33:09 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <873agpk11i.fsf@kobe.laptop> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> Message-ID: <1229691231.1818.53.camel@localhost> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > > The arp-v2 changes have been committed into HEAD. > > Please report problems to me and Kip Macy. Wine is not build any more: ... cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c ipstats.c: In function 'getNumArpEntries': ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) ipstats.c:1253: error: (Each undeclared identifier is reported only once ipstats.c:1253: error: for each function it appears in.) ipstats.c: In function 'getArpTable': ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) ipstats.c:1311: warning: initialization makes integer from pointer without a cast gmake[2]: *** [ipstats.o] ?????? 1 gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' gmake[1]: *** [iphlpapi] ?????? 2 gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' gmake: *** [dlls] ?????? 2 -- Vladimir B. Grebenschikov vova@fbsd.ru From tevans.uk at googlemail.com Fri Dec 19 05:34:38 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Dec 19 05:34:49 2008 Subject: Surf outside Internet through VPN In-Reply-To: <20081219130344.GA38912@zeninc.net> References: <20081219130344.GA38912@zeninc.net> Message-ID: <1229693702.41849.47.camel@strangepork.mintel.co.uk> On Fri, 2008-12-19 at 14:03 +0100, VANHULLEBUS Yvan wrote: > > Please note that, for IPsec (and for IKE negociations), 0.0.0.0/0 does > NOT means "any IP", it does REALLY means "the network with base > address 0.0.0.0 and 0 bits of netmask". > > > Yvan. Could you define an IPv4 IP address that wouldn't be matched by that definition? IE - aren't they both the same thing? I might be being dense.. Cheers Tom From wawa at yandex-team.ru Fri Dec 19 06:08:36 2008 From: wawa at yandex-team.ru (Vladimir Ivanov) Date: Fri Dec 19 06:08:43 2008 Subject: Update of Yandex' SMBable em driver Message-ID: <494BA6A9.5090907@yandex-team.ru> Hi, We've published latest versions at http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.40.tar.gz http://people.yandex-team.ru/~wawa/em-6.9.6-RELENG7-yandex-1.36.2.8.tar.gz These revisions use mtx_trylock instead of mtx_lock in em_start(). Regards, -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- From ottk at zzz.ee Fri Dec 19 06:10:31 2008 From: ottk at zzz.ee (Ott =?utf-8?q?K=C3=B6stner?=) Date: Fri Dec 19 06:10:38 2008 Subject: FD_SETSIZE (too many open file descriptors) + BIND In-Reply-To: References: <200812171506.58607.ottk@zzz.ee> <200812171520.02823.ottk@zzz.ee> Message-ID: <200812191610.27715.ottk@zzz.ee> On Wednesday 17 December 2008 8:40:55 pm JINMEI Tatuya / ???? wrote: > At Wed, 17 Dec 2008 15:20:02 +0200, > Ott K?stner wrote: > > > named[63198]: socket: too many open file descriptors > > last message repeated 26 times > > > > Bind version is: BIND 9.4.2-P2 > > Please try BIND 9.4.3. Even with all attempts to mitigate the trouble > and with tweaking parameters, 9.4.2-P2 still has a fundamental > limitation on performance. It should work for the vast majority of > users, but you really need 9.4.3 if your server is very busy. However there is no FreeBSD port of BIND 9.4.3, manually installed 9.4.3 from sources...and... Yes, it *is* much better now. 'socket: too many open file descriptors' messages disappeared :) Now waiting for FreeBSD port to come into existence... Thank You! O.K. -- M??da oma inteneti kiirust / Test Your Internet speed http://tallinn.speedtest.net/ From ivoras at freebsd.org Fri Dec 19 06:30:32 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Dec 19 06:30:38 2008 Subject: IPv6 routing help? In-Reply-To: <200812190117.43337.max@love2party.net> References: <200812190033.01630.max@love2party.net> <200812190117.43337.max@love2party.net> Message-ID: <9bbcef730812190604p5567295al51e586c2be2b866a@mail.gmail.com> 2008/12/19 Max Laier : > On Friday 19 December 2008 01:11:51 Ivan Voras wrote: >> Max Laier wrote: >> > On the interface you are running rtadvd you need a global address out of >> > your stf prefix, e.g. 2002:aabb:ccdd:1::/64. Once you do that, >> > everything else should just fall into place. The client will configure >> > an address out of that prefix and adds a route via 2002:aabb:ccdd:1::/64. >> > This should get you going. >> >> Thanks, I understand now what I was doing wrong before. Actually 6to4 is >> very elegant. >> >> Another related question: if I understand it correctly, rtadvd should >> also be used for address autoconfiguration (like DHCP for IPv6, but not >> actually DHCP). I have it running with defaults (they look like they >> should do the right thing) and apparently it works as the client got the >> link-local address of the router as it's default IPv6 route, but I >> expected it would also automagically pick up the 2002:aabb:ccdd:1::/64 >> network when I assigned an address from it on the router and >> autoconfigure its own address. Maybe I'm expecting too much of it? > > It will, provided you properly assign an address on the NIC that is running > rtadvd. Thanks, it did! From praesentium at gmail.com Fri Dec 19 06:34:10 2008 From: praesentium at gmail.com (Jordy Dickinson) Date: Fri Dec 19 06:34:17 2008 Subject: Getting WPA2-PSK Message-ID: Hey, I've never used a mailing list before, so forgive me if I'm not doing this right. I'm trying to set up my network card, but I keep getting this error message. I type in this: ifconfig wi0 authmode wpa > And I get this: ieee80211_load_module: load the wlan_xauth module by hand for now. > ifconfig: SIOCS80211: Invalid argument > Can anybody tell me what I'm doing wrong? Thanks, Jordy From rpaulo at fnop.net Fri Dec 19 07:05:09 2008 From: rpaulo at fnop.net (Rui Paulo) Date: Fri Dec 19 07:05:16 2008 Subject: Getting WPA2-PSK In-Reply-To: References: Message-ID: On 19 Dec 2008, at 14:19, Jordy Dickinson wrote: > Hey, I've never used a mailing list before, so forgive me if I'm not > doing > this right. > > I'm trying to set up my network card, but I keep getting this error > message. > I type in this: > > ifconfig wi0 authmode wpa >> > > And I get this: > > ieee80211_load_module: load the wlan_xauth module by hand for now. >> ifconfig: SIOCS80211: Invalid argument >> > > Can anybody tell me what I'm doing wrong? > You're probably running a custom kernel without the wlan_xauth module built in. Either load it as a module or compile it in your kernel. You may also want to use wpa_supplicant instead. Regads, -- Rui Paulo From vanhu at FreeBSD.org Fri Dec 19 07:05:59 2008 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Fri Dec 19 07:06:07 2008 Subject: Surf outside Internet through VPN In-Reply-To: <1229693702.41849.47.camel@strangepork.mintel.co.uk> References: <20081219130344.GA38912@zeninc.net> <1229693702.41849.47.camel@strangepork.mintel.co.uk> Message-ID: <20081219150846.GA39267@zeninc.net> On Fri, Dec 19, 2008 at 01:35:02PM +0000, Tom Evans wrote: > On Fri, 2008-12-19 at 14:03 +0100, VANHULLEBUS Yvan wrote: > > > > Please note that, for IPsec (and for IKE negociations), 0.0.0.0/0 does > > NOT means "any IP", it does REALLY means "the network with base > > address 0.0.0.0 and 0 bits of netmask". > > > > > > Yvan. > > Could you define an IPv4 IP address that wouldn't be matched by that > definition? IE - aren't they both the same thing? I might be being > dense.. When setting up configurations, I often see people who put 0.0.0.0/0 as traffic endpoint one one side, and "something else" on the other side (either in racoon.conf's sainfo sections or in SPD traffic endpoints), and who think it will work. It won't. Of course, once you get such SPD entry, any packet wich matches the other network (myip as source in my previous example) will match the SPD. Yvan. From vlad at prokk.net Fri Dec 19 07:17:52 2008 From: vlad at prokk.net (Vladimir V. Kobal) Date: Fri Dec 19 07:18:00 2008 Subject: Panic on boot with em1 attached Message-ID: <004a01c961ec$ec136540$c43a2fc0$@net> Hello, System is a NAS and has two interfaces. Default route is on em0. The network consisting of 2k hosts is attached to the em1. 7.0-RELEASE, 7.1-BETA2, 7.1-RC1 has the same error. In the progress of boot (uptime 7 seconds) it is panicing: Slab at 0xffffff000152ef50, freei 2 = 0. panic: Duplicate free of item 0xffffff000152e200 from zone 0xffffff003bfd3000(mbuf_packet) If I detach em1 before boot, the system boots and works well, but after attaching em1 back constantly appears a messages like this: rtfree: 0xffffff000187f7c0 has 1 refs May be the cause of this warnings is connected to the cause of panic. Here is a backtrace: #0 doadump () at pcpu.h:195 #1 0xffffffff802cbc97 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xffffffff802cc13c in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:574 #3 0xffffffff805029a8 in uma_dbg_free (zone=Variable "zone" is not available. ) at ../../../vm/uma_dbg.c:302 #4 0xffffffff80501434 in uma_zfree_arg (zone=0xffffff003bfd3000, item=0xffffff000152e200, udata=0x0) at ../../../vm/uma_core.c:2265 #5 0xffffffff803237d9 in m_freem (mb=0x0) at mbuf.h:515 #6 0xffffffff803d39a1 in ip_fastforward (m=0xffffff000152e200) at ../../../netinet/ip_fastfwd.c:609 #7 0xffffffff8036ace6 in ether_demux (ifp=0xffffff0001257000, m=0xffffff000152e200) at ../../../net/if_ethersubr.c:770 #8 0xffffffff8036af62 in ether_input (ifp=0xffffff0001257000, m=0xffffff000152e200) at ../../../net/if_ethersubr.c:692 #9 0xffffffff801fe6f4 in em_rxeof (adapter=0xffffffff80c57000, count=99) at ../../../dev/e1000/if_em.c:4539 #10 0xffffffff801feb8b in em_handle_rxtx (context=Variable "context" is not available. ) at ../../../dev/e1000/if_em.c:1702 #11 0xffffffff80303481 in taskqueue_run (queue=0xffffff0001258600) at ../../../kern/subr_taskqueue.c:282 #12 0xffffffff8030363a in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at ../../../kern/subr_taskqueue.c:401 #13 0xffffffff802aa7ff in fork_exit (callout=0xffffffff803035e0 , arg=0xffffffff80c5b588, frame=0xffffffff9ead9c80) at ../../../kern/kern_fork.c:804 #14 0xffffffff805250e3 in fork_trampoline () at ../../../amd64/amd64/exception.S:455 Dump for the mbuf: 0xffffff000152e200: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e208: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e210: 0x10 0x68 0x53 0x01 0x00 0xff 0xff 0xff 0xffffff000152e218: 0x30 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0xffffff000152e220: 0x01 0x00 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e228: 0x00 0x70 0x25 0x01 0x00 0xff 0xff 0xff 0xffffff000152e230: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e238: 0x30 0x00 0x00 0x00 0x00 0x0f 0x00 0x00 0xffffff000152e240: 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e248: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e250: 0x00 0x68 0x53 0x01 0x00 0xff 0xff 0xff 0xffffff000152e258: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e260: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xffffff000152e268: 0x00 0x08 0x00 0x00 0xde 0xc0 0xad 0xde 0xffffff000152e270: 0x3c 0x00 0xfb 0x3b 0x00 0xff 0xff 0xff 0xffffff000152e278: 0x06 0x00 0x00 0x00 0xde 0xc0 0xad 0xde 0xffffff000152e280: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e288: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e290: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e298: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2a0: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2a8: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2b0: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2b8: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2c0: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2c8: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2d0: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2d8: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2e0: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2e8: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2f0: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde 0xffffff000152e2f8: 0xde 0xc0 0xad 0xde 0xde 0xc0 0xad 0xde I have a tcpdump file for the traffic on em1 during the boot but I can't work out the method of finding the matching packet to the mbuf. Is there any idea where the problem lies? Best regards, Vladimir Kobal From brooks at freebsd.org Fri Dec 19 08:45:36 2008 From: brooks at freebsd.org (Brooks Davis) Date: Fri Dec 19 08:45:42 2008 Subject: Getting WPA2-PSK In-Reply-To: References: Message-ID: <20081219164617.GC50722@lor.one-eyed-alien.net> On Fri, Dec 19, 2008 at 03:04:55PM +0000, Rui Paulo wrote: > > On 19 Dec 2008, at 14:19, Jordy Dickinson wrote: > >> Hey, I've never used a mailing list before, so forgive me if I'm not doing >> this right. >> >> I'm trying to set up my network card, but I keep getting this error >> message. >> I type in this: >> >> ifconfig wi0 authmode wpa >>> >> >> And I get this: >> >> ieee80211_load_module: load the wlan_xauth module by hand for now. >>> ifconfig: SIOCS80211: Invalid argument >>> >> >> Can anybody tell me what I'm doing wrong? >> > > You're probably running a custom kernel without the wlan_xauth module built > in. Either load it as a module or compile it in your kernel. > > You may also want to use wpa_supplicant instead. More specifically, setting "authmode wpa" with ifconfig will always be wrong (unless perhaps someday someone adds a suplicant to the kernel). If you want WPA to work, you must run wpa_supplicant. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081219/9b32debb/attachment.pgp From vova at fbsd.ru Fri Dec 19 09:04:32 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Dec 19 09:04:45 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <873agpk11i.fsf@kobe.laptop> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> Message-ID: <1229706267.85909.6.camel@localhost> On Mon, 2008-12-15 at 15:42 +0200, Giorgos Keramidas wrote: > On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > > Hi All, > > > > The arp-v2 changes have been committed into HEAD. > > Please report problems to me and Kip Macy. Nice, my host sends arp-reply about other hosts my host has MAC address 00:19:7d:8c:0b:44: 19:59:39.409151 00:13:e8:d5:0f:63 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.24.11.35 tell 10.24.11.42 >> it got broadcast arp request from some host 19:59:39.409163 00:19:7d:8c:0b:44 > 00:13:e8:d5:0f:63, ethertype ARP (0x0806), length 42: arp reply 10.24.11.35 is-at 00:13:e8:d5:0f:63 >> it replies - IP you seeking for is on your MAC address some OS do put entries based on such bogus arp reply on their arp tables Looks as serious problem of ARP stack. -- Vladimir B. Grebenschikov vova@fbsd.ru From qing.li at bluecoat.com Fri Dec 19 09:35:37 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Dec 19 09:35:44 2008 Subject: HEADSUP: arp-v2 has been committed References: <200812150634.mBF6YDVC060565@freefall.freebsd.org><873agpk11i.fsf@kobe.laptop> <1229706267.85909.6.camel@localhost> Message-ID: I checked in a fix earlier this morning, sync-up and give it a try. -- Qing Revision 1.188: download - view: text, markup, annotated - select for diffs Fri Dec 19 11:07:34 2008 UTC (6 hours, 26 minutes ago) by qingli Branches: MAIN CVS tags: HEAD Diff to: previous 1.187: preferred, colored Changes since revision 1.187: +52 -57 lines SVN rev 186317 on 2008-12-19 11:07:34Z by qingli The proxy-arp code was broken and responds to ARP requests for addresses that are not proxied locally. -----Original Message----- From: owner-freebsd-current@freebsd.org on behalf of Vladimir Grebenschikov Sent: Fri 12/19/2008 9:04 AM To: Qing Li Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed On Mon, 2008-12-15 at 15:42 +0200, Giorgos Keramidas wrote: > On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > > Hi All, > > > > The arp-v2 changes have been committed into HEAD. > > Please report problems to me and Kip Macy. Nice, my host sends arp-reply about other hosts my host has MAC address 00:19:7d:8c:0b:44: 19:59:39.409151 00:13:e8:d5:0f:63 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.24.11.35 tell 10.24.11.42 >> it got broadcast arp request from some host 19:59:39.409163 00:19:7d:8c:0b:44 > 00:13:e8:d5:0f:63, ethertype ARP (0x0806), length 42: arp reply 10.24.11.35 is-at 00:13:e8:d5:0f:63 >> it replies - IP you seeking for is on your MAC address some OS do put entries based on such bogus arp reply on their arp tables Looks as serious problem of ARP stack. -- Vladimir B. Grebenschikov vova@fbsd.ru _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From chodong2003 at yahoo.com Fri Dec 19 10:09:30 2008 From: chodong2003 at yahoo.com (richard lll) Date: Fri Dec 19 10:09:37 2008 Subject: Packet Loss Under FreeBSD 7.0 Message-ID: <889762.96728.qm@web58407.mail.re3.yahoo.com> Hi, I am new to FreeBSD and I am developing a program that does heavy use of UDP multicast over the LAN. This program is incurring 90-100 percent packet loss on FreeBSD. Packet loss occurs even when a I send just 3 packets. When I send 1000 packets I get 100% packet loss. netstat on FreeBSD shows all the packets, but none/few make it to my program. The program is single-source for FreeBSD, Linux and Solaris and neither Linux nor Solaris has anything like this level of packet loss. I am running a generic kernel, Intel P4, 512MB. I use a quad port SUN HME card 100T. I can telnet, ftp, etc. just fine. My guess is something is misconfigured in FreeBSD. Does anyone know what I need to tune? Thanks, /cho From cswiger at mac.com Fri Dec 19 11:46:36 2008 From: cswiger at mac.com (Chuck Swiger) Date: Fri Dec 19 11:46:47 2008 Subject: Packet Loss Under FreeBSD 7.0 In-Reply-To: <889762.96728.qm@web58407.mail.re3.yahoo.com> References: <889762.96728.qm@web58407.mail.re3.yahoo.com> Message-ID: On Dec 19, 2008, at 9:42 AM, richard lll wrote: > I am new to FreeBSD and I am developing a program that does heavy > use of UDP multicast over the LAN. This program is incurring 90-100 > percent packet loss on FreeBSD. Packet loss occurs even when a I > send just 3 packets. When I send 1000 packets I get 100% packet > loss. netstat on FreeBSD shows all the packets, but none/few make it > to my program. How are you sending your traffic? send() over a socket(), or via BPF or something else? Does adding something like a usleep(1000) call after each packet being sent do anything to help with the packet lossage? Regards, -- -Chuck From noah at webclipping.com Fri Dec 19 11:57:55 2008 From: noah at webclipping.com (Noah Silverman) Date: Fri Dec 19 11:58:02 2008 Subject: Surf outside Internet through VPN In-Reply-To: <494B93E3.5020202@bitfreak.org> References: <494B93E3.5020202@bitfreak.org> Message-ID: <1F763AC2-758E-44B7-A241-E50C1F96C6A5@webclipping.com> I'm not sure that would work. I have my openVPN assigning IPs from a private range, 10.8.0.0 to my laptop. My office gateway is from our ISP on a public IP 123.123.123.123. My guess is that somewhere on the VPN server, I need to configure some kind of route or bridge from the opvnp ip block to the public ip block?? On Dec 19, 2008, at 4:30 AM, Darren Pilgrim wrote: > Noah Silverman wrote: >> I want to find a way to pass ALL traffic from my laptop THROUGH my >> office VPN and then out to the Internet. This is a "road warrior" >> setup. This gives me a few benefits: 1) I can check my email >> securely through VPN. 2) No matter where I am, I will always have >> the external IP of my VPN server when accessing the web. >> I have setup a VPN. Was able to get it working with either tun or >> tap interfaces. That part seems OK. >> Now what?? (I can see and connect to the VPN server with >> '10.0.8.1' easily. I can't see or connect to the outside world.) >> Do I need to add some kind of special route in the routing table? > > If you can talk to arbitrary hosts on your office network--not just > the VPN server--setting your default router to the office's gateway > will achieve what you want. > From thompsa at FreeBSD.org Fri Dec 19 12:01:03 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Fri Dec 19 12:01:09 2008 Subject: Surf outside Internet through VPN In-Reply-To: References: Message-ID: <20081219200058.GA86470@citylink.fud.org.nz> On Fri, Dec 19, 2008 at 03:23:57AM -0800, Noah Silverman wrote: > Hello, > > I want to find a way to pass ALL traffic from my laptop THROUGH my office > VPN and then out to the Internet. This is a "road warrior" setup. This > gives me a few benefits: 1) I can check my email securely through VPN. 2) > No matter where I am, I will always have the external IP of my VPN server > when accessing the web. > > I have setup a VPN. Was able to get it working with either tun or tap > interfaces. That part seems OK. > > Now what?? (I can see and connect to the VPN server with '10.0.8.1' > easily. I can't see or connect to the outside world.) Do I need to add > some kind of special route in the routing table? > > Would this be better as a tun or using a bridge through tap? Have you considered just using a http/socks proxy?, it would do away with all the routing magic. Andrew From noah at webclipping.com Fri Dec 19 12:54:47 2008 From: noah at webclipping.com (Noah Silverman) Date: Fri Dec 19 12:54:55 2008 Subject: Surf outside Internet through VPN In-Reply-To: <20081219200058.GA86470@citylink.fud.org.nz> References: <20081219200058.GA86470@citylink.fud.org.nz> Message-ID: Thanks for all the replies. I think that I need to better explain what I'm trying to do.... My company has a small server farm that is co-located at a major ISP. In that farm we have a machine that acts as a small webserver and pop server. Since that webserver is already "exposed" to the public, I thought it would make a good choice as a VPN server for a few of our guys who travel and/or connect from home. Right now, I have openVPN working, certificates exchanged and signed, etc. I can remotely connect and setup a tunnel easily. I can ssh to the openVPN server using 10.0.8.1 and it works. I CAN'T surf the web or get outside the netblock of my openVPN. For this e-mail, lets assume the public IP of the webserver is 123.123.123.100 This was my plan: 1 )Setup openVPN on the webserver with a TUN interface. 2) Remote workers can then connect to the openVPN running on 123.123.123.100 3) Remote workers can now access our pop and smtp email at 10.0.8.1 (Address from openVPN.) 4) When Remote workers surf web or connect to other outside services, they appear to come from 123.123.123.100 (address of webserver.) 5) Remote workers need to access some "admin" pages on the webserver. Again, this should be easy as they could connect to 10.0.8.1 to get to the webserver through the VPN tunnel. We can then add rules to the webserver to only allow admin access from the 10.0.8.x block. 6) Remote workers can access services on our other servers through various firewalls because we have a simple rule in those firewalls allowing traffic in from 123.123.123.100. The "big picture" was to "standardize" the way remote workers connect, and to make sure all their traffic comes from the same IP address. That way we can manage rules for firewall, email relaying, mysql access, etc. Here are the key config settings for openVPN that I have setup now: proto udp dev tun server 10.0.8.0 255.255.255.0 push "route 10.0.8.0 255.255.255.0" push "redirect-gateway" client-to-client My guess is that I'm missing some very basic config line or routing setup. Here are some interesting observations: ############ On the client (remote laptop) I see some strange things in "netstat - rn" the first line is: Destination Gateway Flags Refs Use Netif Expire 0/1 10.0.8.5 UGSc 6 74 tun0 Why is the gateway coming in as "10.0.8.5"?? I thought my gateway would be 10.0.8.1 from openVPN. Why did it skip to "5" ############## On the webserver (openVPN host) "netstat -rn" gives me the following: Destination Gateway Flags Refs Use Netif Expire default 123.123.123.1 UGS 0 10514423 em0 10.0.8/24 10.0.8.2 UGS 0 436 tun0 Why is the gateway "10.0.8.2"?? Shouldn't it be "10.0.8.1"?? ############## On the webserver (openVPN host) an ifconfig shows some odd results tun0: flags=8051 mtu 1500 inet 10.0.8.1 --> 10.0.8.2 netmask 0xffffffff Opened by PID 52970 What is the reference to '10.0.8.2'?? I didn't put that in. Any and all help, suggestions, ideas, etc would be greatly appreciated!! Thanks!! -N On Dec 19, 2008, at 12:00 PM, Andrew Thompson wrote: > On Fri, Dec 19, 2008 at 03:23:57AM -0800, Noah Silverman wrote: >> Hello, >> >> I want to find a way to pass ALL traffic from my laptop THROUGH my >> office >> VPN and then out to the Internet. This is a "road warrior" setup. >> This >> gives me a few benefits: 1) I can check my email securely through >> VPN. 2) >> No matter where I am, I will always have the external IP of my VPN >> server >> when accessing the web. >> >> I have setup a VPN. Was able to get it working with either tun or >> tap >> interfaces. That part seems OK. >> >> Now what?? (I can see and connect to the VPN server with '10.0.8.1' >> easily. I can't see or connect to the outside world.) Do I need >> to add >> some kind of special route in the routing table? >> >> Would this be better as a tun or using a bridge through tap? > > Have you considered just using a http/socks proxy?, it would do away > with > all the routing magic. > > Andrew > _______________________________________________ > 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 remko at elvandar.org Fri Dec 19 13:00:03 2008 From: remko at elvandar.org (Remko Lodder) Date: Fri Dec 19 13:00:21 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <200812150634.mBF6YDVC060565@freefall.freebsd.org><873agpk11i.fsf@kobe.laptop> <1229706267.85909.6.camel@localhost> Message-ID: Hello, I for one, can confirm that the fix from this morning resolved my problems :-) Cheers remko On Dec 19, 2008, at 6:33 PM, Li, Qing wrote: > > I checked in a fix earlier this morning, sync-up and give it a try. > > -- Qing > > Revision 1.188: download - view: text, markup, annotated - select > for diffs > Fri Dec 19 11:07:34 2008 UTC (6 hours, 26 minutes ago) by qingli > Branches: MAIN > CVS tags: HEAD > Diff to: previous 1.187: preferred, colored > Changes since revision 1.187: +52 -57 lines > > SVN rev 186317 on 2008-12-19 11:07:34Z by qingli > > The proxy-arp code was broken and responds to ARP > requests for addresses that are not proxied locally. > > > > -----Original Message----- > From: owner-freebsd-current@freebsd.org on behalf of Vladimir > Grebenschikov > Sent: Fri 12/19/2008 9:04 AM > To: Qing Li > Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org > Subject: Re: HEADSUP: arp-v2 has been committed > > On Mon, 2008-12-15 at 15:42 +0200, Giorgos Keramidas wrote: >> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>> Hi All, >>> >>> The arp-v2 changes have been committed into HEAD. >>> Please report problems to me and Kip Macy. > > Nice, my host sends arp-reply about other hosts > > my host has MAC address 00:19:7d:8c:0b:44: > > 19:59:39.409151 00:13:e8:d5:0f:63 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: arp who-has 10.24.11.35 tell 10.24.11.42 >>> it got broadcast arp request from some host > > > 19:59:39.409163 00:19:7d:8c:0b:44 > 00:13:e8:d5:0f:63, ethertype ARP > (0x0806), length 42: arp reply 10.24.11.35 is-at 00:13:e8:d5:0f:63 >>> it replies - IP you seeking for is on your MAC address > > some OS do put entries based on such bogus arp reply on their arp > tables > > Looks as serious problem of ARP stack. > > -- > Vladimir B. Grebenschikov > vova@fbsd.ru > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From praesentium at gmail.com Fri Dec 19 14:33:19 2008 From: praesentium at gmail.com (Jordy Dickinson) Date: Fri Dec 19 14:33:25 2008 Subject: Getting WPA2-PSK In-Reply-To: <20081219164617.GC50722@lor.one-eyed-alien.net> References: <20081219164617.GC50722@lor.one-eyed-alien.net> Message-ID: On Fri, Dec 19, 2008 at 11:46 AM, Brooks Davis wrote: > On Fri, Dec 19, 2008 at 03:04:55PM +0000, Rui Paulo wrote: > > > > On 19 Dec 2008, at 14:19, Jordy Dickinson wrote: > > > >> Hey, I've never used a mailing list before, so forgive me if I'm not > doing > >> this right. > >> > >> I'm trying to set up my network card, but I keep getting this error > >> message. > >> I type in this: > >> > >> ifconfig wi0 authmode wpa > >>> > >> > >> And I get this: > >> > >> ieee80211_load_module: load the wlan_xauth module by hand for now. > >>> ifconfig: SIOCS80211: Invalid argument > >>> > >> > >> Can anybody tell me what I'm doing wrong? > >> > > > > You're probably running a custom kernel without the wlan_xauth module > built > > in. Either load it as a module or compile it in your kernel. > > > > You may also want to use wpa_supplicant instead. > > More specifically, setting "authmode wpa" with ifconfig will always be > wrong (unless perhaps someday someone adds a suplicant to the kernel). > If you want WPA to work, you must run wpa_supplicant. > > -- Brooks So how do I use wpa_supplicant? I've installed it on my machine already, and the man pages are gibberish to me. Also, is there a way to make the mailing list stop sending me emails that I'm not part of? From brooks at freebsd.org Fri Dec 19 14:40:33 2008 From: brooks at freebsd.org (Brooks Davis) Date: Fri Dec 19 14:40:40 2008 Subject: Getting WPA2-PSK In-Reply-To: References: <20081219164617.GC50722@lor.one-eyed-alien.net> Message-ID: <20081219224116.GE50722@lor.one-eyed-alien.net> On Fri, Dec 19, 2008 at 05:33:17PM -0500, Jordy Dickinson wrote: > On Fri, Dec 19, 2008 at 11:46 AM, Brooks Davis wrote: > > > On Fri, Dec 19, 2008 at 03:04:55PM +0000, Rui Paulo wrote: > > > > > > On 19 Dec 2008, at 14:19, Jordy Dickinson wrote: > > > > > >> Hey, I've never used a mailing list before, so forgive me if I'm not > > doing > > >> this right. > > >> > > >> I'm trying to set up my network card, but I keep getting this error > > >> message. > > >> I type in this: > > >> > > >> ifconfig wi0 authmode wpa > > >>> > > >> > > >> And I get this: > > >> > > >> ieee80211_load_module: load the wlan_xauth module by hand for now. > > >>> ifconfig: SIOCS80211: Invalid argument > > >>> > > >> > > >> Can anybody tell me what I'm doing wrong? > > >> > > > > > > You're probably running a custom kernel without the wlan_xauth module > > built > > > in. Either load it as a module or compile it in your kernel. > > > > > > You may also want to use wpa_supplicant instead. > > > > More specifically, setting "authmode wpa" with ifconfig will always be > > wrong (unless perhaps someday someone adds a suplicant to the kernel). > > If you want WPA to work, you must run wpa_supplicant. > > > > -- Brooks > > > So how do I use wpa_supplicant? I've installed it on my machine already, and > the man pages are gibberish to me. You have to add appropriate entries to /etc/wpa_supplicant.conf for your network. See the examples in the default file and the wpa_supplicant.conf manpage for details. You would then add WPA to your ifconfig_wi0 line in /etc/rc.conf. However, even if you do this, you will not actually be able to use WPA because wi(4) devices only support WEP (I missed that you were running wi(4) before). If you have a WPA encrypted network you will need to get another card. > Also, is there a way to make the mailing list stop sending me emails that > I'm not part of? You can not subscribe to the list. Since you have pretty basic questions you might consider asking the freebsd-questions list. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081219/4f5836db/attachment.pgp From sam at freebsd.org Fri Dec 19 15:16:14 2008 From: sam at freebsd.org (Sam Leffler) Date: Fri Dec 19 15:16:20 2008 Subject: Getting WPA2-PSK In-Reply-To: <20081219224116.GE50722@lor.one-eyed-alien.net> References: <20081219164617.GC50722@lor.one-eyed-alien.net> <20081219224116.GE50722@lor.one-eyed-alien.net> Message-ID: <494C2B3D.40102@freebsd.org> Brooks Davis wrote: > On Fri, Dec 19, 2008 at 05:33:17PM -0500, Jordy Dickinson wrote: > >> On Fri, Dec 19, 2008 at 11:46 AM, Brooks Davis wrote: >> >> >>> On Fri, Dec 19, 2008 at 03:04:55PM +0000, Rui Paulo wrote: >>> >>>> On 19 Dec 2008, at 14:19, Jordy Dickinson wrote: >>>> >>>> >>>>> Hey, I've never used a mailing list before, so forgive me if I'm not >>>>> >>> doing >>> >>>>> this right. >>>>> >>>>> I'm trying to set up my network card, but I keep getting this error >>>>> message. >>>>> I type in this: >>>>> >>>>> ifconfig wi0 authmode wpa >>>>> >>>>> And I get this: >>>>> >>>>> ieee80211_load_module: load the wlan_xauth module by hand for now. >>>>> >>>>>> ifconfig: SIOCS80211: Invalid argument >>>>>> >>>>>> >>>>> Can anybody tell me what I'm doing wrong? >>>>> >>>>> >>>> You're probably running a custom kernel without the wlan_xauth module >>>> >>> built >>> >>>> in. Either load it as a module or compile it in your kernel. >>>> >>>> You may also want to use wpa_supplicant instead. >>>> >>> More specifically, setting "authmode wpa" with ifconfig will always be >>> wrong (unless perhaps someday someone adds a suplicant to the kernel). >>> If you want WPA to work, you must run wpa_supplicant. >>> >>> -- Brooks >>> >> So how do I use wpa_supplicant? I've installed it on my machine already, and >> the man pages are gibberish to me. >> > > You have to add appropriate entries to /etc/wpa_supplicant.conf for your > network. See the examples in the default file and the wpa_supplicant.conf > manpage for details. You would then add WPA to your ifconfig_wi0 line in > /etc/rc.conf. However, even if you do this, you will not actually be able to > use WPA because wi(4) devices only support WEP (I missed that you were running > wi(4) before). If you have a WPA encrypted network you will need to get > another card. > Depends if he's running HEAD or something older. HEAD supports WPA w/ wi but only for Intersil cards w/ firmware rev >= 1.7. > >> Also, is there a way to make the mailing list stop sending me emails that >> I'm not part of? >> > > You can not subscribe to the list. > > Since you have pretty basic questions you might consider asking the > freebsd-questions list. > > There's also a section in the handbook that talks about setting up wireless network configs. Sam From fernercc at gmail.com Sat Dec 20 00:00:12 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Sat Dec 20 00:00:19 2008 Subject: sending arbitrary UDP packets from kernel module Message-ID: <1229738406.5614.17.camel@mobiliare.Belkin> So i have done some research and reading and found that i need to call either udp_send or udp_output. Can anyone help me out with providing the proper arguments to these functions so i may call them and send arbitrary UDP packets from a kernel module? Thanks everyone :) static int udp_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *addr, struct mbuf *control, struct thread *td); From ivoras at freebsd.org Sat Dec 20 06:30:07 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Dec 20 06:30:14 2008 Subject: Update of Yandex' SMBable em driver In-Reply-To: <494BA6A9.5090907@yandex-team.ru> References: <494BA6A9.5090907@yandex-team.ru> Message-ID: Vladimir Ivanov wrote: > Hi, > > We've published latest versions at > > http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.40.tar.gz > http://people.yandex-team.ru/~wawa/em-6.9.6-RELENG7-yandex-1.36.2.8.tar.gz > > These revisions use mtx_trylock instead of mtx_lock in em_start(). Thank you! Why the two versions? Is the first one for -CURRENT? (It looks like it would be interesting to try it on CURRENT with some ongoing SMP TCP work) -------------- 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/20081220/ef61b5d4/signature.pgp From sem at FreeBSD.org Sat Dec 20 08:47:27 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Sat Dec 20 08:47:59 2008 Subject: Update of Yandex' SMBable em driver In-Reply-To: References: <494BA6A9.5090907@yandex-team.ru> Message-ID: <494D219A.4040601@FreeBSD.org> Ivan Voras ?????: > Vladimir Ivanov wrote: >> Hi, >> >> We've published latest versions at >> >> http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.40.tar.gz >> http://people.yandex-team.ru/~wawa/em-6.9.6-RELENG7-yandex-1.36.2.8.tar.gz >> >> These revisions use mtx_trylock instead of mtx_lock in em_start(). > > Thank you! > > Why the two versions? Is the first one for -CURRENT? > > (It looks like it would be interesting to try it on CURRENT with some > ongoing SMP TCP work) > Nope. The first one for RELENG_6. -- Dixi. Sem. From Michael.Tuexen at lurchi.franken.de Sat Dec 20 13:31:43 2008 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Sat Dec 20 13:31:50 2008 Subject: Checksum offloading Message-ID: Dear all, I'm currently analyzing how TCP/UDP checksum offloading works to find the best way to add SCTP checksum offloading. sys/mbuf.h has constants: #define CSUM_IP 0x0001 /* will csum IP */ #define CSUM_TCP 0x0002 /* will csum TCP */ #define CSUM_UDP 0x0004 /* will csum UDP */ which are used to signal which offloading is supported by the drive. But, if I understand the code correctly, this only applies to UDP/IPv4 and TCP/IPv4. What about IPv6? Would this require flags like CSUM_TCP6 and CSUM_UDP6 to signal that also offloading of UDP/IPv6 and TCP/IPv6 is supported? I'm asking this because we want to add CRC offloading for SCTP/IPv4 and SCTP/IPv6. We could only add one flag CSUM_SCTP and use it for IPv4 and IPv6 ar two flags CSUM_SCTP4 and CSUM_SCTP6... Best regards Michael From gerald at pfeifer.com Sat Dec 20 21:33:53 2008 From: gerald at pfeifer.com (Gerald Pfeifer) Date: Sat Dec 20 21:34:00 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <1229691231.1818.53.camel@localhost> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> Message-ID: The code in question on the Wine side is #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far as I can see. If the arp-v2 update now made us incompatible both with earlier versions of FreeBSD and Linux, that sounds like something that should be fixed (instead of hacking applications like Wine). On the other hand, the commit message at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h explicitly says The change in design obsoletes the semantics of RTF_CLONING, RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications such as "arp" and "ndp" have been modified to reflect those changes. so I guess it's not so easy. How many other ports are affected? What shall we do on the Wine front? Simply #ifdef-ing out the code in question may not be the best of ideas, either. :-( Gerald On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: > On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > >>> The arp-v2 changes have been committed into HEAD. >>> Please report problems to me and Kip Macy. > > Wine is not build any more: > > ... > cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c > ipstats.c: In function 'getNumArpEntries': > ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) > ipstats.c:1253: error: (Each undeclared identifier is reported only once > ipstats.c:1253: error: for each function it appears in.) > ipstats.c: In function 'getArpTable': > ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) > ipstats.c:1311: warning: initialization makes integer from pointer without a cast > gmake[2]: *** [ipstats.o] ?????? 1 > gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' > gmake[1]: *** [iphlpapi] ?????? 2 > gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' > gmake: *** [dlls] ?????? 2 > > -- Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ From kip.macy at gmail.com Sat Dec 20 23:00:19 2008 From: kip.macy at gmail.com (Kip Macy) Date: Sat Dec 20 23:00:31 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> Message-ID: <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> The flag is not needed. It is only possible to retrieve arp entries by way of sysctl. The converse of this is you no longer need to grab all the entries in the routing table and look at each one to determine which are cloned routes (dynamic host routes) which contain ARP entries. -Kip On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer wrote: > The code in question on the Wine side is > > #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) > int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > > and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far > as I can see. > > If the arp-v2 update now made us incompatible both with earlier versions > of FreeBSD and Linux, that sounds like something that should be fixed > (instead of hacking applications like Wine). > > On the other hand, the commit message at > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h > explicitly says > The change in design obsoletes the semantics of RTF_CLONING, > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications > such as "arp" and "ndp" have been modified to reflect those changes. > so I guess it's not so easy. > > How many other ports are affected? > > What shall we do on the Wine front? Simply #ifdef-ing out the code in > question may not be the best of ideas, either. :-( > > Gerald > > On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >> >>>> The arp-v2 changes have been committed into HEAD. >>>> Please report problems to me and Kip Macy. >> >> Wine is not build any more: >> >> ... >> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c >> ipstats.c: In function 'getNumArpEntries': >> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) >> ipstats.c:1253: error: (Each undeclared identifier is reported only once >> ipstats.c:1253: error: for each function it appears in.) >> ipstats.c: In function 'getArpTable': >> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) >> ipstats.c:1311: warning: initialization makes integer from pointer without a cast >> gmake[2]: *** [ipstats.o] ?????? 1 >> gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >> gmake[1]: *** [iphlpapi] ?????? 2 >> gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >> gmake: *** [dlls] ?????? 2 >> >> > > -- > Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ > _______________________________________________ > 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" > -- Als die Nazis die Kommunisten holten, habe ich geschwiegen; ich war ja kein Kommunist. Als sie die Sozialdemokraten einsperrten, habe ich geschwiegen; ich war ja kein Sozialdemokrat. Als sie die Gewerkschafter holten, habe ich nicht protestiert; ich war ja kein Gewerkschafter. Als sie die Juden holten, habe ich geschwiegen; ich war ja kein Jude. Als sie mich holten, gab es keinen mehr, der protestieren konnte. From erwin at FreeBSD.org Sun Dec 21 04:51:23 2008 From: erwin at FreeBSD.org (Erwin Lansing) Date: Sun Dec 21 04:51:35 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> Message-ID: <20081221125120.GO23166@droso.net> On Sun, Dec 21, 2008 at 06:01:35AM +0100, Gerald Pfeifer wrote: > The code in question on the Wine side is > > #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) > int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > > and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far > as I can see. > > If the arp-v2 update now made us incompatible both with earlier versions > of FreeBSD and Linux, that sounds like something that should be fixed > (instead of hacking applications like Wine). > > On the other hand, the commit message at > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h > explicitly says > The change in design obsoletes the semantics of RTF_CLONING, > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications > such as "arp" and "ndp" have been modified to reflect those changes. > so I guess it's not so easy. > > How many other ports are affected? > The latest full run with HEAD from a few days back hasn't quite finished yet, so there might turn up a few more, but so far it's just a handful: net/libdnet devel/libpdel net-mgmt/net-snmp net/netwib net/p5-Net-RawIP net-mgmt/net-snmp4 emulators/wine Cheers, -erwin -- Erwin Lansing http://droso.org erwin@FreeBSD.org You are now free to move around the cabin erwin@aauug.dk -------------- 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/20081221/7d9de8f1/attachment.pgp From hartmut.brandt at dlr.de Sun Dec 21 08:53:27 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Sun Dec 21 08:53:36 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> Message-ID: <494E7481.1090606@dlr.de> Kip Macy wrote: > The flag is not needed. It is only possible to retrieve arp entries by > way of sysctl. The converse of this is you no longer need to grab all > the entries in the routing table and look at each one to determine > which are cloned routes (dynamic host routes) which contain ARP > entries. Does this mean that the snmp daemon cannot monitor the arp entries through the routing socket anymore? This would be a performance issue, since it would have to fetch the ARP table from the kernel each time it is asked for. Now it refreshes the table only if it is older than 30 seconds and in the mean time monitors routing messages. harti > > -Kip > > On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer wrote: >> The code in question on the Wine side is >> >> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >> >> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far >> as I can see. >> >> If the arp-v2 update now made us incompatible both with earlier versions >> of FreeBSD and Linux, that sounds like something that should be fixed >> (instead of hacking applications like Wine). >> >> On the other hand, the commit message at >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h >> explicitly says >> The change in design obsoletes the semantics of RTF_CLONING, >> RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications >> such as "arp" and "ndp" have been modified to reflect those changes. >> so I guess it's not so easy. >> >> How many other ports are affected? >> >> What shall we do on the Wine front? Simply #ifdef-ing out the code in >> question may not be the best of ideas, either. :-( >> >> Gerald >> >> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>> >>>>> The arp-v2 changes have been committed into HEAD. >>>>> Please report problems to me and Kip Macy. >>> Wine is not build any more: >>> >>> ... >>> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c >>> ipstats.c: In function 'getNumArpEntries': >>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) >>> ipstats.c:1253: error: (Each undeclared identifier is reported only once >>> ipstats.c:1253: error: for each function it appears in.) >>> ipstats.c: In function 'getArpTable': >>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) >>> ipstats.c:1311: warning: initialization makes integer from pointer without a cast >>> gmake[2]: *** [ipstats.o] ?????? 1 >>> gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>> gmake[1]: *** [iphlpapi] ?????? 2 >>> gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>> gmake: *** [dlls] ?????? 2 >>> >>> >> -- >> Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ >> _______________________________________________ >> 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 nork at FreeBSD.org Sun Dec 21 10:16:28 2008 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Sun Dec 21 10:16:40 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <20081221125120.GO23166@droso.net> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <20081221125120.GO23166@droso.net> Message-ID: <20081222031625.63645f78.nork@FreeBSD.org> Hi Kip&Erwin! On Sun, 21 Dec 2008 13:51:21 +0100 Erwin Lansing wrote: > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications > > such as "arp" and "ndp" have been modified to reflect those changes. > > so I guess it's not so easy. > > How many other ports are affected? > The latest full run with HEAD from a few days back hasn't quite finished > yet, so there might turn up a few more, but so far it's just a handful: > net/libdnet > devel/libpdel > net-mgmt/net-snmp > net/netwib > net/p5-Net-RawIP > net-mgmt/net-snmp4 > emulators/wine Oh, just time! I'm having a trouble about this issue of devel/libpdel. So I fixed this issue of devel/libpdel. But I don't know that the attached patches are good. So please review these. -------------- next part -------------- --- net/if_arp.c.orig 2005-01-22 06:02:02.000000000 +0900 +++ net/if_arp.c 2008-12-22 02:49:58.000000000 +0900 @@ -124,7 +124,11 @@ mib[2] = 0; mib[3] = AF_INET; mib[4] = NET_RT_FLAGS; +#ifdef RTF_LLINFO mib[5] = RTF_LLINFO; +#else + mib[5] = 0; +#endif if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) return (-1); needed += 128; @@ -227,9 +231,14 @@ sdl = (struct sockaddr_dl *)(void *) (ROUNDUP(sin->sin_len) + (char *)sin); if (sin->sin_addr.s_addr == sin_m.sin_addr.s_addr) { +#ifdef RTF_LLINFO if (sdl->sdl_family == AF_LINK && (rtm->rtm_flags & (RTF_LLINFO|RTF_GATEWAY)) == RTF_LLINFO) { +#else + if (sdl->sdl_family == AF_LINK && + !(rtm->rtm_flags & RTF_GATEWAY)) { +#endif switch (sdl->sdl_type) { case IFT_ETHER: case IFT_FDDI: -------------- next part -------------- --- net/uroute.c.orig 2005-01-22 06:02:03.000000000 +0900 +++ net/uroute.c 2008-12-22 02:53:23.000000000 +0900 @@ -74,9 +74,15 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) #define ADVANCE(x, n) ((x) += ROUNDUP((n)->sa_len)) +#ifdef RTF_LLINFO #define WRITABLE_FLAGS (RTF_STATIC | RTF_LLINFO | RTF_REJECT | RTF_BLACKHOLE \ | RTF_PROTO1 | RTF_PROTO2 | RTF_CLONING \ | RTF_XRESOLVE | RTF_UP | RTF_GATEWAY) +#else +#define WRITABLE_FLAGS (RTF_STATIC | RTF_REJECT | RTF_BLACKHOLE \ + | RTF_PROTO1 | RTF_PROTO2 | RTF_CLONING \ + | RTF_XRESOLVE | RTF_UP | RTF_GATEWAY) +#endif struct route_flag { const char *name; From sam at freebsd.org Sun Dec 21 10:47:57 2008 From: sam at freebsd.org (Sam Leffler) Date: Sun Dec 21 10:48:03 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <494E7481.1090606@dlr.de> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> <494E7481.1090606@dlr.de> Message-ID: <494E8F5B.3060205@freebsd.org> Hartmut Brandt wrote: > Kip Macy wrote: >> The flag is not needed. It is only possible to retrieve arp entries by >> way of sysctl. The converse of this is you no longer need to grab all >> the entries in the routing table and look at each one to determine >> which are cloned routes (dynamic host routes) which contain ARP >> entries. > > Does this mean that the snmp daemon cannot monitor the arp entries > through the routing socket anymore? This would be a performance issue, > since it would have to fetch the ARP table from the kernel each time > it is asked for. Now it refreshes the table only if it is older than > 30 seconds and in the mean time monitors routing messages. If this really becomes an issue you could add a generation # to the arp table and watch for changes to trigger an update. Alternatively it's possible to push the arp table bits through the routing socket but that would likely require more work. We could also define new arp-specific msgs; e.g. to track changes (or just reuse the old msg format). Doing this however perpetuates the routing socket as a kitchen-sink-kinda mechanism--at some point it's worth creating an entirely new path for info like this with a proper TLV-style protocol and support for features like filtering. Sam > > harti > >> >> -Kip >> >> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer >> wrote: >>> The code in question on the Wine side is >>> >>> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >>> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >>> >>> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far >>> as I can see. >>> >>> If the arp-v2 update now made us incompatible both with earlier >>> versions >>> of FreeBSD and Linux, that sounds like something that should be fixed >>> (instead of hacking applications like Wine). >>> >>> On the other hand, the commit message at >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h >>> explicitly says >>> The change in design obsoletes the semantics of RTF_CLONING, >>> RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications >>> such as "arp" and "ndp" have been modified to reflect those changes. >>> so I guess it's not so easy. >>> >>> How many other ports are affected? >>> >>> What shall we do on the Wine front? Simply #ifdef-ing out the code in >>> question may not be the best of ideas, either. :-( >>> >>> Gerald >>> >>> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >>>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>>> >>>>>> The arp-v2 changes have been committed into HEAD. >>>>>> Please report problems to me and Kip Macy. >>>> Wine is not build any more: >>>> >>>> ... >>>> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ >>>> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >>>> -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith >>>> -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o >>>> ipstats.c >>>> ipstats.c: In function 'getNumArpEntries': >>>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this >>>> function) >>>> ipstats.c:1253: error: (Each undeclared identifier is reported only >>>> once >>>> ipstats.c:1253: error: for each function it appears in.) >>>> ipstats.c: In function 'getArpTable': >>>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this >>>> function) >>>> ipstats.c:1311: warning: initialization makes integer from pointer >>>> without a cast >>>> gmake[2]: *** [ipstats.o] ?????? 1 >>>> gmake[2]: Leaving directory >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>>> gmake[1]: *** [iphlpapi] ?????? 2 >>>> gmake[1]: Leaving directory >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>>> gmake: *** [dlls] ?????? 2 >>>> >>>> >>> -- >>> Gerald (Jerry) Pfeifer gerald@pfeifer.com >>> http://www.pfeifer.com/gerald/ >>> _______________________________________________ >>> 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From qing.li at bluecoat.com Sun Dec 21 10:54:34 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Dec 21 10:54:41 2008 Subject: HEADSUP: arp-v2 has been committed Message-ID: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Yes, at least in the IPv4 case, I still generate the routing messages whenever entries are modified, so you can still wait for notifications on the routing socket. One should check for the address family AF_LINK type instead of checking for RTF_LLINFO flag. It's an over sight this note was not attached to the commit message. There are two locations in ND6 where I temporarily disabled rtmsg generation pending further investigation. I have a note-to-self for that in the code comment. Since only ARP entries are returned, you are in fact getting some performance gain. The userland application should also be simplified a little because the list walking code does not have to check for non-ARP entries. -- Qing -----Original Message----- From: Hartmut Brandt Sent: Sunday, December 21, 2008 8:54 AM To: Kip Macy Cc: Vladimir Grebenschikov ; Qing Li ; freebsd-net@freebsd.org ; Gerald Pfeifer ; freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed Kip Macy wrote: > The flag is not needed. It is only possible to retrieve arp entries by > way of sysctl. The converse of this is you no longer need to grab all > the entries in the routing table and look at each one to determine > which are cloned routes (dynamic host routes) which contain ARP > entries. Does this mean that the snmp daemon cannot monitor the arp entries through the routing socket anymore? This would be a performance issue, since it would have to fetch the ARP table from the kernel each time it is asked for. Now it refreshes the table only if it is older than 30 seconds and in the mean time monitors routing messages. harti > > -Kip > > On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer wrote: >> The code in question on the Wine side is >> >> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >> >> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far >> as I can see. >> >> If the arp-v2 update now made us incompatible both with earlier versions >> of FreeBSD and Linux, that sounds like something that should be fixed >> (instead of hacking applications like Wine). >> >> On the other hand, the commit message at >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h >> explicitly says >> The change in design obsoletes the semantics of RTF_CLONING, >> RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications >> such as "arp" and "ndp" have been modified to reflect those changes. >> so I guess it's not so easy. >> >> How many other ports are affected? >> >> What shall we do on the Wine front? Simply #ifdef-ing out the code in >> question may not be the best of ideas, either. :-( >> >> Gerald >> >> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>> >>>>> The arp-v2 changes have been committed into HEAD. >>>>> Please report problems to me and Kip Macy. >>> Wine is not build any more: >>> >>> ... >>> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c >>> ipstats.c: In function 'getNumArpEntries': >>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) >>> ipstats.c:1253: error: (Each undeclared identifier is reported only once >>> ipstats.c:1253: error: for each function it appears in.) >>> ipstats.c: In function 'getArpTable': >>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) >>> ipstats.c:1311: warning: initialization makes integer from pointer without a cast >>> gmake[2]: *** [ipstats.o] ?????? 1 >>> gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>> gmake[1]: *** [iphlpapi] ?????? 2 >>> gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>> gmake: *** [dlls] ?????? 2 >>> >>> >> -- >> Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ >> _______________________________________________ >> 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 qing.li at bluecoat.com Sun Dec 21 11:09:56 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Dec 21 11:10:04 2008 Subject: HEADSUP: arp-v2 has been committed Message-ID: <561201c9639f$b096ac5c$7202020a@internal.cacheflow.com> I am not entirely sure if that piece of code fragment you referred to is OS agnostic. This code is very similar to another piece of code in mibII at.c code where it checks for whether RTF_LLINFO is defined, however, there is inconsistency in enforcement throughout that file. So far in the reported cases the code in question requires a simple removal of that flag bit. One could go a little further and remove some dead code. I am curious if there is a better approach to compatibility without having to re-introduce RTF_LLINFO flag. -- Qing -----Original Message----- From: Gerald Pfeifer Sent: Sunday, December 21, 2008 4:06 AM To: Vladimir Grebenschikov Cc: Qing Li ; freebsd-current@freebsd.org ; freebsd-net@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed The code in question on the Wine side is #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far as I can see. If the arp-v2 update now made us incompatible both with earlier versions of FreeBSD and Linux, that sounds like something that should be fixed (instead of hacking applications like Wine). On the other hand, the commit message at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h explicitly says The change in design obsoletes the semantics of RTF_CLONING, RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications such as "arp" and "ndp" have been modified to reflect those changes. so I guess it's not so easy. How many other ports are affected? What shall we do on the Wine front? Simply #ifdef-ing out the code in question may not be the best of ideas, either. :-( Gerald On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: > On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: > >>> The arp-v2 changes have been committed into HEAD. >>> Please report problems to me and Kip Macy. > > Wine is not build any more: > > ... > cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c > ipstats.c: In function 'getNumArpEntries': > ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) > ipstats.c:1253: error: (Each undeclared identifier is reported only once > ipstats.c:1253: error: for each function it appears in.) > ipstats.c: In function 'getArpTable': > ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) > ipstats.c:1311: warning: initialization makes integer from pointer without a cast > gmake[2]: *** [ipstats.o] ?????? 1 > gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' > gmake[1]: *** [iphlpapi] ?????? 2 > gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' > gmake: *** [dlls] ?????? 2 > > -- Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From julian at elischer.org Sun Dec 21 12:17:11 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Dec 21 12:17:19 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <494E7481.1090606@dlr.de> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> <494E7481.1090606@dlr.de> Message-ID: <494EA44E.4030303@elischer.org> Hartmut Brandt wrote: > Kip Macy wrote: >> The flag is not needed. It is only possible to retrieve arp entries by >> way of sysctl. The converse of this is you no longer need to grab all >> the entries in the routing table and look at each one to determine >> which are cloned routes (dynamic host routes) which contain ARP >> entries. > > Does this mean that the snmp daemon cannot monitor the arp entries > through the routing socket anymore? This would be a performance issue, > since it would have to fetch the ARP table from the kernel each time it > is asked for. Now it refreshes the table only if it is older than 30 > seconds and in the mean time monitors routing messages. this is one of the things that worried me abuot the arp change, which is is that the change itself is fine but that I had no idea if LLINFO was BSD specific or if other ports and 3rd party code would rely on the connection between routing and ARP. maybe ARP activity should produce routing socket events. and maybe teh output should synthesize the missing entries. > > harti > >> >> -Kip >> >> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer >> wrote: >>> The code in question on the Wine side is >>> >>> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >>> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >>> >>> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far >>> as I can see. >>> >>> If the arp-v2 update now made us incompatible both with earlier versions >>> of FreeBSD and Linux, that sounds like something that should be fixed >>> (instead of hacking applications like Wine). >>> >>> On the other hand, the commit message at >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h >>> explicitly says >>> The change in design obsoletes the semantics of RTF_CLONING, >>> RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications >>> such as "arp" and "ndp" have been modified to reflect those changes. >>> so I guess it's not so easy. >>> >>> How many other ports are affected? >>> >>> What shall we do on the Wine front? Simply #ifdef-ing out the code in >>> question may not be the best of ideas, either. :-( >>> >>> Gerald >>> >>> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >>>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>>> >>>>>> The arp-v2 changes have been committed into HEAD. >>>>>> Please report problems to me and Kip Macy. >>>> Wine is not build any more: >>>> >>>> ... >>>> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ >>>> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >>>> -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith >>>> -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o >>>> ipstats.c >>>> ipstats.c: In function 'getNumArpEntries': >>>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this >>>> function) >>>> ipstats.c:1253: error: (Each undeclared identifier is reported only >>>> once >>>> ipstats.c:1253: error: for each function it appears in.) >>>> ipstats.c: In function 'getArpTable': >>>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this >>>> function) >>>> ipstats.c:1311: warning: initialization makes integer from pointer >>>> without a cast >>>> gmake[2]: *** [ipstats.o] ?????? 1 >>>> gmake[2]: Leaving directory >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>>> gmake[1]: *** [iphlpapi] ?????? 2 >>>> gmake[1]: Leaving directory >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>>> gmake: *** [dlls] ?????? 2 >>>> >>>> >>> -- >>> Gerald (Jerry) Pfeifer gerald@pfeifer.com >>> http://www.pfeifer.com/gerald/ >>> _______________________________________________ >>> 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 qing.li at bluecoat.com Sun Dec 21 15:47:48 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Dec 21 15:47:55 2008 Subject: HEADSUP: arp-v2 has been committed References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> <494E7481.1090606@dlr.de> <494EA44E.4030303@elischer.org> Message-ID: In earlier versions I had the kernel returning RTF_LLINFO back to the calling applications to provide a bit of compatibility. It's fairly straightforward for me to put that code back in. The change is tiny in the application in majority of the cases that I have seen. If these flags are obsolete and to be sure they won't linger forever, perhaps the right thing to do is removing them and fix the applications as appropriate in 8.0 release. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Julian Elischer Sent: Sun 12/21/2008 12:17 PM To: Hartmut Brandt Cc: Gerald Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li; freebsd-current@freebsd.org; freebsd-net@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed Hartmut Brandt wrote: > Kip Macy wrote: >> The flag is not needed. It is only possible to retrieve arp entries by >> way of sysctl. The converse of this is you no longer need to grab all >> the entries in the routing table and look at each one to determine >> which are cloned routes (dynamic host routes) which contain ARP >> entries. > > Does this mean that the snmp daemon cannot monitor the arp entries > through the routing socket anymore? This would be a performance issue, > since it would have to fetch the ARP table from the kernel each time it > is asked for. Now it refreshes the table only if it is older than 30 > seconds and in the mean time monitors routing messages. this is one of the things that worried me abuot the arp change, which is is that the change itself is fine but that I had no idea if LLINFO was BSD specific or if other ports and 3rd party code would rely on the connection between routing and ARP. maybe ARP activity should produce routing socket events. and maybe teh output should synthesize the missing entries. > > harti > >> >> -Kip >> >> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer >> wrote: >>> The code in question on the Wine side is >>> >>> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >>> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >>> >>> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far >>> as I can see. >>> >>> If the arp-v2 update now made us incompatible both with earlier versions >>> of FreeBSD and Linux, that sounds like something that should be fixed >>> (instead of hacking applications like Wine). >>> >>> On the other hand, the commit message at >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h >>> explicitly says >>> The change in design obsoletes the semantics of RTF_CLONING, >>> RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications >>> such as "arp" and "ndp" have been modified to reflect those changes. >>> so I guess it's not so easy. >>> >>> How many other ports are affected? >>> >>> What shall we do on the Wine front? Simply #ifdef-ing out the code in >>> question may not be the best of ideas, either. :-( >>> >>> Gerald >>> >>> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >>>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>>> >>>>>> The arp-v2 changes have been committed into HEAD. >>>>>> Please report problems to me and Kip Macy. >>>> Wine is not build any more: >>>> >>>> ... >>>> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ >>>> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >>>> -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith >>>> -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o >>>> ipstats.c >>>> ipstats.c: In function 'getNumArpEntries': >>>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this >>>> function) >>>> ipstats.c:1253: error: (Each undeclared identifier is reported only >>>> once >>>> ipstats.c:1253: error: for each function it appears in.) >>>> ipstats.c: In function 'getArpTable': >>>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this >>>> function) >>>> ipstats.c:1311: warning: initialization makes integer from pointer >>>> without a cast >>>> gmake[2]: *** [ipstats.o] ?????? 1 >>>> gmake[2]: Leaving directory >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>>> gmake[1]: *** [iphlpapi] ?????? 2 >>>> gmake[1]: Leaving directory >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>>> gmake: *** [dlls] ?????? 2 >>>> >>>> >>> -- >>> Gerald (Jerry) Pfeifer gerald@pfeifer.com >>> http://www.pfeifer.com/gerald/ >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From bms at incunabulum.net Sun Dec 21 17:05:33 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sun Dec 21 17:05:40 2008 Subject: sending arbitrary UDP packets from kernel module In-Reply-To: <1229738406.5614.17.camel@mobiliare.Belkin> References: <1229738406.5614.17.camel@mobiliare.Belkin> Message-ID: <494EE7D9.5060000@incunabulum.net> Ferner Cilloniz wrote: > So i have done some research and reading and found that i need to call > either udp_send or udp_output. Can anyone help me out with providing the > proper arguments to these functions so i may call them and send > arbitrary UDP packets from a kernel module? > The NFS and BOOTP code would be the first place to look, it has a rather shonky way of creating a socket in-kernel so that an INPCB will be created, allowing you to send and receive UDP datagrams. Fire up KScope or similar and look at how it does it. cheers BMS From pyunyh at gmail.com Sun Dec 21 17:19:38 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Dec 21 17:19:45 2008 Subject: Checksum offloading In-Reply-To: References: Message-ID: <20081222011929.GB86809@cdnetworks.co.kr> On Sat, Dec 20, 2008 at 10:31:39PM +0100, Michael T?xen wrote: > Dear all, > > I'm currently analyzing how TCP/UDP checksum offloading works > to find the best way to add SCTP checksum offloading. > > sys/mbuf.h has constants: > #define CSUM_IP 0x0001 /* will csum IP */ > #define CSUM_TCP 0x0002 /* will csum TCP */ > #define CSUM_UDP 0x0004 /* will csum UDP */ > which are used to signal which offloading is supported by the drive. > But, if I understand the code correctly, this only > applies to UDP/IPv4 and TCP/IPv4. > What about IPv6? Would this require flags like CSUM_TCP6 and CSUM_UDP6 > to signal that also offloading of UDP/IPv6 and TCP/IPv6 is supported? > > I'm asking this because we want to add CRC offloading for SCTP/IPv4 > and SCTP/IPv6. We could only add one flag CSUM_SCTP and use it > for IPv4 and IPv6 ar two flags CSUM_SCTP4 and CSUM_SCTP6... > I guess you're right. FreeBSD still lacks IPv6 checksum offloading related stuff. All recent hardwares support checksum offloading for TCP/UDP/IPv6 as well as TSO for IPv6. Don't know SCTP checksum offloading as I don't know any hardwares that can do SCTP checksum offloading. Sun Netptune might have the capability but I didn't check it though. > Best regards > Michael -- Regards, Pyun YongHyeon From jfvogel at gmail.com Sun Dec 21 18:08:59 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Dec 21 18:09:05 2008 Subject: Checksum offloading In-Reply-To: <20081222011929.GB86809@cdnetworks.co.kr> References: <20081222011929.GB86809@cdnetworks.co.kr> Message-ID: <2a41acea0812211808y7178d2fp75467f19248d1be3@mail.gmail.com> Our (Intel) hardware can do it, at least the newer adapters, and someone is working on it now btw. Jack On Sun, Dec 21, 2008 at 5:19 PM, Pyun YongHyeon wrote: > On Sat, Dec 20, 2008 at 10:31:39PM +0100, Michael T?xen wrote: > > Dear all, > > > > I'm currently analyzing how TCP/UDP checksum offloading works > > to find the best way to add SCTP checksum offloading. > > > > sys/mbuf.h has constants: > > #define CSUM_IP 0x0001 /* will csum IP */ > > #define CSUM_TCP 0x0002 /* will csum TCP */ > > #define CSUM_UDP 0x0004 /* will csum UDP */ > > which are used to signal which offloading is supported by the drive. > > But, if I understand the code correctly, this only > > applies to UDP/IPv4 and TCP/IPv4. > > What about IPv6? Would this require flags like CSUM_TCP6 and CSUM_UDP6 > > to signal that also offloading of UDP/IPv6 and TCP/IPv6 is supported? > > > > I'm asking this because we want to add CRC offloading for SCTP/IPv4 > > and SCTP/IPv6. We could only add one flag CSUM_SCTP and use it > > for IPv4 and IPv6 ar two flags CSUM_SCTP4 and CSUM_SCTP6... > > > > I guess you're right. FreeBSD still lacks IPv6 checksum offloading > related stuff. All recent hardwares support checksum offloading for > TCP/UDP/IPv6 as well as TSO for IPv6. Don't know SCTP checksum > offloading as I don't know any hardwares that can do SCTP checksum > offloading. Sun Netptune might have the capability but I didn't > check it though. > > > Best regards > > Michael > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > 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 naddy at mips.inka.de Sun Dec 21 19:15:28 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sun Dec 21 19:15:35 2008 Subject: NDP breakage in -CURRENT Message-ID: Something seems to be wrong with IPv6 neighbor discovery. FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 20 17:46:35 CET 2008 naddy@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64 This box is on a network that has IPv6. No exciting configuration, just ipv6_enable=YES and ipv6_defaultrouter and ipv6_ifconfig_nfe0 for a manually configured address. IPv6 with other hosts on the network and beyond works. However, clearing the NDP cache (ndp -c) kills IPv6 connectivity. The cache remains empty. tcpdump shows that neighbor solicitations are sent and advertisement received, but these replies seem to be ignored. ndp -a shows that no entries are added to the cache. This is a new problem. Fallout from arp-v2? -- Christian "naddy" Weisgerber naddy@mips.inka.de From linimon at FreeBSD.org Sun Dec 21 21:24:14 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Dec 21 21:24:26 2008 Subject: kern/129793: [ip6] [patch] Locking related leaks in the kernel (routing handling) Message-ID: <200812220524.mBM5ODq7071783@freefall.freebsd.org> Synopsis: [ip6] [patch] Locking related leaks in the kernel (routing handling) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 22 05:24:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129793 From qing.li at bluecoat.com Sun Dec 21 21:50:05 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Dec 21 21:50:12 2008 Subject: NDP breakage in -CURRENT References: Message-ID: Yes, probably a bug introduced by arp-v2, I will investigate and get back to you. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Christian Weisgerber Sent: Sun 12/21/2008 7:15 PM To: freebsd-net@freebsd.org Subject: NDP breakage in -CURRENT Something seems to be wrong with IPv6 neighbor discovery. FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 20 17:46:35 CET 2008 naddy@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64 This box is on a network that has IPv6. No exciting configuration, just ipv6_enable=YES and ipv6_defaultrouter and ipv6_ifconfig_nfe0 for a manually configured address. IPv6 with other hosts on the network and beyond works. However, clearing the NDP cache (ndp -c) kills IPv6 connectivity. The cache remains empty. tcpdump shows that neighbor solicitations are sent and advertisement received, but these replies seem to be ignored. ndp -a shows that no entries are added to the cache. This is a new problem. Fallout from arp-v2? -- Christian "naddy" Weisgerber naddy@mips.inka.de _______________________________________________ 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 rea-fbsd at codelabs.ru Sun Dec 21 22:26:37 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Dec 21 22:26:45 2008 Subject: [Fwd: em0 disappeared] In-Reply-To: <49499D47.5040509@grohnwaldt.eu> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> <494974F7.7080408@grohnwaldt.eu> <49499D47.5040509@grohnwaldt.eu> Message-ID: <2Bap5VDKzT7zMmPiWYyBFNrSahA@R1iWMyMbby3vqLLqlL15VaO5FRQ> Uwe, good day. Thu, Dec 18, 2008 at 01:45:59AM +0100, Uwe Grohnwaldt wrote: > Maksim Yevmenkin wrote: > > older tyan motherboards. when i upgraded from 7.x to current (amd64 > > arch) both onboard bge nics disappeared. i had to go to the bios > > screen and set "installed os" (or something like that) to "linux". > > other choices were "windows" and "other" (default). > > > The problem is: it is a rented Strato-Server. So I have no access to the > bios. Then the first thing to provide is the output from the verbose boot of the system in question. In your case the system isn't event seeing the PCI device (NIC), so it will be very good to get two outputs: from the system where you had your card recognized and from one that doesn't recognise it. Another thing to try is to disable ACPI. This seems to be very uneasy step -- for me, 8-CURRENT without ACPI wasn't been able to find even the disks, so you likely will want to use nextboot(8). But may be some ACPI-related things are plaing their role, so this is worth to try it. At least it helped me in the past on some systems. -- 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/20081222/5c87f212/attachment.pgp From qing.li at bluecoat.com Sun Dec 21 23:14:20 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Sun Dec 21 23:14:29 2008 Subject: NDP breakage in -CURRENT References: Message-ID: Please sync ./src/sys/netinet6/in6.c to SVN rev 186392 on 2008-12-22 07:11:15Z by qingli Let me know how it works out for you. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Li, Qing Sent: Sun 12/21/2008 9:49 PM To: Christian Weisgerber; freebsd-net@freebsd.org Cc: current@freebsd.org Subject: RE: NDP breakage in -CURRENT Yes, probably a bug introduced by arp-v2, I will investigate and get back to you. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Christian Weisgerber Sent: Sun 12/21/2008 7:15 PM To: freebsd-net@freebsd.org Subject: NDP breakage in -CURRENT Something seems to be wrong with IPv6 neighbor discovery. FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 20 17:46:35 CET 2008 naddy@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64 This box is on a network that has IPv6. No exciting configuration, just ipv6_enable=YES and ipv6_defaultrouter and ipv6_ifconfig_nfe0 for a manually configured address. IPv6 with other hosts on the network and beyond works. However, clearing the NDP cache (ndp -c) kills IPv6 connectivity. The cache remains empty. tcpdump shows that neighbor solicitations are sent and advertisement received, but these replies seem to be ignored. ndp -a shows that no entries are added to the cache. This is a new problem. Fallout from arp-v2? -- Christian "naddy" Weisgerber naddy@mips.inka.de _______________________________________________ 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 ianf at clue.co.za Mon Dec 22 00:29:30 2008 From: ianf at clue.co.za (Ian FREISLICH) Date: Mon Dec 22 00:29:41 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <20081221125120.GO23166@droso.net> Message-ID: Erwin Lansing wrote: > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications > > such as "arp" and "ndp" have been modified to reflect those changes. > > so I guess it's not so easy. > > How many other ports are affected? > The latest full run with HEAD from a few days back hasn't quite finished > yet, so there might turn up a few more, but so far it's just a handful: > net/libdnet > devel/libpdel > net-mgmt/net-snmp > net/netwib > net/p5-Net-RawIP > net-mgmt/net-snmp4 > emulators/wine You can add net/quagga to that list as well. The following patch solves it, and you'll need patch-lib-sockopt.c for multicast to work correctly on -CURRENT. -- Ian Freislich -------------- next part -------------- --- zebra/kernel_socket.c.orig 2008-12-22 09:59:00.000000000 +0200 +++ zebra/kernel_socket.c 2008-12-22 09:59:10.000000000 +0200 @@ -173,9 +173,13 @@ #ifdef RTF_MASK {RTF_MASK, "MASK"}, #endif /* RTF_MASK */ +#ifdef RTF_CLONING {RTF_CLONING, "CLONING"}, +#endif /* RTF_CLONING */ {RTF_XRESOLVE, "XRESOLVE"}, +#ifdef RTF_LLINFO {RTF_LLINFO, "LLINFO"}, +#endif /* RTF_LLINFO */ {RTF_STATIC, "STATIC"}, {RTF_BLACKHOLE, "BLACKHOLE"}, #ifdef RTF_PRIVATE @@ -999,9 +1003,11 @@ if (gate && message == RTM_ADD) msg.rtm.rtm_flags |= RTF_GATEWAY; +#ifdef RTF_CLONING if (! gate && message == RTM_ADD && ifp && (ifp->flags & IFF_POINTOPOINT) == 0) msg.rtm.rtm_flags |= RTF_CLONING; +#endif */ RTF_CLONING */ /* If no protocol specific gateway is specified, use link address for gateway. */ -------------- next part -------------- --- lib/sockopt.c.orig 2007-08-21 18:32:56.000000000 +0200 +++ lib/sockopt.c 2008-08-13 09:07:20.000000000 +0200 @@ -231,6 +231,7 @@ else mreqn.imr_address = if_addr; + mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, (void *)&mreqn, sizeof(mreqn)); if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRINUSE)) From rea-fbsd at codelabs.ru Mon Dec 22 01:40:27 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Dec 22 01:40:34 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081221125120.GO23166@droso.net> Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081222/d844a688/attachment.pgp From qing.li at bluecoat.com Mon Dec 22 01:56:01 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Dec 22 01:56:13 2008 Subject: HEADSUP: arp-v2 has been committed References: <20081221125120.GO23166@droso.net> Message-ID: Thank you all for patching these programs. I scanned through your patches and they all look fine. Each one that I read through seems to be simple fix, which is what I hoped for. Again, just to emphasize the points I made in my previous emails, the code that retrieves the ARP table by means of sysctl() does not have to check for the RTF_LLINFO entries in the returned list because the retrieved entries all belong to the ARP table. For those programs that retrieve the routing table through the routing socket interface, the code that bypasses RTF_LLINFO entries can also be eliminated because the routing table does not contain any L2 information. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Eygene Ryabinkin Sent: Mon 12/22/2008 1:40 AM To: freebsd-current@freebsd.org; freebsd-net@freebsd.org Cc: Gerald Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li; Ian FREISLICH; Erwin Lansing Subject: Re: HEADSUP: arp-v2 has been committed Greetings! Mon, Dec 22, 2008 at 10:04:22AM +0200, Ian FREISLICH wrote: > Erwin Lansing wrote: > > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications > > > such as "arp" and "ndp" have been modified to reflect those changes. > > > so I guess it's not so easy. > > > How many other ports are affected? > > The latest full run with HEAD from a few days back hasn't quite finished > > yet, so there might turn up a few more, but so far it's just a handful: > > net/libdnet > > devel/libpdel > > net-mgmt/net-snmp > > net/netwib > > net/p5-Net-RawIP > > net-mgmt/net-snmp4 > > emulators/wine > > You can add net/quagga to that list as well. net/openospfd is also affected. Attached is the simple patch to take into account the withdrawal of RTF_LLINFO. Perhaps something else should be done -- I'll up some -CURRENT systems and will try to test the Real Stuff (TM). -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From rea-fbsd at codelabs.ru Mon Dec 22 02:41:13 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Dec 22 02:41:26 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081221125120.GO23166@droso.net> Message-ID: Li, good day. Mon, Dec 22, 2008 at 01:55:34AM -0800, Li, Qing wrote: > Thank you all for patching these programs. Thank you for your work! > I scanned through your patches and they all look fine. > Each one that I read through seems to be simple fix, which > is what I hoped for. Are you going to submit the patches for affected ports by yourself or individual persons should do it? For me, it does not matter what route you will take, I just want to know how to proceed ;)) -- 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/20081222/09227008/attachment.pgp From bugmaster at FreeBSD.org Mon Dec 22 03:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 22 03:08:38 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200812221106.mBMB6tn1060645@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/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/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 kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/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 201 problems total. From rrs at lakerest.net Mon Dec 22 03:48:38 2008 From: rrs at lakerest.net (Randall Stewart) Date: Mon Dec 22 03:48:45 2008 Subject: ACE and FreeBSD Message-ID: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> Hi all: I am trying to get the latest ACE/TAO toolkit compiling with Head... (the port is marked broken in 7).. In the process of fixing things I found something I am not sure how to approach.. for now I have just ifdef'd it out but maybe someone can point me to the right method... They are using a ioctl -- SIOCGIFDATA -- to get access to the interface packet counts and such. Now near as I can tell we don't have that SIO. A google of someone a few years ago where the question was asked turned up a, we don't need that instead we should have access to this information via the sysctl. So my immediate thought, hey netstat does this.. and it probably uses the sysctl... so I go and look at the code.. and tada.. it does a kread() to get the actual if_data .... yuck. So, is there a sysctl that gets access to this information? I have poked around in a sysctl -a -N and don't see anything that looks promising.. Pointers to the right approach would be appreciated.. I am not sure what the monitor stuff is used for.. but I would like to get this toolkit fully functional if possible :-) R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From alfred at freebsd.org Mon Dec 22 04:21:28 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Dec 22 04:21:34 2008 Subject: ACE and FreeBSD In-Reply-To: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> References: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> Message-ID: <20081222122127.GO18389@elvis.mu.org> * Randall Stewart [081222 03:48] wrote: > Hi all: > > I am trying to get the latest ACE/TAO toolkit compiling with Head... > (the > port is marked broken in 7).. > > In the process of fixing things I found something I am not sure how > to approach.. for now I have just ifdef'd it out but maybe someone > can point me to the right method... > > They are using a ioctl -- SIOCGIFDATA -- to get access to the interface > packet counts and such. Now near as I can tell we don't have that > SIO. A google of someone a few years ago where the question was > asked turned up a, we don't need that instead we should have > access to this information via the sysctl. > > So my immediate thought, hey netstat does this.. and it probably uses > the sysctl... so I go and look at the code.. and tada.. it does a > kread() to get the actual if_data .... yuck. > > So, is there a sysctl that gets access to this information? I have > poked around in a sysctl -a -N and don't see anything that looks > promising.. > > Pointers to the right approach would be appreciated.. I am not sure > what the monitor stuff is used for.. but I would like to get this > toolkit fully functional if possible :-) You could expand SIOCGIFDATA, but you'd need to make a compat SIOCGIFODATA (OLD DATA) ioctl. Or you could export it maybe through the dev sysctl tree. I like the former. -Alfred From rwatson at FreeBSD.org Mon Dec 22 05:37:25 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Dec 22 05:37:31 2008 Subject: sending arbitrary UDP packets from kernel module In-Reply-To: <494EE7D9.5060000@incunabulum.net> References: <1229738406.5614.17.camel@mobiliare.Belkin> <494EE7D9.5060000@incunabulum.net> Message-ID: On Mon, 22 Dec 2008, Bruce Simpson wrote: > Ferner Cilloniz wrote: > >> So i have done some research and reading and found that i need to call >> either udp_send or udp_output. Can anyone help me out with providing the >> proper arguments to these functions so i may call them and send arbitrary >> UDP packets from a kernel module? > > The NFS and BOOTP code would be the first place to look, it has a rather > shonky way of creating a socket in-kernel so that an INPCB will be created, > allowing you to send and receive UDP datagrams. Fire up KScope or similar > and look at how it does it. I would encourage this approach, if the application model works with it, as it allows using the existing socket infrastruture to reserve the port/ip tuple and avoid conflicts with userspace, use existing buffering on the receive side, etc. Robert N M Watson Computer Laboratory University of Cambridge From naddy at mips.inka.de Mon Dec 22 06:16:35 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Mon Dec 22 06:16:46 2008 Subject: NDP breakage in -CURRENT In-Reply-To: References: Message-ID: <20081222134407.GA1898@lorvorc.mips.inka.de> Li, Qing: > Please sync ./src/sys/netinet6/in6.c to > > SVN rev 186392 on 2008-12-22 07:11:15Z by qingli = rev 1.92 in the CVS export > Let me know how it works out for you. Yes, that fixes the problem. Thanks! -- Christian "naddy" Weisgerber naddy@mips.inka.de From sem at FreeBSD.org Mon Dec 22 07:18:07 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Mon Dec 22 07:18:38 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: Message-ID: <494FAFAC.90802@FreeBSD.org> Ian FREISLICH wrote: > --- lib/sockopt.c.orig 2007-08-21 18:32:56.000000000 +0200 > +++ lib/sockopt.c 2008-08-13 09:07:20.000000000 +0200 > @@ -231,6 +231,7 @@ > else > mreqn.imr_address = if_addr; > > + mreqn.imr_address = if_addr; > ret = setsockopt(sock, IPPROTO_IP, optname, > (void *)&mreqn, sizeof(mreqn)); > if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRINUSE)) > I don't catch your idea here. Can you explain it please? A result code looks ugly: if (ifindex) mreqn.imr_ifindex = ifindex; else mreqn.imr_address = if_addr; mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, ... -- Dixi. Sem. From sem at FreeBSD.org Mon Dec 22 07:20:32 2008 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Mon Dec 22 07:20:38 2008 Subject: ACE and FreeBSD In-Reply-To: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> References: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> Message-ID: <494FB03F.1010005@FreeBSD.org> Randall Stewart wrote: > Hi all: > > I am trying to get the latest ACE/TAO toolkit compiling with Head... (the > port is marked broken in 7).. > Could you take the port and upgrade/fix it? I did not use ace+tao for ages and can't support it anymore. -- Dixi. Sem. From gnn at freebsd.org Mon Dec 22 07:40:30 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Mon Dec 22 07:40:36 2008 Subject: Panic on boot with em1 attached In-Reply-To: <004a01c961ec$ec136540$c43a2fc0$@net> References: <004a01c961ec$ec136540$c43a2fc0$@net> Message-ID: <7ik59sgrgd.wl%gnn@neville-neil.com> Hi, Can you try this with fastforwarding off? It looks like a double free somewhere in the ip_fastforward() routine. Someone frees m but does not NULL it out and at the drop: label the mbuf m is valid but the data within it has already been freed. Knowing if this is related only to the fast forwarding case will help. Best, George From tijl at ulyssis.org Mon Dec 22 07:50:34 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Mon Dec 22 07:50:46 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081221125120.GO23166@droso.net> Message-ID: <200812221621.40722.tijl@ulyssis.org> On Monday 22 December 2008 10:55:34 Li, Qing wrote: > Thank you all for patching these programs. > > I scanned through your patches and they all look fine. > Each one that I read through seems to be simple fix, which > is what I hoped for. > > Again, just to emphasize the points I made in my previous > emails, the code that retrieves the ARP table by means > of sysctl() does not have to check for the RTF_LLINFO > entries in the returned list because the retrieved > entries all belong to the ARP table. For those programs > that retrieve the routing table through the routing socket > interface, the code that bypasses RTF_LLINFO entries can > also be eliminated because the routing table does not > contain any L2 information. I'm looking into the Wine case, but don't have any experience with the implementation of routing tables, so I need to have a few things spelled out. Wine currently uses: int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; I take it this returns all the entries which have the RTF_LLINFO flag set? And to make this compile on CURRENT I have to change this into: #ifdef RTF_LLINFO int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; #else int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; #endif Is AF_INET really the correct address family? What about AF_LINK and AF_ARP? Is using NET_RT_FLAGS with flags mask 0 exactly the same as using NET_RT_DUMP? Also, at some other place, Wine wants to retrieve gateway entries and it uses: int mib[6] = {CTL_NET, PF_ROUTE, 0, PF_INET, NET_RT_DUMP, 0}; ^ this should be AF_INET I think After that it runs over all entries counting only those which have RTF_GATEWAY set and RTF_MULTICAST unset. Is the output of this different now in CURRENT? From auryn at zirakzigil.org Mon Dec 22 13:11:26 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Mon Dec 22 13:11:32 2008 Subject: ng_fec and vlan Message-ID: <494FFC34.9020600@zirakzigil.org> I've tried (without too much effort, I admit...) to create vlan interfaces using a fec device as parent. It was something like this: ... fec_interfaces="fec0" fecconfig_fec0="re1 re2" ifconfig_fec0="inet 192.168.0.1 netmask 255.255.255.0" ... cloned_interfaces="vlan1 vlan2 vlan3 ..." ifconfig_vlan1="inet 192.168.1.1 netmask 255.255.255.0 vlan 1 vlandev fec0" ifconfig_vlan2="inet 192.168.2.1 netmask 255.255.255.0 vlan 2 vlandev fec0" ifconfig_vlan3="inet 192.168.3.1 netmask 255.255.255.0 vlan 3 vlandev fec0" ... freebsd 7 stable (recent) amd64 Result: I see the vlan interfaces up and active, but they neither transmit nor receive. By using tcpdump on the vlan ifaces I can see the arp packets leaving when I try to ping a host on the same vlan, but they are unanswered. The switch has been configured correctly, since the same vlans work using either re1 or re2 as parent. Any idea? From linimon at FreeBSD.org Mon Dec 22 13:47:49 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Dec 22 13:48:01 2008 Subject: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Message-ID: <200812222147.mBMLlm33048696@freefall.freebsd.org> Old Synopsis: /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock New Synopsis: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 22 21:47:10 UTC 2008 Responsible-Changed-Why: May be networking-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=129846 From alfred at freebsd.org Mon Dec 22 16:30:36 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Dec 22 16:30:43 2008 Subject: ipv6 bugfix, need review. Message-ID: <20081223001216.GH18389@elvis.mu.org> Hey guys, we found a bug at Juniper and it resolves an issue for us. I've been asked to forward this to FreeBSD, I honestly am not that clear on the issue so I'm hoping someone can step up to review this. Synopsis is: The traffic class byte is set to 0x00000000 in the header of some BGP packets sent between interfaces that have IPv6 addresses, instead of the correct setting 0xc0 (INTERNETCONTROL). Fix is small and attached. One thing I am wondering, do we need to check "if (inp)" ? I don't think so. Index: bsd/sys/netinet/tcp_syncache.c =================================================================== RCS file: /cvs/junos-2008/bsd/sys/netinet/tcp_syncache.c,v retrieving revision 1.24 diff -p -u -r1.24 tcp_syncache.c --- bsd/sys/netinet/tcp_syncache.c 29 Jul 2008 17:07:43 -0000 1.24 +++ bsd/sys/netinet/tcp_syncache.c 16 Dec 2008 19:23:31 -0000 @@ -1271,6 +1271,7 @@ syncache_respond(sc, m) struct inpcb *inp; #ifdef INET6 struct ip6_hdr *ip6 = NULL; + int inp_tclass; #endif struct rt_nexthop *minmtu_nh; struct route_table *rtb = NULL; @@ -1387,6 +1388,12 @@ syncache_respond(sc, m) /* ip6_hlim is set after checksum */ ip6->ip6_flow &= ~IPV6_FLOWLABEL_MASK; ip6->ip6_flow |= sc->sc_flowlabel; + /* Set the TC for IPv6 just like TOS for IPv4 */ + ip6->ip6_flow &= ~IPV6_CLASS_MASK; + if (inp) { + inp_tclass = IPV6_GET_CLASS(inp->in6p_flowinfo); + ip6->ip6_flow |= IPV6_SET_CLASS(inp_tclass); + } th = (struct tcphdr *)(ip6 + 1); } else -- - Alfred Perlstein From qing.li at bluecoat.com Mon Dec 22 18:27:09 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Dec 22 18:27:26 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812221621.40722.tijl@ulyssis.org> References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> Message-ID: Hi Tijl, Good questions and see my comments below. > > I'm looking into the Wine case, but don't have any experience with the > implementation of routing tables, so I need to have a few things > spelled out. > > Wine currently uses: > > int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > > I take it this returns all the entries which have the RTF_LLINFO flag > set? And to make this compile on CURRENT I have to change this into: > > #ifdef RTF_LLINFO > int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > #else > int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; > #endif > > Is AF_INET really the correct address family? What about AF_LINK and > AF_ARP? Is using NET_RT_FLAGS with flags mask 0 exactly the same as > using NET_RT_DUMP? > AF_INET is the correct address family, which indicates the L2 information (a.k.a RTF_LLINFO previously) should be retrieved from the IPv4 ARP table. If the AF family were instead AF_INET6, then the L2 information would be coming from the ND6 cache. NET_RT_DUMP walks the entire routing tree. Specifying specific flags and using the NET_RT_FLAGS opcode retrieves routing entries that have those bits set. NET_RT_FLAGS with mask 0 is an indication to the kernel the L2 table should be retrieved. I am glad you asked these questions because after re-examining my code, I realized I could make slight optimization and also need to perform additional check against erroneous input. > > Also, at some other place, Wine wants to retrieve gateway entries and > it uses: > > int mib[6] = {CTL_NET, PF_ROUTE, 0, PF_INET, NET_RT_DUMP, 0}; > ^ this should be AF_INET I think > > After that it runs over all entries counting only those which have > RTF_GATEWAY set and RTF_MULTICAST unset. Is the output of this > different now in CURRENT? > No, the output of this command is still the same. NET_RT_DUMP obtains the entire L3 table and filtering for RTF_GATEWAY non-multicast routes have the same semantics. Those flags never apply to L2 entries. -- Qing From qing.li at bluecoat.com Mon Dec 22 18:37:43 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Dec 22 18:37:55 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081221125120.GO23166@droso.net> Message-ID: Hi Eygene, I think it would be more efficient if individuals who have discovered these issues could submit the patches directly to the corresponding port maintainers. You could also file a PR for tracking purposes. In any case, please cc: me so that I am aware of these breakage and in case I need to resolve any non-trivial mapping. Thank you. -- Qing > -----Original Message----- > From: rea-fbsd@codelabs.ru [mailto:rea-fbsd@codelabs.ru] > Sent: Monday, December 22, 2008 2:41 AM > To: Li, Qing > Cc: freebsd-current@freebsd.org; freebsd-net@freebsd.org; Gerald > Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li; Ian FREISLICH; > Erwin Lansing > Subject: Re: HEADSUP: arp-v2 has been committed > > Li, good day. > > Mon, Dec 22, 2008 at 01:55:34AM -0800, Li, Qing wrote: > > Thank you all for patching these programs. > > Thank you for your work! > > > I scanned through your patches and they all look fine. > > Each one that I read through seems to be simple fix, which > > is what I hoped for. > > Are you going to submit the patches for affected ports by yourself > or individual persons should do it? For me, it does not matter > what route you will take, I just want to know how to proceed ;)) > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # From ianf at clue.co.za Mon Dec 22 21:50:18 2008 From: ianf at clue.co.za (Ian FREISLICH) Date: Mon Dec 22 21:50:41 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <494FAFAC.90802@FreeBSD.org> References: <494FAFAC.90802@FreeBSD.org> Message-ID: Sergey Matveychuk wrote: > Ian FREISLICH wrote: > > --- lib/sockopt.c.orig 2007-08-21 18:32:56.000000000 +0200 > > +++ lib/sockopt.c 2008-08-13 09:07:20.000000000 +0200 > > @@ -231,6 +231,7 @@ > > else > > mreqn.imr_address = if_addr; > > > > + mreqn.imr_address = if_addr; > > ret = setsockopt(sock, IPPROTO_IP, optname, > > (void *)&mreqn, sizeof(mreqn)); > > if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRIN USE)) > > > > I don't catch your idea here. Can you explain it please? I can't quite remember exactly why imr_ifindex doesn't work, but on my hosts which have several hundred interfaces and my OSPF sessions are never on the interface that has the default route, until I explicitly set the imr_address, the kernel always chooses the interface which has the default route. I know the resultant code looks ugly. I've just never had the time to relook the problem. Does this look better? --- sockopt.c.orig 2008-12-23 07:00:24.000000000 +0200 +++ sockopt.c 2008-12-23 07:41:28.000000000 +0200 @@ -227,9 +227,11 @@ if (mcast_addr) mreqn.imr_multiaddr.s_addr = mcast_addr; +#if OSVERSION > 700001 if (ifindex) mreqn.imr_ifindex = ifindex; else +#endif mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, Ian -- Ian Freislich From vlad at prokk.net Tue Dec 23 03:58:00 2008 From: vlad at prokk.net (Vladimir V. Kobal) Date: Tue Dec 23 03:58:07 2008 Subject: Panic on boot with em1 attached In-Reply-To: <7ik59sgrgd.wl%gnn@neville-neil.com> References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> Message-ID: <000201c964f5$aa94e6a0$ffbeb3e0$@net> With fastforwarding off the system works well and boots without panicing. As for the rtfree messages, they were caused by net.link.ether.inet.proxyall=1 and were not connected to panicing. Best regards, Vladimir -----Original Message----- From: gnn@freebsd.org [mailto:gnn@freebsd.org] Sent: Monday, December 22, 2008 5:28 PM To: Vladimir V. Kobal Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached Hi, Can you try this with fastforwarding off? It looks like a double free somewhere in the ip_fastforward() routine. Someone frees m but does not NULL it out and at the drop: label the mbuf m is valid but the data within it has already been freed. Knowing if this is related only to the fast forwarding case will help. Best, George From hartmut.brandt at dlr.de Tue Dec 23 05:36:55 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Tue Dec 23 05:37:02 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Message-ID: <4950E95C.9060307@dlr.de> Li, Qing wrote: > Yes, at least in the IPv4 case, I still generate the routing messages whenever entries are modified, so you can still wait for notifications on the routing socket. One should check for the address family AF_LINK type instead of checking for RTF_LLINFO flag. It's an over sight this note was not attached to the commit message. > > There are two locations in ND6 where I temporarily disabled rtmsg generation pending further investigation. I have a note-to-self for that in the code comment. > > Since only ARP entries are returned, you are in fact getting some performance gain. The userland application should also be simplified a little because the list walking code does not have to check for non-ARP entries. > Its not that easy, but fixable :-) Up to now I could use common code to handle routing message from the routing socket and the sysctl. This is not possible anymore, because most of the fields in the sysctl's routing message are just zero. The following should fix this (at least to the extend bsnmp needs it): Index: in.c =================================================================== --- in.c (revision 186335) +++ in.c (working copy) @@ -1200,6 +1200,10 @@ */ bzero(&arpc, sizeof(arpc)); arpc.rtm.rtm_msglen = sizeof(arpc); + arpc.rtm.rtm_version = RTM_VERSION; + arpc.rtm.rtm_type = RTM_GET; + arpc.rtm.rtm_flags = RTF_UP; + arpc.rtm.rtm_addrs = RTA_DST | RTA_GATEWAY; arpc.sin.sin_family = AF_INET; arpc.sin.sin_len = sizeof(arpc.sin); arpc.sin.sin_addr.s_addr = SIN(lle)->sin_addr.s_addr; Also one thing that would be extremly helpful is a short description of that interface arp(4). Currently one has to reverse engineer arp.c to understand how to do things. A last thing: I wonder if this would have been a good chance to get rid of that ugly sockaddr_inaddr construct. It looks like it is used only to hold the proxy flag, right? Couldn't we just use sockaddr_in and put that flag elsewhere. Having a single sa_family value, but two different struct sockaddr depending on the context defeats any kind of generic sockaddr handling. harti From hartmut.brandt at dlr.de Tue Dec 23 06:36:55 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Tue Dec 23 06:37:08 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Message-ID: <4950F770.3090700@dlr.de> Li, Qing wrote: > Yes, at least in the IPv4 case, I still generate the routing messages whenever entries are modified, so you can still wait for notifications on the routing socket. One should check for the address family AF_LINK type instead of checking for RTF_LLINFO flag. It's an over sight this note was not attached to the commit message. > > There are two locations in ND6 where I temporarily disabled rtmsg generation pending further investigation. I have a note-to-self for that in the code comment. > > Since only ARP entries are returned, you are in fact getting some performance gain. The userland application should also be simplified a little because the list walking code does not have to check for non-ARP entries. > Actually I'm somewhat surprised at the moment. I looked at the actual commit and saw that you've heavily changed src/contrib/bsnmp/snmp_mibII. I don't think that was a good idea for several reasons: - this is code maintained in another repository and imported to FreeBSD. Luckily the cvs-times are over where this commit would have taken the files of the vendor branch. But nevertheless it is never a good idea to change code in contrib without pushing the changes upstream. - you just removed a lot of code and left the ipNetToMedia table entirely disfunctional. - you obviously did not test the change. Otherwise you would have seen that it did not work. It took me several hours today to re-engineer usr.sbin/arp/arp.c and the different files under sys/net and sys/netinet to understand how ARP should work now, fixing an issue with half-baken routing messages while beeing here. During this time I was puzzled in what strange state I committed the SNMP stuff: functions that were never called, routing messages that are not handled. Now looking at your commit I understand how this happend. And another point: when changing external interfaces it might be possible to ask for a full port build with the changes to look for the fall-out on ports. I would say that this commit was a good candidate to get the port maintainers into the boat earlier. not so happy, harti > -- Qing > > -----Original Message----- > From: Hartmut Brandt > Sent: Sunday, December 21, 2008 8:54 AM > To: Kip Macy > Cc: Vladimir Grebenschikov ; Qing Li ; freebsd-net@freebsd.org ; Gerald Pfeifer ; freebsd-current@freebsd.org > Subject: Re: HEADSUP: arp-v2 has been committed > > Kip Macy wrote: > >> The flag is not needed. It is only possible to retrieve arp entries by >> way of sysctl. The converse of this is you no longer need to grab all >> the entries in the routing table and look at each one to determine >> which are cloned routes (dynamic host routes) which contain ARP >> entries. >> > > Does this mean that the snmp daemon cannot monitor the arp entries > through the routing socket anymore? This would be a performance issue, > since it would have to fetch the ARP table from the kernel each time it > is asked for. Now it refreshes the table only if it is older than 30 > seconds and in the mean time monitors routing messages. > > harti > > >> -Kip >> >> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer wrote: >> >>> The code in question on the Wine side is >>> >>> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >>> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >>> >>> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far >>> as I can see. >>> >>> If the arp-v2 update now made us incompatible both with earlier versions >>> of FreeBSD and Linux, that sounds like something that should be fixed >>> (instead of hacking applications like Wine). >>> >>> On the other hand, the commit message at >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h >>> explicitly says >>> The change in design obsoletes the semantics of RTF_CLONING, >>> RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications >>> such as "arp" and "ndp" have been modified to reflect those changes. >>> so I guess it's not so easy. >>> >>> How many other ports are affected? >>> >>> What shall we do on the Wine front? Simply #ifdef-ing out the code in >>> question may not be the best of ideas, either. :-( >>> >>> Gerald >>> >>> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote: >>> >>>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote: >>>> >>>> >>>>>> The arp-v2 changes have been committed into HEAD. >>>>>> Please report problems to me and Kip Macy. >>>>>> >>>> Wine is not build any more: >>>> >>>> ... >>>> cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o ipstats.c >>>> ipstats.c: In function 'getNumArpEntries': >>>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function) >>>> ipstats.c:1253: error: (Each undeclared identifier is reported only once >>>> ipstats.c:1253: error: for each function it appears in.) >>>> ipstats.c: In function 'getArpTable': >>>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function) >>>> ipstats.c:1311: warning: initialization makes integer from pointer without a cast >>>> gmake[2]: *** [ipstats.o] ?????? 1 >>>> gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>>> gmake[1]: *** [iphlpapi] ?????? 2 >>>> gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>>> gmake: *** [dlls] ?????? 2 >>>> >>>> >>>> >>> -- >>> Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ >>> _______________________________________________ >>> 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 rrs at lakerest.net Tue Dec 23 07:29:41 2008 From: rrs at lakerest.net (Randall Stewart) Date: Tue Dec 23 07:29:48 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <200812132030.15665.max@love2party.net> References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <200812132030.15665.max@love2party.net> Message-ID: <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> All: Ok here is the latest... this: 1) Incorporates Matt's changes 2) Goes with Matt's idea of adding an INP. 3) We now are holding the INP lock across the call to the tunnel as well as the append. Since the caller will have the INP they can unlock if they need to :-) 4) revamped my s9indent use.. I ran it and then patched back in just its complaints about me... that way the other s9 issues can stay in the file untouched by me :-D Note to Sam, I did not make the base code use the function.. since I thought it got a bit tricky when one started having to worry about sockaddr's being passed to the function AND the typing there of... So I deferred that until later .. :-) I will wait tell all the criticisms settle down and commit eventually here :) R -------------- next part -------------- Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 185928) +++ netinet/udp_usrreq.c (working copy) @@ -488,41 +488,76 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* + * Engage the tunneling protocol we + * will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't + * break :-( + * + * XXXML: Maybe add a flag to the + * prototype so that the tunneling + * can defer work that can't be done + * under the info lock? + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + tunnel_func(m, iphlen, last); + INP_RUNLOCK(last); + } } last = inp; /* - * Don't look for additional matches if this one does - * not have either the SO_REUSEPORT or SO_REUSEADDR - * socket options set. This heuristic avoids - * searching through all pcbs in the common case of a - * non-shared port. It assumes that an application - * will never clear these options after setting them. + * Don't look for additional matches if this one + * does not have either the SO_REUSEPORT or + * SO_REUSEADDR socket options set. This heuristic + * avoids searching through all pcbs in the common + * case of a non-shared port. It assumes that an + * application will never clear these options after + * setting them. */ if ((last->inp_socket->so_options & - (SO_REUSEPORT|SO_REUSEADDR)) == 0) + (SO_REUSEPORT | SO_REUSEADDR)) == 0) break; } if (last == NULL) { /* - * No matching pcb found; discard datagram. (No need - * to send an ICMP Port Unreachable for a broadcast - * or multicast datgram.) + * No matching pcb found; discard datagram. (No + * need to send an ICMP Port Unreachable for a + * broadcast or multicast datgram.) */ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + tunnel_func(m, iphlen, last); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } return; } - /* * Locate pcb for datagram. */ @@ -553,7 +588,6 @@ INP_INFO_RUNLOCK(&V_udbinfo); return; } - /* * Check the minimum TTL for socket. */ @@ -563,6 +597,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + tunnel_func(m, iphlen, inp); + INP_RUNLOCK(inp); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1184,41 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 185928) +++ netinet/udp_var.h (working copy) @@ -107,6 +107,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_func_t)(struct mbuf *, int off, struct inpcb *); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f); #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 185928) +++ netinet6/udp6_usrreq.c (working copy) @@ -262,54 +262,72 @@ if (inp->in6p_lport != uh->uh_dport) continue; /* - * XXX: Do not check source port of incoming datagram - * unless inp_connect() has been called to bind the - * fport part of the 4-tuple; the source could be - * trying to talk to us with an ephemeral port. + * XXX: Do not check source port of incoming + * datagram unless inp_connect() has been called to + * bind the fport part of the 4-tuple; the source + * could be trying to talk to us with an ephemeral + * port. */ if (inp->inp_fport != 0 && inp->inp_fport != uh->uh_sport) continue; if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_laddr)) { if (!IN6_ARE_ADDR_EQUAL(&inp->in6p_laddr, - &ip6->ip6_dst)) + &ip6->ip6_dst)) continue; } if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr)) { if (!IN6_ARE_ADDR_EQUAL(&inp->in6p_faddr, - &ip6->ip6_src) || + &ip6->ip6_src) || inp->in6p_fport != uh->uh_sport) continue; } - if (last != NULL) { struct mbuf *n; if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* + * Engage the tunneling + * protocol we will have to + * leave the info_lock up, + * since we are hunting + * through multiple UDP + * inp's hope we don't break + * :-( + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + tunnel_func(m, off, last); + INP_RUNLOCK(last); + } else { + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; /* - * Don't look for additional matches if this one does - * not have either the SO_REUSEPORT or SO_REUSEADDR - * socket options set. This heuristic avoids - * searching through all pcbs in the common case of a - * non-shared port. It assumes that an application - * will never clear these options after setting them. + * Don't look for additional matches if this one + * does not have either the SO_REUSEPORT or + * SO_REUSEADDR socket options set. This heuristic + * avoids searching through all pcbs in the common + * case of a non-shared port. It assumes that an + * application will never clear these options after + * setting them. */ if ((last->inp_socket->so_options & - (SO_REUSEPORT|SO_REUSEADDR)) == 0) + (SO_REUSEPORT | SO_REUSEADDR)) == 0) break; } if (last == NULL) { /* - * No matching pcb found; discard datagram. (No need - * to send an ICMP Port Unreachable for a broadcast - * or multicast datgram.) + * No matching pcb found; discard datagram. (No + * need to send an ICMP Port Unreachable for a + * broadcast or multicast datgram.) */ V_udpstat.udps_noport++; V_udpstat.udps_noportmcast++; @@ -317,6 +335,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + tunnel_func(m, off, last); + INP_RUNLOCK(last); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +385,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + tunnel_func(m, off, inp); + INP_RUNLOCK(inp); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); -------------- next part -------------- ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From axel at axel.truedestiny.net Tue Dec 23 08:10:03 2008 From: axel at axel.truedestiny.net (Axel Scheepers) Date: Tue Dec 23 08:10:10 2008 Subject: kern/119432: [arp] route add -host <host> -iface <nic> causes arp entry with nic's arp address [regression] Message-ID: <200812231610.mBNGA358041253@freefall.freebsd.org> The following reply was made to PR kern/119432; it has been noted by GNATS. From: Axel Scheepers To: bug-followup@FreeBSD.org, axel@axel.truedestiny.net Cc: Subject: Re: kern/119432: [arp] route add -host <host> -iface <nic> causes arp entry with nic's arp address [regression] Date: Tue, 23 Dec 2008 17:01:52 +0100 --=-DJi/6GyJxBE0ge5Iv6Kh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I had to replace the box in question with a real router due to hardware failure. I think using route add -net host -netmask 255.255.255.255 -interface ip-address-on-egress-interface will actually work but I'm still pretty sure -iface used to work on 4.x. I also found a PR which might be related, 121437. 'Routing to layer-2 address does not work on VLAN interface' I'll try to install freebsd on a spare machine to see if using -net -netmask -interface actually does work. Kind regards, Axel Scheepers --=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --=-DJi/6GyJxBE0ge5Iv6Kh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklRC2sACgkQvOFCXiGjP+AHwQCfXlQhJHzK5jTU8FoOzswPc3W/ FwsAniQwvhcivlEn532JqqfPXiI0L90N =G7cf -----END PGP SIGNATURE----- --=-DJi/6GyJxBE0ge5Iv6Kh-- From tijl at ulyssis.org Tue Dec 23 08:53:02 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Tue Dec 23 08:53:09 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> Message-ID: <200812231750.26602.tijl@ulyssis.org> On Tuesday 23 December 2008 03:27:21 Li, Qing wrote: >> I'm looking into the Wine case, but don't have any experience with >> the implementation of routing tables, so I need to have a few things >> spelled out. >> >> Wine currently uses: >> >> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, >> RTF_LLINFO}; >> >> I take it this returns all the entries which have the RTF_LLINFO >> flag set? And to make this compile on CURRENT I have to change this >> into: >> >> #ifdef RTF_LLINFO >> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, >> RTF_LLINFO}; >> #else >> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; >> #endif >> >> Is AF_INET really the correct address family? What about AF_LINK and >> AF_ARP? Is using NET_RT_FLAGS with flags mask 0 exactly the same as >> using NET_RT_DUMP? > > AF_INET is the correct address family, which indicates the L2 > information (a.k.a RTF_LLINFO previously) should be retrieved from > the IPv4 ARP table. If the AF family were instead AF_INET6, then the > L2 information would be coming from the ND6 cache. > > NET_RT_DUMP walks the entire routing tree. Specifying specific flags > and using the NET_RT_FLAGS opcode retrieves routing entries that have > those bits set. > > NET_RT_FLAGS with mask 0 is an indication to the kernel the L2 table > should be retrieved. > > I am glad you asked these questions because after re-examining my > code, I realized I could make slight optimization and also need to > perform additional check against erroneous input. > >> Also, at some other place, Wine wants to retrieve gateway entries >> and it uses: >> >> int mib[6] = {CTL_NET, PF_ROUTE, 0, PF_INET, NET_RT_DUMP, 0}; >> ^ this should be AF_INET I think >> >> After that it runs over all entries counting only those which have >> RTF_GATEWAY set and RTF_MULTICAST unset. Is the output of this >> different now in CURRENT? > > No, the output of this command is still the same. NET_RT_DUMP obtains > the entire L3 table and filtering for RTF_GATEWAY non-multicast > routes have the same semantics. Those flags never apply to L2 entries. Thanks for answering my questions. I've attached the patch for Wine. -------------- next part -------------- diff --git a/dlls/iphlpapi/ipstats.c b/dlls/iphlpapi/ipstats.c index 3fc91eb..99e78a0 100644 --- a/dlls/iphlpapi/ipstats.c +++ b/dlls/iphlpapi/ipstats.c @@ -1250,7 +1250,11 @@ DWORD getRouteTable(PMIB_IPFORWARDTABLE *ppIpForwardTable, HANDLE heap, DWORD getNumArpEntries(void) { #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) +#ifdef RTF_LLINFO int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; +#else + int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; +#endif #define MIB_LEN (sizeof(mib) / sizeof(mib[0])) DWORD arpEntries = 0; size_t needed; @@ -1308,7 +1312,11 @@ DWORD getArpTable(PMIB_IPNETTABLE *ppIpNetTable, HANDLE heap, DWORD flags) #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) if (table) { +#ifdef RTF_LLINFO int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; +#else + int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; +#endif #define MIB_LEN (sizeof(mib) / sizeof(mib[0])) size_t needed; char *buf, *lim, *next; From gnn at freebsd.org Tue Dec 23 11:35:47 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Dec 23 11:35:53 2008 Subject: Panic on boot with em1 attached In-Reply-To: <000201c964f5$aa94e6a0$ffbeb3e0$@net> References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> <000201c964f5$aa94e6a0$ffbeb3e0$@net> Message-ID: <7ik59q3csb.wl%gnn@neville-neil.com> At Tue, 23 Dec 2008 13:57:39 +0200, Vladimir V. Kobal wrote: > > With fastforwarding off the system works well and boots without panicing. > OK, that narrows it down. Are you using any filtering such as PF, ipfw, etc.? Best, George From dougb at FreeBSD.org Tue Dec 23 12:13:29 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Dec 23 12:13:35 2008 Subject: ipv6 bugfix, need review. In-Reply-To: <20081223001216.GH18389@elvis.mu.org> References: <20081223001216.GH18389@elvis.mu.org> Message-ID: On Mon, 22 Dec 2008, Alfred Perlstein wrote: > Hey guys, we found a bug at Juniper and it resolves an issue > for us. I've been asked to forward this to FreeBSD, I honestly > am not that clear on the issue so I'm hoping someone can step > up to review this. > > Synopsis is: > > The traffic class byte is set to 0x00000000 in the header of some > BGP packets sent between interfaces that have IPv6 addresses, > instead of the correct setting 0xc0 (INTERNETCONTROL). > > Fix is small and attached. One thing I am wondering, do we > need to check "if (inp)" ? I don't think so. How about adding an assert to the patch to prove this theory? :) I'll test it on my home box (which has IPv6) as soon as I'm done with the stuff I'm working on atm. hth, Doug -- This .signature sanitized for your protection From gnn at freebsd.org Tue Dec 23 12:39:05 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Dec 23 12:39:11 2008 Subject: A new tool for low level testing... Message-ID: <7ihc4u3adr.wl%gnn@neville-neil.com> Hi, I just checked in a small tool to HEAD in /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect ethernet packets just about the driver layer without involving the protocol stacks. This is useful for people doing low level testing of drivers and switches. If you happen to be lucky enough to have an ethernet packet generator (ixia et al) this will do what you want in terms of reflecting the packets back. Later, George From vlad at prokk.net Tue Dec 23 12:49:36 2008 From: vlad at prokk.net (Vladimir V. Kobal) Date: Tue Dec 23 12:49:42 2008 Subject: Panic on boot with em1 attached In-Reply-To: <7ik59q3csb.wl%gnn@neville-neil.com> References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> <000201c964f5$aa94e6a0$ffbeb3e0$@net> <7ik59q3csb.wl%gnn@neville-neil.com> Message-ID: <000301c9653f$f32c6dd0$d9854970$@net> We are using pf+ALTQ for shaping and ipfw for filtering, diverting into netgraph nodes, attaching altq queues. Best regards, Vladimir -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of gnn@freebsd.org Sent: Tuesday, December 23, 2008 9:36 PM To: Vladimir V. Kobal Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached OK, that narrows it down. Are you using any filtering such as PF, ipfw, etc.? Best, George From qing.li at bluecoat.com Tue Dec 23 13:18:34 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Tue Dec 23 13:18:45 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <4950F770.3090700@dlr.de> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> Message-ID: Hi Hartmut, I appreciate your candid feedback. You raised many valid points. I combined both of your emails in this reply, please see my comments below ... > > Also one thing that would be extremly helpful is a short description of > that interface arp(4). Currently one has to reverse engineer arp.c to > understand how to do things. > This project has been in the making for quite a long time. I had a lot of content prepared to write in the commit message in my head, but when the moment final arrived in the end, my mind went blank perhaps due to that much anticipation. Funny how that works. I will provide more text on this subject after things have settled down. > > - this is code maintained in another repository and imported to > FreeBSD. Luckily the cvs-times are over where this commit would have > taken the files of the vendor branch. But nevertheless it is never a > good idea to change code in contrib without pushing the changes > upstream. > This was due to my lack of understanding about the structure of that section of the repository. Thank you for providing this information. > > - you just removed a lot of code and left the ipNetToMedia table > entirely disfunctional. > > - you obviously did not test the change. Otherwise you would have seen > that it did not work. > No, I did not test that piece of code. There were so much to do in the end, and having modified arp and ndp myself, I estimated the fix would not be difficult even if I broke it. So I took a calculated gamble. Thank you for fixing my bugs. > > And another point: when changing external interfaces it might be > possible to ask for a full port build with the changes to look for the > fall-out on ports. I would say that this commit was a good candidate to > get the port maintainers into the boat earlier. > > not so happy, > You are absolutely right. This was a complete oversight on my part. I was telling myself "I think I am forgetting something". ... then I remembered when the first port breakage report arrived ;-) To be fair though, I did send a message titled "last call for L2/L3 rewrite code review" a week before the commit to net@, current@ and all of the developers. And I have sent many emails on this subject in the past few years. A couple of points I hope you could recognize: 1. The arp-v2 project replaces a major networking kernel design and all of its dependencies that have been in operation for many years (16+ ??). The networking kernel went through quite a surgery so do expect things will continue to evolve. 2. This is the first time I am making such a major change in the kernel. Since I am still learning the process, I am bound to make mistakes but I will not repeat these mistakes in the future. My goal is to be diligent in monitoring the problem reports and provide timely responses and fixes. And finally I want to thank you and others for your hard work in helping me cleaning up the ports. Thanks again. Cheers, --Qing From julian at elischer.org Tue Dec 23 13:29:11 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Dec 23 13:29:16 2008 Subject: A new tool for low level testing... In-Reply-To: <7ihc4u3adr.wl%gnn@neville-neil.com> References: <7ihc4u3adr.wl%gnn@neville-neil.com> Message-ID: <4951515C.4030706@elischer.org> gnn@freebsd.org wrote: > Hi, > > I just checked in a small tool to HEAD in > /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect > ethernet packets just about the driver layer without involving the > protocol stacks. This is useful for people doing low level testing of > drivers and switches. If you happen to be lucky enough to have an > ethernet packet generator (ixia et al) this will do what you want in > terms of reflecting the packets back. > > Later, > 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" OR ngctl mkpeer em0: echo lower echo hmmmmm no this would leave the source and destination headers in hte same order.. they need to be swapped.. ok so I need to make a patch, but it would be much quicker than a user utility.. From kip.macy at gmail.com Tue Dec 23 14:08:49 2008 From: kip.macy at gmail.com (Kip Macy) Date: Tue Dec 23 14:08:55 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> Message-ID: <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> Hi Harti, Let me first preface this e-mail by saying that you and I have had very little contact prior to this. The comments below are meant to explain the point of view of myself and that of a number of other developers with whom I have spoken, not to criticize you or trivialize your point of view. >> - you just removed a lot of code and left the ipNetToMedia table >> entirely disfunctional. >> >> - you obviously did not test the change. Otherwise you would have seen >> that it did not work. Even those of us well versed in networking are not familiar with all subsystems. I know that whenever someone breaks a subsystem that is important to me that I am indignant. That is natural. Although Sam Leffler reviewed much of the code before commit, and I (re-)implemented all of the locking, we have to accept that there was really only one person working on this. He publicly asked for a review many times and made a good faith effort to test all of the dependent network subsystems that he could. However, at the end of the day the code goes in and bugs get fixed as they crop up. Most of us feel that he has done a commendable job in dealing with issues promptly. >> And another point: when changing external interfaces it might be >> possible to ask for a full port build with the changes to look for the >> fall-out on ports. I would say that this commit was a good candidate > to >> get the port maintainers into the boat earlier. >> >> not so happy, The only reasonable way to do a full ports build is to ask portmgr to use the build systems. Although it may now be possible with svn, in the past there was no way for him to do that for out of tree code. Hence portmgr does not share your point of view. What we should have done is grepped for RTM_RESOLVE and the flags that I removed. However, that did not occur to me. He asked on numerous occasions for review and someone should have brought it up then. We do not feel that it is reasonable to hold him solely responsible when he did not act in a unilateral fashion. Thank you for taking care of that bit of breakage. Cheers, Kip -- Als die Nazis die Kommunisten holten, habe ich geschwiegen; ich war ja kein Kommunist. Als sie die Sozialdemokraten einsperrten, habe ich geschwiegen; ich war ja kein Sozialdemokrat. Als sie die Gewerkschafter holten, habe ich nicht protestiert; ich war ja kein Gewerkschafter. Als sie die Juden holten, habe ich geschwiegen; ich war ja kein Jude. Als sie mich holten, gab es keinen mehr, der protestieren konnte. From hartmut.brandt at dlr.de Tue Dec 23 14:27:59 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Tue Dec 23 14:28:06 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> Message-ID: <495165D8.2070409@dlr.de> Li, Qing wrote: > Hi Hartmut, > > I appreciate your candid feedback. You raised many valid points. > I combined both of your emails in this reply, please see my > comments below ... > > > You are absolutely right. This was a complete oversight on my part. > I was telling myself "I think I am forgetting something". > ... then I remembered when the first port breakage report arrived ;-) > > To be fair though, I did send a message titled > "last call for L2/L3 rewrite code review" a week before the commit > to net@, current@ and all of the developers. > And I have sent many emails on this subject in the past few years. > > A couple of points I hope you could recognize: > > 1. The arp-v2 project replaces a major networking kernel design and > all of its dependencies that have been in operation for many years > (16+ ??). The networking kernel went through quite a surgery so > do expect things will continue to evolve. > > 2. This is the first time I am making such a major change in the > kernel. Since I am still learning the process, I am bound to > make mistakes but I will not repeat these mistakes in the future. > > My goal is to be diligent in monitoring the problem reports and > provide timely responses and fixes. > > And finally I want to thank you and others for your hard work in > helping me cleaning up the ports. > > Well, my mail was probably somewhat harsh, I'm usually more polite. You know, that's the kind of mood you are in after a couple of hours of useless work. Of course I appreciate your work and, I must say, you're an hero for taking this. In any case there is still an Todo on my side: the routing information for NETNATM is currently lost somewhere between L2 and L3 :-) I guess I come back to you in the new year to fix this issue... Have to fetch my ATM equipment from the corner where it is collecting dust to setup a testbed. In the mean time I will do an bsnmp import to fix the arp table problem. keep on your good work, harti From antoine at freebsd.org Tue Dec 23 14:28:47 2008 From: antoine at freebsd.org (Antoine Brodin) Date: Tue Dec 23 14:28:53 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812150634.mBF6YDVC060565@freefall.freebsd.org> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> Message-ID: On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote: > Hi All, > > The arp-v2 changes have been committed into HEAD. > Please report problems to me and Kip Macy. Hi, I still have a panic with ipv6 enabled with current from yesterday afternoon (in6.c rev 1.92): %%% # cat info.1 Dump header from device /dev/ad6s1b Architecture: i386 Architecture Version: 2 Dump Length: 180998144B (172 MB) Blocksize: 512 Dumptime: Tue Dec 23 13:52:41 2008 Hostname: barton.dreadbsd.org. Magic: FreeBSD Kernel Dump Version String: FreeBSD 8.0-CURRENT #2: Mon Dec 22 17:44:06 CET 2008 root@barton.dreadbsd.org.:/usr/obj/usr/src/sys/GENERIC Panic String: _rw_rlock (lle): wlock already held @ /usr/src/sys/netinet6/in6.c:2221 Dump Parity: 1345446215 Bounds: 1 Dump Status: good # kgdb /boot/kernel/kernel vmcore.1 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"... Unread portion of the kernel message buffer: lock order reversal: 1st 0xc549aa08 lle (lle) @ /usr/src/sys/netinet6/in6.c:2219 2nd 0xc51b9608 if_afdata (if_afdata) @ /usr/src/sys/netinet6/nd6_rtr.c:1336 KDB: stack backtrace: db_trace_self_wrapper(c0be5fcb,c4b88648,c08757f6,4,c0be152e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0be152e,c4d26f50,c4d24ac0,c4b886a4,...) at kdb_backtrace+0x29 _witness_debugger(c0be8cb5,c51b9608,c0bf1709,c4d24ac0,c0bfff5d,...) at _witness_debugger+0x26 witness_checkorder(c51b9608,9,c0bfff5d,538,0,...) at witness_checkorder+0x839 _rw_wlock(c51b9608,c0bfff5d,538,c544c000,c51f6a80,...) at _rw_wlock+0x82 find_pfxlist_reachable_router(f4,c549aa48,c4b88724,c08467fd,c0d35140,...) at find_pfxlist_reachable_router+0x37 pfxlist_onlink_check(c549aa00,3a98,6,1,c188ca38,...) at pfxlist_onlink_check+0x2e nd6_na_input(c544c000,28,20,1,7dc,...) at nd6_na_input+0x518 icmp6_input(c4b88aa0,c4b88ab4,3a,c54230a4,c5923028,...) at icmp6_input+0x1cb6 ip6_input(c58ed700,c070a8b2,86dd,c51b9400,86dd,...) at ip6_input+0x101d netisr_dispatch(1b,c58ed700,c4ed6480,1,c51b9400,...) at netisr_dispatch+0x72 ether_demux(c51b9400,c58ed700,3,0,3,...) at ether_demux+0x1f1 ether_input(c51b9400,c58ed700,c549f000,c524b000,c58c8008,...) at ether_input+0x37f ieee80211_deliver_data(c524b000,c549f000,c58ed700,c4f1947c,4,...) at ieee80211_deliver_data+0x94 sta_input(c549f000,c58ed700,25,ffffffa0,669,...) at sta_input+0x9fc ath_rx_proc(c4ede000,1,c0be7657,54,c4f0a35c,...) at ath_rx_proc+0x4b6 taskqueue_run(c4f0a340,c4f0a35c,0,c0bd996f,0,...) at taskqueue_run+0x10b taskqueue_thread_loop(c4ede26c,c4b88d38,c0bded0e,32d,c0d32c40,...) at taskqueue_thread_loop+0x68 fork_exit(c086ea30,c4ede26c,c4b88d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4b88d70, ebp = 0 --- panic: _rw_rlock (lle): wlock already held @ /usr/src/sys/netinet6/in6.c:2221 cpuid = 0 Uptime: 1h40m57s Physical memory: 1519 MB Dumping 172 MB: 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0833dcc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc08340a5 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0832526 in _rw_rlock (rw=0xc549aa08, file=0xc0bfe9e5 "/usr/src/sys/netinet6/in6.c", line=2221) at /usr/src/sys/kern/kern_rwlock.c:291 #4 0xc09a722a in in6_lltable_lookup (llt=0xc5209e00, flags=0, l3addr=0xc4b886a0) at /usr/src/sys/netinet6/in6.c:2221 #5 0xc09b937c in nd6_lookup (addr6=0xc51ebc88, flags=0, ifp=0xc51b9400) at if_llatbl.h:188 #6 0xc09beef4 in find_pfxlist_reachable_router (pr=Variable "pr" is not available. ) at /usr/src/sys/netinet6/nd6_rtr.c:1337 #7 0xc09bef8e in pfxlist_onlink_check () at /usr/src/sys/netinet6/nd6_rtr.c:1376 #8 0xc09bbde8 in nd6_na_input (m=0xc544c000, off=40, icmp6len=32) at /usr/src/sys/netinet6/nd6_nbr.c:742 #9 0xc09a5266 in icmp6_input (mp=0xc4b88aa0, offp=0xc4b88ab4, proto=58) at /usr/src/sys/netinet6/icmp6.c:808 #10 0xc09b2bdd in ip6_input (m=0xc58ed700) at /usr/src/sys/netinet6/ip6_input.c:886 #11 0xc08e2832 in netisr_dispatch (num=27, m=0xc58ed700) at /usr/src/sys/net/netisr.c:178 #12 0xc08dc221 in ether_demux (ifp=0xc51b9400, m=0xc58ed700) at /usr/src/sys/net/if_ethersubr.c:864 #13 0xc08dc68f in ether_input (ifp=0xc51b9400, m=0xc58ed700) at /usr/src/sys/net/if_ethersubr.c:721 #14 0xc08fe974 in ieee80211_deliver_data (vap=0xc524b000, ni=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/net80211/ieee80211_input.c:223 #15 0xc091899c in sta_input (ni=0xc549f000, m=0xc58ed700, rssi=37, noise=-96, rstamp=1641) at /usr/src/sys/net80211/ieee80211_sta.c:824 #16 0xc0584b26 in ath_rx_proc (arg=0xc4ede000, npending=1) at /usr/src/sys/dev/ath/if_ath.c:4218 #17 0xc086e93b in taskqueue_run (queue=0xc4f0a340) at /usr/src/sys/kern/subr_taskqueue.c:282 #18 0xc086ea98 in taskqueue_thread_loop (arg=0xc4ede26c) at /usr/src/sys/kern/subr_taskqueue.c:403 #19 0xc08108f8 in fork_exit (callout=0xc086ea30 , arg=0xc4ede26c, frame=0xc4b88d38) at /usr/src/sys/kern/kern_fork.c:821 #20 0xc0b1a1d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) # ident /boot/kernel/kernel | grep netinet6 $FreeBSD: src/sys/netinet6/dest6.c,v 1.15 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/frag6.c,v 1.41 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/icmp6.c,v 1.101 2008/12/17 13:00:18 bz Exp $ $FreeBSD: src/sys/netinet6/in6.c,v 1.92 2008/12/22 07:11:15 qingli Exp $ $FreeBSD: src/sys/netinet6/in6_cksum.c,v 1.17 2007/12/10 16:03:37 obrien Exp $ $FreeBSD: src/sys/netinet6/in6_gif.c,v 1.34 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/in6_ifattach.c,v 1.53 2008/12/12 02:07:45 kmacy Exp $ $FreeBSD: src/sys/netinet6/in6_pcb.c,v 1.107 2008/12/15 21:50:54 bz Exp $ $FreeBSD: src/sys/netinet6/in6_proto.c,v 1.57 2008/12/11 16:26:38 bz Exp $ $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ $FreeBSD: src/sys/netinet6/in6_rmx.c,v 1.34 2008/12/17 10:03:49 qingli Exp $ $FreeBSD: src/sys/netinet6/in6_src.c,v 1.65 2008/12/16 02:30:42 kmacy Exp $ $FreeBSD: src/sys/netinet6/ip6_forward.c,v 1.46 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/ip6_id.c,v 1.9 2007/12/10 16:03:38 obrien Exp $ $FreeBSD: src/sys/netinet6/ip6_input.c,v 1.112 2008/12/22 12:54:52 bz Exp $ $FreeBSD: src/sys/netinet6/ip6_output.c,v 1.127 2008/12/17 13:00:18 bz Exp $ $FreeBSD: src/sys/netinet6/mld6.c,v 1.39 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/nd6.c,v 1.103 2008/12/17 10:03:49 qingli Exp $ $FreeBSD: src/sys/netinet6/nd6_nbr.c,v 1.59 2008/12/16 02:47:22 kmacy Exp $ $FreeBSD: src/sys/netinet6/nd6_rtr.c,v 1.57 2008/12/17 10:27:34 qingli Exp $ $FreeBSD: src/sys/netinet6/raw_ip6.c,v 1.98 2008/12/17 13:00:18 bz Exp $ $FreeBSD: src/sys/netinet6/route6.c,v 1.18 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/scope6.c,v 1.22 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/sctp6_usrreq.c,v 1.47 2008/12/06 13:19:54 rrs Exp $ $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ $FreeBSD: src/sys/netinet6/udp6_usrreq.c,v 1.103 2008/12/17 13:00:18 bz Exp $ %%% Cheers, Antoine From hartmut.brandt at dlr.de Tue Dec 23 14:39:32 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Tue Dec 23 14:39:44 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> Message-ID: <4951688D.5080202@dlr.de> Hi Kip, Kip Macy wrote: >>> And another point: when changing external interfaces it might be >>> possible to ask for a full port build with the changes to look for the >>> fall-out on ports. I would say that this commit was a good candidate >>> >> to >> >>> get the port maintainers into the boat earlier. >>> >>> not so happy, >>> > > The only reasonable way to do a full ports build is to ask portmgr to > use the build systems. Although it may now be possible with svn, in > the past there was no way for him to do that for out of tree code. > Hence portmgr does not share your point of view. > Well, they did this in the past, for example when I did some heavy work on make(1). At that time Kris did this, I don't know through which magic, though. > What we should have done is grepped for RTM_RESOLVE and the flags that > I removed. However, that did not occur to me. He asked on numerous > occasions for review and someone should have brought it up then. We do > not feel that it is reasonable to hold him solely responsible when he > did not act in a unilateral fashion. > > I usually take care of stuff that touches anything that has to do with the SNMP stuff, but this time the triggering did not work. I probably was sure that people will directly mail before touching someting in src/contrib. > Thank you for taking care of that bit of breakage. > No problem. That was a good kick to finally look how this vendor import stuff works and get the next import prepared. Don't take it too serious, 't was just a bad day (it started with a broken cup :-) harti From kmacy at freebsd.org Tue Dec 23 17:09:30 2008 From: kmacy at freebsd.org (Kip Macy) Date: Tue Dec 23 17:09:37 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> Message-ID: <3c1674c90812231709u1e4b107du8995b6ffc6b8e80e@mail.gmail.com> The should be fixed with 186468. Please confirm. Thanks, Kip On Tue, Dec 23, 2008 at 2:01 PM, Antoine Brodin wrote: > On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote: >> Hi All, >> >> The arp-v2 changes have been committed into HEAD. >> Please report problems to me and Kip Macy. > > Hi, > > I still have a panic with ipv6 enabled with current from yesterday > afternoon (in6.c rev 1.92): > > %%% > # cat info.1 > Dump header from device /dev/ad6s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 180998144B (172 MB) > Blocksize: 512 > Dumptime: Tue Dec 23 13:52:41 2008 > Hostname: barton.dreadbsd.org. > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 8.0-CURRENT #2: Mon Dec 22 17:44:06 CET 2008 > root@barton.dreadbsd.org.:/usr/obj/usr/src/sys/GENERIC > Panic String: _rw_rlock (lle): wlock already held @ > /usr/src/sys/netinet6/in6.c:2221 > Dump Parity: 1345446215 > Bounds: 1 > Dump Status: good > > # kgdb /boot/kernel/kernel vmcore.1 > 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"... > > Unread portion of the kernel message buffer: > lock order reversal: > 1st 0xc549aa08 lle (lle) @ /usr/src/sys/netinet6/in6.c:2219 > 2nd 0xc51b9608 if_afdata (if_afdata) @ /usr/src/sys/netinet6/nd6_rtr.c:1336 > KDB: stack backtrace: > db_trace_self_wrapper(c0be5fcb,c4b88648,c08757f6,4,c0be152e,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0be152e,c4d26f50,c4d24ac0,c4b886a4,...) at kdb_backtrace+0x29 > _witness_debugger(c0be8cb5,c51b9608,c0bf1709,c4d24ac0,c0bfff5d,...) at > _witness_debugger+0x26 > witness_checkorder(c51b9608,9,c0bfff5d,538,0,...) at witness_checkorder+0x839 > _rw_wlock(c51b9608,c0bfff5d,538,c544c000,c51f6a80,...) at _rw_wlock+0x82 > find_pfxlist_reachable_router(f4,c549aa48,c4b88724,c08467fd,c0d35140,...) > at find_pfxlist_reachable_router+0x37 > pfxlist_onlink_check(c549aa00,3a98,6,1,c188ca38,...) at > pfxlist_onlink_check+0x2e > nd6_na_input(c544c000,28,20,1,7dc,...) at nd6_na_input+0x518 > icmp6_input(c4b88aa0,c4b88ab4,3a,c54230a4,c5923028,...) at icmp6_input+0x1cb6 > ip6_input(c58ed700,c070a8b2,86dd,c51b9400,86dd,...) at ip6_input+0x101d > netisr_dispatch(1b,c58ed700,c4ed6480,1,c51b9400,...) at netisr_dispatch+0x72 > ether_demux(c51b9400,c58ed700,3,0,3,...) at ether_demux+0x1f1 > ether_input(c51b9400,c58ed700,c549f000,c524b000,c58c8008,...) at > ether_input+0x37f > ieee80211_deliver_data(c524b000,c549f000,c58ed700,c4f1947c,4,...) at > ieee80211_deliver_data+0x94 > sta_input(c549f000,c58ed700,25,ffffffa0,669,...) at sta_input+0x9fc > ath_rx_proc(c4ede000,1,c0be7657,54,c4f0a35c,...) at ath_rx_proc+0x4b6 > taskqueue_run(c4f0a340,c4f0a35c,0,c0bd996f,0,...) at taskqueue_run+0x10b > taskqueue_thread_loop(c4ede26c,c4b88d38,c0bded0e,32d,c0d32c40,...) at > taskqueue_thread_loop+0x68 > fork_exit(c086ea30,c4ede26c,c4b88d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc4b88d70, ebp = 0 --- > panic: _rw_rlock (lle): wlock already held @ /usr/src/sys/netinet6/in6.c:2221 > cpuid = 0 > Uptime: 1h40m57s > Physical memory: 1519 MB > Dumping 172 MB: 157 141 125 109 93 77 61 45 29 13 > Reading symbols from /boot/kernel/sound.ko...Reading symbols from > /boot/kernel/sound.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from > /boot/kernel/snd_ich.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/snd_ich.ko > Reading symbols from /boot/kernel/radeon.ko...Reading symbols from > /boot/kernel/radeon.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /boot/kernel/drm.ko...Reading symbols from > /boot/kernel/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc0833dcc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xc08340a5 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc0832526 in _rw_rlock (rw=0xc549aa08, file=0xc0bfe9e5 > "/usr/src/sys/netinet6/in6.c", line=2221) > at /usr/src/sys/kern/kern_rwlock.c:291 > #4 0xc09a722a in in6_lltable_lookup (llt=0xc5209e00, flags=0, > l3addr=0xc4b886a0) at /usr/src/sys/netinet6/in6.c:2221 > #5 0xc09b937c in nd6_lookup (addr6=0xc51ebc88, flags=0, > ifp=0xc51b9400) at if_llatbl.h:188 > #6 0xc09beef4 in find_pfxlist_reachable_router (pr=Variable "pr" is > not available. > ) at /usr/src/sys/netinet6/nd6_rtr.c:1337 > #7 0xc09bef8e in pfxlist_onlink_check () at > /usr/src/sys/netinet6/nd6_rtr.c:1376 > #8 0xc09bbde8 in nd6_na_input (m=0xc544c000, off=40, icmp6len=32) at > /usr/src/sys/netinet6/nd6_nbr.c:742 > #9 0xc09a5266 in icmp6_input (mp=0xc4b88aa0, offp=0xc4b88ab4, > proto=58) at /usr/src/sys/netinet6/icmp6.c:808 > #10 0xc09b2bdd in ip6_input (m=0xc58ed700) at > /usr/src/sys/netinet6/ip6_input.c:886 > #11 0xc08e2832 in netisr_dispatch (num=27, m=0xc58ed700) at > /usr/src/sys/net/netisr.c:178 > #12 0xc08dc221 in ether_demux (ifp=0xc51b9400, m=0xc58ed700) at > /usr/src/sys/net/if_ethersubr.c:864 > #13 0xc08dc68f in ether_input (ifp=0xc51b9400, m=0xc58ed700) at > /usr/src/sys/net/if_ethersubr.c:721 > #14 0xc08fe974 in ieee80211_deliver_data (vap=0xc524b000, > ni=dwarf2_read_address: Corrupted DWARF expression. > ) at /usr/src/sys/net80211/ieee80211_input.c:223 > #15 0xc091899c in sta_input (ni=0xc549f000, m=0xc58ed700, rssi=37, > noise=-96, rstamp=1641) > at /usr/src/sys/net80211/ieee80211_sta.c:824 > #16 0xc0584b26 in ath_rx_proc (arg=0xc4ede000, npending=1) at > /usr/src/sys/dev/ath/if_ath.c:4218 > #17 0xc086e93b in taskqueue_run (queue=0xc4f0a340) at > /usr/src/sys/kern/subr_taskqueue.c:282 > #18 0xc086ea98 in taskqueue_thread_loop (arg=0xc4ede26c) at > /usr/src/sys/kern/subr_taskqueue.c:403 > #19 0xc08108f8 in fork_exit (callout=0xc086ea30 > , arg=0xc4ede26c, frame=0xc4b88d38) > at /usr/src/sys/kern/kern_fork.c:821 > #20 0xc0b1a1d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > (kgdb) > > # ident /boot/kernel/kernel | grep netinet6 > $FreeBSD: src/sys/netinet6/dest6.c,v 1.15 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/frag6.c,v 1.41 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/icmp6.c,v 1.101 2008/12/17 13:00:18 bz Exp $ > $FreeBSD: src/sys/netinet6/in6.c,v 1.92 2008/12/22 07:11:15 qingli Exp $ > $FreeBSD: src/sys/netinet6/in6_cksum.c,v 1.17 2007/12/10 16:03:37 > obrien Exp $ > $FreeBSD: src/sys/netinet6/in6_gif.c,v 1.34 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/in6_ifattach.c,v 1.53 2008/12/12 > 02:07:45 kmacy Exp $ > $FreeBSD: src/sys/netinet6/in6_pcb.c,v 1.107 2008/12/15 21:50:54 bz Exp $ > $FreeBSD: src/sys/netinet6/in6_proto.c,v 1.57 2008/12/11 16:26:38 bz Exp $ > $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ > $FreeBSD: src/sys/netinet6/in6_rmx.c,v 1.34 2008/12/17 10:03:49 > qingli Exp $ > $FreeBSD: src/sys/netinet6/in6_src.c,v 1.65 2008/12/16 02:30:42 kmacy Exp $ > $FreeBSD: src/sys/netinet6/ip6_forward.c,v 1.46 2008/12/02 > 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/ip6_id.c,v 1.9 2007/12/10 16:03:38 obrien Exp $ > $FreeBSD: src/sys/netinet6/ip6_input.c,v 1.112 2008/12/22 12:54:52 bz Exp $ > $FreeBSD: src/sys/netinet6/ip6_output.c,v 1.127 2008/12/17 > 13:00:18 bz Exp $ > $FreeBSD: src/sys/netinet6/mld6.c,v 1.39 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/nd6.c,v 1.103 2008/12/17 10:03:49 qingli Exp $ > $FreeBSD: src/sys/netinet6/nd6_nbr.c,v 1.59 2008/12/16 02:47:22 kmacy Exp $ > $FreeBSD: src/sys/netinet6/nd6_rtr.c,v 1.57 2008/12/17 10:27:34 > qingli Exp $ > $FreeBSD: src/sys/netinet6/raw_ip6.c,v 1.98 2008/12/17 13:00:18 bz Exp $ > $FreeBSD: src/sys/netinet6/route6.c,v 1.18 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/scope6.c,v 1.22 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/sctp6_usrreq.c,v 1.47 2008/12/06 > 13:19:54 rrs Exp $ > $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ > $FreeBSD: src/sys/netinet6/udp6_usrreq.c,v 1.103 2008/12/17 > 13:00:18 bz Exp $ > %%% > > Cheers, > > Antoine > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Als die Nazis die Kommunisten holten, habe ich geschwiegen; ich war ja kein Kommunist. Als sie die Sozialdemokraten einsperrten, habe ich geschwiegen; ich war ja kein Sozialdemokrat. Als sie die Gewerkschafter holten, habe ich nicht protestiert; ich war ja kein Gewerkschafter. Als sie die Juden holten, habe ich geschwiegen; ich war ja kein Jude. Als sie mich holten, gab es keinen mehr, der protestieren konnte. From stutiredboy at gmail.com Tue Dec 23 18:31:06 2008 From: stutiredboy at gmail.com (stutiredboy) Date: Tue Dec 23 18:31:15 2008 Subject: [help]strange problem about gethostbyname/getaddrinfo In-Reply-To: References: Message-ID: <49519EE4.7040109@gmail.com> Hajimu UMEMOTO ??: > Hi, > > >>>>>> On Wed, 10 Dec 2008 13:48:51 +0800 >>>>>> "=?GB2312?B?s8LQocn6?=" said: >>>>>> > > stutiredboy> hi,all,we have a project which must resolv some domains in the server > stutiredboy> process > stutiredboy> our system in FreeBSD 6.2 or 6.3, the server process may open 7000+ > stutiredboy> sockets,not fork > > Umm, it seems your system is slightly old. I believe 6.3-RELEASE is > okay. But, there was a bug on 6.2 and earlier that rejected file > descriptors higher than FD_SETSIZE even when using kevent(2). > > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/resolv/res_send.c#rev1.2.2.5 > > Perhaps, it is your case. > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ > hi, thanks for your response, but the testing server we use is FreeBSD 6.3, %uname -a FreeBSD localhost 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:45:45 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 Best Wishes ! From alfred at freebsd.org Tue Dec 23 19:05:54 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Dec 23 19:06:01 2008 Subject: ipv6 bugfix, need review. In-Reply-To: References: <20081223001216.GH18389@elvis.mu.org> Message-ID: <20081224030554.GX18389@elvis.mu.org> * Doug Barton [081223 11:46] wrote: > On Mon, 22 Dec 2008, Alfred Perlstein wrote: > > >Hey guys, we found a bug at Juniper and it resolves an issue > >for us. I've been asked to forward this to FreeBSD, I honestly > >am not that clear on the issue so I'm hoping someone can step > >up to review this. > > > >Synopsis is: > > > > The traffic class byte is set to 0x00000000 in the header of some > > BGP packets sent between interfaces that have IPv6 addresses, > > instead of the correct setting 0xc0 (INTERNETCONTROL). > > > >Fix is small and attached. One thing I am wondering, do we > >need to check "if (inp)" ? I don't think so. > > How about adding an assert to the patch to prove this theory? :) > > I'll test it on my home box (which has IPv6) as soon as I'm done with the > stuff I'm working on atm. > > > hth, > > Doug Thanks Doug, will do. Please let me know results. do you know how to test if this is actually being excersized? I guess you could add a sysctl that gets incremented each time this codepath is hit to test? -- - Alfred Perlstein From linimon at lonesome.com Wed Dec 24 00:58:24 2008 From: linimon at lonesome.com (Mark Linimon) Date: Wed Dec 24 00:58:31 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <4951688D.5080202@dlr.de> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> <4951688D.5080202@dlr.de> Message-ID: <20081224083500.GB8120@soaustin.net> On Tue, Dec 23, 2008 at 11:39:09PM +0100, Hartmut Brandt wrote: > Well, they did this in the past, for example when I did some heavy work > on make(1). At that time Kris did this, I don't know through which > magic, though. Just email portmgr@ and ask for a regression-test on the build cluster. We generally use amd64-7 and tell it "rebuild all ports with the following modified src tree." We can't guarantee that it will happen immediately (we do use the cluster for building packages, after all :-) ) but we do our best to make it a 2-way street. mcl From p.pisati at oltrelinux.com Wed Dec 24 03:09:29 2008 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Wed Dec 24 03:09:35 2008 Subject: A new tool for low level testing... In-Reply-To: <4951515C.4030706@elischer.org> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> Message-ID: <495215A6.2040002@oltrelinux.com> Julian Elischer wrote: > > OR > > ngctl mkpeer em0: echo lower echo > > > hmmmmm no this would leave the source and destination headers in hte > same order.. they need to be swapped.. > > ok so I need to make a patch, but it would be much quicker than a user > utility.. what about a netgraph cookbook? From rizzo at iet.unipi.it Wed Dec 24 03:30:16 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Dec 24 03:30:22 2008 Subject: A new tool for low level testing... In-Reply-To: <495215A6.2040002@oltrelinux.com> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> Message-ID: <20081224111546.GA59523@onelab2.iet.unipi.it> On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: > Julian Elischer wrote: > > > >OR > > > >ngctl mkpeer em0: echo lower echo > > > > > >hmmmmm no this would leave the source and destination headers in hte > >same order.. they need to be swapped.. > > > >ok so I need to make a patch, but it would be much quicker than a user > >utility.. > what about a netgraph cookbook? indeed, that would be a nice Xmas present! cheers luigi From brde at optusnet.com.au Wed Dec 24 04:46:24 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Dec 24 04:46:31 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <200812132030.15665.max@love2party.net> <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> Message-ID: <20081224232356.O754@delplex.bde.org> On Tue, 23 Dec 2008, Randall Stewart wrote: > 4) revamped my s9indent use.. I ran it and then patched back > in just its complaints about me... that way the other s9 issues > can stay in the file untouched by me :-D Thanks, but it still has many of the style bugs already pointed out and a few new ones. Please fix them and s9indent so that they don't get pointed out again :-). % Index: netinet/udp_usrreq.c % =================================================================== % --- netinet/udp_usrreq.c (revision 185928) % +++ netinet/udp_usrreq.c (working copy) % @@ -488,41 +488,76 @@ % struct mbuf *n; % % n = m_copy(m, 0, M_COPYALL); % - if (n != NULL) % - udp_append(last, ip, n, iphlen + % - sizeof(struct udphdr), &udp_in); % - INP_RUNLOCK(last); % + Extra blank line. % + if (last->inp_ppcb == NULL) { % + if (n != NULL) % + udp_append(last, ip, n, iphlen + % + sizeof(struct udphdr), &udp_in); Line too long. % + INP_RUNLOCK(last); % + } else { % + /* % + * Engage the tunneling protocol we % + * will have to leave the info_lock % + * up, since we are hunting through % + * multiple UDP inp's hope we don't % + * break :-( Missing punctuation. % + * % + * XXXML: Maybe add a flag to the % + * prototype so that the tunneling % + * can defer work that can't be done % + * under the info lock? % + */ % + udp_tunnel_func_t tunnel_func; This typedef is very verbose... % + % + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; ... line too long, caused by the verbose typedef. Casts are not followed by a space in KNF. This style bug is made fairly consistently in this patch. Bogus cast (depends on undefined behaviour to save space). % + tunnel_func(m, iphlen, last); % + INP_RUNLOCK(last); % + } % } % last = inp; % /* % - * Don't look for additional matches if this one does % - * not have either the SO_REUSEPORT or SO_REUSEADDR % - * socket options set. This heuristic avoids % - * searching through all pcbs in the common case of a % - * non-shared port. It assumes that an application % - * will never clear these options after setting them. % + * Don't look for additional matches if this one % + * does not have either the SO_REUSEPORT or % + * SO_REUSEADDR socket options set. This heuristic % + * avoids searching through all pcbs in the common % + * case of a non-shared port. It assumes that an % + * application will never clear these options after % + * setting them. % */ % if ((last->inp_socket->so_options & % - (SO_REUSEPORT|SO_REUSEADDR)) == 0) % + (SO_REUSEPORT | SO_REUSEADDR)) == 0) You didn't have to touch this statement. Touching it improves it. % break; % } % % if (last == NULL) { % /* % - * No matching pcb found; discard datagram. (No need % - * to send an ICMP Port Unreachable for a broadcast % - * or multicast datgram.) % + * No matching pcb found; discard datagram. (No % + * need to send an ICMP Port Unreachable for a % + * broadcast or multicast datgram.) You didn't have to touch this. Touching it unimproves it. % ... % } % - % /* % * Locate pcb for datagram. % */ % @@ -553,7 +588,6 @@ % INP_INFO_RUNLOCK(&V_udbinfo); % return; % } % - % /* % * Check the minimum TTL for socket. % */ You didn't have to touch these. Touching them arguably unimproves them, though strict KNF probably doesn't permit these blank lines. % @@ -563,6 +597,18 @@ % INP_RUNLOCK(inp); % goto badunlocked; % } % + if (inp->inp_ppcb) { It is preferable to compare pointers explicitly with NULL. The previous comparision of inp_ppcb in this patch is explicit (but it is for equality). This and all of the following comparisions are implicit (for inequality). % @@ -1138,10 +1184,41 @@ % INP_INFO_WUNLOCK(&V_udbinfo); % inp->inp_vflag |= INP_IPV4; % inp->inp_ip_ttl = V_ip_defttl; % + /* % + * UDP does not have a per-protocol % + * pcb (inp->inp_ppcb). We use this % + * pointer for kernel tunneling pointer. % + * If we ever need to have a protocol % + * block we will need to move this % + * function pointer there. Null % + * in this pointer means "do the normal % + * thing". % + */ Lines too short (formatted for 50-column terminals). Normal entence breaks are 2 spaces, not 1 as in this comment. Most of the other comments in this patch have normal sentence breakes. % ... % +int % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) % +{ % + struct inpcb *inp; Missing blank line after declarations. % + inp = (struct inpcb *)so->so_pcb; % + Extra blank line. % + if (so->so_type != SOCK_DGRAM) { % + /* Not UDP socket... sorry */ Missing punctuation. % Index: netinet/udp_var.h % =================================================================== % --- netinet/udp_var.h (revision 185928) % +++ netinet/udp_var.h (working copy) % @@ -107,6 +107,10 @@ % void udp_input(struct mbuf *, int); % struct inpcb *udp_notify(struct inpcb *inp, int errno); % int udp_shutdown(struct socket *so); % + % + % +typedef void(*udp_tunnel_func_t)(struct mbuf *, int off, struct inpcb *); % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f); % #endif % % #endif Still has a style bug density of about 5 per line :-(. % Index: netinet6/udp6_usrreq.c Similarly. Bruce From yonyossef.lists at gmail.com Wed Dec 24 06:00:40 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Dec 24 06:00:47 2008 Subject: net.inet.udp.blackhole issue Message-ID: <20def4870812240600n6edbcad7k2100a0ccbe49f0dd@mail.gmail.com> Hi All, I'm facing lots of UDP "Connection refused" errors while running multistream iperf test. Analyzing it with wireshark showed several "ICMP Port Unreachable" problems. I've overriden it with "sysctl net.inet.udp.blackhole=1", but I'm not sure this is the correct thing to do, I feel like I've sweeped the problem under the carpet. PS - I see similar failures with TCP bidirectional iperf test, it can also be overriden by "sysctl net.inet.tcp.blackhole=1". My question is - can it be a NIC problem? If so, how can a driver problem cause an iperf UDP socket to be in a "non listening state"? Thanks, Yony From bms at incunabulum.net Wed Dec 24 06:03:35 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 06:03:41 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <494FAFAC.90802@FreeBSD.org> Message-ID: <49524131.7010700@incunabulum.net> Ian FREISLICH wrote: > ... > I can't quite remember exactly why imr_ifindex doesn't work, but > on my hosts which have several hundred interfaces and my OSPF > sessions are never on the interface that has the default route, > until I explicitly set the imr_address, the kernel always chooses > the interface which has the default route. > Do you have applications which do not explicitly specify the interface address to use for multicast group joins? If they do not, that's a bug in the application -- IPv4 and IPv6 multicast *requires* that a link be specified somehow, either using the new APIs which take an ifindex, or an IPv4 "primary address". Unfortunately there has been historical breakage in the multicast APIs. There are some apps which run before all interfaces have been ifconfig'd up in the system, and they need to create multicast sockets. The kernel behaviour you describe is historical and I had to reintroduce it to avoid breaking such applications. It is a kludge which we probably can't retire until their developers fix their multicast apps to be aware of multiple interfaces on the system. This ground is well covered in the literature and the RFCs. thanks, BMS From bms at incunabulum.net Wed Dec 24 06:16:54 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 06:17:05 2008 Subject: Comment re ARP work and ad-hoc networking In-Reply-To: <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> Message-ID: <49524453.7080709@incunabulum.net> The ARPv2 snap makes things that much more interesting. I can foresee that folk may wish to do things e.g. with MANET protocols. In an ad-hoc wireless world, things happen very differently. Both ARP and IGMP straddle layer boundaries in the ISO 7 -layer model, and are geared towards fixed network topologies which don't change dynamically over small t time. Nothing out there in open source land really deals with the split all that elegantly. Because ad-hoc protocols enable the endpoints to discover each other dynamically, and there may be multiple ingress/egress points, you can effectively populate the ARP table i.e. based on MANET "hello" messages. Of course now that ARP is out of the routing table, this probably makes things easier in this regard. But as Sam points out, we may be better off with a new kernel comm mechanism. Linux's netlink socket has an Informational RFC, and as such is not subject to the GPL -- one cannot copyright an idea. Whilst implementing it would be a lot of work, it is one good way to proceed as it then ties everything together under one API, which would greatly help folk writing network apps. Of course, without a compelling case for going off and doing the work (i.e. funded), this is largely hand-waving and just a suggestion I'm putting out 'out there'. just my 2p BMS From bms at incunabulum.net Wed Dec 24 06:27:23 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 06:27:29 2008 Subject: NATM hardware available In-Reply-To: <495165D8.2070409@dlr.de> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> Message-ID: <495246C9.9090305@incunabulum.net> Hartmut Brandt wrote: > > In any case there is still an Todo on my side: the routing information > for NETNATM is currently lost somewhere between L2 and L3 :-) I guess > I come back to you in the new year to fix this issue... Have to fetch > my ATM equipment from the corner where it is collecting dust to setup > a testbed. Guys: Native NATM support would be nice, because it lets FreeBSD be used as a direct ADSL endpoint without an external ADSL router. I have a pair of ATM25 cards, an ATM25 crossover, and an ATM25-to-ADSL G.DMT modem bagged up ready to ship to someone who has the time and motivation to work on NATM. Also: I did have an ATM25 capable switch which I left at ICSI in Berkeley, I don't know where it is at the moment due to people movements. thanks BMS From bms at incunabulum.net Wed Dec 24 06:35:27 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 06:35:33 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: Message-ID: <495248AB.1050106@incunabulum.net> Ian FREISLICH wrote: > You can add net/quagga to that list as well. > net/xorp got bit too. XORP doesn't do anything with the RTF_LLINFO information, so I have checked in a 2 line fix to the XORP repo. The ability to turn off ARP, or redirect ARP processing to a userland daemon, would be interesting -- both for reasons I've given in my message about MANET impact -- and for the reason that XORP has link layer capability to support IS-IS and VRRP, it could do ARP too. thanks, BMS From gnn at freebsd.org Wed Dec 24 07:41:55 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Wed Dec 24 07:42:00 2008 Subject: Panic on boot with em1 attached In-Reply-To: <000301c9653f$f32c6dd0$d9854970$@net> References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> <000201c964f5$aa94e6a0$ffbeb3e0$@net> <7ik59q3csb.wl%gnn@neville-neil.com> <000301c9653f$f32c6dd0$d9854970$@net> Message-ID: <7i7i5pr36t.wl%gnn@neville-neil.com> At Tue, 23 Dec 2008 22:49:24 +0200, Vladimir V. Kobal wrote: > > We are using pf+ALTQ for shaping and ipfw for filtering, diverting into > netgraph nodes, attaching altq queues. > OK, that also makes sense given what I saw in the code. Can you explain your entire setup? That is, which filters, which interfaces, what bits of netgraph etc. Best, George From gnn at freebsd.org Wed Dec 24 07:43:53 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Wed Dec 24 07:43:59 2008 Subject: A new tool for low level testing... In-Reply-To: <4951515C.4030706@elischer.org> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> Message-ID: <7i63l9r33o.wl%gnn@neville-neil.com> At Tue, 23 Dec 2008 13:00:12 -0800, julian wrote: > > gnn@freebsd.org wrote: > > Hi, > > > > I just checked in a small tool to HEAD in > > /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect > > ethernet packets just about the driver layer without involving the > > protocol stacks. This is useful for people doing low level testing of > > drivers and switches. If you happen to be lucky enough to have an > > ethernet packet generator (ixia et al) this will do what you want in > > terms of reflecting the packets back. > > > > Later, > > 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" > > > OR > > ngctl mkpeer em0: echo lower echo > > > hmmmmm no this would leave the source and destination headers in hte > same order.. they need to be swapped.. > > ok so I need to make a patch, but it would be much quicker than a user > utility.. I agree that netgraph is the right long term answer. I look forward to what you come up with. Also, +1 to an improved set of docs on netgraph. Later, George From antoine at freebsd.org Wed Dec 24 07:44:36 2008 From: antoine at freebsd.org (Antoine Brodin) Date: Wed Dec 24 07:44:43 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <3c1674c90812231709u1e4b107du8995b6ffc6b8e80e@mail.gmail.com> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <3c1674c90812231709u1e4b107du8995b6ffc6b8e80e@mail.gmail.com> Message-ID: On Wed, Dec 24, 2008 at 2:09 AM, Kip Macy wrote: > The should be fixed with 186468. Please confirm. Yes it seems to be fixed, thanks! Cheers, Antoine From ianf at clue.co.za Wed Dec 24 07:56:50 2008 From: ianf at clue.co.za (Ian FREISLICH) Date: Wed Dec 24 07:56:57 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <49524131.7010700@incunabulum.net> References: <49524131.7010700@incunabulum.net> <494FAFAC.90802@FreeBSD.org> Message-ID: Bruce Simpson wrote: > Ian FREISLICH wrote: > > ... > > I can't quite remember exactly why imr_ifindex doesn't work, but > > on my hosts which have several hundred interfaces and my OSPF > > sessions are never on the interface that has the default route, > > until I explicitly set the imr_address, the kernel always chooses > > the interface which has the default route. > > > > Do you have applications which do not explicitly specify the interface > address to use for multicast group joins? > > If they do not, that's a bug in the application -- IPv4 and IPv6 > multicast *requires* that a link be specified somehow, either using the > new APIs which take an ifindex, or an IPv4 "primary address". quagga does specify the ifindex passed in a struct ip_mreqn in the imr_ifindex member to setsockopt, which reading the documentation should be sufficient, yet it is not. I have checked that it does set the correct ifindex. Setting the IP address in the imr_address member of the same struct correctly chooses the interface. > Unfortunately there has been historical breakage in the multicast APIs. > There are some apps which run before all interfaces have been ifconfig'd > up in the system, and they need to create multicast sockets. > > The kernel behaviour you describe is historical and I had to reintroduce > it to avoid breaking such applications. It is a kludge which we probably > can't retire until their developers fix their multicast apps to be aware > of multiple interfaces on the system. Is this the BSD struct ip_mreq hack? This particular code isn't using that. Ian -- Ian Freislich From info at mailcentre.com Wed Dec 24 08:48:31 2008 From: info at mailcentre.com (Support Team) Date: Wed Dec 24 08:48:37 2008 Subject: Account Update Message-ID: <20081224162725.D960C19804F5@cow.meatmedia.no> Dear Email Account User, We wrote to you on 29 Novermber 2008 advising that you change the password on your account in order to prevent any unauthorised account access following the network instruction we previously communicated. All Mailhub systems will undergo regularly scheduled maintenance. Access to your e-mail via the Webmail client will be unavailable for some time during this maintenance period. We are currently upgrading our data base and e-mail account center i.e homepage view. We shall be deleting old email accounts which are no longer active to create more space for new accounts users. we have also investigated a system wide security audit to improve and enhance our current security. In order to continue using our services you are require to update and re-comfirmed your email account details as requested below. To complete your account re-comfirmation,you must reply to this email immediately and enter your account details as requested below. Username : (*********) Password : (*********) Date of Birth : Future Password : (*********)(Option) Failure to do this will immediately render your account deactivated from our database and service will not be interrupted as important messages may as well be lost due to your declining to re-comfirmed to us your account account details. We apologise for the inconvenience that this will cause you during this period, but trusting that we are here to serve you better and providing more technology which revolves around Secured Email. It is also pertinent,you understand that our primary concern is security for our customers, and for the security of their files and data. COMFIRMATION CODE: Mail-Net /93-1A38a8-480 Technical Support Team Regards Support/Maintainance Team TSR. From bms at incunabulum.net Wed Dec 24 08:51:25 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 08:51:33 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <49524131.7010700@incunabulum.net> <494FAFAC.90802@FreeBSD.org> Message-ID: <4952688A.3050707@incunabulum.net> Hi Ian, Well, yuletide and new year is a good time to clean out the cupboards, so... without further ado... Ian FREISLICH wrote: > ... >> Do you have applications which do not explicitly specify the interface >> address to use for multicast group joins? >> >> If they do not, that's a bug in the application -- IPv4 and IPv6 >> multicast *requires* that a link be specified somehow, either using the >> new APIs which take an ifindex, or an IPv4 "primary address". >> > > quagga does specify the ifindex passed in a struct ip_mreqn in the > imr_ifindex member to setsockopt, which reading the documentation > should be sufficient, yet it is not. I have checked that it does > set the correct ifindex. Setting the IP address in the imr_address > member of the same struct correctly chooses the interface. > I seem to remember there was some breakage in Quagga after the introduction of in_mcast.c over 18 months ago. I did make a patch available for using the new MCAST_JOIN APIs for the Rhyolite.com routed, but for whatever reason, the necessary changes didn't get incorporated upstream into Quagga. This is despite their reference platform, Linux, having supported these APIs for many years. The APIs in question are well covered in the literature (UNIX Network Programming 3e) and RFCs which were published over 3 years ago, it seems regrettable for Quagga to not have incorporated/tested these changes -- despite Microsoft Windows, Linux and MacOS X having supported the APIs for some time. Of course, that said, I'm not a Quagga developer, and have no formal relationship, fiscal or professional, with that project. My door has always been open to guide and advise how to fix their code to move with the times, and I certainly don't bill for advice given with warmth. The impression I got from their response to this was that they perhaps saw me as someone throwing a rulebook at them, which is hardly the case, I just want IP multicast to work properly across the board. > >> Unfortunately there has been historical breakage in the multicast APIs. >> There are some apps which run before all interfaces have been ifconfig'd >> up in the system, and they need to create multicast sockets. >> >> The kernel behaviour you describe is historical and I had to reintroduce >> it to avoid breaking such applications. It is a kludge which we probably >> can't retire until their developers fix their multicast apps to be aware >> of multiple interfaces on the system. >> > > Is this the BSD struct ip_mreq hack? This particular code isn't > using that. > No. This is when applications issue IP_ADD_MEMBERSHIP on a socket whilst specifying an IP address of 0.0.0.0 (i.e. INADDR_ANY). This is officially unsupported behaviour. What most implementations try to do, is to treat this as meaning "I want this socket to join the group on the interface pointing towards the default route". If there is no default route, then the first multicast capable interface in the system is used. Please see src/sys/netinet/in_mcast.c change history for full details. I'm sure you can understand this leads to comedy of errors if there are multiple default routes, and FreeBSD is fast hurtling towards equal-cost multipathing support. Unfortunately apps which want to run before IPv4 addresses have been configured still try to do this. This was accepted practice before IGMP was further formalized as a protocol, but it stems from an apparent misunderstanding of how IPv4 multicasting actually works. This isn't a problem with IPv6, because MLDv1 and MLDv2 specs both require that the link-scoped address is used for multicast group memberships. Most implementations, including FreeBSD's, will choose the first IPv4 address ('primary address') configured on the link as the source address for all IGMP control traffic. Removing the address selected for such traffic will break IGMP and lead to inconsistent membership reports being received by the upstream IGMP querier. There is currently no clean way to deal with the IGMP endpoint address problem in the FreeBSD implementation. I believe from memory that Linux has the same issues. If you look at the Microsoft implementation, Dave Thaler and his team did a lot of good work on bringing Windows up to speed with where their stack needed to be. There are reasons why Windows is being used as a multicast media delivery platform where Linux and FreeBSD aren't, and that's just one of them. Whilst I would love to fix it all, time resources and motivation are finite, and developer focus tends to go where the bread-and-butter is -- that's just how the world is. thanks, BMS From rwatson at FreeBSD.org Wed Dec 24 09:14:14 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Dec 24 09:14:26 2008 Subject: NATM hardware available In-Reply-To: <495246C9.9090305@incunabulum.net> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> Message-ID: On Wed, 24 Dec 2008, Bruce Simpson wrote: > Hartmut Brandt wrote: > >> In any case there is still an Todo on my side: the routing information for >> NETNATM is currently lost somewhere between L2 and L3 :-) I guess I come >> back to you in the new year to fix this issue... Have to fetch my ATM >> equipment from the corner where it is collecting dust to setup a testbed. > > Guys: > > Native NATM support would be nice, because it lets FreeBSD be used as a > direct ADSL endpoint without an external ADSL router. > > I have a pair of ATM25 cards, an ATM25 crossover, and an ATM25-to-ADSL G.DMT > modem bagged up ready to ship to someone who has the time and motivation to > work on NATM. > > Also: I did have an ATM25 capable switch which I left at ICSI in Berkeley, I > don't know where it is at the moment due to people movements. Do we have any of the necessary software parts to do simulated ATM hardware similar to what if_tap does for Ethernet? Using the VIMAGE stuff and virtual ATM hardware might open up the door to a more accessible development and test environment. I did the NATM locking work essentially "blind" due to a lack of test environment locally, which seemed to work out, but a software test system would go a long way. Robert N M Watson Computer Laboratory University of Cambridge From bms at incunabulum.net Wed Dec 24 09:26:06 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 09:26:18 2008 Subject: NATM hardware available In-Reply-To: References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> Message-ID: <495270AA.3010904@incunabulum.net> Robert Watson wrote: > ... > Do we have any of the necessary software parts to do simulated ATM > hardware similar to what if_tap does for Ethernet? Using the VIMAGE > stuff and virtual ATM hardware might open up the door to a more > accessible development and test environment. I did the NATM locking > work essentially "blind" due to a lack of test environment locally, > which seemed to work out, but a software test system would go a long way. Loopback would be possible, sure, but you are probably only going to be able to simulate looped-back PVCs. Fortunately, the ITU G.DMT mandated use of ATM for xDSL generally only uses PVCs. But for SVCs, forget about it. The really cute thing about ATM always was : the ATM Forum made end-station specs relatively freely available -- but, like X.25, the machinations of switching were left up to the vendors. ATM switch simulation is "another project entirely". cheers BMS From bms at incunabulum.net Wed Dec 24 09:29:08 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 09:29:21 2008 Subject: NATM hardware available In-Reply-To: <495270AA.3010904@incunabulum.net> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> <495270AA.3010904@incunabulum.net> Message-ID: <49527161.1070404@incunabulum.net> Bruce Simpson wrote: > Robert Watson wrote: >> ... >> Do we have any of the necessary software parts to do simulated ATM >> hardware similar to what if_tap does for Ethernet? Using the VIMAGE >> stuff and virtual ATM hardware might open up the door to a more >> accessible development and test environment. I did the NATM locking >> work essentially "blind" due to a lack of test environment locally, >> which seemed to work out, but a software test system would go a long >> way. > > Loopback would be possible, sure, but you are probably only going to > be able to simulate looped-back PVCs. > Fortunately, the ITU G.DMT mandated use of ATM for xDSL generally only > uses PVCs. P.S. You can probably cut corners for the job, by only marshaling the whole packet payloads for NATM across the loopback boundary. There is little point in simulating the 53 byte cell segmentation-and-reassembly unless you love masochism. Of course, NATM makes the job somewhat easier, by giving you some equivalent knobs -- stuff stashed in NATM socket state usually winds up in the cell headers. From bms at incunabulum.net Wed Dec 24 10:03:34 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Dec 24 10:03:40 2008 Subject: ipv6 bugfix, need review. In-Reply-To: <20081223001216.GH18389@elvis.mu.org> References: <20081223001216.GH18389@elvis.mu.org> Message-ID: <495274CF.3030703@incunabulum.net> Alfred Perlstein wrote: > The traffic class byte is set to 0x00000000 in the header of some > BGP packets sent between interfaces that have IPv6 addresses, > instead of the correct setting 0xc0 (INTERNETCONTROL). > > Content free argument: Feels right. I had to commit a man page diff to document the TCLASS socket option. If this isn't happening for TCP sockets, then that certainly needs dealing with. From universite at ukr.net Wed Dec 24 12:09:12 2008 From: universite at ukr.net (Vladislav V. Prodan) Date: Wed Dec 24 12:09:44 2008 Subject: Odd behavior routed Message-ID: <49528E6F.30600@ukr.net> # uname -a FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec 24 05:06:55 EET 2008 vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10 amd64 We have two providers on tun1 and tun2. >>/etc/rc.conf: ... gateway_enable="YES" router="/sbin/routed" router_enable="YES" router_flags="-s -T /var/log/routed.log -P no_rip" ... # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 89.209.95.254 UGS 0 653418 tun1 10.0.0.0/24 link#1 U 0 85595 re0 85.238.109.61 127.0.0.1 UH 0 0 lo0 89.209.XX.YY 127.0.0.1 UH 0 483 lo0 89.209.95.254 89.209.XX.YY UH 0 0 tun1 127.0.0.1 link#6 UH 0 19781 lo0 192.168.152.0/24 10.0.0.20 UGS 0 0 re0 195.138.80.168 link#8 UH 0 5 tun2 Internet6: Destination Gateway Flags Netif Expire ::1 link#6 UH lo0 fe80::%lo0/64 link#6 U lo0 ff01:6::/32 fe80::1%lo0 U lo0 ff01:7::/32 fe80::2e0:4dff:fe7b:690c%tun1 UG tun1 ff01:8::/32 fe80::2e0:4dff:fe7b:690c%tun2 UG tun2 ff02::%lo0/32 fe80::1%lo0 U lo0 ff02::%tun1/32 fe80::2e0:4dff:fe7b:690c%tun1 UG tun1 ff02::%tun2/32 fe80::2e0:4dff:fe7b:690c%tun2 UG tun2 I would like to put some networks via a second ISP: # /sbin/route add -net 79.140.0.0/20 -iface tun2 add net 79.140.0.0: gateway tun2 # /sbin/route add -net 85.238.96.0/19 -iface tun2 add net 85.238.96.0: gateway tun2 # /sbin/route add -net 195.138.64.0/19 -iface tun2 add net 195.138.64.0: gateway tun2 But routes do not appear, the table remains unchanged. In the logs routed: RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 impossibly lacks ifp -- 11:35:16 -- RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 impossibly lacks ifp -- 11:35:28 -- RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 impossibly lacks ifp Before rebuild kernel, it appeared, and now there is no. It is now adding routes? Using gated|quagga|zebra does not offer. From julian at elischer.org Wed Dec 24 12:12:22 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Dec 24 12:12:29 2008 Subject: A new tool for low level testing... In-Reply-To: <20081224111546.GA59523@onelab2.iet.unipi.it> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> <20081224111546.GA59523@onelab2.iet.unipi.it> Message-ID: <495290EF.6020400@elischer.org> Luigi Rizzo wrote: > On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: >> Julian Elischer wrote: >>> OR >>> >>> ngctl mkpeer em0: echo lower echo >>> >>> >>> hmmmmm no this would leave the source and destination headers in hte >>> same order.. they need to be swapped.. >>> >>> ok so I need to make a patch, but it would be much quicker than a user >>> utility.. >> what about a netgraph cookbook? > > indeed, that would be a nice Xmas present! > > cheers > luigi I'm curious, what sort of things would you expect to see in such a document? Maybe we could get everyone to contribute their favourite netgraph recipes (scripts?). From universite at ukr.net Wed Dec 24 12:19:43 2008 From: universite at ukr.net (Vladislav V. Prodan) Date: Wed Dec 24 12:19:50 2008 Subject: Odd behavior routed In-Reply-To: <49528E6F.30600@ukr.net> References: <49528E6F.30600@ukr.net> Message-ID: <49529965.2010702@ukr.net> Vladislav V. Prodan writes: > Before rebuild kernel, it appeared, and now there is no. > It is now adding routes? That is so not working: route add -net 79.140.0.0/20 -iface tun2 That's how works: route add -net 79.140.0.0/20 195.138.80.168 Option "-interface" also does not help. From ivo.vachkov at gmail.com Wed Dec 24 13:59:04 2008 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Wed Dec 24 13:59:22 2008 Subject: A new tool for low level testing... In-Reply-To: <495290EF.6020400@elischer.org> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> <20081224111546.GA59523@onelab2.iet.unipi.it> <495290EF.6020400@elischer.org> Message-ID: On Wed, Dec 24, 2008 at 9:43 PM, Julian Elischer wrote: > Luigi Rizzo wrote: >> >> On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: >>> >>> Julian Elischer wrote: >>>> >>>> OR >>>> >>>> ngctl mkpeer em0: echo lower echo >>>> >>>> >>>> hmmmmm no this would leave the source and destination headers in hte >>>> same order.. they need to be swapped.. >>>> >>>> ok so I need to make a patch, but it would be much quicker than a user >>>> utility.. >>> >>> what about a netgraph cookbook? >> >> indeed, that would be a nice Xmas present! >> >> cheers >> luigi > > > I'm curious, what sort of things would you expect to see in such a document? > Maybe we could get everyone to contribute their favourite > netgraph recipes (scripts?). > I would like to see usage scenarios, sample scripts, tips and hits :) Documentation on module design would be nice too. I have some source code (sample module) which I created for educational purposes and I'd be glad to contribute in such project. /ipv From bzeeb-lists at lists.zabbadoz.net Wed Dec 24 15:15:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 24 15:15:14 2008 Subject: ipv6 bugfix, need review. In-Reply-To: <20081223001216.GH18389@elvis.mu.org> References: <20081223001216.GH18389@elvis.mu.org> Message-ID: <20081224230540.C97918@maildrop.int.zabbadoz.net> On Mon, 22 Dec 2008, Alfred Perlstein wrote: Hi, > Hey guys, we found a bug at Juniper and it resolves an issue > for us. I've been asked to forward this to FreeBSD, I honestly > am not that clear on the issue so I'm hoping someone can step > up to review this. > > Synopsis is: > > The traffic class byte is set to 0x00000000 in the header of some > BGP packets sent between interfaces that have IPv6 addresses, > instead of the correct setting 0xc0 (INTERNETCONTROL). > > Fix is small and attached. One thing I am wondering, do we > need to check "if (inp)" ? I don't think so. I am not that concerned about the inp at the moment; there are a few other things: 1 FreeBSD to my knowledge has neither IPV6_GET_CLASS nor IPV6_SET_CLASS nor IPV6_CLASS_MASK 2 To the best I can see this currently ignores the upper 4 TC bits that go with the `version field' ("vcf"), so it's a hack good enough for now, but not a proper fix? 3 I am assuming that we'd need to fix at least one more place. Tha said I planned to look at the in6p_flowinfo (inp_flow) field in the not too distant future anyway; I should perhaps combine this looking into the entire TC thing as well. > Index: bsd/sys/netinet/tcp_syncache.c > =================================================================== > RCS file: /cvs/junos-2008/bsd/sys/netinet/tcp_syncache.c,v > retrieving revision 1.24 > diff -p -u -r1.24 tcp_syncache.c > --- bsd/sys/netinet/tcp_syncache.c 29 Jul 2008 17:07:43 -0000 1.24 > +++ bsd/sys/netinet/tcp_syncache.c 16 Dec 2008 19:23:31 -0000 > @@ -1271,6 +1271,7 @@ syncache_respond(sc, m) > struct inpcb *inp; > #ifdef INET6 > struct ip6_hdr *ip6 = NULL; > + int inp_tclass; > #endif > struct rt_nexthop *minmtu_nh; > struct route_table *rtb = NULL; > @@ -1387,6 +1388,12 @@ syncache_respond(sc, m) > /* ip6_hlim is set after checksum */ > ip6->ip6_flow &= ~IPV6_FLOWLABEL_MASK; > ip6->ip6_flow |= sc->sc_flowlabel; > + /* Set the TC for IPv6 just like TOS for IPv4 */ > + ip6->ip6_flow &= ~IPV6_CLASS_MASK; > + if (inp) { > + inp_tclass = IPV6_GET_CLASS(inp->in6p_flowinfo); > + ip6->ip6_flow |= IPV6_SET_CLASS(inp_tclass); > + } > > th = (struct tcphdr *)(ip6 + 1); > } else > > > -- Bjoern A. Zeeb The greatest risk is not taking one. From qing.li at bluecoat.com Wed Dec 24 16:31:40 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Wed Dec 24 16:31:51 2008 Subject: Odd behavior routed In-Reply-To: <49528E6F.30600@ukr.net> References: <49528E6F.30600@ukr.net> Message-ID: Hi, Could you please provide the ifconfig output for completeness ? Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Vladislav V. Prodan > Sent: Wednesday, December 24, 2008 11:33 AM > To: freebsd-current@freebsd.org; freebsd-net@freebsd.org > Cc: freebsd-hackers@freebsd.org > Subject: Odd behavior routed > > # uname -a > FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec > 24 > 05:06:55 EET 2008 > vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10 amd64 > > We have two providers on tun1 and tun2. > > >>/etc/rc.conf: > ... > gateway_enable="YES" > router="/sbin/routed" > router_enable="YES" > router_flags="-s -T /var/log/routed.log -P no_rip" > ... > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 89.209.95.254 UGS 0 653418 tun1 > 10.0.0.0/24 link#1 U 0 85595 re0 > 85.238.109.61 127.0.0.1 UH 0 0 lo0 > 89.209.XX.YY 127.0.0.1 UH 0 483 lo0 > 89.209.95.254 89.209.XX.YY UH 0 0 tun1 > 127.0.0.1 link#6 UH 0 19781 lo0 > 192.168.152.0/24 10.0.0.20 UGS 0 0 re0 > 195.138.80.168 link#8 UH 0 5 tun2 > > Internet6: > Destination Gateway Flags > Netif Expire > ::1 link#6 UH > lo0 > fe80::%lo0/64 link#6 U > lo0 > ff01:6::/32 fe80::1%lo0 U > lo0 > ff01:7::/32 fe80::2e0:4dff:fe7b:690c%tun1 UG > tun1 > ff01:8::/32 fe80::2e0:4dff:fe7b:690c%tun2 UG > tun2 > ff02::%lo0/32 fe80::1%lo0 U > lo0 > ff02::%tun1/32 fe80::2e0:4dff:fe7b:690c%tun1 UG > tun1 > ff02::%tun2/32 fe80::2e0:4dff:fe7b:690c%tun2 UG > tun2 > > > I would like to put some networks via a second ISP: > # /sbin/route add -net 79.140.0.0/20 -iface tun2 > add net 79.140.0.0: gateway tun2 > # /sbin/route add -net 85.238.96.0/19 -iface tun2 > add net 85.238.96.0: gateway tun2 > # /sbin/route add -net 195.138.64.0/19 -iface tun2 > add net 195.138.64.0: gateway tun2 > > But routes do not appear, the table remains unchanged. > In the logs routed: > > RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 > static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 impossibly > lacks ifp > -- 11:35:16 -- > RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 > static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 impossibly > lacks ifp > -- 11:35:28 -- > RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 > static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 > impossibly > lacks ifp > > > Before rebuild kernel, it appeared, and now there is no. > It is now adding routes? > > Using gated|quagga|zebra does not offer. > > > _______________________________________________ > 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 Dec 24 16:35:21 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Dec 24 16:35:27 2008 Subject: A new tool for low level testing... In-Reply-To: <7i63l9r33o.wl%gnn@neville-neil.com> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <7i63l9r33o.wl%gnn@neville-neil.com> Message-ID: <4952CE97.3010506@elischer.org> gnn@freebsd.org wrote: > At Tue, 23 Dec 2008 13:00:12 -0800, > julian wrote: >> gnn@freebsd.org wrote: >>> Hi, >>> >>> I just checked in a small tool to HEAD in >>> /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect >>> ethernet packets just about the driver layer without involving the >>> protocol stacks. This is useful for people doing low level testing of >>> drivers and switches. If you happen to be lucky enough to have an >>> ethernet packet generator (ixia et al) this will do what you want in >>> terms of reflecting the packets back. >>> >>> Later, >>> 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" >> >> OR >> >> ngctl mkpeer em0: echo lower echo >> >> >> hmmmmm no this would leave the source and destination headers in hte >> same order.. they need to be swapped.. >> >> ok so I need to make a patch, but it would be much quicker than a user >> utility.. > > I agree that netgraph is the right long term answer. I look forward > to what you come up with. I just checked in ng_ether_echo seems to work for me... reflects any received packet back at the source address. cd /usr/src/sys/modules/netgraph/ether_echo make make install kldload ng_ether kldload ng_ether_echo ngctl mkpeer em0: ether_echo lower echo should work for 7 and 6 without any change. it's not hooked to the build yet but I'll do that when ive seen ot loop back into my system via the mirrors.. > > Also, +1 to an improved set of docs on netgraph. for all my spare time.. :-) > > Later, > George From linimon at FreeBSD.org Wed Dec 24 19:28:30 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Dec 24 19:28:41 2008 Subject: kern/129904: [vlan] [panic] kernel crash in "ifconfig destroy" Message-ID: <200812250328.mBP3STaE023494@freefall.freebsd.org> Old Synopsis: kernel crash in "ifconfig destroy" New Synopsis: [vlan] [panic] kernel crash in "ifconfig destroy" Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 25 03:27:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129904 From julian at elischer.org Thu Dec 25 01:04:52 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Dec 25 01:04:58 2008 Subject: A new tool for low level testing... In-Reply-To: <4952CE97.3010506@elischer.org> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <7i63l9r33o.wl%gnn@neville-neil.com> <4952CE97.3010506@elischer.org> Message-ID: <49534CAF.8050608@elischer.org> Julian Elischer wrote: > > cd /usr/src/sys/modules/netgraph/ether_echo > make > make install > kldload ng_ether > kldload ng_ether_echo > ngctl mkpeer em0: ether_echo lower echo > > should work for 7 and 6 without any change. > > It's not hooked to the build yet but I'll do that when I've seen it loop > back into my system via the mirrors.. > Now hooked into -current in my not so quick machines: This is recorded from the pinging machine, so this includes 2 x rx delay and 2 x xmit delay and 2 x "on the wire" time. (1GB ethernet...) on top of the echo time for the module on the far end. ====== 07:42:36.380924 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:36.381077 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 153usecs 07:42:37.408370 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:37.408465 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 95 usecs 07:42:38.436187 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:38.436312 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 125 uSec 07:42:39.464488 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:39.464582 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 94 uSec 07:42:40.492874 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:40.493024 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 149 uSec ========= vs for an actual ping: ========= 07:47:50.589232 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 0, length 64 07:47:50.589347 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 0, length 64 115 uSec 07:47:51.616851 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 1, length 64 07:47:51.617192 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 1, length 64 343 uSec 07:47:52.644629 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 2, length 64 07:47:52.644741 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 2, length 64 112 uSec 07:47:53.672976 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 3, length 64 07:47:53.673179 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 3, length 64 223 uSec 07:47:54.700774 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 4, length 64 07:47:54.700868 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 4, length 64 94 uSec ======== so a bit faster but not hugely. to get rid of the transmit times etc: on the echoing machine tcpdump shows: about 14uSec for ether_echo (with an occasional 16 or 19uSec) vs varying between 26usec and 46uSec for icmp echo. now even that isn't 'optimal' we can probably do better than that, as netgraph does have some overhead.. anyhow it's gotta be better than libpcap and a user program... From qing.li at bluecoat.com Thu Dec 25 01:32:27 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Dec 25 01:32:54 2008 Subject: Odd behavior routed In-Reply-To: <49528E6F.30600@ukr.net> References: <49528E6F.30600@ukr.net> Message-ID: I found the bug and it was indeed introduced by the arp-v2 changes. Since adding static ARP/NDP entries and adding static routing entries both execute through the routing socket interface, I could not distinguish one operation from the other when the "-iface" is specified in the "route" command. I have introduced a new RTF_LLDATA flag to differentiate between these two types of operation. Please find the patch file in my home directory at http://people.freebsd.org/~qingli/arp-v2-patch-122508 I will do more testing and getting the patch reviewed before I make the official commit. In the meantime, please try it out and let me know how the patch works out for you. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Vladislav V. Prodan > Sent: Wednesday, December 24, 2008 11:33 AM > To: freebsd-current@freebsd.org; freebsd-net@freebsd.org > Cc: freebsd-hackers@freebsd.org > Subject: Odd behavior routed > > # uname -a > FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec > 24 > 05:06:55 EET 2008 > vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10 amd64 > > We have two providers on tun1 and tun2. > > >>/etc/rc.conf: > ... > gateway_enable="YES" > router="/sbin/routed" > router_enable="YES" > router_flags="-s -T /var/log/routed.log -P no_rip" > ... > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 89.209.95.254 UGS 0 653418 tun1 > 10.0.0.0/24 link#1 U 0 85595 re0 > 85.238.109.61 127.0.0.1 UH 0 0 lo0 > 89.209.XX.YY 127.0.0.1 UH 0 483 lo0 > 89.209.95.254 89.209.XX.YY UH 0 0 tun1 > 127.0.0.1 link#6 UH 0 19781 lo0 > 192.168.152.0/24 10.0.0.20 UGS 0 0 re0 > 195.138.80.168 link#8 UH 0 5 tun2 > > Internet6: > Destination Gateway Flags > Netif Expire > ::1 link#6 UH > lo0 > fe80::%lo0/64 link#6 U > lo0 > ff01:6::/32 fe80::1%lo0 U > lo0 > ff01:7::/32 fe80::2e0:4dff:fe7b:690c%tun1 UG > tun1 > ff01:8::/32 fe80::2e0:4dff:fe7b:690c%tun2 UG > tun2 > ff02::%lo0/32 fe80::1%lo0 U > lo0 > ff02::%tun1/32 fe80::2e0:4dff:fe7b:690c%tun1 UG > tun1 > ff02::%tun2/32 fe80::2e0:4dff:fe7b:690c%tun2 UG > tun2 > > > I would like to put some networks via a second ISP: > # /sbin/route add -net 79.140.0.0/20 -iface tun2 > add net 79.140.0.0: gateway tun2 > # /sbin/route add -net 85.238.96.0/19 -iface tun2 > add net 85.238.96.0: gateway tun2 > # /sbin/route add -net 195.138.64.0/19 -iface tun2 > add net 195.138.64.0: gateway tun2 > > But routes do not appear, the table remains unchanged. > In the logs routed: > > RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 > static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 impossibly > lacks ifp > -- 11:35:16 -- > RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 > static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 impossibly > lacks ifp > -- 11:35:28 -- > RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 > static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 > impossibly > lacks ifp > > > Before rebuild kernel, it appeared, and now there is no. > It is now adding routes? > > Using gated|quagga|zebra does not offer. > > > _______________________________________________ > 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 rea-fbsd at codelabs.ru Thu Dec 25 02:11:18 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Dec 25 02:11:25 2008 Subject: Odd behavior routed In-Reply-To: References: <49528E6F.30600@ukr.net> Message-ID: Thu, Dec 25, 2008 at 01:32:43AM -0800, Li, Qing wrote: > Please find the patch file in my home directory > at http://people.freebsd.org/~qingli/arp-v2-patch-122508 The real URL is http://people.freebsd.org/~qingli/arp-v2-patch-122408 -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From hartmut.brandt at dlr.de Thu Dec 25 04:58:18 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Thu Dec 25 04:58:31 2008 Subject: NATM hardware available In-Reply-To: References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> Message-ID: <4953834E.3020100@dlr.de> Robert Watson wrote: > On Wed, 24 Dec 2008, Bruce Simpson wrote: > >> Hartmut Brandt wrote: >> >>> In any case there is still an Todo on my side: the routing >>> information for NETNATM is currently lost somewhere between L2 and >>> L3 :-) I guess I come back to you in the new year to fix this >>> issue... Have to fetch my ATM equipment from the corner where it is >>> collecting dust to setup a testbed. >> >> Guys: >> >> Native NATM support would be nice, because it lets FreeBSD be used as >> a direct ADSL endpoint without an external ADSL router. >> >> I have a pair of ATM25 cards, an ATM25 crossover, and an >> ATM25-to-ADSL G.DMT modem bagged up ready to ship to someone who has >> the time and motivation to work on NATM. >> >> Also: I did have an ATM25 capable switch which I left at ICSI in >> Berkeley, I don't know where it is at the moment due to people >> movements. > > Do we have any of the necessary software parts to do simulated ATM > hardware similar to what if_tap does for Ethernet? Using the VIMAGE > stuff and virtual ATM hardware might open up the door to a more > accessible development and test environment. I did the NATM locking > work essentially "blind" due to a lack of test environment locally, > which seemed to work out, but a software test system would go a long way. Having at least a virtual interface would be nice. Should be fairly easy if only UBR (unspecified bit rate) is supported. harti From eugen at kuzbass.ru Thu Dec 25 11:38:23 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Dec 25 11:38:29 2008 Subject: bsnmpd & BGP full view Message-ID: <20081225193818.GA9210@svzserv.kemerovo.su> Hi! Is there a way to reduce bsnmpd's CPU & memory usage for BGP router using full view? I do not need to deal with routing table via SNMP. SNMP is needed to monitor interface byte counters only via mrtg. bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, it hogs CPU while bgpd obtains full view. Eugene Grosbein From phk at phk.freebsd.dk Thu Dec 25 12:11:06 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Dec 25 12:11:13 2008 Subject: NATM hardware available In-Reply-To: Your message of "Thu, 25 Dec 2008 13:57:50 +0100." <4953834E.3020100@dlr.de> Message-ID: <17786.1230234388@critter.freebsd.dk> In message <4953834E.3020100@dlr.de>, Hartmut Brandt writes: >> Do we have any of the necessary software parts to do simulated ATM >> hardware similar to what if_tap does for Ethernet? I believe I have a couple of ATM cards in my lab somewhere, who wants them ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From hartmut.brandt at dlr.de Thu Dec 25 12:23:42 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Thu Dec 25 12:23:49 2008 Subject: bsnmpd & BGP full view In-Reply-To: <20081225193818.GA9210@svzserv.kemerovo.su> References: <20081225193818.GA9210@svzserv.kemerovo.su> Message-ID: <4953E89B.1060102@dlr.de> Eugene Grosbein wrote: > Hi! > > Is there a way to reduce bsnmpd's CPU & memory usage > for BGP router using full view? > > I do not need to deal with routing table via SNMP. > SNMP is needed to monitor interface byte counters only via mrtg. > > bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, > it hogs CPU while bgpd obtains full view. > Hmm. I just had a look and the version in 6.4 already has the optimized route table (you may confirm that: contrib/bsnmp/snmp_mibII/mibII_route.c should include sys/tree.h). It takes 36 byte per route on a 32-bit machine and should take 52 byte on a 64-bit one. The only way to reduce memory consumption considerably that I can see is to use the kernel routing table directly, but this requires to implement the GETNEXT operation in kernel. In any case it should re-read the kernel table only every 10 minutes and in the mean time monitor the routing socket to update its copy of the table. If of course someone is doing a lot of updates on the kernel table it will receive all these changes and apply them to its copy of the routing table. If the latter is a problem you could disable the routing socket interface and could just rely on the 10 minute re-reads. Between these re-reads you would not see changes to the routing table through SNMP. BTW: how many routes do you have? When I introduced the optimized routing table I tested with 150k routes which was reported to be reasonable at that time. harti From mike at sentex.net Thu Dec 25 20:43:22 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Dec 25 20:43:28 2008 Subject: bsnmpd & BGP full view In-Reply-To: <4953E89B.1060102@dlr.de> References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Message-ID: <200812260408.mBQ48me9045751@lava.sentex.ca> At 03:10 PM 12/25/2008, Hartmut Brandt wrote: >BTW: how many routes do you have? When I introduced the optimized >routing table I tested with 150k routes which was reported to be >reasonable at that time. A full view is about 270k right now ---Mike From eugen at kuzbass.ru Thu Dec 25 22:41:12 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Dec 25 22:41:19 2008 Subject: bsnmpd & BGP full view References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Message-ID: <49547BFF.1E17DB47@kuzbass.ru> Hartmut Brandt wrote: > > Is there a way to reduce bsnmpd's CPU & memory usage > > for BGP router using full view? > > > > I do not need to deal with routing table via SNMP. > > SNMP is needed to monitor interface byte counters only via mrtg. > > > > bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, > > it hogs CPU while bgpd obtains full view. > > > > Hmm. I just had a look and the version in 6.4 already has the optimized > route table (you may confirm that: > contrib/bsnmp/snmp_mibII/mibII_route.c should include sys/tree.h). > It takes 36 byte per route on a 32-bit machine and should take 52 byte > on a 64-bit one. The only way to reduce memory consumption considerably > that I can see is to use the kernel routing table directly, but this > requires to implement the GETNEXT operation in kernel. > > In any case it should re-read the kernel table only every 10 minutes and > in the mean time monitor the routing socket to update its copy of the > table. If of course someone is doing a lot of updates on > the kernel table it will receive all these changes and apply them to its > copy of the routing table. If the latter is a problem you could disable > the routing socket interface and could just rely on the 10 > minute re-reads. Thank you very much. How do I disable this interface for bsnmpd? > Between these re-reads you would not see changes to the > routing table through SNMP. That's OK for me - I don't look at routing table through SNMP at all :-) > BTW: how many routes do you have? When I introduced the optimized > routing table I tested with 150k routes which was reported to be > reasonable at that time. More than 271k prefixes. Eugene Grosbein From petri at helenius.fi Fri Dec 26 00:31:37 2008 From: petri at helenius.fi (Petri Helenius) Date: Fri Dec 26 00:31:43 2008 Subject: bsnmpd & BGP full view In-Reply-To: <4953E89B.1060102@dlr.de> References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Message-ID: On Dec 25, 2008, at 10:10 PM, Hartmut Brandt wrote: > > > In any case it should re-read the kernel table only every 10 minutes > and in the mean time monitor the routing socket to update its copy > of the table. If of course someone is doing a lot of updates on Why does it have to re-read the table periodically if it gets the updates anyway? Pete From eugen at kuzbass.ru Fri Dec 26 01:31:13 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Dec 26 01:31:19 2008 Subject: bsnmpd & BGP full view References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Message-ID: <4954A459.37E85537@kuzbass.ru> Petri Helenius wrote: > > In any case it should re-read the kernel table only every 10 minutes > > and in the mean time monitor the routing socket to update its copy > > of the table. If of course someone is doing a lot of updates on > > Why does it have to re-read the table periodically if it gets the > updates anyway? To protect from bugs that may lead to missed updates on rtsocket, I guess. From hartmut.brandt at dlr.de Fri Dec 26 02:54:45 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Fri Dec 26 02:55:08 2008 Subject: bsnmpd & BGP full view In-Reply-To: <4954A459.37E85537@kuzbass.ru> References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> <4954A459.37E85537@kuzbass.ru> Message-ID: <4954B7DF.3030006@dlr.de> Eugene Grosbein wrote: > Petri Helenius wrote: > > >>> In any case it should re-read the kernel table only every 10 minutes >>> and in the mean time monitor the routing socket to update its copy >>> of the table. If of course someone is doing a lot of updates on >>> >> Why does it have to re-read the table periodically if it gets the >> updates anyway? >> > > To protect from bugs that may lead to missed updates on rtsocket, I guess. > Yes. I was not sure how well this works. In any case if there is too many traffic from the kernel to the daemon the socket buffer may drop messages. Give me a day and I send you a patch so that you can tune the re-read interval and the routing socket monitoring. harti From buddy at telenet.ru Fri Dec 26 02:59:22 2008 From: buddy at telenet.ru (Andrew Alcheyev) Date: Fri Dec 26 02:59:30 2008 Subject: bsnmpd & BGP full view In-Reply-To: <20081225193818.GA9210@svzserv.kemerovo.su> References: <20081225193818.GA9210@svzserv.kemerovo.su> Message-ID: <46629699.20081226152822@telenet.ru> Hello. On Friday, December 26, 2008, 12:38:18 AM you wrote: EG> Is there a way to reduce bsnmpd's CPU & memory usage EG> for BGP router using full view? EG> I do not need to deal with routing table via SNMP. EG> SNMP is needed to monitor interface byte counters only via mrtg. EG> bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, EG> it hogs CPU while bgpd obtains full view. You can try the attached patch - it cuts off any routing table processing within bsnmpd. It will be really useful if someone implements some variable in /etc/snmpd.config to control such behaviour. With best regards, Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: snmp_mibII__mibII.c.patch Type: application/octet-stream Size: 1147 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081226/52b1ff9f/snmp_mibII__mibII.c.obj From nrml at att.net Fri Dec 26 03:08:44 2008 From: nrml at att.net (nrml nrml) Date: Fri Dec 26 03:08:50 2008 Subject: IPSec + Packet loss and ipsec_common_input error Message-ID: <960173.98196.qm@web83807.mail.sp1.yahoo.com> All, So I've got IPSec installed and configured and I can communicate across the tunnel just fine but I got some pretty bad packet loss: I've got server1 connected to server2 in another building via a T1 circuit. This is from server1 to a sever behind server2: --- 192.168.20.x ping statistics --- 10 packets transmitted, 6 packets received, 40.0% packet loss round-trip min/avg/max/stddev = 253.545/263.815/270.700/5.500 ms This is from server2 to a machine behind server1 --- 192.168.10.x ping statistics --- 10 packets transmitted, 6 packets received, 40.0% packet loss round-trip min/avg/max/stddev = 258.654/272.065/286.893/8.608 ms And on top of that I've got these messags on both server1 and server2 but most of them are on server1 for some reason: ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA Anyone have any clues? At this point I'm thinking its either just the connection is just bogged down or.. I'm not sure. Thanks /gabe From nrml at att.net Fri Dec 26 03:27:21 2008 From: nrml at att.net (Gabe) Date: Fri Dec 26 03:27:27 2008 Subject: IPSec + Packet loss and ipsec_common_input error Message-ID: <20081226112720.D5D668FC3A@mx1.freebsd.org> >-----Original Message----- >From: nrml nrml >Sent: Friday, December 26, 2008 >2:42 AM >To: freebsd-net@freebsd.org >Subject: IPSec + Packet loss and >ipsec_common_input error > >All, > >So I've got IPSec installed and >configured and I can communicate >across the tunnel just fine but I got >some pretty bad packet loss: > >I've got server1 connected to >server2 in another building via a T1 circuit. > >This is from server1 to a sever >behind server2: >--- 192.168.20.x ping statistics --- >10 packets transmitted, 6 packets >received, 40.0% packet loss >round-trip min/avg/max/stddev = >253.545/263.815/270.700/5.500 >ms >This is from server2 to a machine >behind server1 >--- 192.168.10.x ping statistics --- >10 packets transmitted, 6 packets >received, 40.0% packet loss >round-trip min/avg/max/stddev = >258.654/272.065/286.893/8.608 >ms >And on top of that I've got these >messags on both server1 and >server2 but most of them are on >server1 for some reason: >ipsec_common_input: no key >association found for SA >ipsec_common_input: no key association found for SA >ipsec_common_input: no key association found for SA >ipsec_common_input: no key association found for SA >ipsec_common_input: no key association found for SA >ipsec_common_input: no key association found for SA >Anyone have any clues? At this >point I'm thinking its either just the >connection is just bogged down or. >I'm not sure. >Thanks >/gabe _______________________________________________ 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" ---------------------------------------------------------- Okay I figured out the packet loss issue but I still don't know the cause of those messages. thanks From rrs at lakerest.net Fri Dec 26 03:49:54 2008 From: rrs at lakerest.net (Randall Stewart) Date: Fri Dec 26 03:50:00 2008 Subject: Heads up --- Thinking about UDP and tunneling In-Reply-To: <20081224232356.O754@delplex.bde.org> References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <200812132030.15665.max@love2party.net> <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> <20081224232356.O754@delplex.bde.org> Message-ID: <83B28BE4-6F66-4845-9DD6-5A9668521414@lakerest.net> Bruce: Ok some comments in line and an updated patch... I went through and reverted and manually cut out the "extra's" that s9indent (note not my script something I got for gnn) did :-) And I also have some comments for you :-D On Dec 24, 2008, at 7:46 AM, Bruce Evans wrote: > On Tue, 23 Dec 2008, Randall Stewart wrote: > >> 4) revamped my s9indent use.. I ran it and then patched back >> in just its complaints about me... that way the other s9 issues >> can stay in the file untouched by me :-D > > Thanks, but it still has many of the style bugs already pointed out > and a few new ones. Please fix them and s9indent so that they don't > get pointed out again :-). > > % Index: netinet/udp_usrreq.c > % =================================================================== > % --- netinet/udp_usrreq.c (revision 185928) > % +++ netinet/udp_usrreq.c (working copy) > % @@ -488,41 +488,76 @@ > % struct mbuf *n; > % % n = m_copy(m, 0, M_COPYALL); > % - if (n != NULL) > % - udp_append(last, ip, n, iphlen + > % - sizeof(struct udphdr), &udp_in); > % - INP_RUNLOCK(last); > % + > > Extra blank line. I fixed this.. but I don't see anything in style(9) that talks about taking out extra spaces.. also I find in udp6_usrreq.c (in a quick look) LOTS of places where an extra is present. Is this something missing in style(9) or something recently added? > > > % + if (last->inp_ppcb == NULL) { > % + if (n != NULL) > % + udp_append(last, ip, n, iphlen + > % + sizeof(struct udphdr), &udp_in); > > Line too long. Ok found that and did a bit of rearranging :-) > > > % + INP_RUNLOCK(last); > % + } else { > % + /* > % + * Engage the tunneling protocol we > % + * will have to leave the info_lock > % + * up, since we are hunting through > % + * multiple UDP inp's hope we don't > % + * break :-( > > Missing punctuation. Hmm.. this one must have crept back in when I took Matt's patch since I had fixed it before. Note that just like the extra blank, I don't see anything in style(9) that talks about punctuation in comments (besides the comments on the list that :-)/( and friends were thought to be punctuation :-D)... is this too a new or just missing item from style(9)? > > > % + * % + * XXXML: Maybe add a flag to the > % + * prototype so that the tunneling > % + * can defer work that can't be done > % + * under the info lock? > % + */ > % + udp_tunnel_func_t tunnel_func; > > This typedef is very verbose... Ok, I dropped it down to udp_tun_func_t .. the minimum IMO needed to make it clear what is being done. I have some of those c++ tendency's to want things to be clear :-) > > > % + > % + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; > > ... line too long, caused by the verbose typedef. I think the 3 char's fix this .. :-) > > > Casts are not followed by a space in KNF. This style bug is made > fairly > consistently in this patch. Hmm I wonder if that was s9indent.. need to go look at that script... since I normally don't put white space in front of a cast ;-D > > > Bogus cast (depends on undefined behaviour to save space). We discussed this.. and I don't think its worth adding the space... > > > % + tunnel_func(m, iphlen, last); > % + INP_RUNLOCK(last); > % + } > % } > % last = inp; > % /* > % - * Don't look for additional matches if this one does > % - * not have either the SO_REUSEPORT or SO_REUSEADDR > % - * socket options set. This heuristic avoids > % - * searching through all pcbs in the common case of a > % - * non-shared port. It assumes that an application > % - * will never clear these options after setting them. > % + * Don't look for additional matches if this one > % + * does not have either the SO_REUSEPORT or > % + * SO_REUSEADDR socket options set. This heuristic > % + * avoids searching through all pcbs in the common > % + * case of a non-shared port. It assumes that an > % + * application will never clear these options after > % + * setting them. > % */ > % if ((last->inp_socket->so_options & > % - (SO_REUSEPORT|SO_REUSEADDR)) == 0) > % + (SO_REUSEPORT | SO_REUSEADDR)) == 0) > > You didn't have to touch this statement. Touching it improves it. > > % break; > % } > % % if (last == NULL) { > % /* > % - * No matching pcb found; discard datagram. (No need > % - * to send an ICMP Port Unreachable for a broadcast > % - * or multicast datgram.) > % + * No matching pcb found; discard datagram. (No > % + * need to send an ICMP Port Unreachable for a > % + * broadcast or multicast datgram.) > > You didn't have to touch this. Touching it unimproves it. > > % ... > % } > % - > % /* > % * Locate pcb for datagram. > % */ > % @@ -553,7 +588,6 @@ > % INP_INFO_RUNLOCK(&V_udbinfo); > % return; > % } > % - > % /* > % * Check the minimum TTL for socket. > % */ > > You didn't have to touch these. Touching them arguably unimproves > them, > though strict KNF probably doesn't permit these blank lines. Ok, All of those touches (improvements or un-improvements) are gone now :-D > > > % @@ -563,6 +597,18 @@ > % INP_RUNLOCK(inp); > % goto badunlocked; > % } > % + if (inp->inp_ppcb) { > > It is preferable to compare pointers explicitly with NULL. The > previous > comparision of inp_ppcb in this patch is explicit (but it is for > equality). > This and all of the following comparisions are implicit (for > inequality). I agree .. and have made those changes :-D > > > % @@ -1138,10 +1184,41 @@ > % INP_INFO_WUNLOCK(&V_udbinfo); > % inp->inp_vflag |= INP_IPV4; > % inp->inp_ip_ttl = V_ip_defttl; > % + /* > % + * UDP does not have a per-protocol > % + * pcb (inp->inp_ppcb). We use this > % + * pointer for kernel tunneling pointer. > % + * If we ever need to have a protocol > % + * block we will need to move this > % + * function pointer there. Null > % + * in this pointer means "do the normal > % + * thing". > % + */ > > Lines too short (formatted for 50-column terminals). Fixed... > > > Normal entence breaks are 2 spaces, not 1 as in this comment. Most > of the > other comments in this patch have normal sentence breakes. > > % ... > % +int > % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) > % +{ > % + struct inpcb *inp; > > Missing blank line after declarations. > > % + inp = (struct inpcb *)so->so_pcb; > % + > > Extra blank line. > > % + if (so->so_type != SOCK_DGRAM) { > % + /* Not UDP socket... sorry */ > > Missing punctuation. fixed both of these... but my comments above apply :-D > > > % Index: netinet/udp_var.h > % =================================================================== > % --- netinet/udp_var.h (revision 185928) > % +++ netinet/udp_var.h (working copy) > % @@ -107,6 +107,10 @@ > % void udp_input(struct mbuf *, int); > % struct inpcb *udp_notify(struct inpcb *inp, int errno); > % int udp_shutdown(struct socket *so); > % + > % + > % +typedef void(*udp_tunnel_func_t)(struct mbuf *, int off, struct > inpcb *); > % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t > f); > % #endif > % % #endif > > Still has a style bug density of about 5 per line :-(. > > % Index: netinet6/udp6_usrreq.c > > Similarly. > > Bruce > -------------- next part -------------- Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 186478) +++ netinet/udp_usrreq.c (working copy) @@ -488,10 +488,33 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, + ip, n, + iphlen + + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + } else { + /* + * Engage the tunneling protocol we + * will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't + * break. + * + * XXXML: Maybe add a flag to the + * prototype so that the tunneling + * can defer work that can't be done + * under the info lock? + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)last->inp_ppcb; + tunnel_func(n, iphlen, last); + INP_RUNLOCK(last); + } } last = inp; /* @@ -516,10 +539,24 @@ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)last->inp_ppcb; + tunnel_func(m, iphlen, last); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } return; } @@ -563,6 +600,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb != NULL) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)inp->inp_ppcb; + tunnel_func(m, iphlen, inp); + INP_RUNLOCK(inp); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1187,38 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol pcb (inp->inp_ppcb). + * We use this pointer for kernel tunneling pointer. + * If we ever need to have a protocol block we will + * need to move this function pointer there. Null + * in this pointer means "do the normal thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f) +{ + struct inpcb *inp; + + inp = (struct inpcb *)so->so_pcb; + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry! */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 186478) +++ netinet/udp_var.h (working copy) @@ -110,6 +110,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tun_func_t)(struct mbuf *, int off, struct inpcb *); +int udp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f); #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 186478) +++ netinet6/udp6_usrreq.c (working copy) @@ -287,8 +287,25 @@ if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb != NULL) { + /* + * Engage the tunneling + * protocol we will have to + * leave the info_lock up, + * since we are hunting + * through multiple UDP + * inp's hope we don't break. + * + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)last->inp_ppcb; + tunnel_func(n, off, last); + INP_RUNLOCK(last); + } else { + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; @@ -317,6 +334,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb != NULL) { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)inp->inp_ppcb; + tunnel_func(m, off, last); + INP_RUNLOCK(last); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +384,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb != NULL) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)inp->inp_ppcb; + tunnel_func(m, off, inp); + INP_RUNLOCK(inp); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); -------------- next part -------------- ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From qing.li at bluecoat.com Fri Dec 26 12:15:33 2008 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Dec 26 12:15:40 2008 Subject: Odd behavior routed In-Reply-To: References: <49528E6F.30600@ukr.net> Message-ID: Hi, I have committed a patch for this problem. Please sync-up to SVN rev 186500 on 2008-12-26 19:45:24Z by qingli Thank, -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Li, Qing > Sent: Thursday, December 25, 2008 1:33 AM > To: Vladislav V. Prodan; Qing Li > Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org > Subject: RE: Odd behavior routed > > I found the bug and it was indeed introduced by the arp-v2 > changes. > > Since adding static ARP/NDP entries and adding static > routing entries both execute through the routing socket > interface, I could not distinguish one operation from > the other when the "-iface" is specified in the "route" > command. > > I have introduced a new RTF_LLDATA flag to differentiate > between these two types of operation. > > Please find the patch file in my home directory > at http://people.freebsd.org/~qingli/arp-v2-patch-122508 > > I will do more testing and getting the patch reviewed > before I make the official commit. In the meantime, > please try it out and let me know how the patch works > out for you. > > Thanks, > > -- Qing > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > net@freebsd.org] On Behalf Of Vladislav V. Prodan > > Sent: Wednesday, December 24, 2008 11:33 AM > > To: freebsd-current@freebsd.org; freebsd-net@freebsd.org > > Cc: freebsd-hackers@freebsd.org > > Subject: Odd behavior routed > > > > # uname -a > > FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec > > 24 > > 05:06:55 EET 2008 > > vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10 amd64 > > > > We have two providers on tun1 and tun2. > > > > >>/etc/rc.conf: > > ... > > gateway_enable="YES" > > router="/sbin/routed" > > router_enable="YES" > > router_flags="-s -T /var/log/routed.log -P no_rip" > > ... > > > > # netstat -rn > > Routing tables > > > > Internet: > > Destination Gateway Flags Refs Use Netif > > Expire > > default 89.209.95.254 UGS 0 653418 tun1 > > 10.0.0.0/24 link#1 U 0 85595 re0 > > 85.238.109.61 127.0.0.1 UH 0 0 lo0 > > 89.209.XX.YY 127.0.0.1 UH 0 483 lo0 > > 89.209.95.254 89.209.XX.YY UH 0 0 tun1 > > 127.0.0.1 link#6 UH 0 19781 lo0 > > 192.168.152.0/24 10.0.0.20 UGS 0 0 re0 > > 195.138.80.168 link#8 UH 0 5 tun2 > > > > Internet6: > > Destination Gateway Flags > > Netif Expire > > ::1 link#6 UH > > lo0 > > fe80::%lo0/64 link#6 U > > lo0 > > ff01:6::/32 fe80::1%lo0 U > > lo0 > > ff01:7::/32 fe80::2e0:4dff:fe7b:690c%tun1 UG > > tun1 > > ff01:8::/32 fe80::2e0:4dff:fe7b:690c%tun2 UG > > tun2 > > ff02::%lo0/32 fe80::1%lo0 U > > lo0 > > ff02::%tun1/32 fe80::2e0:4dff:fe7b:690c%tun1 UG > > tun1 > > ff02::%tun2/32 fe80::2e0:4dff:fe7b:690c%tun2 UG > > tun2 > > > > > > I would like to put some networks via a second ISP: > > # /sbin/route add -net 79.140.0.0/20 -iface tun2 > > add net 79.140.0.0: gateway tun2 > > # /sbin/route add -net 85.238.96.0/19 -iface tun2 > > add net 85.238.96.0: gateway tun2 > > # /sbin/route add -net 195.138.64.0/19 -iface tun2 > > add net 195.138.64.0: gateway tun2 > > > > But routes do not appear, the table remains unchanged. > > In the logs routed: > > > > RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 > > static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 > impossibly > > lacks ifp > > -- 11:35:16 -- > > RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> > 85.238.109.61 > > static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 > impossibly > > lacks ifp > > -- 11:35:28 -- > > RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> > 85.238.109.61 > > static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 > > impossibly > > lacks ifp > > > > > > Before rebuild kernel, it appeared, and now there is no. > > It is now adding routes? > > > > Using gated|quagga|zebra does not offer. > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net- > unsubscribe@freebsd.org" From vanhu at FreeBSD.org Fri Dec 26 13:43:05 2008 From: vanhu at FreeBSD.org (vanhu@FreeBSD.org) Date: Fri Dec 26 13:43:11 2008 Subject: kern/124609: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 Message-ID: <200812262143.mBQLh4IQ008891@freefall.freebsd.org> Synopsis: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 Responsible-Changed-From-To: freebsd-net->vanhu Responsible-Changed-By: vanhu Responsible-Changed-When: Fri Dec 26 21:42:15 UTC 2008 Responsible-Changed-Why: We are currently tracking down the same problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=124609 From gerald at pfeifer.com Sat Dec 27 04:28:43 2008 From: gerald at pfeifer.com (Gerald Pfeifer) Date: Sat Dec 27 04:28:49 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812231750.26602.tijl@ulyssis.org> References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> <200812231750.26602.tijl@ulyssis.org> Message-ID: On Tue, 23 Dec 2008, Tijl Coosemans wrote: >> No, the output of this command is still the same. NET_RT_DUMP obtains >> the entire L3 table and filtering for RTF_GATEWAY non-multicast >> routes have the same semantics. Those flags never apply to L2 entries. > Thanks for answering my questions. I've attached the patch for Wine. Thanks, Tijl! Are you also going to submit this patch upstream or would you prefer me to submit my (syntactically different, but equivalent) version? I'd love to see this addressed in Wine 1.1.12. Gerald From tijl at ulyssis.org Sat Dec 27 05:58:56 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Sat Dec 27 05:59:04 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081221125120.GO23166@droso.net> <200812231750.26602.tijl@ulyssis.org> Message-ID: <200812271458.52492.tijl@ulyssis.org> On Saturday 27 December 2008 13:28:42 Gerald Pfeifer wrote: > On Tue, 23 Dec 2008, Tijl Coosemans wrote: >>> No, the output of this command is still the same. NET_RT_DUMP >>> obtains the entire L3 table and filtering for RTF_GATEWAY >>> non-multicast routes have the same semantics. Those flags never >>> apply to L2 entries. >> >> Thanks for answering my questions. I've attached the patch for Wine. > > Thanks, Tijl! Are you also going to submit this patch upstream or > would you prefer me to submit my (syntactically different, but > equivalent) version? I'd love to see this addressed in Wine 1.1.12. I was kind of waiting for the dust to settle. I didn't want to speak up because I'm no authority in this area and in the end I'm OK with any outcome, but personnaly I find special-casing {NET_RT_FLAGS,0} to retrieve the L2 entries a bit odd. Surely, letting {NET_RT_FLAGS,RTF_LLINFO} return L2 entries is exactly the same to implement, is far more descriptive, is fully backwards compatible and compatible with other sysctl operating systems like the other BSDs and Mac OS X, which helps portability. AFAIK, the other use of RTF_LLINFO was to filter out L2 entries from the entire L2+L3 routing table to obtain just the L3 entries. Because the L2 and L3 table have been separated this filtering isn't needed anymore, but what harm would it do to reintroduce RTF_LLINFO? The filtering code would become a useless no-op, but you'd stay fully compatible, again both backwards and with other operating systems. I just think that removing RTF_LLINFO was a bit too aggressive an optimisation with little advantage and too many disadvantages and I'd like to see it return. From qingli at speakeasy.net Sat Dec 27 12:47:56 2008 From: qingli at speakeasy.net (Qing Li) Date: Sat Dec 27 12:48:03 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812271458.52492.tijl@ulyssis.org> Message-ID: <20081227204756.B1CB98FC1E@mx1.freebsd.org> Right now I am also a bit leaning towards reintroducing the RTF_LLINFO flag bit. This is mainly due to the recent discovery of the "route" command issued with the "-iface/-interface" option, which conflicts with the way how "arp" and "ndp" is handled in the kernel. I renamed this flag bit to RTF_LLDATA because only the "arp" and "ndp" commands need it. > > I didn't want to speak up because I'm no authority in this > area and in the end I'm OK with any outcome, but personnaly I > find special-casing {NET_RT_FLAGS,0} to retrieve the L2 > entries a bit odd. > As I've indicated previously, a few ports already have the #ifdef RTF_LLINFO block around the sysctl() setup code. Perhaps it's because these ports (such as Wine) run on OS that does not support RTF_LLINFO (e.g. Linux?) ? > > Surely, letting {NET_RT_FLAGS,RTF_LLINFO} > return L2 entries is exactly the same to implement, is far > more descriptive, is fully backwards compatible and > compatible with other sysctl operating systems like the other > BSDs and Mac OS X, which helps portability. > I believe all of the affected ports have been updated to include the conditional blocks around RTF_LLINFO. So there is still a level of compatibility, right ? > > AFAIK, the other use of RTF_LLINFO was to filter out L2 > entries from the entire L2+L3 routing table to obtain just > the L3 entries. Because the L2 and L3 table have been > separated this filtering isn't needed anymore, but what harm > would it do to reintroduce RTF_LLINFO? The filtering code > would become a useless no-op, but you'd stay fully > compatible, again both backwards and with other operating systems. > > I just think that removing RTF_LLINFO was a bit too > aggressive an optimisation with little advantage and too many > disadvantages and I'd like to see it return. > I believe examining the impacts of RTF_LLINFO on the ports was a good exercise even if we have to rejuvenate it. I hope we could reach a consensus soon now that we have more input from the ports developers. Please provide your input ... -- Qing From julian at elischer.org Sat Dec 27 14:54:36 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Dec 27 14:54:43 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <20081227204756.B58938FC1F@mx1.freebsd.org> References: <20081227204756.B58938FC1F@mx1.freebsd.org> Message-ID: <4956B22A.6080109@elischer.org> Qing Li wrote: > > > I believe examining the impacts of RTF_LLINFO on the ports > was a good exercise even if we have to rejuvenate it. > > I hope we could reach a consensus soon now that we have more > input from the ports developers. > > Please provide your input ... reintroduce it with value 0 then teh optimiser should remove dead code... > > -- Qing > > > > > > > > > > > > From peterjeremy at optushome.com.au Sat Dec 27 15:06:26 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Dec 27 15:06:33 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <4956B22A.6080109@elischer.org> References: <20081227204756.B58938FC1F@mx1.freebsd.org> <4956B22A.6080109@elischer.org> Message-ID: <20081227230613.GB64280@server.vk2pj.dyndns.org> On 2008-Dec-27 14:54:34 -0800, Julian Elischer wrote: >Qing Li wrote: >> I believe examining the impacts of RTF_LLINFO on the ports >> was a good exercise even if we have to rejuvenate it. > >reintroduce it with value 0 And a comment indicating that the definition of RTF_LLINFO is solely for backward compatibility. (To make it clear why it's never referenced in the base system and not needed for new code). -- 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/20081227/801fca00/attachment.pgp From sam at freebsd.org Sat Dec 27 15:07:28 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Dec 27 15:07:40 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <4956B22A.6080109@elischer.org> References: <20081227204756.B58938FC1F@mx1.freebsd.org> <4956B22A.6080109@elischer.org> Message-ID: <4956B52F.2070300@freebsd.org> Julian Elischer wrote: > Qing Li wrote: >> >> >> I believe examining the impacts of RTF_LLINFO on the ports was a good >> exercise even if we have to rejuvenate it. >> >> I hope we could reach a consensus soon now that we have more input >> from the ports developers. >> >> Please provide your input ... > > reintroduce it with value 0 > then teh optimiser should remove dead code... > The worry is that this will cause subtle bugs when code assumes functionality is present. We tried yanking this entirely and it's obviously caused some issues. The question now is whether to follow through and accept an incompatibility or put back sufficient compatibility to enable legacy code to work unchanged. Sam From lastewart at swin.edu.au Sun Dec 28 04:33:47 2008 From: lastewart at swin.edu.au (Lawrence Stewart) Date: Sun Dec 28 04:33:55 2008 Subject: CFT: TCP Appropriate Byte Counting (RFC3465) Patch Message-ID: <49576E98.2070403@swin.edu.au> Hi all, The first chunk of work from the FreeBSD Foundation sponsored "Improving the FreeBSD TCP Implementation" project [1] is ready for some public review and testing. Being my first project related email, I'll point out to anyone interested that you can track the overall project via [2,3]. TCP appropriate byte counting (ABC) [4] addresses a congestion control related issue introduced by the early TCP specifications. It suggests increasing the congestion window by the number of bytes acknowledged by a TCP ACK, as opposed to the current scheme which relies on an approximation driven by ACK clocking. ABC will most commonly benefit FreeBSD by improving TCP sender performance when communicating with a delayed acknowledgement enabled receiver. The patch against 8-CURRENT svn rev 186471 can be found at [5] along with a readme [6] covering all the necessary juicy bits in more detail. I welcome all feedback and reports of both success or failure. I'm currently working on analysing the small-scale dynamic behaviour effects of the patch in detail, so I'm not asking you to go into minute detail with your testing. I'd like to hear that running with an ABC enabled kernel allows TCP to work as it did previously and is not negatively impacting throughput for any particular TCP workloads you have available for testing. I aim to commit this within the next week or so assuming nothing bad turns up in this round of testing. Cheers, Lawrence http://caia.swin.edu.au/ [1] http://www.freebsdfoundation.org/project%20announcements.shtml#Lawrence [2] http://svn.freebsd.org/viewvc/base/projects/tcp_ffcaia2008_8.x/ [3] http://lists.freebsd.org/mailman/listinfo/svn-src-projects [4] http://www.rfc-editor.org/rfc/rfc3465.txt [5] http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/tcp_abc_8.x.r186471.patch [6] http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/tcp_abc_8.x.r186471.patch.readme From tijl at ulyssis.org Sun Dec 28 07:13:52 2008 From: tijl at ulyssis.org (Tijl Coosemans) Date: Sun Dec 28 07:14:00 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> Message-ID: <200812281613.49404.tijl@ulyssis.org> On Saturday 27 December 2008 21:21:25 Qing Li wrote: > Right now I am also a bit leaning towards reintroducing > the RTF_LLINFO flag bit. This is mainly due to the recent > discovery of the "route" command issued with the > "-iface/-interface" option, which conflicts with the > way how "arp" and "ndp" is handled in the kernel. > > I renamed this flag bit to RTF_LLDATA because only the > "arp" and "ndp" commands need it. I wouldn't rename it. That breaks old code just the same. >> I didn't want to speak up because I'm no authority in this >> area and in the end I'm OK with any outcome, but personnaly I >> find special-casing {NET_RT_FLAGS,0} to retrieve the L2 >> entries a bit odd. > > As I've indicated previously, a few ports already have the > #ifdef RTF_LLINFO block around the sysctl() setup code. > Perhaps it's because these ports (such as Wine) run on OS > that does not support RTF_LLINFO (e.g. Linux?) ? That's odd, because a quick google shows that for instance NetBSD, OpenBSD, DragonFly and Mac OS X all define this flag. Linux is completely different. It doens't use sysctl(3). You have to read /proc/net/arp and /proc/net/route. >> Surely, letting {NET_RT_FLAGS,RTF_LLINFO} >> return L2 entries is exactly the same to implement, is far >> more descriptive, is fully backwards compatible and >> compatible with other sysctl operating systems like the other >> BSDs and Mac OS X, which helps portability. > > I believe all of the affected ports have been updated to > include the conditional blocks around RTF_LLINFO. So > there is still a level of compatibility, right ? Yes, and I'm OK with this. It's just that this makes FreeBSD 8 a special case. >> AFAIK, the other use of RTF_LLINFO was to filter out L2 >> entries from the entire L2+L3 routing table to obtain just >> the L3 entries. Because the L2 and L3 table have been >> separated this filtering isn't needed anymore, but what harm >> would it do to reintroduce RTF_LLINFO? The filtering code >> would become a useless no-op, but you'd stay fully >> compatible, again both backwards and with other operating systems. >> >> I just think that removing RTF_LLINFO was a bit too >> aggressive an optimisation with little advantage and too many >> disadvantages and I'd like to see it return. > > I believe examining the impacts of RTF_LLINFO on the ports > was a good exercise even if we have to rejuvenate it. > > I hope we could reach a consensus soon now that we have more > input from the ports developers. > > Please provide your input ... If it's easy to reintroduce it and become backwards compatible I would do it. Like Julian said, you can give it the value 0. It would be nice if the kernel tested for the old value as well, perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7 keep working. From gnn at neville-neil.com Sun Dec 28 09:30:36 2008 From: gnn at neville-neil.com (George Nevill-Neil) Date: Sun Dec 28 09:30:42 2008 Subject: A new tool for low level testing... In-Reply-To: <495290EF.6020400@elischer.org> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> <20081224111546.GA59523@onelab2.iet.unipi.it> <495290EF.6020400@elischer.org> Message-ID: <3BE32C00-3AF8-4C8F-B48D-45F50D55A2B2@neville-neil.com> On Dec 24, 2008, at 2:43 PM, Julian Elischer wrote: > Luigi Rizzo wrote: >> On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: >>> Julian Elischer wrote: >>>> OR >>>> >>>> ngctl mkpeer em0: echo lower echo >>>> >>>> >>>> hmmmmm no this would leave the source and destination headers in >>>> hte same order.. they need to be swapped.. >>>> >>>> ok so I need to make a patch, but it would be much quicker than a >>>> user utility.. >>> what about a netgraph cookbook? >> indeed, that would be a nice Xmas present! >> cheers >> luigi > > > I'm curious, what sort of things would you expect to see in such a > document? Maybe we could get everyone to contribute their favourite > netgraph recipes (scripts?). > I have often thought of updating the docs I've found but as usual $paidwork gets in the way. I may be about to use netgraph at work so I might be able to help with this. The things that I find to be missing in the current netgraph documentation are: 1) Developers Guide How do I write new nodes? Walk through a non trivial node step by step. 2) Updated overall use guide I've found a few docs on netgraph on the net, but I bet most people are still looking at Archie Cobb's old document and it's out of date. 3) Recipes Sure, a fine idea, but it's not the first thing I need. Best, George From universite at ukr.net Sun Dec 28 10:08:12 2008 From: universite at ukr.net (Vladislav V. Prodan) Date: Sun Dec 28 10:08:18 2008 Subject: Odd behavior routed In-Reply-To: References: <49528E6F.30600@ukr.net> Message-ID: <4957BEC7.6010603@ukr.net> Thank you. The option "-iface" works as expected. Also solved the problem when the squid 3.0.STABLE10 could not connect to the real ip, which ISP issued on pppoe. Now squid normally sees routes to these IP. Li, Qing writes: > Hi, > I have committed a patch for this problem. Please sync-up to > SVN rev 186500 on 2008-12-26 19:45:24Z by qingli > Thank, > -- Qing From bzeeb-lists at lists.zabbadoz.net Sun Dec 28 15:25:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Dec 28 15:25:16 2008 Subject: arp-v2 (void *)-1 "hack" Message-ID: <20081228225956.G28465@maildrop.int.zabbadoz.net> Hi, Cc:ing freebsd-net as I came across the (void *)-1 "hack" 1.5 weeks ago while debugging some problems with others and they might be interested as well. I was sure I hadn't seen that hack in patches posted before. I spent some time today and looked a bit more into it (also comitted the LLE_IS_VALID() check). In short: I don't like it and I don't understand why a new API needs a hack already that is passed down through two functions into the code. It was introduced the last days before the commit. I found r186010 and r186027 in SVN but that's just two of the 4 places. I think the proper behavior would be to either return an "errno" or the lle via an additional argument and the other as return value. As the lle is the return value already I would say adding an extra argument 'int *error' will be easier. For now this seems to only affect LLE_DELETE cases but I am not sure all (especially wrt to the future of v6) has been shaken out yet and returning a proper error code (possibly along with the NULL lle) would make this more flexible. I am also not sure if all the "void" callers on delete are right but I got distracted by a "dead" function in one of the callpaths while investigating. What do you think wrt to adding the (possibly optional) int *error and returning the errno rather than a (void *)-1? If you'd be ok, I'd can prepare the patch. I'd rather break the API now than in a few months. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From kmacy at freebsd.org Sun Dec 28 15:30:59 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sun Dec 28 15:31:05 2008 Subject: arp-v2 (void *)-1 "hack" In-Reply-To: <20081228225956.G28465@maildrop.int.zabbadoz.net> References: <20081228225956.G28465@maildrop.int.zabbadoz.net> Message-ID: <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> > What do you think wrt to adding the (possibly optional) int *error and > returning the errno rather than a (void *)-1? If you'd be ok, I'd can > prepare the patch. I'd rather break the API now than in a few months. I would greatly prefer having a dedicated new function that calls in to it. There are a lot of calls to lla_lookup that would have to be changed needlessly. In other words: 1) lla_lookup_internal - a static function which takes all 3 args 2) lla_delete - which returns an errno 3) lla_lookup - which maintains the current interface I'll review the patch as soon as it is ready. -Kip From bzeeb-lists at lists.zabbadoz.net Sun Dec 28 15:55:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Dec 28 15:55:14 2008 Subject: arp-v2 (void *)-1 "hack" In-Reply-To: <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> References: <20081228225956.G28465@maildrop.int.zabbadoz.net> <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> Message-ID: <20081228234501.F28465@maildrop.int.zabbadoz.net> On Sun, 28 Dec 2008, Kip Macy wrote: Hi, >> What do you think wrt to adding the (possibly optional) int *error and >> returning the errno rather than a (void *)-1? If you'd be ok, I'd can >> prepare the patch. I'd rather break the API now than in a few months. > > I would greatly prefer having a dedicated new function that calls in > to it. There are a lot of calls to lla_lookup that would have to be > changed needlessly. In other words: Right, there are 14 or so of them and at least 2 will need to be touched. > 1) lla_lookup_internal - a static function which takes all 3 args > 2) lla_delete - which returns an errno > 3) lla_lookup - which maintains the current interface I wonder if it's worth adding two more functions for about a dozen calls from basically 2 files; especially considering that we will need to modify the internal API (llt_lookup function pointer in struct lltable and in_lltable_lookup()/in6_lltable_lookup()) anyway. That's why I thought adding the int *error now consistently would be easier and cleaner. Most of the callers, currently not caring could just pass in NULL, if they don't care and we keep the argument optional. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bzeeb-lists at lists.zabbadoz.net Sun Dec 28 16:35:16 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Dec 28 16:35:23 2008 Subject: arp-v2 (void *)-1 "hack" In-Reply-To: <20081228234501.F28465@maildrop.int.zabbadoz.net> References: <20081228225956.G28465@maildrop.int.zabbadoz.net> <3c1674c90812281530l52b83404k9822cf6818329f01@mail.gmail.com> <20081228234501.F28465@maildrop.int.zabbadoz.net> Message-ID: <20081229003106.G28465@maildrop.int.zabbadoz.net> On Sun, 28 Dec 2008, Bjoern A. Zeeb wrote: Hi, > On Sun, 28 Dec 2008, Kip Macy wrote: > > Hi, > >>> What do you think wrt to adding the (possibly optional) int *error and >>> returning the errno rather than a (void *)-1? If you'd be ok, I'd can >>> prepare the patch. I'd rather break the API now than in a few months. >> >> I would greatly prefer having a dedicated new function that calls in >> to it. There are a lot of calls to lla_lookup that would have to be >> changed needlessly. In other words: > > Right, there are 14 or so of them and at least 2 will need to be > touched. > >> 1) lla_lookup_internal - a static function which takes all 3 args >> 2) lla_delete - which returns an errno >> 3) lla_lookup - which maintains the current interface > > I wonder if it's worth adding two more functions for about a dozen calls > from basically 2 files; especially considering that we will need to modify > the internal API (llt_lookup function pointer in struct lltable and > in_lltable_lookup()/in6_lltable_lookup()) anyway. > > That's why I thought adding the int *error now consistently would be > easier and cleaner. > > Most of the callers, currently not caring could just pass in NULL, if > they don't care and we keep the argument optional. Just as a follow-up. I talked to Qing and the summary is: * we agree that this should be changed - one way or the other. * we'll wait a bit for things to settle more and possibly (though hopefully not) collect another few cases and fix them all at once should they show up. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From gerryw at compvia.com Sun Dec 28 18:30:00 2008 From: gerryw at compvia.com (Gerry Weaver) Date: Sun Dec 28 18:30:07 2008 Subject: pfil + if_bridge hooks not being called Message-ID: <20081229015957.4fe4d0ac@mail01.compvia.com> Hello All, I am working on a driver to collect some network statistics using pfil. I have set up a bridge and set net.link.bridge.pfil_member=1 via sysctl. I have added hooks for incoming and outgoing packets. I also put a third adapter into the system for dev/managment purposes. My hooks are only being called for outgoing packets on the management (non bridge) interface. I have been searching for information about what I may have overlooked, but I can't find anything concrete. Is there something else that I need to do to see packets on the bridge member interfaces and incoming packets in general? I'm using FreeBSD 7.0-RELEASE. struct pfil_head *pfh_inet; pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET); if(pfh_inet == NULL) { uprintf("ERROR: Cannot get pfil head\n"); return ENOENT; } pfil_add_hook(packets_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet); pfil_add_hook(packets_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet); ... Thanks in advance, Gerry From invite+ke5r5rmn at facebookmail.com Sun Dec 28 21:04:09 2008 From: invite+ke5r5rmn at facebookmail.com (Michael Sierchio) Date: Sun Dec 28 21:04:17 2008 Subject: Check out my Facebook profile Message-ID: <7342474667325a9d0c0ebfc000da4a0e@localhost.localdomain> Hi freebsd-net, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Michael To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=605054484&k=64GZ6VV4W26M5CEIXFY6X3&r From fernercc at gmail.com Sun Dec 28 21:11:47 2008 From: fernercc at gmail.com (Ferner Cilloniz) Date: Sun Dec 28 21:11:56 2008 Subject: Check out my Facebook profile In-Reply-To: <7342474667325a9d0c0ebfc000da4a0e@localhost.localdomain> References: <7342474667325a9d0c0ebfc000da4a0e@localhost.localdomain> Message-ID: <1230505903.4966.0.camel@mobiliare.Belkin> Because that is clearly related to freebsd-net. Have you lost your mind?? On Sun, 2008-12-28 at 17:14 -0800, Michael Sierchio wrote: > Hi freebsd-net, > > I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. > > Thanks, > Michael > > To sign up for Facebook, follow the link below: > http://www.facebook.com/p.php?i=605054484&k=64GZ6VV4W26M5CEIXFY6X3&r > > _______________________________________________ > 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 rea-fbsd at codelabs.ru Sun Dec 28 23:10:41 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Dec 28 23:10:49 2008 Subject: pfil + if_bridge hooks not being called In-Reply-To: <20081229015957.4fe4d0ac@mail01.compvia.com> References: <20081229015957.4fe4d0ac@mail01.compvia.com> Message-ID: Gerry, good day. Sun, Dec 28, 2008 at 07:59:57PM -0600, Gerry Weaver wrote: > I am working on a driver to collect some network statistics using > pfil. I have set up a bridge and set net.link.bridge.pfil_member=1 via > sysctl. I have added hooks for incoming and outgoing packets. I also > put a third adapter into the system for dev/managment purposes. My > hooks are only being called for outgoing packets on the management > (non bridge) interface. A simple check will be to fire up standard hooks (for example, pf firewall + some rules with 'log' keyword, see 'man pf.conf') and watch for the logged packets on a pflog0 interface using tcpdump. If you'll see the packets you wanted to see, then the problem is probably with your code. If not, then probably your setup is incorrect and/or system has a bug. > I have been searching for information about > what I may have overlooked, but I can't find anything concrete. Is > there something else that I need to do to see packets on the bridge > member interfaces and incoming packets in general? You may want to add some diagnostics to the bridge_pfil() in /sys/net/if_bridge.c, rebuild your kernel and try to see how it goes. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From gerald at pfeifer.com Mon Dec 29 00:54:53 2008 From: gerald at pfeifer.com (Gerald Pfeifer) Date: Mon Dec 29 00:55:00 2008 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <200812281613.49404.tijl@ulyssis.org> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> Message-ID: On Sun, 28 Dec 2008, Tijl Coosemans wrote: > On Saturday 27 December 2008 21:21:25 Qing Li wrote: >> I believe all of the affected ports have been updated to >> include the conditional blocks around RTF_LLINFO. emulators/wine has not been adjusted yet, pending this discussion. > Yes, and I'm OK with this. It's just that this makes FreeBSD 8 > a special case. Agreed. > If it's easy to reintroduce it and become backwards compatible I > would do it. Like Julian said, you can give it the value 0. It > would be nice if the kernel tested for the old value as well, > perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people > upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7 > keep working. What of this will be doable, Qing? I guess Tijl and me need to understand when/whether/what to submit to Wine upstream... Gerald From gerryw at compvia.com Mon Dec 29 02:36:49 2008 From: gerryw at compvia.com (Gerry Weaver) Date: Mon Dec 29 02:36:56 2008 Subject: pfil + if_bridge hooks not being called In-Reply-To: "" Message-ID: <20081229103617.cee01bda@mail01.compvia.com> _____ From: Eygene Ryabinkin [mailto:rea-fbsd@codelabs.ru] To: Gerry Weaver [mailto:gerryw@compvia.com] Cc: freebsd-net@freebsd.org Sent: Mon, 29 Dec 2008 01:10:37 -0600 Subject: Re: pfil + if_bridge hooks not being called Gerry, good day. Sun, Dec 28, 2008 at 07:59:57PM -0600, Gerry Weaver wrote: > I am working on a driver to collect some network statistics using > pfil. I have set up a bridge and set net.link.bridge.pfil_member=1 via > sysctl. I have added hooks for incoming and outgoing packets. I also > put a third adapter into the system for dev/managment purposes. My > hooks are only being called for outgoing packets on the management > (non bridge) interface. A simple check will be to fire up standard hooks (for example, pf firewall + some rules with 'log' keyword, see 'man pf.conf') and watch for the logged packets on a pflog0 interface using tcpdump. If you'll see the packets you wanted to see, then the problem is probably with your code. If not, then probably your setup is incorrect and/or system has a bug. > I have been searching for information about > what I may have overlooked, but I can't find anything concrete. Is > there something else that I need to do to see packets on the bridge > member interfaces and incoming packets in general? You may want to add some diagnostics to the bridge_pfil() in /sys/net/if_bridge.c, rebuild your kernel and try to see how it goes. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # _______________________________________________ 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" Hello All, Thanks for the advice Eygene. It turns out that the pointer to the ifnet structure is null when the hook is called for incoming packets. I had a check for a null pointer, but failed to log the error. Reworking this code fixed the incoming packet problem. I put a printf in the outgoing packet hook function and things magically started working. If I take it out, things stop working. Something is getting stepped on. I'm gonna fiddle with it a bit to see what's happening there. I would assume it's probably something in my code as well. Also, after having a look at the if_bridge code, I'm starting to rethink the use of pfil in the first place. Calling my code from the if_bridge code offers some additional protocol support as well as several other possibilities. I appreciate the pointer to if_bridge.c. It made me look at it a lot sooner than I probably would have otherwise. Thanks Again for your help, Gerry From bugmaster at FreeBSD.org Mon Dec 29 03:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 29 03:08:36 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200812291106.mBTB6wF7024515@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/129904 net [vlan] [panic] kernel crash in "ifconfig destroy" o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/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/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/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 202 problems total. From nrml at att.net Mon Dec 29 04:01:44 2008 From: nrml at att.net (Gabe) Date: Mon Dec 29 04:01:50 2008 Subject: +ipsec_common_input: no key association found for SA Message-ID: <204586.11713.qm@web83809.mail.sp1.yahoo.com> Anyone know what causes this error message? +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 Thanks, /gabe From ajassal.ext at orange-ftgroup.com Mon Dec 29 04:33:26 2008 From: ajassal.ext at orange-ftgroup.com (ajassal.ext@orange-ftgroup.com) Date: Mon Dec 29 04:33:33 2008 Subject: SCTP : problems in sending ASCONF chunks Message-ID: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> Hi all, I have been working with SCTP and more specifically with the mobility features of SCTP at my work. Basically, I have been trying to use SCTP to perform handover tests between 2 separate Wifi networks. I use IPv6 for all my tests. I have a local LAN (wired-network), on which I have 3 machines, one of them is the machine I use to communicate with for the tests (I'll call it T to make things simple), and the other two are used as Wifi Access Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I set up both Access Points to send Router Advertisement messages periodically (minimum of 3 seconds, maximum of 4 seconds). That way I can have automatic address reconfiguration when I connect to either of the access points. The aim of my tests is to use a PC, connect to Wifi1 (for example), launch an SCTP association with T (T sends data to my PC), and then perform a handover on Wifi2. I do make address reconfiguration during the handover process. The important point is that I work with only ONE address on my network interface. Before I start my tests, I set the following sysctl parameters : # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w net.inet.sctp.mobility_fasthandoff=1 # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump messages in /var/log/messages) net.inet.sctp.auto_asconf is set to 1 by default. I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful but I'm trying to be thorough. This is the script I use to perform handover : ifconfig rum0 inet6 delete ifconfig rum0 ssid route del -inet6 default rtsol rum0 If I'm not mistaken, the PC should have sent an ASCONF chunk to perform dynamic address reconfiguration. However what I observed is that nothing happens. No ASCONF chunks are sent, and therefore, T doesn't ever know that it should send data on the PC's newly acquired address. I tried to investigate the problem myself, by adding some debug logs in the sctp source code (to see which functions are called during the handover process), and it seems as if the kernel doesn't ever add an ASCONF chunk to send in its queue... But that's just my understanding of the problem... I looked up in the CVS repository for answers, and to see the various changes that were gradually brought on the code. There, I noticed that on the revision dating 24th July 2007, changes were made for dynamic address reconfiguration : "Change behaviour so that when the last address is deleted (auto-asconf on a boudall endpoint) no action is taken until an address is added ; at that time an ASCONF add+delete is sent (if the asoc is still up)" In my humble opinion, this is exactly the case that corresponds to my handover scenario. But I just haven't been able to successfully perform it because I don't seem to send any ASCONF chunk. I'm struggling to understand why I do not see any ASCONF chunk sent. If it can help, I'm also attaching links to the kind of debug logs I got when performing a handover test. This is the kind of debug logs that I got : http://www.divshare.com/download/6200509-560 This is another debug logfile, but with my own debug logs added in the sctp source code : http://www.divshare.com/download/6200504-2e9 Many thanks for your work, and I hope someone will be able to help and shed some light on this problem :-) Aman Jassal From bzeeb-lists at lists.zabbadoz.net Mon Dec 29 04:55:10 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Dec 29 04:55:17 2008 Subject: +ipsec_common_input: no key association found for SA In-Reply-To: <204586.11713.qm@web83809.mail.sp1.yahoo.com> References: <204586.11713.qm@web83809.mail.sp1.yahoo.com> Message-ID: <20081229124113.A28465@maildrop.int.zabbadoz.net> On Mon, 29 Dec 2008, Gabe wrote: > Anyone know what causes this error message? > > +ipsec_common_input: no key association found for SA 69.x.x.x[0]/04e317a1/50 from what I remember without looking, this means that you ahve an IPsec policy for src/dst but no SA matching this pair or rather no matching destination + protocol + security parameter index (see rfc2401). The easiest thing you can do is to check setkey -Da for this tripple the time the printf happens. The first thing in the printf is your destination IP (your local side), the next is the SPI in hex and last is the protocol (50 == ESP). With that you can see if what the peer sends you is what you negotiated/expected. Are you using static keying or an ike daemon like racoon? Do this happen for all packets or just randomly or exactly every n minutes/hours? If you find an exact match of the triplet in setkey -Da you may also want to check if there is another one and/or the state of the entry/entries (state=.. at the end of the fourth line). If it's not "mature" check the time ralted values to see if there is an expiry problem.. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From Michael.Tuexen at lurchi.franken.de Mon Dec 29 05:09:18 2008 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Mon Dec 29 05:09:30 2008 Subject: SCTP : problems in sending ASCONF chunks In-Reply-To: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> Message-ID: <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM, wrote: > Hi all, > > I have been working with SCTP and more specifically with the mobility > features of SCTP at my work. Basically, I have been trying to use SCTP > to perform handover tests between 2 separate Wifi networks. I use IPv6 > for all my tests. > > I have a local LAN (wired-network), on which I have 3 machines, one of > them is the machine I use to communicate with for the tests (I'll call > it T to make things simple), and the other two are used as Wifi Access > Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I > set > up both Access Points to send Router Advertisement messages > periodically > (minimum of 3 seconds, maximum of 4 seconds). That way I can have > automatic address reconfiguration when I connect to either of the > access > points. > > The aim of my tests is to use a PC, connect to Wifi1 (for example), > launch an SCTP association with T (T sends data to my PC), and then > perform a handover on Wifi2. I do make address reconfiguration during > the handover process. The important point is that I work with only ONE > address on my network interface. Before I start my tests, I set the > following sysctl parameters : > > # sysctl -w net.inet.sctp.mobility_base=1 > # sysctl -w net.inet.sctp.mobility_fasthandoff=1 > # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump > messages in /var/log/messages) > > net.inet.sctp.auto_asconf is set to 1 by default. > > I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful > but > I'm trying to be thorough. This is the script I use to perform > handover > : > > ifconfig rum0 inet6 delete > ifconfig rum0 ssid > route del -inet6 default > rtsol rum0 > > If I'm not mistaken, the PC should have sent an ASCONF chunk to > perform > dynamic address reconfiguration. However what I observed is that > nothing > happens. No ASCONF chunks are sent, and therefore, T doesn't ever know > that it should send data on the PC's newly acquired address. > > I tried to investigate the problem myself, by adding some debug logs > in > the sctp source code (to see which functions are called during the > handover process), and it seems as if the kernel doesn't ever add an > ASCONF chunk to send in its queue... But that's just my > understanding of > the problem... > > I looked up in the CVS repository for answers, and to see the various > changes that were gradually brought on the code. There, I noticed that > on the revision dating 24th July 2007, changes were made for dynamic > address reconfiguration : "Change behaviour so that when the last > address is deleted (auto-asconf on a boudall endpoint) no action is > taken until an address is added ; at that time an ASCONF add+delete is > sent (if the asoc is still up)" > > In my humble opinion, this is exactly the case that corresponds to my > handover scenario. But I just haven't been able to successfully > perform > it because I don't seem to send any ASCONF chunk. I'm struggling to > understand why I do not see any ASCONF chunk sent. > > If it can help, I'm also attaching links to the kind of debug logs I > got > when performing a handover test. This is the kind of debug logs that I > got : > > http://www.divshare.com/download/6200509-560 > > This is another debug logfile, but with my own debug logs added in the > sctp source code : > > http://www.divshare.com/download/6200504-2e9 > > > Many thanks for your work, and I hope someone will be able to help and > shed some light on this problem :-) > > > Aman Jassal > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From bzeeb-lists at lists.zabbadoz.net Mon Dec 29 05:20:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Dec 29 05:20:13 2008 Subject: +ipsec_common_input: no key association found for SA In-Reply-To: <20081229124113.A28465@maildrop.int.zabbadoz.net> References: <204586.11713.qm@web83809.mail.sp1.yahoo.com> <20081229124113.A28465@maildrop.int.zabbadoz.net> Message-ID: <20081229131719.K28465@maildrop.int.zabbadoz.net> On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > On Mon, 29 Dec 2008, Gabe wrote: > >> Anyone know what causes this error message? >> >> +ipsec_common_input: no key association found for SA >> 69.x.x.x[0]/04e317a1/50 > > from what I remember without looking, this means that you ahve an > IPsec policy for src/dst but no SA matching this pair or rather no > matching destination + protocol + security parameter index (see rfc2401). > > The easiest thing you can do is to check > setkey -Da > for this tripple the time the printf happens. > > The first thing in the printf is your destination IP (your local side), > the next is the SPI in hex and last is the protocol (50 == ESP). With > that you can see if what the peer sends you is what you negotiated/expected. > > Are you using static keying or an ike daemon like racoon? > Do this happen for all packets or just randomly or exactly every n > minutes/hours? > > If you find an exact match of the triplet in setkey -Da you may also > want to check if there is another one and/or the state of the entry/entries > (state=.. at the end of the fourth line). > If it's not "mature" check the time ralted values to see if there is > an expiry problem.. One more thing - you may want to flip the sysctl to net.key.preferred_oldsa=0 and see if that makes a change. But beware - this is going to affect all your peers, not just one, so if you have 99 working and 1 not you'll most likely kill the other 99. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From ajassal.ext at orange-ftgroup.com Mon Dec 29 05:36:37 2008 From: ajassal.ext at orange-ftgroup.com (ajassal.ext@orange-ftgroup.com) Date: Mon Dec 29 05:36:44 2008 Subject: SCTP : problems in sending ASCONF chunks In-Reply-To: <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> References: <3418F3471F1CA4409901547349FFAE2E0910679F@ftrdmel2> <2C67145C-C26B-4666-B7A5-6EC1C4ABA1E5@lurchi.franken.de> Message-ID: <3418F3471F1CA4409901547349FFAE2E091067B8@ftrdmel2> Hello M.T?xen, No, only the PC is running under FreeBSD 7.0. T is running under Linux (kernel version is 2.6.21 and the distribution used is Fedora Core 7). SCTP is running on T thanks to the lksctp implementation, we loaded the sctp module on it and made the necessary configurations so that it is loaded at boot time. Also, I enable net.sctp.addip_enable=1 on T, just in case, I'm not exactly sure if it has an effect on my tests. Kind regards Aman Jassal -----Message d'origine----- De : Michael T?xen [mailto:Michael.Tuexen@lurchi.franken.de] Envoy? : lundi 29 d?cembre 2008 14:09 ? : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM, wrote: > Hi all, > > I have been working with SCTP and more specifically with the mobility > features of SCTP at my work. Basically, I have been trying to use SCTP > to perform handover tests between 2 separate Wifi networks. I use IPv6 > for all my tests. > > I have a local LAN (wired-network), on which I have 3 machines, one of > them is the machine I use to communicate with for the tests (I'll call > it T to make things simple), and the other two are used as Wifi Access > Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I > set up both Access Points to send Router Advertisement messages > periodically (minimum of 3 seconds, maximum of 4 seconds). That way I > can have automatic address reconfiguration when I connect to either of > the access points. > > The aim of my tests is to use a PC, connect to Wifi1 (for example), > launch an SCTP association with T (T sends data to my PC), and then > perform a handover on Wifi2. I do make address reconfiguration during > the handover process. The important point is that I work with only ONE > address on my network interface. Before I start my tests, I set the > following sysctl parameters : > > # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w > net.inet.sctp.mobility_fasthandoff=1 > # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump > messages in /var/log/messages) > > net.inet.sctp.auto_asconf is set to 1 by default. > > I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful > but I'm trying to be thorough. This is the script I use to perform > handover > : > > ifconfig rum0 inet6 delete ifconfig rum0 ssid target access point> route del -inet6 default rtsol > rum0 > > If I'm not mistaken, the PC should have sent an ASCONF chunk to > perform dynamic address reconfiguration. However what I observed is > that nothing happens. No ASCONF chunks are sent, and therefore, T > doesn't ever know that it should send data on the PC's newly acquired > address. > > I tried to investigate the problem myself, by adding some debug logs > in the sctp source code (to see which functions are called during the > handover process), and it seems as if the kernel doesn't ever add an > ASCONF chunk to send in its queue... But that's just my understanding > of the problem... > > I looked up in the CVS repository for answers, and to see the various > changes that were gradually brought on the code. There, I noticed that > on the revision dating 24th July 2007, changes were made for dynamic > address reconfiguration : "Change behaviour so that when the last > address is deleted (auto-asconf on a boudall endpoint) no action is > taken until an address is added ; at that time an ASCONF add+delete is > sent (if the asoc is still up)" > > In my humble opinion, this is exactly the case that corresponds to my > handover scenario. But I just haven't been able to successfully > perform it because I don't seem to send any ASCONF chunk. I'm > struggling to understand why I do not see any ASCONF chunk sent. > > If it can help, I'm also attaching links to the kind of debug logs I > got when performing a handover test. This is the kind of debug logs > that I got : > > http://www.divshare.com/download/6200509-560 > > This is another debug logfile, but with my own debug logs added in the > sctp source code : > > http://www.divshare.com/download/6200504-2e9 > > > Many thanks for your work, and I hope someone will be able to help and > shed some light on this problem :-) > > > Aman Jassal > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From nrml at att.net Mon Dec 29 06:18:37 2008 From: nrml at att.net (Gabe) Date: Mon Dec 29 06:18:43 2008 Subject: +ipsec_common_input: no key association found for SA Message-ID: <847488.86907.qm@web83814.mail.sp1.yahoo.com> > From: Bjoern A. Zeeb > To: Gabe > Cc: freebsd-net@freebsd.org > Sent: Monday, December 29, 2008 5:19:16 AM > Subject: Re: +ipsec_common_input: no key association found for SA > > On Mon, 29 Dec 2008, Bjoern A. Zeeb wrote: > > > On Mon, 29 Dec 2008, Gabe wrote: > > > >> Anyone know what causes this error message? > >> > >> +ipsec_common_input: no key association found for SA > >> 69.x.x.x[0]/04e317a1/50 > > > > from what I remember without looking, this means that you ahve an > > IPsec policy for src/dst but no SA matching this pair or rather no > > matching destination + protocol + security parameter index (see rfc2401). > > > > The easiest thing you can do is to check > > setkey -Da > > for this tripple the time the printf happens. > > > > The first thing in the printf is your destination IP (your local side), > > the next is the SPI in hex and last is the protocol (50 == ESP). With > > that you can see if what the peer sends you is what you negotiated/expected. > > > > Are you using static keying or an ike daemon like racoon? > > Do this happen for all packets or just randomly or exactly every n > > minutes/hours? > > > > If you find an exact match of the triplet in setkey -Da you may also > > want to check if there is another one and/or the state of the entry/entries > > (state=.. at the end of the fourth line). > > If it's not "mature" check the time ralted values to see if there is > > an expiry problem.. This is what setkey -Da returns: box# setkey -Da Invalid extension type Invalid extension type box# I only have one peer (site to site link) and this appears to happen sporadically with no particular pattern that I can figure out. I also tried rebuilding the ipsec-tools port as a just in case and that made no change. This is some more log info: Dec 29 05:50:37 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/03e4aece/50 Dec 29 05:50:39 box last message repeated 64 times Dec 29 05:51:33 box kernel: WARNING: pseudo-random number generator used for IPsec processing Dec 29 05:54:54 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/0cb33e2b/50 Dec 29 05:54:56 box last message repeated 8 times Dec 29 06:07:32 box kernel: ipsec_common_input: no key association found for SA 69.x.x.x[0]/0c4ccc0d/50 Dec 29 06:07:44 box last message repeated 241 times This st