Re: CARP over LAGG
Hello, This should be possible. I do have 7.2 systems which have lagg0 on em0/em1 VLANs over lagg0 and carp over those VLANs. So I guess carp over lagg0 should no be a problem. lagg0: flags=8943 metric 0 mtu 1500 options=19b ether 00:30:48:c8:2f:50 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c vlan4: flags=8943 metric 0 mtu 1500 options=3 ether 00:30:48:c8:2f:50 inet 10.62.4.253 netmask 0xff00 broadcast 10.62.4.255 media: Ethernet autoselect status: active vlan: 4 parent interface: lagg0 carp4: flags=49 metric 0 mtu 1500 inet 10.62.4.1 netmask 0xff00 carp: MASTER vhid 4 advbase 1 advskew 0 On Aug 3, 2010, at 5:55 PM, Andrea Venturoli wrote: > Hello. > > On a couple of 7.2 systems, I've got some carp interfaces build upon a > physical interface (em0 or igb0) and everything works fine. > > On both box I've tried aggregating two interfaces (resp. em0+em1 and > igb0+igb1) into a lagg0 interface, using LACP. > However, in this case CARP will stop working as all carp devices which work > over lagg0 will stay in INIT state. > > Is this a bug? > Is "carp over lagg" possible at all? > > bye & Thanks > av. > ___ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ 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: When configuring 2 VLANs to be on the same subnet, only one works.
Greetings, For me your configuration looks invalid. Try with netmask 255.255.0.0 The question here is why freebsd allow this. On Jan 13, 2009, at 3:09 PM, Eitan Shefi wrote: I'm testing a NIC driver. I use 2 directly connected FreeBSD-7.0 hosts. When I create 2 VLANs for the same interface (mtnic0), on each host, and configure the VLANs on each host to be on the same subnet: ping works only to one of the VLANs. I run: On sw259: /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 /sbin/ifconfig vlan1 91.154.12.5 netmask 255.0.0.0 /sbin/ifconfig vlan2 91.155.12.5 netmask 255.0.0.0 On sw260: /sbin/ifconfig vlan1 create vlan 1 vlandev mtnic0 /sbin/ifconfig vlan2 create vlan 2 vlandev mtnic0 /sbin/ifconfig vlan1 91.154.12.6 netmask 255.0.0.0 /sbin/ifconfig vlan2 91.155.12.6 netmask 255.0.0.0 Now on sw259 run: ping 91.154.12.6 - works. ping 91.155.12.6 - does not work. I saw the same behavior also when running via a different NIC. Is this expected ? Thanks, Eitan. ___ 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ 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: MAC locking and filtering in FreeBSD
Hi, apr -S (or -s) is not helping? Have in mind that this is not a real security as it's very easy to change your MAC. On May 13, 2009, at 7:48 PM, Brett Glass wrote: I need to find a way to do "MAC address locking" in FreeBSD -- that is, to ensure that only a machine with a particular MAC address can use a particular IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 information in a packet can't look at Layer 3, and vice versa. Is there a way to work around this to do MAC address locking and/or other functions that involve looking at Layer 2 and Layer 3 simultaneously? --Brett Glass ___ 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ 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: MAC locking and filtering in FreeBSD
Hi, On May 13, 2009, at 10:03 PM, Brett Glass wrote: Stefan: You are correct: This is not real security. In fact, I would argue that it's not security at all. But many businesses that have to maintain hotspots -- especially some hotel chains -- are "allergic" to any sort of serious security. This is because a small but vocal subset of their customers just want to get on the Net and complain about any sort of security. Even having to enter a password or a WEP key irks them. (I personally think that these people are ignorant fools and are setting themselves up for identity theft and worse, but that's just me. And the businesses seem more willing to allow piracy of their Wi-Fi than to irritate these boneheads.) Also, these systems have to be usable by some fairly lame devices -- e.g. an XBox -- that aren't really computers and don't have the capability to run secure protocols or even a particularly good Web browser built in. So, painful as it is, I have to help these guys implement systems which "bless" MAC addresses. The "arp -s" command can sort of lock an IP to a MAC address, but awkwardly and only for outbound packets. What I'd like is to get this into the firewall, so I can not only block spoofing but trigger a log entry when it happens. I think /usr/ports/net-mgmt/arpwatch will be helpful then, though I never used in on wireless. Not that I understand how "knowing" mac address is easier for customers then wpa2 password ;) --Brett At 12:46 PM 5/13/2009, Stefan Lambrev wrote: Hi, apr -S (or -s) is not helping? Have in mind that this is not a real security as it's very easy to change your MAC. On May 13, 2009, at 7:48 PM, Brett Glass wrote: I need to find a way to do "MAC address locking" in FreeBSD -- that is, to ensure that only a machine with a particular MAC address can use a particular IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 information in a packet can't look at Layer 3, and vice versa. Is there a way to work around this to do MAC address locking and/or other functions that involve looking at Layer 2 and Layer 3 simultaneously? --Brett Glass ___ 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 " -- Best Wishes, Stefan Lambrev ICQ# 24134177 -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ 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: MAC locking and filtering in FreeBSD
Hi Brett, I think what you are looking for is called captive portal. You can look at pfsense - http://doc.pfsense.org/index.php/Category:Captive_Portal which comes with such solution into it. On May 14, 2009, at 1:29 AM, Brett Glass wrote: At 03:38 PM 5/13/2009, Christian Brueffer wrote: Sounds like wlan_acl(4) may be of interest to you. Unfortunately, wlan_acl(4) is only useful if one wants to ban users from the network, which these venues will rarely want to do except to block an abuser. Rather, they'll want the equipment to recognize MAC addresses and grant different degrees of access to them. For example, a user might be trapped in a "walled garden" until agreeing to an acceptable use policy, and then redirected -- but only once -- to a specific Web page, such as the hotel chain's reservation page. --Brett Glass -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ 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"
FIN_WAIT_2 on FreeBSD 6.2-STABLE
Hi, I'm seeing strange problem with sockets in state FIN_WAIT_2. netstat -n |grep FIN_WAIT_2|wc -l shows 12234 lines, Those sockets never die and just grow more and more, when finally today I saw this in logs: postfix/smtp[6968]: connect to gmail-smtp-in.l.google.com[66.249.91.27]: Can't assign requested address (port 25) and this happens not only to postfix, but all clients & servers on this host. Even things that use only local connections throw out: connect: Can't assign requested address Shorty after I moved away almost everything from this server, there was a spontaneous reboot. I know what apache and some buggy clients can cause sockets to stay in state FIN_WAIT_2, but they should disappear after some timeout. Is there a point to go for 6.3-prerelease, or nothing like this was reported, respectively fixed between may 2007 and today? Migration to RELENG_7 is not option for me at this point as this host serves something like 6mbps of http traffic, and there is a report that sometimes hosts running releng_7 can't be reached .. 6.2-STABLE from May 9 - amd64 Thanks in advance. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Test changes to em
Jack Vogel wrote: Although I see it at least one person claims the message came thru with only the header file, so I am going to send if_em.c thru again. Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" In this mail if_em.c is not here for me, as in the previous. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rtfree: 0xc741ee88 has 1 refs
Hi, I see rtfree: 0xc741ee88 has 1 refs with freebsd releng_7 (i386) from today. I think it's easy reproducible. What I have is: releng_7 (10.1.1.2) -> default GW (10.1.1.1) on default GW I have route to 10.10.1.1/24 -> 10.1.1.3 so everytime when 10.1.1.2 try to contact someone from 10.10.1.1/24 I see: rtfree: 0xc741ee88 has 1 refs if I add direct route on 10.1.1.2 to 10.10.1.1/24 through 10.1.1.3 the message will go away. Should I ignore this msg for now, or should I expect kernel panic soon? :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rtfree: 0xc741ee88 has 1 refs
Hi, Sorry to reply to myself, but I found that the problem exist only if the GW is carp interface, e.g. 10.1.1.1 sits on carp0 on default GW. I'm still testing how to reproduce this in my test lab and will fill a PR. Stefan Lambrev wrote: Hi, I see rtfree: 0xc741ee88 has 1 refs with freebsd releng_7 (i386) from today. I think it's easy reproducible. What I have is: releng_7 (10.1.1.2) -> default GW (10.1.1.1) on default GW I have route to 10.10.1.1/24 -> 10.1.1.3 so everytime when 10.1.1.2 try to contact someone from 10.10.1.1/24 I see: rtfree: 0xc741ee88 has 1 refs if I add direct route on 10.1.1.2 to 10.10.1.1/24 through 10.1.1.3 the message will go away. Should I ignore this msg for now, or should I expect kernel panic soon? :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
icmp type 5 redirect
Hi, When FreeBSD 6 act as a gatewa,y by default sends icmp type 5 redirect when needed, but releng_7 does not. Any ideas how to enable this on RELENG_7? net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: icmp type 5 redirect
Hi, Yuri Pankov wrote: On Tue, 2007-11-06 at 14:04 +0200, Stefan Lambrev wrote: Hi, When FreeBSD 6 act as a gatewa,y by default sends icmp type 5 redirect when needed, but releng_7 does not. Any ideas how to enable this on RELENG_7? net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 It's "net.inet.ip.redirect", if I'm not mistaken. from /sys/netinet/ip_input.c: SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, &ipsendredirects, 0, "Enable sending IP redirects"); The sysctl is ok. and the redirect work ok, I found where the problem is. seems that my problems are carp related :) but I'll share my findings on the "rtfree: 0xc741ee88 has 1 refs" thread and fill PRs where needed. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SYN Flood protection
Hi list, On bridge firewall with PF can I do anything more then using (source-track rule, max-src-conn-rate SS/ss, max-src-states X) to protect servers&services behind it from SYN flood? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux SMP network performance measurements
Greetings, Thierry Herbelot wrote: Hello, a recent article (http://www.ibm.com/developerworks/linux/library/l-scalability/?ca=dgr-lnxw02FasterLinuxNet) gives some measurements on various tweakings of an SMP machine with 4 Xeon processors (it *shows* a nice improvement when using more CPUs and more bonded Ethernet interfaces). Has some the machine (and the time, obviously) to make some of the same measurements with the latest FreeBSD versions ? I'm planning to test network performance on FreeBSD + bridged interfaces, very soon, but my test servers are not so powerful as the server from this page :) Best that I'll have is 1x quad core processor, 4 port gigabit intel network card and 2GB RAM. But I think this should be enough for tests. When I have some results/question I'll post to -performance :) TfH ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMPable version of EM driver
Hi Vladimir, Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz work out of the box on FreeBSD 7, or it's just for 6.X? Vladimir Ivanov wrote: Privet, Alexandr Alexandr Kovalenko wrote: Hello, Vladimir Ivanov! [skip] Which of newest versions should I use in RELENG_6_X now? Let you try http://people.yandex-team.ru/wawa/em-6.7.3-yandex-1.28.tar.gz. We keep code synced with latest RELENG_6. Latest feature: I have start to move m_freem/m_get away from em_start and em_rxeof. They lock. Truly, -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMPable version of EM driver
Hi Vladimir, Vladimir Ivanov wrote: Hi, Stefan Stefan Lambrev wrote: Hi Vladimir, Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz work out of the box on FreeBSD 7, or it's just for 6.X? We use (and debug) it w/RELENG_6. I seem it can be used w/CURRENT but I didn't test it yet. Also, pls use 1.30 revision instead (I've fixed rare stuck condition in txirq-less code). Thanks for your reply. I'll give a try of your latest driver and will let you know if it works with 7_0. Do you have some stats that compare pps throughput with both drivers? WBR, Vladimir ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMPable version of EM driver
Hi Vladimir, Vladimir Ivanov wrote: Hi, Stefan Stefan Lambrev wrote: Hi Vladimir, Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz work out of the box on FreeBSD 7, or it's just for 6.X? We use (and debug) it w/RELENG_6. I seem it can be used w/CURRENT but I didn't test it yet. Also, pls use 1.30 revision instead (I've fixed rare stuck condition in txirq-less code). I'm unable to get this driver working under releng_7_0. It builds without problems but panic my machine when I load it. May be I'll wait until you have "official" version for FreeBSD 7.0 or changes get merged into Intel's driver :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RESOLVED] Re: Strange resolver behavior
Greetings, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JINMEI Tatuya / 神明達哉 wrote: [snip] At the beginning I was confused with host(1) and resolver library, they are different problems, sorry for the confusion. I think Hajimu-san's analysis was correct that it was caused by the check in resolver, here is a ktrace output from a system without patched libc: http://www.delphij.net/kdump.txt Note that, with a patched (with ume@'s patch) resolver, the program *does* worked as expected, also this will make firefox to be able to resolve the domain name. Test program can be downloaded from http://www.delphij.net/test.c . With patched libc you will get no output (expected), and with unpatched libc you will get "Unknown server error" and will be unable to get the A RR. It turns out that the baidu.com DNS administrator might be unaware of the potential violation of RFC 952 "ASSUMPTIONS" and RFC 1034 Section 3.5. However, I am afraid that there are some DNS server implementations that does allow '_'s in domain names, so if there is no potential risks allowing it from the resolver side I think it might be a good idea to be more permissive for this case, because there are real uses of it, and other operating systems does allow it at the client side. Did you check http://tools.ietf.org/html/rfc2782 ? It is "PROPOSED STANDARD" and MS DNS in Win2003 already uses it (if you have domain controller for example). -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: route-to not working
Greetings,
Wesley wrote:
Dear people,
I have 2 links on a box, and I don't want to load balance it but, only to
reply requests in the same interface that it comes.
I tried to use the route-to, but it not seems to work.
Could you please, give-me a help?
I do not see where you use "reply-to" in you configuration
But here is working example which you can improve off course.
#dual home
pass in on $ext_if1 reply-to ($ext_if1 $gw1) from any to $external_addr1
keep state
pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any
pass in on $ext_if2 reply-to ($ext_if2 $gw2) from any to $external_addr2
keep state
pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any
#dual home ssh only
pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any
pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any
pass in on $ext_if1 reply-to ($ext_if1 $gw1) proto tcp from any to
$external_addr1 port 22 keep state
pass in on $ext_if2 reply-to ($ext_if2 $gw2) proto tcp from any to
$external_addr2 port 22 keep state
It's my configuration:
set skip on lo0
scrub on xl0 reassemble tcp no-df random-id
scrub on xl1 reassemble tcp no-df random-id
scrub on dc0 reassemble tcp no-df random-id
nat on xl0 from 172.16.0.0/24 to any -> (xl0) static-port
rdr on dc0 inet proto tcp to port 80 -> 127.0.0.1 port 3128 round-robin
sticky-address
antispoof quick for {xl0,dc0,xl1}
block proto tcp from 172.16.0.0/24 to any port 3128
# Internal Traffic
pass in quick on dc0 from any to any
pass out quick on dc0 from any to any
# Outgoing
pass out on xl0 proto tcp all flags S/SA modulate state
pass out on xl0 proto { udp, icmp } all keep state
pass out on xl1 proto tcp all flags S/SA modulate state
pass out on xl1 proto { udp, icmp } all keep state
# Pass basic services
pass in quick on xl1 proto tcp from any to any port { 22, 21, 1194 } keep
state
pass in quick on xl0 proto tcp from any to any port { 22, 21, 1194 } keep
state
pass in on xl0 proto udp from any to any port 53
pass in on xl1 proto udp from any to any port 53
# Pass VPN
pass in quick on xl1 proto udp from any to port 1194 keep state
pass quick on tun0
# Source nat route
pass out log on xl0 route-to ( xl1 200.232.164.1 ) from xl1 to any
pass out on xl1 route-to ( xl0 201.83.16.1 ) from xl0 to any
# Close
block return-rst in log quick on xl0 inet proto tcp from any to any
block return-rst in log quick on xl1 inet proto tcp from any to any
block return-icmp in log quick on xl0 proto udp from any to any
block return-icmp in log quick on xl1 proto udp from any to any
block in quick on xl0 all
block in quick on xl1 all
Best Regards,
Wesley Gentine
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: route-to not working
Vlad GALU wrote:
On 3/20/08, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
Greetings,
Wesley wrote:
> Dear people,
>
> I have 2 links on a box, and I don't want to load balance it but, only to
> reply requests in the same interface that it comes.
>
> I tried to use the route-to, but it not seems to work.
>
> Could you please, give-me a help?
>
I do not see where you use "reply-to" in you configuration
But here is working example which you can improve off course.
#dual home
pass in on $ext_if1 reply-to ($ext_if1 $gw1) from any to $external_addr1
keep state
pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any
pass in on $ext_if2 reply-to ($ext_if2 $gw2) from any to $external_addr2
keep state
pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any
#dual home ssh only
pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any
pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any
pass in on $ext_if1 reply-to ($ext_if1 $gw1) proto tcp from any to
$external_addr1 port 22 keep state
pass in on $ext_if2 reply-to ($ext_if2 $gw2) proto tcp from any to
$external_addr2 port 22 keep state
Don't mind me asking, but isn't your example working due to your
route-to rules? I, as well as Wesley, assumed that reply-to should've
been enough to reach the goal.
It's working because of reply-to rules - incoming packets does not match
"pass out route-to" rules.
The "pass out" rules are needed if the packet(s) is generated locally
and does not match the "pass in" rules.
You forget that the first rule to match wins and keep state (which is on
by default in 7.0)
will make replies to match the state not the pass out rules.
It's my configuration:
>
> set skip on lo0
> scrub on xl0 reassemble tcp no-df random-id
> scrub on xl1 reassemble tcp no-df random-id
> scrub on dc0 reassemble tcp no-df random-id
> nat on xl0 from 172.16.0.0/24 to any -> (xl0) static-port
> rdr on dc0 inet proto tcp to port 80 -> 127.0.0.1 port 3128 round-robin
> sticky-address
> antispoof quick for {xl0,dc0,xl1}
> block proto tcp from 172.16.0.0/24 to any port 3128
> # Internal Traffic
> pass in quick on dc0 from any to any
> pass out quick on dc0 from any to any
> # Outgoing
> pass out on xl0 proto tcp all flags S/SA modulate state
> pass out on xl0 proto { udp, icmp } all keep state
> pass out on xl1 proto tcp all flags S/SA modulate state
> pass out on xl1 proto { udp, icmp } all keep state
> # Pass basic services
> pass in quick on xl1 proto tcp from any to any port { 22, 21, 1194 } keep
> state
> pass in quick on xl0 proto tcp from any to any port { 22, 21, 1194 } keep
> state
> pass in on xl0 proto udp from any to any port 53
> pass in on xl1 proto udp from any to any port 53
> # Pass VPN
> pass in quick on xl1 proto udp from any to port 1194 keep state
> pass quick on tun0
> # Source nat route
> pass out log on xl0 route-to ( xl1 200.232.164.1 ) from xl1 to any
> pass out on xl1 route-to ( xl0 201.83.16.1 ) from xl0 to any
> # Close
> block return-rst in log quick on xl0 inet proto tcp from any to any
> block return-rst in log quick on xl1 inet proto tcp from any to any
> block return-icmp in log quick on xl0 proto udp from any to any
> block return-icmp in log quick on xl1 proto udp from any to any
> block in quick on xl0 all
> block in quick on xl1 all
>
> Best Regards,
>
> Wesley Gentine
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: route-to not working
Greetings, Eygene Ryabinkin wrote: Stefan, good day. Thu, Mar 20, 2008 at 03:43:44PM +0200, Stefan Lambrev wrote: But here is working example which you can improve off course. #dual home pass in on $ext_if1 reply-to ($ext_if1 $gw1) from any to $external_addr1 keep state pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any pass in on $ext_if2 reply-to ($ext_if2 $gw2) from any to $external_addr2 keep state pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any #dual home ssh only pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any pass in on $ext_if1 reply-to ($ext_if1 $gw1) proto tcp from any to $external_addr1 port 22 keep state pass in on $ext_if2 reply-to ($ext_if2 $gw2) proto tcp from any to $external_addr2 port 22 keep state [...] You forget that the first rule to match wins and keep state (which is on by default in 7.0) will make replies to match the state not the pass out rules. May be I am badly interpreting the last sentence, but in pf, the last rule that matches (or the first rule with the 'quick' keyword) wins. The above rules are just decoupled from each other, because they are differing in the interface/direction. And sure, when the state is created, the subsequent packets are not passed through the ruleset. Am I missing something? Yes you are absolutely right - last rule, that match will win, and there is only one rule that will match incoming packets and will create state, thus preventing outgoing packets to match anything else, just this state. Thank you. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
Greetings, I'm little lost in this thread. Is there a solution for the problem and is it part of RELENG_7? If yes can someone tell me which version of which files fix this? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Troubles with em on FreeBSD 7
Oleksandr Samoylyk wrote: Oleksandr Samoylyk wrote: Alexander Sack wrote: Oleksandr: Are you using DEVICE_POLLING by chance? If so, have you tried turning it off (ifconfig use -polling etc.)? Just curious. Surely, no :) # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b I'm just trying the same configuration on i386. The same thing here (i386): PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 745 root 436 1040 219M 67028K select 1 0:00 4845.65% mpd5 23 root1 -68- 0K 8K CPU1 0 333:40 100.00% em0 taskq how many packets per second ? I've seen this only during syn floods :) Can you show the output of netstat -I em0 2 ? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Discrepancy on netstat -w x -I and what Cisco reports
options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_CDNR options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options NETGRAPH options NETGRAPH_CISCO options NETGRAPH_FEC options NETGRAPH_ETHER 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.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU5140 @ 2.33GHz (2329.26-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4286042112 (4087 MB) avail memory = 4124753920 (3933 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 64-87 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci6: on pcib1 pcib2: at device 0.0 on pci6 pci7: on pcib2 pcib3: at device 0.0 on pci7 pci8: on pcib3 pcib4: at device 0.0 on pci8 pci9: on pcib4 bce0: mem 0xd600-0xd7ff irq 16 at device 0.0 on pci9 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:19:b9:cd:60:44 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) pcib5: at device 1.0 on pci7 pci10: on pcib5 pcib6: at device 0.0 on pci10 pci11: on pcib6 pcib7: at device 0.0 on pci11 pci12: on pcib7 em0: port 0xece0-0xecff mem 0xd5ee-0xd5ef,0xd5ec-0xd5ed irq 17 at device 0.0 on pci12 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:5d:2a:40 em1: port 0xecc0-0xecdf mem 0xd5ea-0xd5eb,0xd5e8-0xd5e9 irq 18 at device 0.1 on pci12 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:5d:2a:41 pcib8: at device 1.0 on pci11 pci13: on pcib8 em2: port 0xdce0-0xdcff mem 0xd5ce-0xd5cf,0xd5cc-0xd5cd irq 18 at device 0. lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:2a:40 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c lagg1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:28:62 inet netmask 0xfffc broadcast media: Ethernet autoselect status: active laggproto lacp laggport: em7 flags=1c laggport: em6 flags=1c lagg2: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:28:60 media: Ethernet autoselect status: active laggproto lacp laggport: em5 flags=1c laggport: em4 flags=1c ___________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
Greetings, Alexander Motin wrote: Stefan Lambrev wrote: Yes, You can with ng_tcpmss Isn't it doable only with ipfw/divert when using ng_tcpmss? I have and some concerns about performance too .. There are several ways to inject packet to ng_tcpmss: - ipfw + divert + ng_ksocket. It should be faster then usual user-level implementation - ipfw + netgraph as described in ng_tcpmss(4) - use ng_tcpmss directly in some complicated netgraph setup. For example, mpd is able to use it. This is probably the fastest and easiest way, but only for some setups. Thanks for all ideas. I think I'll try the route -mtu feature. Looks like easier for implementation and testing. :) Anyway it will be good if we have such feature in the base system. It shouldn't be very difficult? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adjust Maximum Segment Size?
Ermal Luçi wrote: On Tue, May 27, 2008 at 8:04 PM, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Greetings, Alexander Motin wrote: Stefan Lambrev wrote: Yes, You can with ng_tcpmss Isn't it doable only with ipfw/divert when using ng_tcpmss? I have and some concerns about performance too .. There are several ways to inject packet to ng_tcpmss: - ipfw + divert + ng_ksocket. It should be faster then usual user-level implementation - ipfw + netgraph as described in ng_tcpmss(4) - use ng_tcpmss directly in some complicated netgraph setup. For example, mpd is able to use it. This is probably the fastest and easiest way, but only for some setups. Thanks for all ideas. I think I'll try the route -mtu feature. Looks like easier for implementation and testing. :) Anyway it will be good if we have such feature in the base system. It shouldn't be very difficult? :) -- Actually converting ng_tcpmss to pfil(9) should be easy. I'm thinking about adding additional checks in tcp_mss() and tcp_mssopt() - both in sys/netinet/tcp_input.c plus two sysctl entries for max mss and max mss IPv6. Does it sound like a reasonable solution or I'm missing something? P.S. One of the things that bothers me is that pf uses it's own pf_get_mss() and pf_calc_mss() and they should be fixed accordingly? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: carpdev?
Greetings, I'm trying this patch against 7-stable amd64 from today. The patch applies cleanly, but: ifconfig carp create ifconfig carp0 carpdev em3 ifconfig: carpdev: bad value What is the proper syntax to set carpdev? Btw 5-10min latter the server panic, but failed to dump a core. The pid to blame was em3 taskq. If I manage to get working configuration, I'll test the patch against unpatched CARP from 6.3 and will test also with quad core/amd64 and dual core i386 (both 7-stable from today) and let you know the results. Max Laier wrote: I did the attached patch some time ago, but didn't find sufficient testers and when I did - I didn't have time. This should work. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jboss4 on freebsd
Greetings, I'm experimenting with jboss4 cluster under freebsd 7 (amd64). In my configuration I have 2 jboss instances which are in cluster and they communicate via separate network (used only for shared data) When I create some load on the application sometimes I see this error: 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed sending message to 10.50.1.1:57680 (59800 bytes) java.io.IOException: No buffer space available It looks very much, that jboss can't handle properly such error as on linux there is no such thing as no network buffers ;) - http://wiki.freebsd.org/AvoidingLinuxisms But what really bothers me is that I see "No buffer space available" on very low network IO - input (em2) output packets errs bytespackets errs bytes colls 144 02203390292 02072771 0 1568 02329764 63 0 9099 0 76 0 231562 34 0 148306 0 563 01152531 1009 01768748 0 1625 02601502104 0 229728 0 65 0 467296 85 0 441566 0 464 0 680082973 01439442 0 357 01940361 55 0 222484 0 1651 02827932145 0 450265 0 E.g. traffic between 1-3MB/s. I'm using: em2: flags=8843 metric 0 mtu 9000 options=19b ether 00:15:17:60:04:c8 inet 10.3.3.117 netmask 0xff00 broadcast 10.3.3.255 media: Ethernet autoselect (1000baseTX ) status: active em2: port 0x2020-0x203f mem 0xb882-0xb883,0xb840-0xb87f irq 18 at device 0.0 on pci5 em2: Using MSI interrupt em2: [FILTER] and my sysctl.conf is: kern.maxfiles=65000 kern.ipc.shmmax=67108864 kern.fallback_elf_brand=3 kern.threads.max_threads_per_proc=6000 kern.ipc.somaxconn=512 #jboss extra net.inet.udp.maxdgram=73728 kern.ipc.maxsockbuf=1048576 net.inet.udp.recvspace=147456 kern.ipc.maxsockets=49312 Any ideas how I can improve things? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jboss4 on freebsd
Paul wrote: kern.ipc.nmbclusters=128000 changed - no effect Check output from netstat -m, this shows network buffers. 770/8200/8970 mbufs in use (current/cache/total) 768/5426/6194/128000 mbuf clusters in use (current/cache/total/max) 768/5248 mbuf+clusters out of packet secondary zone in use (current/cache) 0/677/677/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1728K/15610K/17338K 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 73 requests for I/O initiated by sendfile 0 calls to protocol drain routines This output is in the same second as I see no buffer space available .. isn't this weird? Stefan Lambrev wrote: Greetings, I'm experimenting with jboss4 cluster under freebsd 7 (amd64). In my configuration I have 2 jboss instances which are in cluster and they communicate via separate network (used only for shared data) When I create some load on the application sometimes I see this error: 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed sending message to 10.50.1.1:57680 (59800 bytes) java.io.IOException: No buffer space available It looks very much, that jboss can't handle properly such error as on linux there is no such thing as no network buffers ;) - http://wiki.freebsd.org/AvoidingLinuxisms But what really bothers me is that I see "No buffer space available" on very low network IO - input (em2) output packets errs bytespackets errs bytes colls 144 02203390292 02072771 0 1568 02329764 63 0 9099 0 76 0 231562 34 0 148306 0 563 01152531 1009 01768748 0 1625 02601502104 0 229728 0 65 0 467296 85 0 441566 0 464 0 680082973 01439442 0 357 01940361 55 0 222484 0 1651 02827932145 0 450265 0 E.g. traffic between 1-3MB/s. I'm using: em2: flags=8843 metric 0 mtu 9000 options=19b ether 00:15:17:60:04:c8 inet 10.3.3.117 netmask 0xff00 broadcast 10.3.3.255 media: Ethernet autoselect (1000baseTX ) status: active em2: port 0x2020-0x203f mem 0xb882-0xb883,0xb840-0xb87f irq 18 at device 0.0 on pci5 em2: Using MSI interrupt em2: [FILTER] and my sysctl.conf is: kern.maxfiles=65000 kern.ipc.shmmax=67108864 kern.fallback_elf_brand=3 kern.threads.max_threads_per_proc=6000 kern.ipc.somaxconn=512 #jboss extra net.inet.udp.maxdgram=73728 kern.ipc.maxsockbuf=1048576 net.inet.udp.recvspace=147456 kern.ipc.maxsockets=49312 Any ideas how I can improve things? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
if_bridge turns off checksum offload of members?
Greetings, I just noticed, that when I add em network card to bridge the checksum offload is turned off. I even put in my rc.conf: ifconfig_em0="rxcsum up" ifconfig_em1="rxcsum up" but after reboot both em0 and em1 have this feature disabled. Is this expected behavior? Should I care about csum in bridge mode? I noticed that enabling checksum offload manually improve things little btw. Also I'm experimenting with bridge performance and with today's 7-stable I can't reach the results from my previous test with 7-current (before few months) The best that bridge can do today is just 720kpps (just incoming) vs 1000kpps with sources from few months ago. I'm using the same hardware and same configuration so I'm not sure why -stable is slower. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Paul wrote: The higher I set the buffer the worse it is.. 256 and 512 I get about 50-60k more pps than i do with 2048 or 4096.. You would think it would be the other way around but obviously there is some contention going on. :/ Looks like in bridge mode hw.em.rxd=512 and hw.em.txd=512 yields best results also. reducing or increasing those leads to worse performance. btw is there any news with hwpmc for new CPUs ? last time I checked was real pain to get it working with core2 CPUs :( I'm sticking with 512 for now, as it seems to make it worse with anything higher. Keep in mind, i'm using random source ips, random source and destination ports.. Although that should have zero impact on the amount of PPS it can route but for some reason it seems to.. ? Any ideas on that one? A single stream one source ip/port to one destination ip/port seems to use less cpu, although I haven't generated the same pps with that yet.. I am going to test it soon Ingo Flaschberger wrote: Dear Paul, I tried this.. I put 6-STABLE (6.3), using default driver was slower than FBSD7 have you set the rx/tx buffers? /boot/loader.conf hw.em.rxd=4096 hw.em.txd=4096 bye, Ingo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge turns off checksum offload of members?
Andrew Thompson wrote: On Mon, Jun 30, 2008 at 07:16:29PM +0900, Pyun YongHyeon wrote: On Mon, Jun 30, 2008 at 12:11:40PM +0300, Stefan Lambrev wrote: > Greetings, > > I just noticed, that when I add em network card to bridge the checksum > offload is turned off. > I even put in my rc.conf: > ifconfig_em0="rxcsum up" > ifconfig_em1="rxcsum up" > but after reboot both em0 and em1 have this feature disabled. > > Is this expected behavior? Should I care about csum in bridge mode? > I noticed that enabling checksum offload manually improve things little btw. > AFAIK this is intended one, bridge(4) turns off Tx side checksum offload by default. I think disabling Tx checksum offload is required as not all members of a bridge may be able to do checksum offload. The same is true for TSO but it seems that bridge(4) doesn't disable it. If all members of bridge have the same hardware capability I think bridge(4) may not need to disable Tx side hardware assistance. I guess bridge(4) can scan every interface capabilities in a member and can decide what hardware assistance can be activated instead of blindly turning off Tx side hardware assistance. This patch should do that, are you able to test it Stefan? ===> if_bridge (all) cc -O2 -fno-strict-aliasing -pipe -march=nocona -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/CORE/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/CORE -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/if_bridge/../../net/if_bridge.c /usr/src/sys/modules/if_bridge/../../net/if_bridge.c: In function 'bridge_capabilities': /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:787: error: 'IFCAP_TOE' undeclared (first use in this function) /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:787: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:787: error: for each function it appears in.) *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error I'm building without "-j5" to see if the error message will change :) I'm using 7-STABLE from Jun 27 cheers, Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Steve Bertrand wrote: Support (Rudy) wrote: Ingo Flaschberger wrote: usually interface polling is also chosen to prevent "lock-ups". man polling I used polling in FreeBSD 5.x and it helped a bunch. I set up a new router with 7.0 and MSI was recommended to me. (I noticed no difference when moving from polling -> MSI, however, on 5.4 polling seemed to help a lot. I'm curious now... how do you change individual device polling via sysctl? Using sysctl for polling is deprecated I think. You can do it with ifconfig ifX polling (-polling) you can add polling in rc.conf options also: ifconfig_em0="polling up" #bridged interface in my conf Steve ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Hi, Ingo Flaschberger wrote: Dear Rudy, I used polling in FreeBSD 5.x and it helped a bunch. I set up a new router with 7.0 and MSI was recommended to me. (I noticed no difference when moving from polling -> MSI, however, on 5.4 polling seemed to help a lot. What are people using in 7.0? polling or MSI? if you have a inet-router with gige-uplinks, it is possible that there will be (d)dos attacks. only polling helps you then to keep the router manageable (but dropping packets). Let me disagree :) I'm experimenting with bridge and Intel 82571EB Gigabit Ethernet Controller. On quad core system I have no problems with the stability of the bridge without polling. taskq em0 takes 100% CPU, but I have another three (cpus/cores) that are free and the router is very very stable, no lag on other interfaces and the average load is not very high too. Kind regards, Ingo Flaschberger ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Greetings Paul, --OK I'm stumped now.. Rebuilt with preemption and ULE and preemption again and it's not doing what it did before.. I saw this in my configuration too :) Just leave your test running for longer time and you will see this strange inconsistency in action. In my configuration I almost always have better throughput after reboot, which drops latter (5-10min under flood) with 50-60kpps and after another 10-15min the number of correctly passed packet increase again. Looks like "auto tuning" of which I'm not aware :) How could that be? Now about 500kpps.. That kind of inconsistency almost invalidates all my testing.. why would it be so much different after trying a bunch of kernel options and rebooting a bunch of times and then going back to the original config doesn't get you what it did in the beginning.. I'll have to dig into this further.. never seen anything like it :) Hopefully the ip_input fix will help free up a few cpu cycles. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge turns off checksum offload of members?
Hi, May be a stupid questions, but: 1) There are zero matches of IFCAP_TOE in kernel sources .. there is not support for TOE in 7.0, but may be this is work in progress for 8-current? 2) In #define BRIDGE_IFCAPS_MASK (IFCAP_TOE|IFCAP_TSO|IFCAP_TXCSUM) - TOE should be repleaced with RXCSUM or just removed? 3) Why RX is never checked? In my case this doesn't matter because em turn off both TX and RX if only one is disabled, but probably there is a hardware, that can separate them e.g. RX disabled while TX enabled? 4) I'm not sure why bridge should not work with two interfaces one of which support TX and the other does not? At least if I turn on checksum offload only on one of the interfaces the bridge is still working ... Andrew Thompson wrote: - cut - This patch should do that, are you able to test it Stefan? cheers, Andrew P.S. I saw very good results with netisr2 on a kernel from p4 before few months .. are there any patches flying around so I can test them with 7-STABLE? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge turns off checksum offload of members?
Hi, Sorry to reply to myself. Stefan Lambrev wrote: Hi, May be a stupid questions, but: 1) There are zero matches of IFCAP_TOE in kernel sources .. there is not support for TOE in 7.0, but may be this is work in progress for 8-current? 2) In #define BRIDGE_IFCAPS_MASK (IFCAP_TOE|IFCAP_TSO|IFCAP_TXCSUM) - TOE should be repleaced with RXCSUM or just removed? Your patch plus this small change (replacing TOE with RXCSUM) seems to work fine for me - kernel compiles without a problem and checksum offload is enabled after reboot. 3) Why RX is never checked? In my case this doesn't matter because em turn off both TX and RX if only one is disabled, but probably there is a hardware, that can separate them e.g. RX disabled while TX enabled? 4) I'm not sure why bridge should not work with two interfaces one of which support TX and the other does not? At least if I turn on checksum offload only on one of the interfaces the bridge is still working ... Andrew Thompson wrote: - cut - This patch should do that, are you able to test it Stefan? cheers, Andrew P.S. I saw very good results with netisr2 on a kernel from p4 before few months .. are there any patches flying around so I can test them with 7-STABLE? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge turns off checksum offload of members?
Greetings Andrew, The patch compiles and works as expected. I noticed something strange btw - swi1: net was consuming 100% WCPU (shown on top -S) but I'm not sure this have something to do with your patch, as I can't reproduce it right now .. Andrew Thompson wrote: On Tue, Jul 01, 2008 at 12:51:42PM +0300, Stefan Lambrev wrote: Hi, May be a stupid questions, but: 1) There are zero matches of IFCAP_TOE in kernel sources .. there is not support for TOE in 7.0, but may be this is work in progress for 8-current? Yes, its in current only. Just remove IFCAP_TOE. 2) In #define BRIDGE_IFCAPS_MASK (IFCAP_TOE|IFCAP_TSO|IFCAP_TXCSUM) - TOE should be repleaced with RXCSUM or just removed? 3) Why RX is never checked? In my case this doesn't matter because em turn off both TX and RX if only one is disabled, but probably there is a hardware, that can separate them e.g. RX disabled while TX enabled? Rx does not matter, whatever isnt offloaded in hardware is just computed locally such as checking the cksum. Its Tx that messes up the bridge, if a outgoing packet is generated locally on an interface that has Tx offloading, it may actaully be sent out a different bridge member that does not have that capability. This would cause it to be sent with an invalid checksum for instance. The bridge used to just disable Tx offloading but this patch you are testing makes sure each feature is supported by all members. 4) I'm not sure why bridge should not work with two interfaces one of which support TX and the other does not? At least if I turn on checksum offload only on one of the interfaces the bridge is still working ... Andrew Thompson wrote: - cut - This patch should do that, are you able to test it Stefan? cheers, Andrew P.S. I saw very good results with netisr2 on a kernel from p4 before few months .. are there any patches flying around so I can test them with 7-STABLE? :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Hi Ingo Flaschberger wrote: Dear Paul, I still don't like the huge hit ipfw and lagg take :/ You have to try PF, then you will respect IPFW again ;) -cut- So my maximum without polling is close to 800kpps but if I push that it starts locking me from doing things, or how many kpps do you want to achieve? Do not know for Paul but, I want to be able to route (and/or bridge to handle) 600-700mbps syn flood, which is something like 1500kpps in every direction. Is it unrealistic? If the code is optimized to fully utilize MP I do not see a reason why quad core processor should not be able to do this. After all single core seems to handle 500kpps, if we utilize four, eight or even more cores we should be able to route 1500kpps + ? I hope TOE once MFCed to 7-STABLE will help too? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arplookup x.x.x.x failed: host is not on local network
Hi, Peter Jeremy wrote: I'm occasionally seeing pairs of messages like the following on my NAT host: arplookup 192.168.181.114 failed: host is not on local network arpresolve: can't allocate route for 192.168.181.114 Normally this happens in badly configured LAN. Lets say we have two hosts in the same physical network (same switch for example) Host1 is configured 192.168.1.33/24 and Hosts2 have 192.168.1.1/30 Now when a broadcast or other packet is sent from Host1 it can reach Host2 without a problem. But when Host2 try reach directly Host1 it doesn't know how and from here - can't allocate route ... I bet 192.168.181.114 have a wrong network mask ;) In my particular configuration, there are dual subnets between the NAT and target host. My initial assumption was that the request was arriving on the other subnet and I added if_xname to the arplookup printf() - but that shows that interface matches the IP address. I've looked back through the mailing lists but the previous reports of this problem don't match my scenario. I've seen this with FreeBSD 5.3, 6.2 and 7.0. The (in)frequency of the problem makes me wonder if it's actually a resource exhaustion problem. Has anyone got any suggestions? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Hi, Kip Macy wrote: On Mon, Jul 7, 2008 at 6:07 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote: At 02:44 PM 7/7/2008, Paul wrote: Also my 82571 NIC supports multiple received queues and multiple transmit queues so why hasn't anyone written the driver to support this? It's not a 10gb card and it still supports it and it's widely available and not too expensive either. The new 82575/6 chips support even more queues and the two port version will be out this month and the 4 port in october (PCI-E cards). Motherboards are already shipping with the 82576.. (82571 supports 2x/2x 575/6 support 4x/4x) Actually, do any of your NICs attach via the igb driver ? I have a pre-production card. With some bug fixes and some tuning of interrupt handling (custom stack - I've been asked to push the changes back in to CVS, I just don't have time right now) an otherwise unoptimized igb can forward 1.04Mpps from one port to another (1.04 Mpps in on igb0 and 1.04 Mpps out on igb1) using 3.5 cores on an 8 core system. Is this on 1gbps or on 10gbps NIC? -Kip ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Hi, Kip Macy wrote: On Mon, Jul 7, 2008 at 6:22 PM, Paul <[EMAIL PROTECTED]> wrote: I read through the IGB driver, and it says 82575/6 only... which is the new chip Intel is releasing on the cards this month 2 port and october 4 port, but the chips are on some of the motherboards right now. Why can't it also use the 82571 ? doesn't make any sense.. I haven't tried it but just browsing the driver source doesn't look like it will work. The igb driver has been written to remove a lot of the cruft that has accumulated to work around deficiencies in earlier 8257x hardware. Although it supports "legacy" descriptor handling it has a new mode of descriptor handling that is ostensibly better. I don't have access to the data sheets for pre-zoar hardware so I'm not sure what it would take to support multiple queues on that hardware. May be we should ask Jack Vogel? He will have some news probably. -Kip ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
Hi Paul, Paul wrote: I tested Linux in bridge configuration with the same machine and it CPUed out at about 600kpps through the bridge.. 600kpps incoming or 600kpps incoming+ outgoing ? That's a bit low :/ Soft interrupt using all the cpu. Same opteron , 82571EB Pci express NIC. Tried SMP/ non-smp , load balanced irqs, etc.. Does hwpmc work out of the box (FreeBSD) with those CPUs? Good news is using iptables only adds a few percentage onto the CPU usage. But still, what's with that.. So far FreeBSD got the highest pps rating for forwarding. I haven't tried bridge mode. Ipfw probably takes a big hit in that too though. Looking for an 82575 to test.. P.S. It was a nice chat, but what we can expect from the future? Any plans, patches etc? Someone suggested to install 8-current and test with it as this is the "fast" way to have something included in FreeBSD. I can do this - I can install 8-current, patch it and put it under load and report results, but need patches :) I guess Paul is in the same situation .. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small patch to multicast code...
Greetings, [EMAIL PROTECTED] wrote: At Fri, 22 Aug 2008 21:42:00 +0200, Luigi Rizzo wrote: On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: [EMAIL PROTECTED] wrote: I gather you mean that a fast link on which also we're looping back the packet will be an issue? Since this packet is only going into the simloop() routine. We end up calling if_simloop() from a few "interesting" places, in particular the kernel PIM packet handler. In this particular case we're going to take a full mbuf chain copy every time we send a packet which needs to be looped back to userland. ... In the case of ip_mloopback(), somehow we are stomping on a read-only copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine according to the documented uses of mbuf(9), although as Luigi pointed out, most likely we need to look at the upper-layer protocol too, e.g. where UDP checksums are also being offloaded. in fact, george, if you have an easy way to reproduce the error, could you see if reverting your change and instead adding sizeof(struct udphdr) to the length argument in the call to m_pullup() fixes the problem ? I don't have sample code I can give but it's simple to set up and test. On machine A set up a sender and a listener for the same multicast group/port. On machine B set up a listener. Send from A with the listener on. B should see nothing and its "bad checksums" counter should increase. Turn off listener on A. Send again, B should get the packet. Hm this looks very much like the showstopper when trying to use jboss in cluster environment. The nodes are replicating their data using multicast udp. I'll try this patch to see will the cluster work now under FreeBSD. If you listen to the traffic with tcpdump on a 3rd machine you'll see that the checksum is constant, even if the data in the packet, like the ports, is not. Your ethernet cards have to have hardware checksum offloading. I'm using em/igb in 7-STABLE. em cards and here. Jboss in cluster creates lot of traffic when under pressure, so I wander how this patch will affect performance. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
http://www.clearchain.com/wiki/wpi
Hello, Can someone help me little with WPI driver ? I'm willing to test it on my laptop, but I'm stuck at compile/install process :) I downloaded http://www.clearchain.com/~benjsc/download/20070107-wpi-freebsd.tar.gz but I'm not sure what to do with it. Any tips how to compile it? I'm using FreeBSD 6.2 RC2 - amd64. Thanks in advance. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CARP Question
Hi, Andrea Venturoli wrote: Hello. I've got two servers configured as follows: a) /etc/rc.conf: ifconfig_xl0="inet 192.168.0.2 netmask 255.255.255.0" ifconfig_fxp0="inet 192.168.101.4 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 advskew 100 pass 192.168.101.10" ifconfig_carp1="vhid 2 pass 192.168.101.10" ifconfig_carp2="vhid 3 advskew 100 pass 192.168.0.4" ifconfig_carp3="vhid 4 pass 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 b) /etc/rc.conf: ifconfig_fxp0="inet 192.168.101.1 netmask 255.255.255.0" ifconfig_fxp1="inet 192.168.0.3 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 pass 192.168.101.10" ifconfig_carp1="vhid 2 advskew 100 pass 192.168.101.10" ifconfig_carp2="vhid 3 pass 192.168.0.4" ifconfig_carp3="vhid 4 advskew 100 pass 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 With this I would expect that, being both servers online, they should have two MASTER and two BACKUP carp interfaces each. Instead, one has all MASTERs and the other all BACKUPs. a) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: BACKUP vhid 1 advbase 1 advskew 100 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: BACKUP vhid 2 advbase 1 advskew 0 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: BACKUP vhid 3 advbase 1 advskew 100 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: BACKUP vhid 4 advbase 1 advskew 0 b) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: MASTER vhid 1 advbase 1 advskew 0 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xff00 carp: MASTER vhid 2 advbase 1 advskew 100 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: MASTER vhid 3 advbase 1 advskew 0 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xff00 carp: MASTER vhid 4 advbase 1 advskew 100 Why? man carp: net.inet.carp.preempt Allow virtual hosts to preempt each other. It is also used to failover carp interfaces as a group. When the option is enabled and one of the carp enabled physical interfaces goes down, advskew is changed to 240 on all carp inter- faces. See also the first example. Disabled by default. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
if_bridge & pf
Hello, I have 2 firewalls, and every of them have 2 bridged interfaces + STP , running FreeBSD 6.1-STABLE Unfortunately one of them is totally dead (hw problems) and I have to make new one, but I plan to use FreeBSD-6.2-STABLE. My question is are there any know compatibility issues between 6.1 and 6.2? I know that a lot of changes are committed to if_bridge and pf/pfsync, that's why I'm little unsure :) Sorry if this is not the proper mail list. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vrrp/CARP/ucarp Problems
HI all, Ross Draper wrote: Hi All I was wondering if I could get some advice from those of you who have successfully implemented ip address failover systems such as carp and freevrrpd. I am trying to set up a high availability web loadbalancer using a pair of freebsd 6.2 boxes. I have tried a number of ways to perform failover but always seem to be hitting a problem. UCARP Pro's:This would be my ideal solution as the startup/shutdown scripts enable me to stop and start my applications and add aliases to adaptors easily. Cons: When the backup box is rebooted it always comes up advertising itself as the master then after a few seconds reverts to backup, although I was under the impression it was supposed to wait and listen for advertisements(it doesnt seem to). The backup boxes initial gratuitous arp as a master is sufficient to poison any traffic from the local router to the shared ip address. Only solution was to use arp-sk to send gratuitous arps every few secs, however, arp-sk was a bit flakey and it was a bodge. CARP Pro's: stable and built into the kernel. Could enable acive/active arp load sharing at a later point. Cons: There is a Freebsd bug (I've seen it discussed on the lists) where the creation and destroyal of a carp interface causes a kernel panic. Also, there is no support for start/stop scripts. I do not have experience with ucarp and freevrrpd, so I can talk only about CARP :) The bug you are talking is fixed in -CURRENT, and you can trigger it only if you have more then 1 carp interface per host. I fetch changes from -current and made patch for -stable, that seems to work without problems. There are other bugs, and I'm not sure what is their status, but you always can search for PR. I do not think start/stop scripts are problem as average sysadmin can solve this for itself :) Freevrrpd Pros: Mac address changing removes some of the arp timeout issues/gratuitous arp problems and it supports start/stop scripts Cons: I'm finding that upon rebooting the backup unit it correctly starts as a backup, then three seconds later syslogs that it is the master and changes its mac address accordingly. although a sniff of the network traffic indicates it is sending the right advertisements(lower priority), it never goes into backup mode again. So, what am I doing wrong? Are these common problems, or something that appears specific to my hosts/switches? are there more suitable options? The loadbalancers are all single homed and I have tried a mixture of xl, bge and fxp cards. Any help/suggestions much appreciated, also, any links to a perl based gratuitous arp util would be great! Many thanks Ross PS - Apologies if you see multiple copies of this message, I seem to be having trouble getting mails onto the list. All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England & Wales with No. 923454 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" P.S. the attached patch is little old so I'm not sure it still apply cleanly to the latest -stable :) I tested base functionality with patched carp, but still do not have server in production with it, so be careful! -- Best Wishes, Stefan Lambrev ICQ# 24134177 --- src/sys/netinet/ip_carp.c.orig Thu Feb 1 18:53:55 2007 +++ src/sys/netinet/ip_carp.c Tue Feb 6 18:41:24 2007 @@ -191,7 +191,7 @@ static voidcarp_input_c(struct mbuf *, struct carp_header *, sa_family_t); static int carp_clone_create(struct if_clone *, int); static voidcarp_clone_destroy(struct ifnet *); -static voidcarpdetach(struct carp_softc *); +static voidcarpdetach(struct carp_softc *, int); static int carp_prepare_ad(struct mbuf *, struct carp_softc *, struct carp_header *); static voidcarp_send_ad
Re: The broadcast of python in FreeBSD
Hi, Zhu Yan wrote: Hi, Everybody. In FreeBSD, I write a program in python(2.4.4 & 2.5), which include a broadcast routine. But, I send the broadcast in FreeBSD, it's different from others OS, like Windows, Linux... When I send the broadcast in FreeBSD with address 255.255.255.255, the packet can not be received by other OS. But I send the broadcast in non-BSD System with address 255.255.255.255, all OS got it. When I send the broadcast in FreeBSD with address like 192.168.1.255, all OS got it. I have seen the Python socket implement, there is no added option for FreeBSD, but why? Why it is different? Can you change "sysctl net.inet.icmp.bmcastecho=1" and test again? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sockets without owner.
Hello list, I'm having very strange problem. I have near 200 sockets reported by netstat -An, which are NOT reported by sockstat and fstat. All of them look like (output from netstat -An) : ff0169282000 tcp4 0 0 192.168.13.12.4965 192.168.13.3.8080 FIN_WAIT_2 I'm trying to figure out what keeps them active (tcpdump shows traffic from 192.168.13.12 to 192.168.13.3) The application that create them is stopped before more then a week but request are still "flying" around. I tried fstat |grep ff0169282000, but the output is 0 lines. Is there any way to close those sockets, as it appears that they are stalled and without owner? And what is the timeout for FIN_WAIT_2 in freebsd ? (the rfc doesn't define timeout but I read somewhere that freebsd's network stack have timeout) FreeBSD 6.2-PRERELEASE SMP amd64. I have access to both IPs - 192.168.13.12 is http balancer and 192.168.13.3 is apache server (both were restarted) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wpi driver.
Hello, Are there any news about wpi driver ? Something that can be compiled on freebsd 6.2 stable ? I tried the latest drivers from http://www.clearchain.com/~benjsc/download, but no success :( I tried and from perforce but I've got this error: # make Warning: Object directory not changed from original /root/wpi/sys/modules/wpi @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include :> opt_bdg.h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O2 -fno-strict-aliasing -pipe -g -DWITNESS -DINVARIANT_SUPPORT -DINVARIANTS -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/root/wpi/sys/modules/wpi/../../ -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c: In function `wpi_firmware_get': /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c:294: warning: assignment discards qualifiers from pointer target type *** Error code 1 Stop in /root/wpi/sys/modules/wpi. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wpi driver.
Hi, Thanks for the quick reply. But ... Orum wrote: Stefan, I've gotten it to work on 6.2, but you need to get the patched version (specifically made for 6.2) from this location: http://www.bsdmon.com/download/20070121-wpi-freebsd.tar.gz This does NOT compile on FreeBSD 6.2-stable from 12 Mar 2007. The error is the same. You will also need to install the wpi-firmware port (not in the ports tree yet) from a later official release. I'm sorry to say I don't remember the link for the tar archive that included the port. Also note that it's still a very touchy driver, and might need to be unloaded/reloaded to get up and running (at least, that seems to fix it on my T60). In addition WPA/WPA2 do not work with it (don't know about WEP as I've never tried). Not very useful without WPA(2) as I do not want to share my network .. :) I'm more interested is there something new about the driver with the new firmware, because it was mentioned in last quarter report, and few other places on the net, but there is nothing new "released". Thanks, Ian On 4/19/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hello, Are there any news about wpi driver ? Something that can be compiled on freebsd 6.2 stable ? I tried the latest drivers from http://www.clearchain.com/~benjsc/download, but no success :( I tried and from perforce but I've got this error: # make Warning: Object directory not changed from original /root/wpi/sys/modules/wpi @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include :> opt_bdg.h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O2 -fno-strict-aliasing -pipe -g -DWITNESS -DINVARIANT_SUPPORT -DINVARIANTS -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/root/wpi/sys/modules/wpi/../../ -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c: In function `wpi_firmware_get': /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c:294: warning: assignment discards qualifiers from pointer target type *** Error code 1 Stop in /root/wpi/sys/modules/wpi. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0 - bge0 failed to work at 1000baseTX
Hello, I'm trying to get two gigabit network cards to work together. em0: port 0x1000-0x101f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 [EMAIL PROTECTED]:25:0: class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet and broadcom on the other end: bge0: mem 0xf410-0xf410 irq 16 at device 0.0 on pci8 [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a3103c chip=0x16fd14e4 rev=0x21 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5753M NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet When I connect both networks without switch e.g. directly they auto negotiate to: media: Ethernet autoselect (100baseTX ) but I want 1000baseTX :( First thing that I tried was to force both network card with: ifconfig bge0/em0 media 1000baseTX mediaopt full-duplex but this lead to status: no carrier Second step was to set bge link0 and em0 link1, but still "no carrier" (from bge manual) On the machine with em card I have linux installed so I boot under linux and then everything works with autoselect, and I'm able to transfer with speed +50MB/s. When I forced both network cards to 1000baseTX I notice this: em0 media: Ethernet 1000baseTX (autoselect) bge0 media: Ethernet 1000baseTX (none) Something else that is quite strange is that when I change em media from autoselec to 1000baseTX, I see that for 2-3 seconds there is a connection between cards (e.g. status: active), but just for 2-3 seconds and then it disconnects again. (ping between hosts works for 2 seconds) At this time ifconfig shows: em0 media: Ethernet 1000baseTX ^^ no autoselect here ? status: active and bge0: media: Ethernet autoselect (1000baseTX ) ( I left bge to autoselect at some point as I saw it does not change a thing..) status: active I compiled new kernel with #define EM_MASTER_SLAVE 2 (and then 3) in if_em.h (as I'm suspecting em driver ..) but still no success. Last thing that I notice while (re)booting freebsd server with em0 is that during starting program and rc scripts the status of the network changed from 100mbps -> 1000mbps -> no carrier -> 100mbps. So any ideas how to get my network working at gigabit speeds? :) P.S. both machines are running freebsd 6.2 stable - em0 is i386 and bge0 is on amd64. em0 was tested with 6.2-release too. Thanks in advance. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 - bge0 failed to work at 1000baseTX
Hello, Jack Vogel wrote: On 4/24/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hello, I'm trying to get two gigabit network cards to work together. em0: port 0x1000-0x101f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 [EMAIL PROTECTED]:25:0: class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet and broadcom on the other end: bge0: mem 0xf410-0xf410 irq 16 at device 0.0 on pci8 [EMAIL PROTECTED]:0:0: class=0x02 card=0x30a3103c chip=0x16fd14e4 rev=0x21 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5753M NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet When I connect both networks without switch e.g. directly they auto negotiate to: media: Ethernet autoselect (100baseTX ) but I want 1000baseTX :( First thing that I tried was to force both network card with: ifconfig bge0/em0 media 1000baseTX mediaopt full-duplex but this lead to status: no carrier Second step was to set bge link0 and em0 link1, but still "no carrier" (from bge manual) On the machine with em card I have linux installed so I boot under linux and then everything works with autoselect, and I'm able to transfer with speed +50MB/s. When I forced both network cards to 1000baseTX I notice this: em0 media: Ethernet 1000baseTX (autoselect) bge0 media: Ethernet 1000baseTX (none) Something else that is quite strange is that when I change em media from autoselec to 1000baseTX, I see that for 2-3 seconds there is a connection between cards (e.g. status: active), but just for 2-3 seconds and then it disconnects again. (ping between hosts works for 2 seconds) At this time ifconfig shows: em0 media: Ethernet 1000baseTX ^^ no autoselect here ? status: active and bge0: media: Ethernet autoselect (1000baseTX ) ( I left bge to autoselect at some point as I saw it does not change a thing..) status: active I compiled new kernel with #define EM_MASTER_SLAVE 2 (and then 3) in if_em.h (as I'm suspecting em driver ..) but still no success. Last thing that I notice while (re)booting freebsd server with em0 is that during starting program and rc scripts the status of the network changed from 100mbps -> 1000mbps -> no carrier -> 100mbps. So any ideas how to get my network working at gigabit speeds? :) P.S. both machines are running freebsd 6.2 stable - em0 is i386 and bge0 is on amd64. em0 was tested with 6.2-release too. Thanks in advance. Do me a favor please, go to downloadfinder.intel.com and get my latest driver, its version 6.3.9, since ICH8 is fairly recent and has had some late-breaking fixes in shared code its possible that will solve things. You will want to use this driver as a module, its a hassle to build into the kernel (although there is a patch to allow you to do that if you wish). Please report back EITHER if it works or fails, if it does still fail I will have our test/validation group get hardware set up to look into this. Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" Unfortunately 6.3.9 have the same behavior as 6.2.9 and I can't get both network cards to work at gigabit speed. Any other ideas ? :) dmesg: Copyright (c) 1992-2007 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 6.2-STABLE #3: Wed Apr 25 07:40:24 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CORE-SMP acpi_alloc_wakeup_handler: can't alloc wake memory ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 3.00GHz (2992.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf65 Stepping = 5 Features=0xbfebfbff Features2=0xe49d,> AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 1048248320 (999 MB) avail memory = 1019318272 (972 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pc
Re: em0 - bge0 failed to work at 1000baseTX
Hi, Jack Vogel wrote: -cut- The new driver I just checked into CURRENT has this fix, I hope its going to be in the May snapshot, Stefan, can you try CURRENT to see if it solves your problem? Jack I'll need some time for this :) But my idea was to run some benchmarks on freebsd 6.2-release and freebsd 6.2-stable. I'll prepare 7.0 and will let you know if the drivers works for me :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 - bge0 failed to work at 1000baseTX
Hi again, Jack Vogel wrote: The new driver I just checked into CURRENT has this fix, I hope its going to be in the May snapshot, Stefan, can you try CURRENT to see if it solves your problem? Jack I have problems with loading if_em as module on 7.0-current from today: link_elf: symbol e1000_init_function_pointers_82575 undefined so I compiled in the kernel, and it works, but nothing changed about my problem - it still refuses to stay on 1000baseTX for more then 2 seconds and auto-negotiate to 100baseTX. em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] I'm ready to test any new patches :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 - bge0 failed to work at 1000baseTX
Jack Vogel wrote: On 5/7/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hi again, Jack Vogel wrote: > > The new driver I just checked into CURRENT has this fix, I hope its > going to be in the May snapshot, Stefan, can you try CURRENT to > see if it solves your problem? > > Jack I have problems with loading if_em as module on 7.0-current from today: link_elf: symbol e1000_init_function_pointers_82575 undefined so I compiled in the kernel, and it works, but nothing changed about my problem - it still refuses to stay on 1000baseTX for more then 2 seconds and auto-negotiate to 100baseTX. em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] I'm ready to test any new patches :) My patch made assumptions about what is causing your problem, and that may be incorrect. Our test group does not have that Broadcom adapter but they are going to get one. I'll make tests with other gigabit network cards (first working day) to be sure that the problem exists only with broadcom then. They had a suggestion that you can try, go into your BIOS, and then the Advanced Menu, I believe under that you will find settings for the NorthBridge, in that submenu there is settings for HECI, disable that, it is the interface to the management processor. Sorry I'm unable to find such menu in the BIOS. This is some new HP's BIOS, that really do not make me happy ... Then boot up and test again, if it now autonegs correctly then it is the management getting in your way, on the other hand if you still see it happen then we're back to square one :) Good luck, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 - bge0 failed to work at 1000baseTX
Hi Jack, Jack Vogel wrote: On 5/7/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hi again, Jack Vogel wrote: > > The new driver I just checked into CURRENT has this fix, I hope its > going to be in the May snapshot, Stefan, can you try CURRENT to > see if it solves your problem? > > Jack I have problems with loading if_em as module on 7.0-current from today: link_elf: symbol e1000_init_function_pointers_82575 undefined so I compiled in the kernel, and it works, but nothing changed about my problem - it still refuses to stay on 1000baseTX for more then 2 seconds and auto-negotiate to 100baseTX. em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] I'm ready to test any new patches :) My patch made assumptions about what is causing your problem, and that may be incorrect. Our test group does not have that Broadcom adapter but they are going to get one. They had a suggestion that you can try, go into your BIOS, and then the Advanced Menu, I believe under that you will find settings for the NorthBridge, in that submenu there is settings for HECI, disable that, it is the interface to the management processor. Then boot up and test again, if it now autonegs correctly then it is the management getting in your way, on the other hand if you still see it happen then we're back to square one :) Good luck, Jack I finally succeed with building latest current, found another Gige Intel card and make more tests: Both servers are running freebsd 7.0 new server with dual-port em network card (7.0-CURRENT #9: Thu May 24): em1: port 0x2000-0x201f mem 0xb8c0-0xb8c1,0xb840-0xb87f irq 19 at device 0.1 on pci4 em1: Ethernet address: 00:15:17:1b:08:ed em1: [FILTER] problematic server with verbose boot (FreeBSD 7.0-CURRENT #8: Sat May 26) : em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xf050 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf0524000 em0: bpf attached em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] Just after boot I see: em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP em0: Link is Down em0: link state changed to DOWN em0: Link is up 100 Mbps Full Duplex em0: link state changed to UP So the problem is not with bge0, but em0. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0 failed to work at 1000baseTX. WAS [Re: em0 - bge0 failed to work at 1000baseTX]
Hi, MQ wrote: Actually, I'd rather consider the bge(4) has some problems with its media negotiation. It seems that the problem you described was just the same with mine as I had mentioned earlier this year. I encountered the problem as I wanted a BCM5701 and a BCM5780 to connect to each other with 1000TX duplex. Hm seems my last mail got lost and didn't reach the mail list. I replaced the broadcom device with other intel gigabit card: em1: port 0x2000-0x201f mem 0xb8c0-0xb8c1,0xb840-0xb87f irq 19 at device 0.1 on pci4 em1: Ethernet address: 00:15:17:1b:08:ed em1: [FILTER] on the other end is the "problematic" network card (that does work under linux&windows): em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xf050 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf0524000 em0: bpf attached em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] When I verbose boot the server I see: em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP em0: Link is Down em0: link state changed to DOWN em0: Link is up 100 Mbps Full Duplex em0: link state changed to UP if I type ifconfig em0 media auto it happens exactly the same: card down card negotiate to 1000 Mbps Full Duplex card up - netowrk work for 2 seconds card down card negotiate to 100Mbps Full Duplex card up. If i force 1000mbps network : ifconfig em0 media 1000basetx mediaopt full-duplex 2 seconds latter I see: status: no carrier Both machines are running FreeBSD 7.0-CURRENT from ~2 days ago. A checked up connection between bge0 and the new server with intel card and everything works fine. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 failed to work at 1000baseTX. WAS [Re: em0 - bge0 failed to work at 1000baseTX]
Hi Jack, Jack Vogel wrote: Stefan, I am having a long weekend and am supposed to be doing something other than this :) However, when I get back in the office on Tuesday I will see if I can repro this, so just to make sure, tell me what the PCI ID of the two cards are when it fails with Intel on both sides, that should be easy. Jack this is the card that works in my tests: [EMAIL PROTECTED]:0:1: class=0x02 card=0x34768086 chip=0x10968086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 EB Network Connection' class = network subclass = ethernet and this is the one that do not work at gigabit speed: [EMAIL PROTECTED]:25:0: class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet On 5/27/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Hi, MQ wrote: > > Actually, I'd rather consider the bge(4) has some problems with its > media negotiation. It seems that the problem you described was just > the same with mine as I had mentioned earlier this year. I encountered > the problem as I wanted a BCM5701 and a BCM5780 to connect to each > other with 1000TX duplex. Hm seems my last mail got lost and didn't reach the mail list. I replaced the broadcom device with other intel gigabit card: em1: port 0x2000-0x201f mem 0xb8c0-0xb8c1,0xb840-0xb87f irq 19 at device 0.1 on pci4 em1: Ethernet address: 00:15:17:1b:08:ed em1: [FILTER] on the other end is the "problematic" network card (that does work under linux&windows): em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xf050 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf0524000 em0: bpf attached em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] When I verbose boot the server I see: em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP em0: Link is Down em0: link state changed to DOWN em0: Link is up 100 Mbps Full Duplex em0: link state changed to UP if I type ifconfig em0 media auto it happens exactly the same: card down card negotiate to 1000 Mbps Full Duplex card up - netowrk work for 2 seconds card down card negotiate to 100Mbps Full Duplex card up. If i force 1000mbps network : ifconfig em0 media 1000basetx mediaopt full-duplex 2 seconds latter I see: status: no carrier Both machines are running FreeBSD 7.0-CURRENT from ~2 days ago. A checked up connection between bge0 and the new server with intel card and everything works fine. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 failed to work at 1000baseTX. WAS [Re: em0 - bge0 failed to work at 1000baseTX]
Jack Vogel wrote: On 5/29/07, Jack Vogel <[EMAIL PROTECTED]> wrote: On 5/27/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > On 5/27/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: > > Hi Jack, > > > > Jack Vogel wrote: > > > Stefan, > > > > > > I am having a long weekend and am supposed to be doing > > > something other than this :) However, when I get back in the office > > > on Tuesday I will see if I can repro this, so just to make sure, tell > > > me what the PCI ID of the two cards are when it fails with Intel > > > on both sides, that should be easy. > > > > > > Jack > > this is the card that works in my tests: > > > > [EMAIL PROTECTED]:0:1: class=0x02 card=0x34768086 chip=0x10968086 rev=0x01 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'PRO/1000 EB Network Connection' > > class = network > > subclass = ethernet > > > > and this is the one that do not work at gigabit speed: > > > > [EMAIL PROTECTED]:25:0: class=0x02 card=0x2800103c chip=0x104a8086 rev=0x02 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82566DM Gigabit Network Connection' > > class = network > > subclass = ethernet > > OK, I will attempt to repro this on Tuesday, thanks Stefan. Good News, I have repro'd this on hardware here, so I'm actively debugging things now, hope its an easy fix... stay tuned. I have fixed the problem, I will be checking in that together with a couple other minor bugs this afternoon sometime. Cheers, Jack Thank you very much for the help Jack :)) Unfortunately I'm off next four days and probably will not be able to test it before Monday. Btw any chances to have patch for releng_6 or the difference in the drivers is too big ? :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 failed to work at 1000baseTX. WAS [Re: em0 - bge0 failed to work at 1000baseTX]
Hi, Jack Vogel wrote: On 5/31/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Thank you very much for the help Jack :)) Unfortunately I'm off next four days and probably will not be able to test it before Monday. Btw any chances to have patch for releng_6 or the difference in the drivers is too big ? :) Welcome, turns out its just as well that you didnt test yet because my test engineer came back to me this morning and it turns out there was still a code path that caused the autoneg back down to 100, I worked with him this morning and now I've simplified the code and plugged that hole at the same time, so another delta will be coming today. em0: port 0x2000-0x201f mem 0xf050-0xf051,0xf0524000-0xf0524fff irq 19 at device 25.0 on pci0 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xf050 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf0524000 em0: bpf attached em0: Ethernet address: 00:0f:fe:4e:78:16 em0: [FILTER] This is freebsd 7-current with src from today and I still have the same problem :( Here are few lines from messages: Jun 4 11:55:20 shitler kernel: em0: Link is up 1000 Mbps Full Duplex Jun 4 11:55:20 shitler kernel: em0: link state changed to UP Jun 4 11:55:23 shitler kernel: em0: Link is Down Jun 4 11:55:23 shitler kernel: em0: link state changed to DOWN Jun 4 11:55:26 shitler kernel: em0: Link is up 100 Mbps Full Duplex Jun 4 11:55:26 shitler kernel: em0: link state changed to UP As for 6.X, well, its definitely a fix that needs to go back, but the question is how. What I would like to do is MFC the whole new shared code driver, in fact the next release that gets published by Intel which is a few months out should have that version anyway so I'll work that and the MFC together. However, if you have an urgent need for this fix on 6.2 I can make up a special patch, I'm pretty sure the old shared code still has what we need to do this. My idea was to use this server to benchmark few apps under different OSes, but with network card running on 100mbps under freebsd .. it's impossible to compare things. Unfortunately I'll need this server soon in production and will be unable to finish the tests on it. Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
