Current problem reports assigned to freebsd-net@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/140142 net[ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140051 net[bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net[iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net[bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net[ipfilter] ipfilter ioctl SIOCDELST broken o kern/139559 net[tun] several tun(4) interfaces can be created with sa o kern/139387 net[ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net[patch] arp(8) add option to remove static entries lis o kern/139268 net[if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net[arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net[fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net[ip6] IPv6 blackhole / reject routes broken o kern/139117 net[lagg] + wlan boot timing (EBUSY) o kern/139113 net[arp] removing IP alias doesn't delete permanent arp e o kern/139058 net[ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net[libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net[dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net[panic] sbflush_internal: cc 0 || mb 0xff004127b00 o kern/138739 net[wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net[bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net[rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net[lo] FreeBSD does not assign linklocal address to loop o kern/138676 net[route] after buildworld not work local routes [regres f kern/138666 net[multicast] [panic] not working multicast through igmp o kern/138660 net[igb] igb driver troubles in 8.0-BETA4 o kern/138652 netTCP window scaling value calculated incorrectly? o kern/138620 net[lagg] [patch] lagg port bpf-writes blocked o kern/138427 net[wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net[gre] gre(4) interface does not come up after reboot o kern/138378 net[altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net[tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net[panic] kernel panic when udp benchmark test used as r o kern/138177 net[ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net[tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net[netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net[patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net[sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net[rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net[netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 netifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net[ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net[patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net[ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net[ral] FreeBSD doesn't support wireless interface from o kern/137317 net[tcp] logs full of syncache problems o kern/137292 net[ste] DFE-580TX not working properly o kern/137279 net[bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net[lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net[patch] ifconfig(8) print carp mac address o kern/136943 net[wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net[netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net[bge] bge will not resume properly after suspend o kern/136836 net[ath] atheros card stops functioning after about 12 ho o kern/136618 net[pf][stf] panic on cloning interface without unit numb o kern/136482 net[age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net[panic] spawning several dhclients in parallel panics o kern/136168 net[em] em driver initialization fails on Intel 5000PSL m o kern/135836 net[bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net[periodic] Warning message raised by rtfree function i o kern/135222 net[igb] low speed rou
How much similar interfaces
How much similar interfaces can I create? (i.e. tun0, tun1, tun2... tunN) -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), JID: cityc...@jabber.org OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: dummynet dropping too many packets
--- On Tue, 10/20/09, rihad wrote: > From: rihad > Subject: Re: dummynet dropping too many packets > To: freebsd-net@freebsd.org > Date: Tuesday, October 20, 2009, 11:41 AM > I'm so happy today: finally running a > "ifp->if_snd.ifq_drv_maxlen = 4096;" and HZ=4000 kernel > with 4100+ online users @500+ mbps, and, most importantly, > with absolutely 0 drops since boot time! ;-) Even if drops > do come in, I'll know where to look first. I'd like to > express my gratitude to Robert Watson for pointing out the > "ifnet transmit queue sizes" issue, to others who suggested > the problem might be in dummynet's burstiness, and yet to > others who tried hard to help with other suggestions. Thank > you, folks! Tomorrow I'm going to suggest to my boss to > donate some $$$ to the FreeBSD Foundation: > http://www.freebsdfoundation.org/donate/ Seems to me that spending money on a real packetshaper would be a better investment than donating to compromise on the free stuff (not that I'd want to discourage anyone from contributing to FreeBSD generally). Your problem is that at high traffic levels you need to reduce traffic flows, not just delay it as dummynet does. The entire point of traffic shaping is to smooth out your traffic flows; not to make it so choppy that you have packets sitting in a transmit queue for 1/2 millisecond in addition to the dummynet delays. While dummynet may not be dropping packets, you have packets being dropped in TCP stacks throughout your customer base, most likely. Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Sangoma drops FreeBSD support - is there a replacment?
I've got a couple of their A301 DS3 cards (one in production, one as backup on the shelf), and the one in production is working fine for now, but since Sangoma have dropped support for FreeBSD across the board, I'm looking for an alternative. Anyone know of a good DS3 replacement card that supports FreeBSD? Kurt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
"route get" returning error on classful networks
Gentlemen, While writing a script to do some route table maintenance on a firewall I stumbled on to something curious (all network numbers are examples): = $ route get 35.0.0.0 route: writing to routing socket: No such process $ route -n get 35.0.0.1 route to: 35.0.0.1 destination: default mask: default gateway: 10.10.0.1 interface: lagg0 flags: recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 = It seems "route get" returns an error when asked to look up the route to a network with the network .0 ip as the lookup key. This follows classful network boundaries, and is somewhat easier to demonstrate than to explain: = class A: $ route get 9.0.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 9.1.0.0 > /dev/null 2>&1 ; echo $? 0 class B: $ route get 130.0.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 130.1.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 130.1.1.0 > /dev/null 2>&1 ; echo $? 0 class C: $ route get 200.0.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 200.1.0.0 > /dev/null 2>&1 ; echo $? 1 $ route get 200.1.1.0 > /dev/null 2>&1 ; echo $? 1 $ route get 200.1.1.1 > /dev/null 2>&1 ; echo $? 0 = This happens on Freebsd 6-7-8 on all machines I have access to. The error message is confusing and suggests there is a problem writing to the routing table which is not what I am doing at all. Is this a bug, or can somebody offer an explanation for this ? Thank you! :) Thomas Rasmussen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140066: [bwi] install report for 8.0 RC 2 (multiple problems)
Old Synopsis: install report for 8.0 RC 2 New Synopsis: [bwi] install report for 8.0 RC 2 (multiple problems) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 3 02:10:29 UTC 2009 Responsible-Changed-Why: Reassigning this PR to -net because it contains information about a bwi problem. To submitter: handling this kind of PR is a bit problematic for us, since it lists several different problems. There really isn't one person/group who works on "overall usability issues". (I'll accept a criticism that there *should* be, but FreeBSD is a volunteer project, so all I can do is advocate for more people to work on such issues.) In the meantime you may be able to find help with certain problems in the FreeBSD Forums, or, if you are more traditional, the freebsd- questions@ mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=140066 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: dummynet dropping too many packets
Barney Cordoba wrote: Your problem is that at high traffic levels you need to reduce traffic flows, not just delay it as dummynet does. Dummynet does not "just adds delay". The entire point of traffic shaping is to smooth out your traffic flows; not to make it so choppy that you have packets sitting in a transmit queue for 1/2 millisecond in addition to the dummynet delays. While dummynet may not be dropping packets, you have packets being dropped in TCP stacks throughout your customer base, most likely. If you followed the thread, you known that rihad tried GRED. The problem was not due to exceeded bandwidth but in inadequate interface-level FIFO queue length. And no way to adjust it without a patch. This makes me think we should have general user interface for setting the queue length for any network interface just like Cisco 'hold-queue' command does. For now, only some drivers (e.g., em(4)) have such option. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ral driver
hi all is this resolved in current or head? http://lists.freebsd.org/pipermail/freebsd-bugs/2009-May/035231.html i have this ral card that drops off after about 15 min or so and have the same symptoms as described in that bug report.. thank you... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Marvell 88E8057
hi pyun... and all after a few hours i'm sorry to report that the card is visible but not usable (yet?!). here is what i have done so far: 1. got the files from http://svn.freebsd.org/viewvc/base/head/sys/dev/ 2. applied the patch that pyun provided. 3. replaced if_maddr_rlock(ifp) with IF_ADDR_UNLOCK(ifp) in if_msk.c - two instances. 4. replaced the files in /usr/src/sys/dev for mii and msk with he new ones on the freebsd 7.2 machine. 5. recompiled the kernel.. here is what i get: from dmesg at boot: mskc0: port 0xde00-0xdeff mem 0xfddfc000-0xfddf irq 18 at device 0.0 on pci2 mskc0: unknown device: id=0xba, rev=0x00 device_attach: mskc0 attach returned 6 cant find what 6 stands for but it's not good.. pciconf -lvvv: ms...@pci0:2:0:0:class=0x02 card=0x51131297 chip=0x438011ab rev=0x10 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' class = network subclass = ethernet if i put if_msk_load="YES" in loader.conf dmesg says: module_register: module msk/miibus already exists! Module msk/miibus failed to register: 17 module_register: module mskc/msk already exists! Module mskc/msk failed to register: 17 module_register: module pci/mskc already exists! Module pci/mskc failed to register: 17 ifconfig doesn't see it. sysinstall does not see it. now what?! thanks... Pyun YongHyeon wrote: On Sat, Oct 24, 2009 at 02:46:40PM -0700, Pyun YongHyeon wrote: On Fri, Oct 23, 2009 at 11:44:15PM -0400, kalin m wrote: hi all.. does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? according to the kernel list of drivers (7.2) marvell chips are driven by the msk driver. but it doesn't show up in pciconf, dmesg or sysinstall strangely enough 88E8057 is not in the list in man msk. although 88E8056 and 88E8058 are. is this just bad luck?! I think 88E8057(Yukon Ultra 2) is the latest chipset from Marvell and no one ever expressed his/her willingness to try experiment patch. I guess msk(4) in HEAD has all required features to support 88E8057. Would you try attached patch? The patch was generated against HEAD. If you have to use 7.2-RELEASE copy the following files from HEAD and apply attached patch. /usr/src/sys/dev/msk/if_msk.c /usr/src/sys/dev/msk/if_mskreg.h /usr/src/sys/dev/mii/miidevs /usr/src/sys/dev/mii/e1000phy.c /usr/src/sys/dev/mii/e1000phyreg.c ^^ It should be read e1000phyreg.h ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
dummynet dropping too many packets
>Seems to me that spending money on a real packetshaper would be a >better investment than donating to compromise on the free stuff (not >that I'd want to discourage anyone from contributing to FreeBSD >generally). >Your problem is that at high traffic levels you need to reduce traffic >flows, not just delay it as dummynet does. The entire point of traffic >shaping is to smooth out your traffic flows; not to make it so choppy >that you have packets sitting in a transmit queue for 1/2 millisecond >in addition to the dummynet delays. While dummynet may not be dropping >packets, you have packets being dropped in TCP stacks throughout your >customer base, most likely. >Barney Packetshaper? It can't work over 300M/s. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
