Re: DNS query performance
Marcelo Gardini do Amaral <[EMAIL PROTECTED]> writes: > > I would like to discuss a little bit more about UDP performance. I've > made some tests and the results may have some value here. > > In this test is easy to see that there is something different in the > FreeBSD 6 branch. 1. Can you try this with another network card ? em for example ? 2. Have you tried device polling ? Just curious. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.1 + ath0 + NAT
Hi all,
This is my first post, so please be gentle :-)
I have a Linksys WAG54G V.2 ADSL modem (Firmware Version: 1.00.39)
connection to the Internet, and a Netgear WG311T wireless Ethernet card
running on FreeBSD 6.1 (PC#1).
Recently I added a second FreeBSD 6.1 system (PC#2) which has no
wireless card (well it does, but it's a TI chipset not supported in
FreeBSD). So I connected it to PC#1 with a Gigabit copper wire
connection. I also added firewall and NATing on PC#1 to provide PC#2
with a route to the Internet.
When I boot PC#1, the connection between ath0 and the ADSL modem will run
as expected (routing to the Internet for itself and PC#2) for some time
(roughly anywhere from 0 to 30 minutes), but always eventually hangs.
It's then not possible to ping the ADSL modem.
The hang happens regardless of whether the new (PC#2) system is booted
or not.
The PC#1 ath0 wireless connection has been woking flawlessly (without
the firewall and NAT changs) for nearly a year (originally under FreeBSD
6.0 with Sam Lefflers ath patches) and more recently on FreeBSD 6.1.
Can anybody spot anything obviously wrong with the new setup, or know of
any bug reports that might impact a NATing gateway on a wireless connection?
I have also recently discovered the link goes up and down every 20 or 30
minutes with what looks like a DHCP lease renewal. This extracted from
/var/log/messages:
Sep 13 19:42:21 kt400 kernel: ath0: link state changed to DOWN
Sep 13 19:42:23 kt400 kernel: ath0: link state changed to UP
Sep 13 19:42:23 kt400 dhclient: New IP Address (ath0): 192.168.1.64
Sep 13 19:42:23 kt400 dhclient: New Subnet Mask (ath0): 255.255.255.0
Sep 13 19:42:23 kt400 dhclient: New Broadcast Address (ath0): 192.168.1.255
Sep 13 19:42:23 kt400 dhclient: New Routers (ath0): 192.168.1.1
Sep 13 20:12:21 kt400 kernel: ath0: link state changed to DOWN
Sep 13 20:12:23 kt400 kernel: ath0: link state changed to UP
Sep 13 20:12:23 kt400 dhclient: New IP Address (ath0): 192.168.1.64
Sep 13 20:12:23 kt400 dhclient: New Subnet Mask (ath0): 255.255.255.0
Sep 13 20:12:23 kt400 dhclient: New Broadcast Address (ath0): 192.168.1.255
Sep 13 20:12:23 kt400 dhclient: New Routers (ath0): 192.168.1.1
Sep 13 21:32:21 kt400 kernel: ath0: link state changed to DOWN
Sep 13 21:32:24 kt400 kernel: ath0: link state changed to UP
Looks like a smoking gun? Is this likely to upset the firewall/NATing?
[I have not yet had a chance to correlate the hang with the lease renewal,
but will test that tomorrow.]
In the kernel config file I have added:
options IPFIREWALL
options IPDIVERT
In /etc/rc.conf I have:
# See also /etc/wpa_supplicant.conf
ifconfig_ath0="WPA DHCP"
# Private x-over to printer
ifconfig_rl0="inet kt400pr netmask 255.255.255.0 broadcast 10.0.0.255"
# Private x-over to Dell 350 (PC#2)
ifconfig_sk0="inet gbkt400 netmask 255.255.255.0 broadcast 192.168.2.255"
# These added for firewall/NATing
gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="ath0"
natd_flags=""
[kt400.145] cat /etc/wpa_supplicant.conf
network={
ssid="linksys"
key_mgmt=NONE
wep_key0=xx
wep_tx_keyidx=0
}
[kt400.146] ifconfig -a
sk0: flags=8843 mtu 1500
options=8
inet6 fe80::215:e9ff:feb0:e5b0%sk0 prefixlen 64 scopeid 0x1
inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255
ether 00:15:e9:b0:e5:b0
media: Ethernet autoselect (none)
status: no carrier
ath0: flags=8843 mtu 1500
inet6 fe80::20f:b5ff:fef6:28eb%ath0 prefixlen 64 scopeid 0x2
inet 192.168.1.64 netmask 0xff00 broadcast 192.168.1.255
ether 00:0f:b5:f6:28:eb
media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
status: associated
ssid linksys channel 11 bssid 00:14:bf:7a:57:94
authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpowmax 37
protmode CTS burst roaming MANUAL bintval 100
rl0: flags=8843 mtu 1500
options=8
inet6 fe80::220:edff:fe70:471a%rl0 prefixlen 64 scopeid 0x3
inet 10.0.0.254 netmask 0xff00 broadcast 10.0.0.255
ether 00:20:ed:70:47:1a
media: Ethernet autoselect (none)
status: no carrier
fwe0: flags=108802 mtu 1500
options=8
ether 02:00:20:71:b9:a6
ch 1 dma -1
lo0: flags=8049 mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff00
Thanks,
--
Phil
I don't do drugs anymore 'cause I find I get the same effect just by standing
up really fast.
-- Johnathan Katz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Rapid link state changes on bge(4) interface
Hi, I'm testing network failover on IBM BladeCenter running FreeBSD 6.1 STABLE for Sep 6th. I suspect a problem with link state change detection in bge code. When I disable internal port on chassis built-in ethernet switch, kernel floods syslog with messages about link state changes and coalescing them. Log snippet follows: Sep 13 14:58:28 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:28 w3-6 kernel: bge1: link state changed to UP Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to UP Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:29 w3-6 kernel: bge1: 4 link states coalesced Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:29 w3-6 kernel: bge1: 11 link states coalesced Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to UP Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:30 w3-6 kernel: bge1: 3 link states coalesced Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to UP Sep 13 14:58:30 w3-6 kernel: bge1: 7 link states coalesced Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:30 w3-6 kernel: bge1: 4 link states coalesced Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to DOWN Sep 13 14:58:30 w3-6 kernel: bge1: 2 link states coalesced As you can see, messages are generated in rapid succession and therefore any probing of link state change by ng_one2many for interface failover is meaningless. Ethernet switch doesn't register and log any interface state changes after disabling this port. LS20 blades use chipset 8850. My firmware is 3.38, full changelog, if it is of any help, is here: http://www-307.ibm.com/pc/support/site.wss/license.do?filename=pc_servers/brcm_fw_nic_12021_anyos_anycpu.chg Any ideas what might be wrong? /S -- Sławek Żak / UNIX Systems Administrator ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is IPSec NAT-T support?
On Sat, Sep 09, 2006 at 08:31:47PM +0900, Norikatsu Shigemura wrote: > On Wed, 6 Sep 2006 09:01:35 +0200 [NAT-T patches] > > - The public patch (A) works for IPSEC, and should apply on both > > RELENG_6 and RELENG_6_1 (some minor patching issues may need to be > > solved by hand, but it's just some indentation changes in the source > > code between the two versions). > > - This public patch does NOT provide support for multiple peers behind > > the same NAT device. > > - I have a newer version of the patch (B), against RELENG_6_1, which > > provides such support for multiples peers behind the same NAT > > device. I was about to put it in public place when someone raised a > > discutable implementation choice in the way ipsec-tools and kernel > > exchange some datas specific to that NAT-T support (I ported it from > > Manu's work on NetBSD). > > How to get the patch(B)? I'm interesting new version of the patch. I just updated the public patch, it should be available on ipsec-tools website in a few hours (it replaces the old one, same address, MD5 sum is 81d535363981b5e84be77cbf26918ccc). [] > I'm interesting FAST_IPSEC support:-). if Larry or someone else have quickly some time to do it, please let me know. If no one else port that (it shouldn't be too difficult, but takes some time), I'll do it "ASAP". Yvan. -- NETASQ http://www.netasq.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is IPSec NAT-T support?
>> I'm interesting FAST_IPSEC support:-). > > if Larry or someone else have quickly some time to do it, please let > me know. > > If no one else port that (it shouldn't be too difficult, but takes > some time), I'll do it "ASAP". I'll make the time. Should have something in the next day or two. Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS query performance
Hi John, > I have not had time to fully investigate this issue but it appeared that > some queries from queryperf never made it out of the FreeBSD 6.1 box. When > I ran netstat -s -p udp I saw that that the numbers for delivered and > datagrams output differed by the number of queries that queryperf was > reporting as lost. However I am yet to figure out what this means. With my FreeBSD 4.11 client box the number of queries lost in the queryperf is the same as the reported by netstat command. I made a new test in another hardware, because with HP Blade Proliant is impossible to add an aditional NIC: there isn't any PCI slot and the bge interfaces are onboard. So, I used a Dell 1750, Xeon 3.06GHz with 'bge' interfaces onboard and an 'em' inserted in a slot, both running at 1Gbit/s. The results, for the same zone and queries: queries/s Server NIC F4.11-UP F6.1-UP F6.1-SMP -- --- --- bindbge 24846 1590014700 em22703 1880017477 nsd bge 58948 1800014009 em67454 4200035571 In general, em has a better performance than bge. But the performance on F6.1 is not so good if compared with F4.11, even for em interface. This is very vivid for NSD 3.0.1 results. On F4.11, the bge has a performance around 3 times better than F6.1. em is at least 1.5 times better. On F6.1, em has a performance about twice better than bge. On F4.11, there is no such big difference - just about 20% With this numbers, I think I can say there are something wrong with bge driver and also with F6.1 branch, because I didn't get similar results, even with em NIC. -- Att., Marcelo Gardini ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improved TCP syncookie implementation
On Sun, 3 Sep 2006, Andre Oppermann wrote: I've pretty much rewritten our implementation of TCP syncookies to get rid of some locking in TCP syncache and to improve their functionality. The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK optional feature information. This means that a FreeBSD host may run with syncookies only and not degrade TCP connections made through it. All important TCP connection setup negotiated options are preserved (send/receive window scaling, SACK, MSS) without storing any state on the host during the SYN-SYN/ACK phase. As a nice side effect the timestamps we respond with are randomized instead of directly using ticks (which reveals out uptime). As I understand syncache is used to retransmit SYN/ACK. What would be if 1) a client sent SYN, 2) we sent SYN/ACK with cookie, 3) the client sent ACK, but the ACK was lost ? I suppose the client will see timed out error. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Rapid link state changes on bge(4) interface
> I'm testing network failover on IBM BladeCenter running FreeBSD 6.1 > STABLE for Sep 6th. > > I suspect a problem with link state change detection in bge code. When > I disable internal port on chassis built-in ethernet switch, kernel > floods syslog with messages about link state changes and coalescing > them. Log snippet follows: > > Sep 13 14:58:28 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:28 w3-6 kernel: bge1: link state changed to UP > Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to UP > Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:29 w3-6 kernel: bge1: 4 link states coalesced > Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:29 w3-6 kernel: bge1: 11 link states coalesced > Sep 13 14:58:29 w3-6 kernel: bge1: link state changed to UP > Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:30 w3-6 kernel: bge1: 3 link states coalesced > Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to UP > Sep 13 14:58:30 w3-6 kernel: bge1: 7 link states coalesced > Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:30 w3-6 kernel: bge1: 4 link states coalesced > Sep 13 14:58:30 w3-6 kernel: bge1: link state changed to DOWN > Sep 13 14:58:30 w3-6 kernel: bge1: 2 link states coalesced > > As you can see, messages are generated in rapid succession and > therefore any probing of link state change by ng_one2many for > interface failover is meaningless. Ethernet switch doesn't register > and log any interface state changes after disabling this port. LS20 > blades use chipset 8850. My firmware is 3.38, full changelog, if it is > of any help, is here: > > http://www-307.ibm.com/pc/support/site.wss/license.do?filename =pc_servers/brcm_fw_nic_12021_anyos_anycpu.chg > > Any ideas what might be wrong? I can't access the information on this web site through Mozilla after clicking "I Accept". Is this a 5704 controller using a SerDes link? I'm familiar with some Blade Center problems in the past (which I think were related to Sigdet) though I'm not in the office and can't look into it right away. A comparison between the serdes code in the Linux driver vs. the FreeBSD driver is probably the first area to investigate. Dave ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS query performance
On Mon, 11 Sep 2006, Marcelo Gardini do Amaral wrote: I would like to discuss a little bit more about UDP performance. I've made some tests and the results may have some value here. In this test is easy to see that there is something different in the FreeBSD 6 branch. I made a benchmark with bind 9.3.2 (without threads support) and nsd 3.0.1 (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among FreeBSD 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386 systems. I used this simple zone file: Are you able to boot a 7.x kernel on this box? An as yet un-MFC'd optimization to the UDP send path is present in the 7.x kernel, suggested by ISC, which significantly improves threaded BIND9 performance. I've not benchmarked unthreaded BIND9 with the change. If you want to test specifically the before/after case for that change, you can find the reference to sosend_dgram in src/sys/netinet/udp_usrreq.c and swap it to sosend, which restores the old behavior. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS query performance
On Wed, 13 Sep 2006, Robert Watson wrote: On Mon, 11 Sep 2006, Marcelo Gardini do Amaral wrote: I would like to discuss a little bit more about UDP performance. I've made some tests and the results may have some value here. In this test is easy to see that there is something different in the FreeBSD 6 branch. I made a benchmark with bind 9.3.2 (without threads support) and nsd 3.0.1 (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among FreeBSD 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386 systems. I used this simple zone file: Are you able to boot a 7.x kernel on this box? An as yet un-MFC'd optimization to the UDP send path is present in the 7.x kernel, suggested by ISC, which significantly improves threaded BIND9 performance. I've not benchmarked unthreaded BIND9 with the change. If you want to test specifically the before/after case for that change, you can find the reference to sosend_dgram in src/sys/netinet/udp_usrreq.c and swap it to sosend, which restores the old behavior. The other common optimization advice that you may already have received is to check which time counter FreeBSD has selected. Right now, 6.x/7.x err on the side of accurate over fast. There's been quite a bit of debate about this approach, and it's useful to investigate the issue. You can view and set the current choice by looking at the sysctl kern.timecounter.hardware, and you can see the choices on your hardware by looking at kern.timecounter.choice. Typically, TSC is the fastest, but may suffer from drift as the CPU changes speed (as a result of temperature, power saving, etc). Set it to TSC if it's not already TSC, and see what the effect is. As many event libraries read time stamps frequently to set up sleeping in user space, it can have a substantial performance impact. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS query performance
At 01:27 PM 9/13/2006, Robert Watson wrote: The other common optimization advice that you may already have received is to check which time counter FreeBSD has selected. Right now, 6.x/7.x err on the side of accurate over fast. There's been quite a bit of debate about this approach, and it's useful to investigate the issue. You can view and set the current choice by looking at the sysctl kern.timecounter.hardware, and you can see the choices on your hardware by looking at kern.timecounter.choice. Typically, TSC is the fastest, but may suffer from drift as the CPU changes Hi, How safe is TSC on SMP systems on RELENG_6 ? Do you still have to boot with kern.timecounter.smp_tsc="1" in /boot/loader.conf ? I was able to set it to TSC on my SMP box # sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: TSC kern.timecounter.nsetclock: 4 kern.timecounter.ngetmicrotime: 1710689523 kern.timecounter.ngetnanotime: 0 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetmicrouptime: 417696361 kern.timecounter.ngetnanouptime: 6622371 kern.timecounter.ngetbinuptime: 17943777 kern.timecounter.nmicrotime: 2454574760 kern.timecounter.nnanotime: 1315721638 kern.timecounter.nbintime: 3770262461 kern.timecounter.nmicrouptime: 407340 kern.timecounter.nnanouptime: 1397760 kern.timecounter.nbinuptime: 3787035688 kern.timecounter.stepwarnings: 0 kern.timecounter.smp_tsc: 0 But the console fills up with Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379728 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379758 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379789 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379819 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379849 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379879 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379910 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379940 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335379970 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380002 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380032 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380065 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380096 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380126 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380156 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380186 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380216 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380247 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380277 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380307 usec for pid 66442 (clamd) Sep 13 13:47:57 pumice1 kernel: calcru: runtime went backwards from 6336196518 usec to 6335380337 usec for pid 66442 (clamd) So I set things back to kern.timecounter.hardware: ACPI-fast ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bridge
Hi. According to man if_bridge one could filter L2-traffic with ipfw: From man if_bridge: ARP and REVARP packets are forwarded without being filtered and others that are not IP nor IPv6 packets are not forwarded when pfil_onlyip is enabled. IPFW can filter Ethernet types using mac-type so all packets are passed to the filter for processing. ARP is still forwarded though I have the following config: I have the following sysctl set: net.link.bridge.ipfw: 1 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.pfil_onlyip: 1 ipfw list: 65533 deny ip from any to any MAC any any 65534 deny ip from any to any layer2 65535 deny ip from any to any ifconfig: em0: flags=8943 mtu 1500 options=b inet6 fe80::204:23ff:febd:2342%em0 prefixlen 64 scopeid 0x1 ether 00:04:23:bd:23:42 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 mtu 1500 options=b ether 00:04:23:bd:23:43 media: Ethernet autoselect status: no carrier plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 vlan1000: flags=8843 mtu 1500 inet6 fe80::204:23ff:febd:2342%vlan1000 prefixlen 64 scopeid 0x5 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 ether 00:04:23:bd:23:42 media: Ethernet autoselect (100baseTX ) status: active vlan: 1000 parent interface: em0 vlan1001: flags=8943 mtu 1500 inet6 fe80::204:23ff:febd:2342%vlan1001 prefixlen 64 scopeid 0x6 ether 00:04:23:bd:23:42 media: Ethernet autoselect (100baseTX ) status: active vlan: 1001 parent interface: em0 vlan1002: flags=8943 mtu 1500 inet6 fe80::204:23ff:febd:2342%vlan1002 prefixlen 64 scopeid 0x7 ether 00:04:23:bd:23:42 media: Ethernet autoselect (100baseTX ) status: active vlan: 1002 parent interface: em0 bridge0: flags=8043 mtu 1500 ether ac:de:48:83:8d:c6 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: vlan1002 flags=3 member: vlan1001 flags=3 member: vlan10 flags=3 vlan10: flags=8943 mtu 1500 inet 10.1.1.1 netmask 0xff00 broadcast 10.1.1.255 inet6 fe80::204:23ff:febd:2342%vlan10 prefixlen 64 scopeid 0x9 ether 00:04:23:bd:23:42 media: Ethernet autoselect (100baseTX ) status: active vlan: 10 parent interface: em0 ARP-broadcast can still travel between member IFs in bridge0. Have I missed something here? Do I have to use bridge instead of if_bridge? /Jon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improved TCP syncookie implementation
Igor Sysoev wrote: On Sun, 3 Sep 2006, Andre Oppermann wrote: I've pretty much rewritten our implementation of TCP syncookies to get rid of some locking in TCP syncache and to improve their functionality. The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK optional feature information. This means that a FreeBSD host may run with syncookies only and not degrade TCP connections made through it. All important TCP connection setup negotiated options are preserved (send/receive window scaling, SACK, MSS) without storing any state on the host during the SYN-SYN/ACK phase. As a nice side effect the timestamps we respond with are randomized instead of directly using ticks (which reveals out uptime). As I understand syncache is used to retransmit SYN/ACK. What would be if 1) a client sent SYN, 2) we sent SYN/ACK with cookie, 3) the client sent ACK, but the ACK was lost If the client sent ACK it will retry again after the normal retransmit timeout. If our SYN-ACK back to client is lost we won't resend it with syncookies. The client then has to try again which is does after the syn retransmit timeout. The only brokeness with syncookies used to be that we would not be able to use RFC1323 features, most prominently window scaling. This would seriously affect throughput on todays links. The improved syncookies can carry all that information in the timestamp if present and thus get rid of the limitations of the original syncookie concept and implementation. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improved TCP syncookie implementation
On Wed, 13 Sep 2006, Andre Oppermann wrote: Igor Sysoev wrote: On Sun, 3 Sep 2006, Andre Oppermann wrote: I've pretty much rewritten our implementation of TCP syncookies to get rid of some locking in TCP syncache and to improve their functionality. The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK optional feature information. This means that a FreeBSD host may run with syncookies only and not degrade TCP connections made through it. All important TCP connection setup negotiated options are preserved (send/receive window scaling, SACK, MSS) without storing any state on the host during the SYN-SYN/ACK phase. As a nice side effect the timestamps we respond with are randomized instead of directly using ticks (which reveals out uptime). As I understand syncache is used to retransmit SYN/ACK. What would be if 1) a client sent SYN, 2) we sent SYN/ACK with cookie, 3) the client sent ACK, but the ACK was lost If the client sent ACK it will retry again after the normal retransmit timeout. Well, suppose protocol similar to SSH or SMTP: 1) the client calls connect(), it sends SYN; 2) the server receives SYN and sends SYN/ACK with cookie; 3) the client receives SYN/ACK and sends ACK; 4) the client returns successfully from connect() and calls read(); 5) the ACK is lost; 6) the server does not about this connection, so application can not accept() it, and it can not send() HELO message. 7) the client gets ETIMEDOUT from read(). Where in this sequence client may retransmit its ACK ? If our SYN-ACK back to client is lost we won't resend it with syncookies. The client then has to try again which is does after the syn retransmit timeout. Yes. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improved TCP syncookie implementation
Igor Sysoev wrote: On Wed, 13 Sep 2006, Andre Oppermann wrote: Igor Sysoev wrote: On Sun, 3 Sep 2006, Andre Oppermann wrote: I've pretty much rewritten our implementation of TCP syncookies to get rid of some locking in TCP syncache and to improve their functionality. The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK optional feature information. This means that a FreeBSD host may run with syncookies only and not degrade TCP connections made through it. All important TCP connection setup negotiated options are preserved (send/receive window scaling, SACK, MSS) without storing any state on the host during the SYN-SYN/ACK phase. As a nice side effect the timestamps we respond with are randomized instead of directly using ticks (which reveals out uptime). As I understand syncache is used to retransmit SYN/ACK. What would be if 1) a client sent SYN, 2) we sent SYN/ACK with cookie, 3) the client sent ACK, but the ACK was lost If the client sent ACK it will retry again after the normal retransmit timeout. Well, suppose protocol similar to SSH or SMTP: 1) the client calls connect(), it sends SYN; 2) the server receives SYN and sends SYN/ACK with cookie; 3) the client receives SYN/ACK and sends ACK; 4) the client returns successfully from connect() and calls read(); 5) the ACK is lost; 6) the server does not about this connection, so application can not accept() it, and it can not send() HELO message. 7) the client gets ETIMEDOUT from read(). Where in this sequence client may retransmit its ACK ? Never. You're correct. There is no data that would cause a retransmit if the application is waiting for a server prompt first. I shouldn't write wrong explanations when I'm tired, hungry and in between two tasks. ;) This problem is the reason why we don't switch entirely to syncookies and still keep syncache as is. If our SYN-ACK back to client is lost we won't resend it with syncookies. The client then has to try again which is does after the syn retransmit timeout. Yes. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limit arp on bridge
On Tue, Sep 12, 2006 at 05:04:12PM +0200, Jon Otterholm wrote:
> Hello.
>
> I am trying to limit arp-broadcast between member-IF on a bridge
> (if_bridge) with no luck.
>
> I have the following sysctls set:
>
> net.link.bridge.pfil_member: 1
> net.link.bridge.pfil_bridge: 1
> net.link.bridge.pfil_onlyip: 1
>
> I am using PF for filtering - do I have to use IPFW to limit
> arp-broadcast between memeber-ifs?
See this snippit of code from if_bridge
* (Note that since pfil doesn't understand ARP it will pass *ALL*
* ARP traffic.)
*/
switch (ether_type) {
case ETHERTYPE_ARP:
case ETHERTYPE_REVARP:
return (0); /* Automatically pass */
The only way that you will be able to filter ARP packets is by setting
pfil_onlyip=0, ipfw=1 and use the IPFW layer2 filtering.
cheers,
Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bridge
On Wed, Sep 13, 2006 at 08:19:41PM +0200, Jon Otterholm wrote:
> Hi.
>
> According to man if_bridge one could filter L2-traffic with ipfw:
>
> From man if_bridge:
> ARP and REVARP packets are forwarded without being filtered and others
> that are not IP nor IPv6 packets are not forwarded when pfil_onlyip is
> enabled. IPFW can filter Ethernet types using mac-type so all packets
> are passed to the filter for processing.
>
> ARP is still forwarded though I have the following config:
>
> I have the following sysctl set:
>
> net.link.bridge.ipfw: 1
> net.link.bridge.pfil_member: 1
> net.link.bridge.pfil_bridge: 1
> net.link.bridge.pfil_onlyip: 1
>
> ipfw list:
>
> 65533 deny ip from any to any MAC any any
> 65534 deny ip from any to any layer2
> 65535 deny ip from any to any
The check for ARP happens before the ipfw layer2 code so it isnt
currently possible to filter them.
switch (ether_type) {
case ETHERTYPE_ARP:
case ETHERTYPE_REVARP:
return (0); /* Automatically pass */
You are the second person in so many days to ask this, is it something
that should be changed?
Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bridge
Andrew, good day!
> The check for ARP happens before the ipfw layer2 code so it isnt
> currently possible to filter them.
>
> switch (ether_type) {
>case ETHERTYPE_ARP:
>case ETHERTYPE_REVARP:
>return (0); /* Automatically pass */
I am a bit confused because in the another thread (also created by
Jon Otterholm) you've answered that
-
The only way that you will be able to filter ARP packets is by setting
pfil_onlyip=0, ipfw=1 and use the IPFW layer2 filtering.
-
citing the same code. Am I understand something incorrectly or these
two answers do contradict with each other?
--
Eygene
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bridge
On Thu, Sep 14, 2006 at 08:38:02AM +0400, Eygene Ryabinkin wrote:
> Andrew, good day!
>
> > The check for ARP happens before the ipfw layer2 code so it isnt
> > currently possible to filter them.
> >
> > switch (ether_type) {
> > case ETHERTYPE_ARP:
> > case ETHERTYPE_REVARP:
> > return (0); /* Automatically pass */
> I am a bit confused because in the another thread (also created by
> Jon Otterholm) you've answered that
> -
> The only way that you will be able to filter ARP packets is by setting
> pfil_onlyip=0, ipfw=1 and use the IPFW layer2 filtering.
> -
> citing the same code. Am I understand something incorrectly or these
> two answers do contradict with each other?
Yes, thats just me being stupid :)
My first answer to Jon was not correct, you can not currently filter
ARP. I have attached a patch that should make this possible my
rearranging things.
Thanks for pointing it out.
Andrew
Index: if_bridge.c
===
RCS file: /home/ncvs/src/sys/net/if_bridge.c,v
retrieving revision 1.79
diff -u -p -r1.79 if_bridge.c
--- if_bridge.c 25 Aug 2006 20:11:56 - 1.79
+++ if_bridge.c 14 Sep 2006 04:38:50 -
@@ -490,11 +490,9 @@ sysctl_pfil_ipfw(SYSCTL_HANDLER_ARGS)
/*
* Disable pfil so that ipfw doesnt run twice, if the user
* really wants both then they can re-enable pfil_bridge and/or
-* pfil_member. Also allow non-ip packets as ipfw can filter by
-* layer2 type.
+* pfil_member.
*/
if (pfil_ipfw) {
- pfil_onlyip = 0;
pfil_bridge = 0;
pfil_member = 0;
}
@@ -2736,34 +2734,6 @@ bridge_pfil(struct mbuf **mp, struct ifn
}
}
- /*
-* If we're trying to filter bridge traffic, don't look at anything
-* other than IP and ARP traffic. If the filter doesn't understand
-* IPv6, don't allow IPv6 through the bridge either. This is lame
-* since if we really wanted, say, an AppleTalk filter, we are hosed,
-* but of course we don't have an AppleTalk filter to begin with.
-* (Note that since pfil doesn't understand ARP it will pass *ALL*
-* ARP traffic.)
-*/
- switch (ether_type) {
- case ETHERTYPE_ARP:
- case ETHERTYPE_REVARP:
- return (0); /* Automatically pass */
- case ETHERTYPE_IP:
-#ifdef INET6
- case ETHERTYPE_IPV6:
-#endif /* INET6 */
- break;
- default:
- /*
-* Check to see if the user wants to pass non-ip
-* packets, these will not be checked by pfil(9) and
-* passed unconditionally so the default is to drop.
-*/
- if (pfil_onlyip)
- goto bad;
- }
-
/* Strip off the Ethernet header and keep a copy. */
m_copydata(*mp, 0, ETHER_HDR_LEN, (caddr_t) &eh2);
m_adj(*mp, ETHER_HDR_LEN);
@@ -2836,9 +2806,14 @@ ipfwpass:
error = 0;
/*
-* Run the packet through pfil
+* Run the packet through pfil. (Note that since pfil doesn't understand
+* ARP it will pass *ALL* ARP traffic.)
*/
switch (ether_type) {
+ case ETHERTYPE_ARP:
+ case ETHERTYPE_REVARP:
+ return (0); /* Automatically pass */
+
case ETHERTYPE_IP:
/*
* before calling the firewall, swap fields the same as
@@ -2930,7 +2905,14 @@ ipfwpass:
break;
#endif
default:
- error = 0;
+ /*
+* Check to see if the user wants to pass non-ip
+* packets.
+*/
+ if (pfil_onlyip) {
+ error = -1;
+ goto bad;
+ }
break;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Reading a configuration file from a driver code during intialization.
Hi all, For our driver we have following requirement. We have a configuration file that will be updated by the user and while loading the driver, the initialization code should read the configuration file to get the value and use it in the driver code. Is there is any way to read a configuration file from driver code? Currently I have written a small kernel module that will create a sysctl variable and update with a default value. After loading this module, using shell scripts, I read the configuration file and get the user set values and update the sysctl variable in that value. Then I will load my driver where I read the sysctl variable to get the required values set by the user in the configuration file. Is there is any other solution to the above problem? Actually I am looking for some thing similar to Module loadable parameters in the Linux Device Driver. Thanks, ~Siva The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
