VPLS implementation
Are there any plans or ongoing work to implement VPLS in the network stack? http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service //JO ___ 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: strange resolver behavour
Hi,
> On Mon, 11 Oct 2010 13:31:04 +0700
> Eugene Grosbein said:
egrosbein> FreeBSD 8.1-STABLE:
egrosbein> # host koin-nkz.com.
egrosbein> koin-nkz.com has address 62.231.164.101
egrosbein> Host koin-nkz.com not found: 3(NXDOMAIN)
egrosbein> This domain does not have MX records but NXDOMAIN seems to wrong
return
egrosbein> code to me. Think about MTA that does look-up for MX first,
egrosbein> obtains NXDOMAIN and rejects mail.
egrosbein> tcpdump shows that after MX look-up failure resolver adds my local
egrosbein> domain suffix from /etc/resolv.conf's "search" clause and
egrosbein> goes to my local DNS server looking for MX record for
egrosbein> 'koin-nkz.com.my.ru.' that does not exists. Hence, NXDOMAIN.
egrosbein> Is it a bug in our resolver?
I think no, host(1) links ISC's resolver, and it doesn't use libc's
resolver. I suspect there is some problem in host(1) or ISC's
resolver.
egrosbein> I've tested 6.4-STABLE and 7.3-STABLE, same effect.
egrosbein> I've also tested 4.11-STABLE and it works correctly - no wrong
egrosbein> suffix addition, no NXDOMAIN.
4.X's host(1) is from BIND8, but it comes from BIND9 on 5.X and later.
I confirmed it on my 4.11 box with our in-tree host(1). However,
host(1) from ports has same behavior with 8.1. It is bind9-9.3.6.1.1.
% uname -r
4.11-RELEASE-p25
% /usr/bin/host koin-nkz.com.
koin-nkz.com has address 62.231.164.101
% /usr/local/bin/host koin-nkz.com.
koin-nkz.com has address 62.231.164.101
Host koin-nkz.com not found: 3(NXDOMAIN)
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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"
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/150920 net[ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net[igb] igb0: Watchdog timeout -- resetting o kern/150257 net[msk] watchdog timeout o kern/150251 net[patch] [ixgbe] Late cable insertion broken o kern/150249 net[ixgbe] Media type detection broken o kern/150247 net[patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 netppp(8) does not reassign static IP after kill -KILL co o kern/150148 net[ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net[wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net[wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net[ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net[bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net[rum] device not sending proper beacon frames in ap mo o kern/149609 net[panic] reboot after adding second default route o kern/149539 net[ath] atheros ar9287 is not supported by ath_hal o kern/149516 net[ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net[realtek/atheros]: None of my network card working o kern/149307 net[ath] Doesn't work Atheros 9285 o kern/149306 net[alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net[inet] [patch] in_pcbbind: redundant test o kern/149086 net[multicast] Generic multicast join failure in 8.1 o kern/148862 net[panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net[ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net[ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net[ath] wireless networking stops functioning o kern/147985 net[alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net[ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net[wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net[ip6] setfb not work with ipv6 o kern/146845 net[libc] close(2) returns error 54 (connection reset by o kern/146792 net[flowtable] flowcleaner 100% cpu's core load o kern/146759 net[cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net[pf] [panic] PF or dumynet kernel panic o kern/146534 net[icmp6] wrong source address in echo reply o kern/146517 net[ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net[mwl] Additional virtual access points don't work on m o kern/146426 net[mwl] 802.11n rates not possible on mwl o kern/146425 net[mwl] mwl dropping all packets during and after high u f kern/146394 net[vlan] IP source address for outgoing connections o bin/146377 net[ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net[vlan] wrong destination MAC address o kern/146165 net[wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net[ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net[panic] mpd + CoA = kernel panic o bin/145934 net[patch] add count option to netstat(1) o kern/145826 net[ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net[panic] panic: soabort: so_count o kern/145777 net[wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net[lagg] Stops working lagg between two servers. o amd64/145654 netamd64-curent memory leak in kernel o kern/144987 net[wpi] [panic] injecting packets with wlaninject using o kern/144882 netMacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net[if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net[rc.d] async dhclient breaks stuff for too many people o kern/144642 net[rum] [panic] Enabling rum interface causes panic o kern/144616 net[nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net[carp] CARP preemption mode traffic partially goes to f kern/144315 net[ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net[ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net[wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net[ath] [patch] [request] allow Atheros watchdog timeout o kern/143846
Strange behavior of packet scheduling in ipfw3
Hello! The system is: FreeBSD mysystem 8.0-STABLE-201005 FreeBSD 8.0-STABLE-201005 #0: Wed Jul 28 12:04:29 MSD 2010 r...@mysystem:/usr/src/sys/amd64/compile/MYKERNEL amd64 There is firewall "ipfw3" from Luigi Rizzo with packet scheduling. There is part of firewall config (tariff with 1Mbit/s speed, for example), below (the rules for another speeds are the same): $IPFW pipe 11 config bw 1040Kbit/s mask dst-ip 0x $IPFW pipe 12 config bw 1040Kbit/s mask src-ip 0x pipe 11 $IPFW sched 11 config type QFQ mask dst-ip 0xff00 $IPFW queue 111 config sched 11 weight 10 $IPFW queue 112 config sched 11 weight 8 $IPFW queue 113 config sched 11 weight 4 $IPFW queue 114 config sched 11 weight 1 $IPFW add queue 111 ip from any to table\(10\) via igb0 out proto udp src-port 5060 $IPFW add queue 112 ip from any to table\(10\) via igb0 out proto tcp src-port 80,443,8080 $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto icmp $IPFW add queue 114 ip from any to table\(10\) via igb0 out $IPFW add queue 111 ip from any to table\(10\) via igb2 out proto udp src-port 5060 $IPFW add queue 112 ip from any to table\(10\) via igb2 out proto tcp src-port 80,443,8080 $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto icmp $IPFW add queue 114 ip from any to table\(10\) via igb2 out pipe 12 $IPFW sched 12 config type QFQ mask src-ip 0xff00 $IPFW queue 121 config sched 12 weight 10 $IPFW queue 122 config sched 12 weight 8 $IPFW queue 123 config sched 12 weight 4 $IPFW queue 124 config sched 12 weight 1 $IPFW add queue 1210 ip from table\(11\) to any via igb1 out proto udp dst-port 5060 $IPFW add queue 122 ip from table\(11\) to any via igb1 out proto tcp dst-port 80,443,8080 $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto icmp $IPFW add queue 124 ip from table\(11\) to any via igb1 out $IPFW add queue 121 ip from table\(11\) to any via igb3 out proto udp dst-port 5060 $IPFW add queue 122 ip from table\(11\) to any via igb3 out proto tcp dst-port 80,443,8080 $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto icmp $IPFW add queue 124 ip from table\(11\) to any via igb3 out Firstly, we have been tested firewall by ourself. And we had no any bad results or any problems or maybe we have not seen them in our synthetic tests. After that we have started this firewall in production. A few months later we received a message from our subscriber with speed 1Mbit/s. He had a problems with online game (big answer delay from the server). We spent a lot of time to solve this problem. Finaly we solved it. The reason was in packet scheduling: 1. we`ve tried to give to subscriber another channel (4Mbit/s) with packet scheduling - there are no such problems; 2. we`ve tried to "turn off" the packet scheduling on 1Mbit channel - there are no such problems. The utilization of subscibers channel was always 0.4Mbit/s. But the traffic from this subscriber was go on under the packet scheduling rules. That`s very strange because of: 1. net.inet.ip.dummynet.io_fast=1; 2. subscribers channel utilization 0.4Mbit/s. As I know with this option, with this firewall config and with this channel utilization (0.4Mbit/s) traffic should bypass the pipe without packet scheduling. Why subscribers traffic with all these conditions doesn`t bypass through pipe without any delays? Why his traffic was on packet scheduling rules? Thanks. ___ 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: Strange behavior of packet scheduling in ipfw3
[top post as i am in a rush] first, there is (fixed in HEAD, but not yet in -stable) an issue with io_fast=1 so try to set it to 0. Secondly, because of the way scheduling works, you can't expect packets to bypass the pipe, even if the individual flow is below its share. Even the best scheduling algorithm has a worst case delay which is at least 1 max-sized packet (the constant is actually 3..6 times for QFQ). cheers luigi On Mon, Oct 11, 2010 at 06:40:43PM +0400, Dmukha Nikolay wrote: > Hello! > > The system is: > FreeBSD mysystem 8.0-STABLE-201005 FreeBSD 8.0-STABLE-201005 #0: Wed Jul 28 > 12:04:29 MSD 2010 r...@mysystem:/usr/src/sys/amd64/compile/MYKERNEL amd64 > > There is firewall "ipfw3" from Luigi Rizzo with packet scheduling. > There is part of firewall config (tariff with 1Mbit/s speed, for example), > below (the rules for another speeds are the same): > $IPFW pipe 11 config bw 1040Kbit/s mask dst-ip 0x > $IPFW pipe 12 config bw 1040Kbit/s mask src-ip 0x > pipe 11 > $IPFW sched 11 config type QFQ mask dst-ip 0xff00 > $IPFW queue 111 config sched 11 weight 10 > $IPFW queue 112 config sched 11 weight 8 > $IPFW queue 113 config sched 11 weight 4 > $IPFW queue 114 config sched 11 weight 1 > $IPFW add queue 111 ip from any to table\(10\) via igb0 out proto udp > src-port 5060 > $IPFW add queue 112 ip from any to table\(10\) via igb0 out proto tcp > src-port 80,443,8080 > $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto tcp > src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 > $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto icmp > $IPFW add queue 114 ip from any to table\(10\) via igb0 out > $IPFW add queue 111 ip from any to table\(10\) via igb2 out proto udp > src-port 5060 > $IPFW add queue 112 ip from any to table\(10\) via igb2 out proto tcp > src-port 80,443,8080 > $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto tcp > src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 > $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto icmp > $IPFW add queue 114 ip from any to table\(10\) via igb2 out > pipe 12 > $IPFW sched 12 config type QFQ mask src-ip 0xff00 > $IPFW queue 121 config sched 12 weight 10 > $IPFW queue 122 config sched 12 weight 8 > $IPFW queue 123 config sched 12 weight 4 > $IPFW queue 124 config sched 12 weight 1 > $IPFW add queue 1210 ip from table\(11\) to any via igb1 out proto udp > dst-port 5060 > $IPFW add queue 122 ip from table\(11\) to any via igb1 out proto tcp > dst-port 80,443,8080 > $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto tcp > dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 > $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto icmp > $IPFW add queue 124 ip from table\(11\) to any via igb1 out > $IPFW add queue 121 ip from table\(11\) to any via igb3 out proto udp > dst-port 5060 > $IPFW add queue 122 ip from table\(11\) to any via igb3 out proto tcp > dst-port 80,443,8080 > $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto tcp > dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, , 27000-27050, 42292 > $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto icmp > $IPFW add queue 124 ip from table\(11\) to any via igb3 out > > Firstly, we have been tested firewall by ourself. And we had no any bad > results or any problems or maybe we have not seen them in our synthetic > tests. After that we have started this firewall in production. A few months > later we received a message from our subscriber with speed 1Mbit/s. He had a > problems with online game (big answer delay from the server). We spent a lot > of time to solve this problem. Finaly we solved it. The reason was in packet > scheduling: > 1. we`ve tried to give to subscriber another channel (4Mbit/s) with packet > scheduling - there are no such problems; > 2. we`ve tried to "turn off" the packet scheduling on 1Mbit channel - there > are no such problems. > > The utilization of subscibers channel was always 0.4Mbit/s. But the traffic > from this subscriber was go on under the packet scheduling rules. That`s very > strange because of: > 1. net.inet.ip.dummynet.io_fast=1; > 2. subscribers channel utilization 0.4Mbit/s. > > As I know with this option, with this firewall config and with this channel > utilization (0.4Mbit/s) traffic should bypass the pipe without packet > scheduling. > > Why subscribers traffic with all these conditions doesn`t bypass through pipe > without any delays? Why his traffic was on packet scheduling rules? > Thanks. > ___ > 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" ___ freebsd-net@freebsd.org mailing list
Re: [cxgb] Chelsio T304 quad gig pcie adapter TSO disabled
On Mon, Oct 11, 2010 at 12:56:55AM -0400, Bill Desjardins wrote: > Hi All, > > I have a couple Chelsio T304 quad gigabit nics that are going into > iscsi servers. I got these for the TOE capabilities, but I found in > the cxgb driver code that it is explicitly disabled for > 2 port nics > (line 1036 : /usr/src/sys/dev/cxgb/cxgb_main.c) . The current cxgb > driver is based on the chelsio 7.8.0 firmware (11/25/09), but chelsio > is up to 7.11.0 (07/20/10). I had updated the firmware using cxgbtool > to 7.11, but received complaints from the driver to 'upgrade' to > 7.8.0, which I did. > > my question is, is if the cxgb driver is being worked on to update to > latest chelsio firmware and/or fix TSO for the quad port cards? I > don't have the programming skill's to assist with that side of things, > but I can easily provide a remote spare machine with a serial console > for development and testing if its helpful. Hello Bill, TSO is not supported on the T304 (not even with the 7.11.0 firmware). This is a 4 x gigabit card and you'll be able to max it out in either direction without TSO. > cxgbc0: Insufficient clusters and/or jumbo buffers. > ^^ ^^ this indicates you need to bump up the number of clusters and jumbos. Do so in /boot/loader.conf if you load if_cxgb early, or in /etc/sysctl.conf if you load it after the system has booted up: /boot/loader.conf: kern.ipc.nmbclusters=262144 /etc/sysctl.conf: kern.ipc.nmbclusters=262144 kern.ipc.nmbjumbo9=262144 kern.ipc.nmbjumbo16=262144 Regards, Navdeep ___ 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"
if_ndis: fix for panic with VIMAGE
Hi, There is no single valid reason to call rt_ifmsg() in ndis_linksts_done() Patch attached. diff --git a/sys/dev/if_ndis/if_ndis.c b/sys/dev/if_ndis/if_ndis.c index 2ec9d0e..a4672e0 100644 --- a/sys/dev/if_ndis/if_ndis.c +++ b/sys/dev/if_ndis/if_ndis.c @@ -1644,10 +1644,6 @@ ndis_linksts_done(adapter) default: break; } - - /* Notify possible listners of interface change. */ - - rt_ifmsg(ifp); } static void ___ 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/123961: [vr] [patch] Allow vr interface to handle vlans
Synopsis: [vr] [patch] Allow vr interface to handle vlans State-Changed-From-To: patched->closed State-Changed-By: yongari State-Changed-When: Mon Oct 11 20:15:37 UTC 2010 State-Changed-Why: Close, vr(4) should support VLAN oversized frame. If you happen to encounter the issue again please open a new PR. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Oct 11 20:15:37 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=123961 ___ 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"
10GE adapters
Howdy - I remember seeing posts from Broadcom about the Net Extreme II 57711 (bxe) some time back - they had beta available a year or so ago but nothing since. Also, anyone know if the Qlogic QLE8152 (CNA) is on the radar? Thanks, Frank \\ Frank Terhaar-Yonkers W4FTY TRA 8325/L3 Cisco Systems, Inc. 7025 Kit Creek Road PO Box 14987 Research Triangle Park, North Carolina 27709 f...@cisco.com voice(919)392-2101 ___ 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: strange resolver behavour
On 11.10.2010 18:05, Hajimu UMEMOTO wrote: > egrosbein> Is it a bug in our resolver? > > I think no, host(1) links ISC's resolver, and it doesn't use libc's > resolver. I suspect there is some problem in host(1) or ISC's > resolver. Is there a command capable of looking up MX records and linked with libc resolver in base system? It's a pity if we have no diagnostic utility that behaves just like ordinary applications like MTA dealing with DNS... How am I supposed to debug suspected MTA behavior without such utility? Eugene Grosbein ___ 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"
