msk gigabit NIC missed interrupts and watchdog timeouts
Hello, I am testing FreeBSD-8_STABLE updated as of a few minutes ago along with a msk type NIC. Having trouble with missed TX interrupts and watchdog timeouts. Tested http://svn.freebsd.org/changeset/base/205161 which made the NIC a little more stable but it finally exhibited the same issues after 10 minutes of load vs 1 minute. Does anyone have any suggestions on things that I can do to make this NIC more robust? pciconf -l shows: ms...@pci0:2:0:0: class=0x02 card=0x34588086 chip=0x436111ab rev=0x18 hdr=0x00 dmesg -a | grep msk shows: mskc0: Marvell Yukon 88E8050 Gigabit Ethernet port 0xc800-0xc8ff mem 0xdedfc000-0xdedf irq 16 at device 0.0 on pci2 msk0: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02 on mskc0 msk0: Ethernet address: 00:0e:0c:a4:54:ad miibus0: MII bus on msk0 mskc0: [FILTER] Thanks in advance for any pointers, etc Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: msk gigabit NIC missed interrupts and watchdog timeouts
On Wed, Mar 17, 2010 at 11:36 AM, Pyun YongHyeon pyu...@gmail.com wrote: Would you try latest msk(4) in HEAD? I think you can download if_msk.c and if_mskreg.h from HEAD and can build it on stable/8. Due to added interface capabilities you have to add the following code in the beginning of if_msk.c to build it on stable/8. #ifndef IFCAP_VLAN_HWTSO #define IFCAP_VLAN_HWTSO 0 #endif No problem. Just compiled a kernel containing the newest files. Also show me the output of devinfo -rv | grep phy. nas2# devinfo -rv | grep ph e1000phy0 pnpinfo oui=0x5043 model=0xc rev=0x2 at phyno=0 I am now testing the new kernel and it has been under load for quite a while. I shifted 2+ gigabytes through it and it seems OK now. Thanks for the help !! Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible scheduler (SCHED_ULE) bug?
On Fri, Oct 23, 2009 at 2:46 PM, Jaime Bozza jbo...@mindsites.com wrote: I believe I found a problem with the ULE scheduler - At least the fact that there is a problem, but I'm not sure where to go from here. The system locks all processes, but doesn't panic, so I have no output to give. I was able to duplicate this on three different machines and solved it by switching to the scheduler to 4BSD. Here's the environment: FreeBSD 7.2 i386, installed from bootonly ISO, Custom install, minimal, no other changes other than setting timezone, changing root password, and turning on sshd (allowing root and password connection). Running portsnap (fetch, then extract) to get latest ports tree. From ports, make installs of lang/php5 and www/lighttpd, using defaults for all ports installed. Modified lighttpd.conf for PHP (attached diff), created a short script called uploadfile.php (attached). File was installed at /usr/local/www/data/uploadfile.php Start lighttpd (lighttpd_enable=YES in rc.conf, /usr/local/etc/rc.d/lighttpd start), connect and run script. As long as I upload a file less than 64K, everything works fine. If I try to upload something larger than 64K, system no longer responds. Console prompt at login will allow me to enter username/password, but nothing happens after that. Console prompt logged in will allow me to type a single line, but if I press enter, nothing after that. No errors get written anywhere - console, logs, etc. I'm at a loss of what to do next. Can anyone give me ideas of what else I can do? Try adding this or changing these items in lighttpd.conf: ## FreeBSD! server.event-handler= freebsd-kqueue server.network-backend = writev Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: I need to add commands that starts every time at system boot.
On Sun, Jun 7, 2009 at 3:36 PM, Chris Reesutis...@googlemail.com wrote: 2009/6/7 Clifton Royston clift...@lava.net: If you feel you just *can't* do it via a script in /usr/local/etc/rc.d, which is the better way, add a script called /etc/rc.local and that will be run after all the other start-up steps. What's wrong with rc.local? Probably stems from this discussion: http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html Cheers Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFC: side effects of fixing loader_conf_files handling
On Wed, Jan 21, 2009 at 4:39 PM, Andrew Thompson thom...@freebsd.org wrote: That sounds good, thanks for working on this. Hi All, With this change it seems that if /boot/loader.conf is not present the loader stops altogether at |. Was that the desired effect of these changes? It is not a big deal for me to touch the files during build but wanted to make sure that this was the desired effect. Thanks Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: carpX: incorrect hash with IP aliases
On Tue, Mar 3, 2009 at 12:52 PM, Max Laier m...@love2party.net wrote: [snip] Make sure that you are configuring the same aliases with the same netmasks on all members of the carp group - preferably before bringing the interface up for the first time (though it should properly recalculate the hashes as you add aliases). As you seem to be using pfsense you might want to check with them to make sure they have the fix in their build - though I recall it was a joined effort back then. 1.2.3 is based on 7.1 so this patch should be in the base system now. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: php-cgi frozen with sbwait when SMP enable
On Tue, Nov 25, 2008 at 6:40 AM, Ken Chen [EMAIL PROTECTED] wrote: Change to configuration to solve this problem: #server.network-backend = freebsd-sendfile server.network-backend = writev http://redmine.lighttpd.net/boards/2/topics/show/141 Maybe this patch is related? http://redmine.lighttpd.net/issues/show/1813 Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any idea when a bind update will be forthcoming?
On Thu, Jul 10, 2008 at 12:09 PM, Paul Schmehl [EMAIL PROTECTED] wrote: Given the serious nature of the vulnerability, I'm sure this is at the top of someone's list. Do we have a scheduled release date yet? See the thread BIND update?. Scott PS: please do not crosspost. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem compiling RELENG_6
On Nov 18, 2007 4:59 PM, Michael Eubanks [EMAIL PROTECTED] wrote: I've CVSup'd my RELENG_6 source and tried a make buildworld. Compilation breaks with the following error: === sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 I noticed there was another post with this same problem at http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-11/msg00203.htm l, although, I'm curious if there is a fix? You most likely cvsupped in the middle of Darren Reeds forgotten Makefile commit. It should be commited now if you want to try cvsupping and building again. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seems like pf skips some packets.
On 7/12/07, Alexey Sopov [EMAIL PROTECTED] wrote:
Hi
On my machine with FreeBSD 6.2-STABLE #4 I noticed there are
outgoing packets from net 192.168.0.0/16 on external interface
Some details:
Here 1 a,b,c,d,e,f 254
~ ifconfig internal
internal: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=4bRXCSUM,TXCSUM,VLAN_MTU,POLLING
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
ether 00:04:23:b0:53:ca
media: Ethernet autoselect (1000baseTX full-duplex)
status: active
~ ifconfig external
external: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=48VLAN_MTU,POLLING
inet a.b.c.22 netmask 0xfffc broadcast a.b.c.23
ether 00:02:b3:4c:83:6e
media: Ethernet autoselect (100baseTX full-duplex)
status: active
~ grep -v '^#' /etc/pf.conf | grep mynet
table mynet { 192.168.0.0/16, 172.16.0.0/16 }
~ sudo pfctl -s a | less
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on external inet from mynet to ! mynet - a.b.d.240/28 bitmask
rdr on external inet proto tcp from any to a.b.e.1 port = ftp - 192.168.0.2
port 21
rdr on external inet proto udp from any to a.b.e.1 port = 4127 - 192.168.0.2
port 4127
rdr on external inet proto tcp from any to a.b.e.1 port = 4899 - 192.168.0.2
port 4899
rdr on external inet proto tcp from any to a.b.c.22 port = 4022 - 172.16.56.57
port 22
FILTER RULES:
pass in all
pass out all
pass out quick on external inet from a.b.c.20/30 to any
pass out quick on external inet from a.b.d.224/27 to any
pass out quick on external inet from a.b.e.0/24 to any
block drop out on external all
STATES:
#a lot of states
INFO:
Status: Enabled for 0 days 11:06:40 Debug: Urgent
Hostid: 0x2055eb8b
State Table Total Rate
current entries 4182
searches 250779576 6269.5/s
inserts 1877065 46.9/s
removals 1872883 46.8/s
Counters
match 165990128 4149.8/s
bad-offset 00.0/s
fragment 150.0/s
short 20.0/s
normalize 00.0/s
memory 00.0/s
bad-timestamp 00.0/s
congestion 00.0/s
ip-option 45500.1/s
proto-cksum00.0/s
state-mismatch 62330.2/s
state-insert 00.0/s
state-limit00.0/s
src-limit 00.0/s
synproxy 00.0/s
TIMEOUTS:
tcp.first30s
tcp.opening 5s
tcp.established 18000s
tcp.closing 60s
tcp.finwait 30s
tcp.closed 30s
tcp.tsdiff 10s
udp.first60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 5s
interval 2s
adaptive.start0 states
adaptive.end 0 states
src.track 0s
LIMITS:
states hard limit 5
src-nodes hard limit 3
frags hard limit 5
TABLES:
mynet
OS FINGERPRINTS:
348 fingerprints loaded
Here I try to catch packets on external interface:
~ sudo tcpdump -ni external src net 192.168.0.0/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on external, link-type EN10MB (Ethernet), capture size 96 bytes
12:59:44.401906 IP 192.168.56.152.1090 64.12.31.180.5190: . ack 1528988903
win 0
12:59:44.401921 IP 192.168.12.43.60481 81.19.88.11.80: . ack 2815867423 win 0
12:59:44.401933 IP 192.168.46.101.1650 81.176.76.116.80: . ack 669974985 win 0
12:59:44.401946 IP 192.168.54.12.2124 194.145.212.35.80: . ack 2208596276 win 0
12:59:44.401958 IP 192.168.22.10.1510 194.67.45.129.80: . ack 1166126606 win 0
12:59:44.401971 IP 192.168.46.101.1652 81.19.80.2.80: . ack 1004425830 win 0
12:59:44.401983 IP 192.168.38.79.63441 66.102.11.164.80: . ack 1120457487 win 0
12:59:44.401995 IP 192.168.54.71.1578 87.248.217.79.80: . ack 2473371997 win 0
12:59:44.402022 IP 192.168.38.49.4183 65.54.195.188.80: . ack 964472648 win 0
12:59:44.402041 IP 192.168.42.90.60363 66.249.93.91.80: . ack 2862783680 win 0
12:59:44.402055 IP 192.168.46.46.58867 89.188.102.70.80: . ack 2523375288 win 0
12:59:44.402075 IP
Re: question about CARP
On 5/16/07, Marko Lerota [EMAIL PROTECTED] wrote: In handbook at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/carp.html is written that two machines should have different VHIDs. But man page of carp says VHIDs should be the same. Which is wright configuration? From handbook or from man page? 6.2-RELEASE-p4 Each shared CARP IP should have the same VHID. The example in the handbook lists two CARP IP addresses. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD spamd port update coming?
On 4/16/07, Charles Sprickman [EMAIL PROTECTED] wrote: On Mon, 16 Apr 2007, Jonathan Stewart wrote: Does anyone know of any work towards updating the spamd port to the latest version? The makefile shows version 3.7 and OpenBSD is up to 4.1 now. I'm looking at setting it up so helping test would not be a problem for me. There's an unofficial port floating around out there that I'm using. I don't have the URL handy, but I think it's a 3.9 version. It's new enough to support the auto-whitelisting functions in spamlogd. I don't recall what the reason was, but apparently the patches were rejected or perhaps there just isn't an active maintainer anymore. It does work well though... Looks like there is a 4.1 version floating around: http://developer.berlios.de/projects/freebsdspamd/ Please note that I have not tested this personally. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Nexcom 1086 - Marvell Chipsets - Nics show in dmesg but do not show up in ifconfig
Hello, I am currently working with a Nexcom 1086 that features 2 Marvell chipsets with 8 total nics. This device is slated to become a FreeBSD/pfSense router. During probing, all nics show up okay sk0-sk3 and skc-0-3 but the skc nics do not show up in ifconfig. Is there something that I am overlooking to enable the nics? DMESG -a is located here: http://www.pfsense.com/~sullrich/nexcom_1086_dmesg.txt Thanks in advance! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nexcom 1086 - Marvell Chipsets - Nics show in dmesg but do not show up in ifconfig
Nevermind, I found http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html Now the nics are working. Thanks anyways! Scott On 1/16/07, Scott Ullrich [EMAIL PROTECTED] wrote: Hello, I am currently working with a Nexcom 1086 that features 2 Marvell chipsets with 8 total nics. This device is slated to become a FreeBSD/pfSense router. During probing, all nics show up okay sk0-sk3 and skc-0-3 but the skc nics do not show up in ifconfig. Is there something that I am overlooking to enable the nics? DMESG -a is located here: http://www.pfsense.com/~sullrich/nexcom_1086_dmesg.txt Thanks in advance! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Oh, I did not realise this use. Hmm...still, I thought that this is what tables are for :) Yep, thats another usage for tables. But tables have not been around for very long either. Considering that I have used IPFW since FreeBSD version 2 or something or another these fancy features have not always been around :) Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate IPFW rules
On 12/21/06, Václav Haisman [EMAIL PROTECTED] wrote: Huh, really? How is it useful? Please, explain. One example feature is to be able to delete many rules at once. If you know that a specific rule number holds rules (example: time based rules) then the script has less work to do. Now granted since sets where introduced this can be done via this method but this feature has been useful (at least to me) for years and years now. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic while starting OpenNTPD
Sources from today, right before the compile. I have paused the virtual machine if someone would like me to issue further db commands. Thanks, Scott FreeBSD 6.2-PRERELEASE #0: Sat Nov 11 02:47:35 UTC 2006 [EMAIL PROTECTED]:/usr/obj.pfSense/usr/src/sys/pfSense_Dev.6 lock order reversal: (sleepable after non-sleepable) 1st 0xc0a57000 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf.c:6406 2nd 0xc0a787e4 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: kdb_backtrace(0,,c0b59f08,c0b5b740,c0a03b2c,...) at kdb_backtrace+0x29 witness_checkorder(c0a787e4,9,c09a1f59,c02) at witness_checkorder+0x578 _sx_xlock(c0a787e4,c09a1f59,c02) at _sx_xlock+0x50 _vm_map_lock_read(c0a787a0,c09a1f59,c02,18e17c0,c25846b0,...) at _vm_map_lock_read+0x37 vm_map_lookup(cc1c4a4c,0,1,cc1c4a50,cc1c4a40,cc1c4a44,cc1c4a27,cc1c4a28) atvm_m ap_lookup+0x28 vm_fault(c0a787a0,0,1,0,c2585a80,...) at vm_fault+0x66 trap(cc1c4b14,0,104) at trap+0x65e trap(8,28,28,c27432c4,c26aee00,...) at trap+0x341 alltraps(1,c274e400,cc1c4c5c,0,0) at alltraps+0x1a pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 ip_input(c2743200) at ip_input+0x274 netisr_unregister(c0b99f78) at netisr_unregister+0x11e netisr_queue(0) at netisr_queue+0x146 ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at ithread_destroy+0x21b fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0489090 stack pointer = 0x28:0xcc1c4b54 frame pointer = 0x28:0xcc1c4c1c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 13 (swi1: net) [thread pid 13 tid 13 ] Stopped at pf_test+0x968: cmpl$0,0x104(%eax) db bt Tracing pid 13 tid 13 td 0xc2585a80 pf_test(1,c274e400,cc1c4c5c,0,0) at pf_test+0x968 pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 ip_input(c2743200) at ip_input+0x274 netisr_unregister(c0b99f78) at netisr_unregister+0x11e netisr_queue(0) at netisr_queue+0x146 ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at ithread_destroy+0x21b fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- db Tracing pid 13 tid 13 td 0xc2585a80 pf_test(1,c274e400,cc1c4c5c,0,0) at pf_test+0x968 pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 ip_input(c2743200) at ip_input+0x274 netisr_unregister(c0b99f78) at netisr_unregister+0x11e netisr_queue(0) at netisr_queue+0x146 ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at ithread_destroy+0x21b fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- db ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Userland freezes during heavy packet forwarding workloads
Hello! We (pfSense developers) have noticed an interesting problem where userland stops functioning under high packet forwarding workloads. Userland applications such as sshd and lighttpd freeze but userland resumes after the network load eases. We tested with both PF enabled and disabled and the problem remains in either case so chances are that its not a firewalling / pfil issue. Machines tested so far: PC Engines WRAP 266 mhz, 3 sis nics Soekris Engineering 4801 266 mhz, 3 sis nics AMD K6-2 450MHZ, 384 MB ram, 5 XL nics (3c905c) FreeBSD versions tested and are affected: FreeBSD 6.1-RELEASE as of October 10th, 2006 FreeBSD 6.2-PRERELEASE as of October 10th, 2006 FreeBSD versions tested and are not affected: FreeBSD 4.11-RELEASE Kernel configuration file: [http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense_wrap.6?rev=1.36;content-type=text%2Fplain] Copy of /etc/sysctl.conf in use: [http://www.pfsense.com/~sullrich/logs/sysctl.conf] Is there anything we can do to prevent userland from stopping completely when under heavy load? Is this a bug? Unfortunately, I cannot reproduce this behavior in FreeBSD 4.X. Thanks in advance! Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Userland freezes during heavy packet forwarding workloads
On 10/12/06, Chuck Swiger [EMAIL PROTECTED] wrote: On Oct 12, 2006, at 2:11 PM, Scott Ullrich wrote: We (pfSense developers) have noticed an interesting problem where userland stops functioning under high packet forwarding workloads. Userland applications such as sshd and lighttpd freeze but userland resumes after the network load eases. [ ...note that the links you posted included the trailing square bracket, and thus were broken, although easily fixable by hand... ] Yes, this is to prevent breakage of the URLs in many common mailers. Is there anything we can do to prevent userland from stopping completely when under heavy load? Is this a bug? You're probably experiencing some form of livelock; your hardware isn't horribly fast, and if the NICs are generating interrupts rapidly enough due to the high rate of packet forwarding, you're not going to have a lot of spare CPU available to run userland tasks. I notice you're compiling in support for DEVICE_POLLING; does enabling it do anything to help the responsiveness of the userland tasks under high network load? You might try adjusting HZ from 100 to 250 or so...I found that made a decent tradeoff between packet delay and scheduler overhead on similar Soerkis 4801 or VIA C3/EPIA-M hardware to yours. We are not interested in polling, it is not the answer to the problem at hand.4.X does not require polling to keep userland available during these workloads. Why should 6.X require this? I understand where you are going with this but we are somewhat interested in helping get FreeBSD back on track, not to introduce workarounds. Thanks for your response. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Userland freezes during heavy packet forwarding workloads
On 10/12/06, Chuck Swiger [EMAIL PROTECTED] wrote: On Oct 12, 2006, at 2:11 PM, Scott Ullrich wrote: We (pfSense developers) have noticed an interesting problem where userland stops functioning under high packet forwarding workloads. Userland applications such as sshd and lighttpd freeze but userland resumes after the network load eases. [ ...note that the links you posted included the trailing square bracket, and thus were broken, although easily fixable by hand... ] Is there anything we can do to prevent userland from stopping completely when under heavy load? Is this a bug? You're probably experiencing some form of livelock; your hardware isn't horribly fast, and if the NICs are generating interrupts rapidly enough due to the high rate of packet forwarding, you're not going to have a lot of spare CPU available to run userland tasks. I notice you're compiling in support for DEVICE_POLLING; does enabling it do anything to help the responsiveness of the userland tasks under high network load? You might try adjusting HZ from 100 to 250 or so...I found that made a decent tradeoff between packet delay and scheduler overhead on similar Soerkis 4801 or VIA C3/EPIA-M hardware to yours. When polling is enabled, userland does indeed stay responsive, but throughput also drops by 25-35% in testing on a Soekris 4801, 266 MHz. Again, this is not the case with 4.x. These slower boxes actually get as much as 20% faster with polling in 4.x, not slower as it does in 6.x. And with or without polling, userland always stays responsive (albeit much slower, of course) on 4.x when under much higher pps load. At this time, we're not sure if this same problem exists in 5.x, but if anyone thinks that information might be useful, we can test that as well. Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I thought I had waited until a patch was issued for the SHA256 issue...
On 10/10/06, Joe Altman [EMAIL PROTECTED] wrote: to update world...I was it was recently committed, and ran an update at approximately 10 AM EDT. Here is where 'make buildworld' stopped: cc -pg -O -pipe -march=pentiumpro -I/usr/src/secure/lib/libssh/../../../crypto/openssh -include ssh_namespace.h -c /usr/src/secure/lib/libssh/../../../crypto/openssh/openbsd-compat/xmmap.c -o xmmap.po cc -pg -O -pipe -march=pentiumpro -I/usr/src/secure/lib/libssh/../../../crypto/openssh -include ssh_namespace.h -c /usr/src/secure/lib/libssh/../../../crypto/openssh/version.c -o version.po building profiled ssh library ranlib libssh_p.a === secure/libexec (all) === secure/libexec/sftp-server (all) cc -O -pipe -march=pentiumpro -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -c /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server.c cc -O -pipe -march=pentiumpro -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -c /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-common.c cc -O -pipe -march=pentiumpro -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -o sftp-server sftp-server.o sftp-common.o -lssh -lcrypt -lcrypto -lz /usr/obj/usr/src/tmp/usr/lib/libssh.so: undefined reference to `SHA256_Update' /usr/obj/usr/src/tmp/usr/lib/libssh.so: undefined reference to `SHA256_Final' /usr/obj/usr/src/tmp/usr/lib/libssh.so: undefined reference to `SHA256_Init' *** Error code 1 Stop in /usr/src/secure/libexec/sftp-server. *** Error code 1 Stop in /usr/src/secure/libexec. *** Error code 1 Stop in /usr/src/secure. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. And yes, I do have NO_KERBEROS= true in make.conf, if that matters. uname -a: FreeBSD chthonic 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Fri Sep 15 23:56:36 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHTHONIC i386 Please post your /etc/make.conf file. It sounds like you have -static enabled. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start from
On 6/28/06, Mihir Sanghavi [EMAIL PROTECTED] wrote: Hi, I have installed FreeBSD 5.5 . My computer is still not hooked to the network. I would like to start working on it. what should I start with as I have never worked with BSD before. are there any good tutorials to start with? FreeBSD has excellent documentation located at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ Also visit http://www.freebsddiary.org/ Good luck! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: trying to sleep while sleeping is prohibited - USB network panic after ifconfig
Sleeping on usbsyn with the following non-sleepable locks held: exclusive sleep mutex in_multi_mtx r = 0 (0xc0acfbc0) locked @ /usr/src/sys/neti net/in.c:971 KDB: stack backtrace: kdb_backtrace(1,c27e5418,c27e7000,1,ccfe3a50) at kdb_backtrace+0x29 witness_warn(5,0,c0993d00,c09846cb) at witness_warn+0x18e msleep(c27ffb00,0,4c,c09846cb,0) at msleep+0x42 usbd_transfer(c27ffb00,ccfe3ab0,c0649b2d,c27ffb00,c24a1580) at usbd_transfer+0x1 21 usbd_sync_transfer(c27ffb00,c24a1580,ccfe3acc,c06c6ea4,c25d0a00) at usbd_sync_tr ansfer+0x11 usbd_do_request_flags_pipe(c257d600,c257d280,ccfe3b0c,ccfe3b0b,0) at usbd_do_req uest_flags_pipe+0x5d usbd_do_request_flags(c257d600,ccfe3b0c,ccfe3b0b,0,0) at usbd_do_request_flags+0 x20 usbd_do_request(c257d600,ccfe3b0c,ccfe3b0b) at usbd_do_request+0x1a aue_csr_read_1(c25d0a00,0) at aue_csr_read_1+0x50 aue_setmulti(c25d0a00,c280e280,c25d3000,ccfe3ba8,ccfe3b78) at aue_setmulti+0x4a aue_ioctl(c25d3000,80206931,0) at aue_ioctl+0x106 if_addmulti(c25d3000,ccfe3ba8,ccfe3ba4,ccfe3ba8,10,c0acfbc0,0,c09a3cd4,3cb) at i f_addmulti+0x1b8 in_addmulti(ccfe3bdc,c25d3000) at in_addmulti+0x69 in_ifinit(c25d3000,c27da500,c262dcd0,0,ccfe3c38) at in_ifinit+0x529 in_control(c28206f4,8040691a,c262dcc0,c25d3000,c27e7000) at in_control+0x882 ifioctl(c28206f4,8040691a,c262dcc0,c27e7000,0) at ifioctl+0x198 soo_ioctl(c2678c60,8040691a,c262dcc0,c2480780,c27e7000) at soo_ioctl+0x2db ioctl(c27e7000,ccfe3d04,3,2,286) at ioctl+0x370 syscall(3b,3b,3b,8056080,80583c0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28131603, esp = 0xbfbfe59c, ebp = 0xbfbfede8 --- panic: trying to sleep while sleeping is prohibited cpuid = 0 KDB: enter: panic [thread pid 13 tid 13 ] Stopped at kdb_enter+0x2b: nop More information (bt, bt all, show alllocks) can be found at http://www.pfsense.com/~sullrich/panics/usb_network_nic_panic.txt Let me know if you need any more information. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 2.2.9 Released
On 4/1/06, Silves [EMAIL PROTECTED] wrote: I have just one curious question, why is FreeBSD 2.2.x still being developed ? The same reason Slashdot is now in purple with the OMG Ponies!!! theme. This is maybe a stupid question, but i am only curious to know why ? Is there any special reason for this ? Check the date. :) Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic with 5.4-RELEASE when typing on console?
Hi,
I cvsupped a bit ago and now when I type on the console I get a panic:
[EMAIL PROTECTED] kgdb kernel.debug vmcore.57
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
#0 doadump () at pcpu.h:159
159 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) backtrace
#0 doadump () at pcpu.h:159
#1 0xc066e6b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2 0xc066ea0d in panic (fmt=0xc08d2844 from debugger)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc049d23d in db_panic (addr=174, have_addr=0, count=-1,
modif=0xc7291ad0 ) at /usr/src/sys/ddb/db_command.c:435
#4 0xc049d1d4 in db_command (last_cmdp=0xc09b6b24, cmd_table=0x0,
aux_cmd_tablep=0xc092b7fc, aux_cmd_tablep_end=0xc092b818)
at /usr/src/sys/ddb/db_command.c:349
#5 0xc049d29c in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#6 0xc049ee35 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221
#7 0xc068661f in kdb_trap (type=12, code=0, tf=0x1)
at /usr/src/sys/kern/subr_kdb.c:468
#8 0xc0885b19 in trap_fatal (frame=0xc7291c64, eva=174)
at /usr/src/sys/i386/i386/trap.c:812
#9 0xc0885877 in trap_pfault (frame=0xc7291c64, usermode=0, eva=174)
at /usr/src/sys/i386/i386/trap.c:735
#10 0xc088546d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 13, tf_esi =
-1063218240, tf_ebp = -953606976, tf_isp = -953607024, tf_ebx =
-1056298496, tf_edx = -1066811620, tf_ecx = -1063473756, tf_eax = 13,
tf_trapno = 12, tf_err = 0, tf_eip = 174, tf_cs = 8, tf_eflags =
66050, tf_esp = -1064933159, tf_ss = 13})
at /usr/src/sys/i386/i386/trap.c:425
---Type return to continue, or q return to quit---
#11 0xc08732da in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#12 0x0018 in ?? ()
#13 0x0010 in ?? ()
#14 0x0010 in ?? ()
#15 0x000d in ?? ()
#16 0xc0a093c0 in sc_devclass ()
#17 0xc7291cc0 in ?? ()
#18 0xc7291c90 in ?? ()
#19 0xc10a2a00 in ?? ()
#20 0xc069bf1c in ttylclose () at /usr/src/sys/kern/tty.c:1567
#21 0xc0856b18 in atkbd_intr (kbd=0xc0a093c0, arg=0x0)
at /usr/src/sys/dev/kbd/atkbd.c:461
#22 0xc088fc2a in atkbd_isa_intr (arg=0x0) at /usr/src/sys/isa/atkbd_isa.c:177
#23 0xc065a069 in ithread_loop (arg=0xc0edee80)
at /usr/src/sys/kern/kern_intr.c:547
#24 0xc0659105 in fork_exit (callout=0xc0659f10 ithread_loop,
arg=0xc0edee80, frame=0xc7291d48) at /usr/src/sys/kern/kern_fork.c:791
#25 0xc087333c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
(kgdb)
Has anyone seen this problem or could this be something on my end?
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with 5.4-RELEASE when typing on console?
On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Could that be related to the recent heads up?
HEADS-UP: Problem with RELENG_5{_4}
I think it is. Hopefully my backtrace can help.
Sorry for the false alarm since its known about.
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IPsec packets seen on wrong interface by ipfw (was Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?)
Guido, I am using a tunneling device (gif0). How are we supposed to fix the issue with your patch installed? If we need to add more rules, that's fine but what would these rules be? Are they before the divert? After the divert, etc? Is there a bug in ipfw? Either way, these changes should be noted in UPDATING since there are most likely a lot more people out there using gif tunnels. Thanks, Scott PS: I tried allowing the gif device rules (before and after the divert), allowing the internal addresses (before and after the divert rules) to no avail with your patch installed. -Original Message- From: Guido van Rooij [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 1:56 PM To: David Kelly Cc: Scott Ullrich; 'Archie Cobbs'; '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: Re: IPsec packets seen on wrong interface by ipfw (was Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?) On Tue, Nov 19, 2002 at 10:11:29AM -0600, David Kelly wrote: Once the ipsec history is removed from the packet then how/what/where is the packet tagged as having come from? In my case it appears to have It is tagged as any other packet. retained properties of the ESP packet it was encased within. Don't really know as I don't have multiple interfaces with ESP packets. The system is in production so I can't casually swap interfaces to verify. At some point since early October when this system was previously updated these IPsec packets started appearing on the wrong interface in ipfw. Currently only one end of my link is updated, the other end is running with the same configuration it has used for the past 9 months. With configured (but apparently unused) gif and everything. What do you mean with wrong interface? What I did was remove the ipsec history check in ip_input(). What happens in you case is that ip packet come in, are fed into ipfw, then they are decrypted in esp_input() and then fed into the ip subprotocol directly from esp_input(). The code I removed only appears in the first call to ip_input(), but the code would not have any effect in that case. The only way that this removal could have an effect is when esp_input() called xxx_input() which in turn calls ip_input() again. Since you are not using a tunneling device, this does not happen. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: IPsec packets seen on wrong interface by ipfw (was Re: IPsec/ gif VPN tunnel packets on wrong NIC in ipfw?)
I need the divert rule for NATD. -Scott -Original Message- From: Guido van Rooij [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 2:24 PM To: Scott Ullrich Cc: David Kelly; 'Archie Cobbs'; '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: Re: IPsec packets seen on wrong interface by ipfw (was Re: IPsec/ gif VPN tunnel packets on wrong NIC in ipfw?) On Tue, Nov 19, 2002 at 02:08:54PM -0500, Scott Ullrich wrote: Guido, I am using a tunneling device (gif0). How are we supposed to fix the issue with your patch installed? If we need to add more rules, that's fine but what would these rules be? Are they before the divert? After the divert, etc? What divert? There should not be a need for a divert. If you have a gif tunnel for ESP (like I described in a mail I just sent): Let's examine the following situation: interfaces: fxp0, gif0 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280 tunnel inet 192.168.100.1 -- 192.168.100.2 inet 10.0.0.1 -- 10.0.1.1 netmask 0xff00 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255 Then suppose I have ESP betwee 10.0.0.1 and 10.0.1.1. Then you should have rules allowing IPSECed packets in and out of fxp0, rules allowing UDP traffic on port 500 in and out (ISAKMP) and rules in and out from the gif device for the unecrypted packets. You can use tcpdump to see what is on which interface. Let me state that I am not an ipfw developer. But if tcpdump shows a packet coming in or going out an interface, thehn ipfw should be able to filter that packet _on that interface_. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?
I have reverted back to revision 1.130.2.39 of ip_input.c and that solved my issues! Guido, I am running IPFW2. If there is anything you need from me to help fix this issue, please let me know. Thanks again Archie for giving me the pointers of which file to revert. -Scott -Original Message- From: Archie Cobbs [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 17, 2002 2:56 PM To: Scott Ullrich Cc: '[EMAIL PROTECTED]'; David Kelly; [EMAIL PROTECTED] Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Scott Ullrich wrote: I am also having this same problem. If I revert back to 4.7 RELEASE the problem goes away. Anyone have an idea of what changed the default behavior between 4.7 RELEASE and STABLE or if there is a better workaround other than adding a rule before the divert statement allowing the internal networks to talk? Try reverting rev. 1.130.2.40 of netinet/ip_input.c (there may be other files in this commit; didn't look (you could do it by time)). This is just a guess because it seems like it might be relevant. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c?only_with_t ag=RELENG_4 -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?
I am also having this same problem. If I revert back to 4.7 RELEASE the
problem goes away.
Anyone have an idea of what changed the default behavior between 4.7 RELEASE
and STABLE or if there is a better workaround other than adding a rule
before the divert statement allowing the internal networks to talk?
Thanks,
Scott
-Original Message-
From: Greg Panula [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 15, 2002 10:47 AM
To: David Kelly
Cc: [EMAIL PROTECTED]
Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?
David Kelly wrote:
On Fri, Nov 15, 2002 at 07:21:21AM -0600, Greg Panula wrote:
If you are using gif tunnels for passing your ipsec traffic thru you
might want to try not using them. I ran into some similar funkyness
a while back. Packets traverse the gif tunnel, get decrypted and
then get rejected by the firewall rules for the external interface.
If you would like a quickie example of ipsec tunnel setup between
two freebsd boxes, let me know.
Have a suspicion I'm not really using gif altho I've configured the
interfaces. Earlier yesterday found I had not updated an IP address in
the gif0 device which changed a month or to prior. Yet things were
still working.
So yes, please, I'd like to see your notes on how to IPsec tunnel
without gif.
Quickie how-to for ipsec tunnel between two freebsd gateways. Assumes
racoon is installed gateways use automatic key exchange. Usable sample
racoon.conf included.
Network A: 10.1.1.0/24
Gateway A: int nic=10.1.1.1 ext nic=1.1.1.1
Network B: 10.2.2.0/24
Gateway B: int nic=10.2.2.1 ext nic=2.2.2.1
SPD setup on Gateway A:
setkey -c EOF
spdadd 10.1.1.0/24 10.2.2.0/24 any -P out ipsec
esp/tunnel/1.1.1.1-2.2.2.1/unique;
spdadd 10.2.2.0/24 10.1.1.0/24 any -P in ipsec
esp/tunnel/2.2.2.1-1.1.1.1/unique;
EOF
SPD setup on Gateway B:
setkey -c EOF
spdadd 10.1.1.0/24 10.2.2.0/24 any -P in ipsec
esp/tunnel/1.1.1.1-2.2.2.1/unique;
spdadd 10.2.2.0/24 10.1.1.0/24 any -P out ipsec
esp/tunnel/2.2.2.1-1.1.1.1/unique;
EOF
**The above 'spdadd' commands are *one* line each. Adding the spdadd lines
to /etc/ipsec.conf will get the spds added in at boot-time.
Next is either adding a pre-shared secret to /usr/local/etc/racoon/psk.txt
or setting up certificates. Sorry haven't done certs, yet. Format of
psk.txt is hostname/ip
addresstabpre-shared secret.
Here is a fairly generic /usr/local/etc/racoon/racoon.conf configuration.
It should be usable on both gateways. (works for megrin).
### begin ###
# path must be placed before it should be used.
# You can overwrite which you defined, but it should not use due to
confusing. path include /usr/local/etc/racoon ; #include remote.conf ;
# search this file for pre_shared_key with various ID key.
path pre_shared_key /usr/local/etc/racoon/psk.txt ;
# racoon will look for certificate file in the directory,
# if the certificate/certificate request payload is received. path
certificate /usr/local/etc/cert ;
# log specifies logging level.
# It is followed by either notify, debug
# or debug2.
#log debug;
log notify;
# padding defines some parameter of padding.
# You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize on; # enable randomize length.
randomize_length on;
strict_check off; # enable strict check.
exclusive_tail on; # extract last one octet.
}
# if no listen directive is specified, racoon will listen to all # available
interface addresses. listen {
#isakmp ::1 [7000];
#isakmp 202.249.11.124 [500];
#admin [7002]; # administrative's port by kmpstat.
#strict_address;# required all addresses must be bound.
}
# Specification of default various timer.
timer
{
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 40 sec;# maximum interval to resend.
persend 1; # the number of packets per a send.
# timer for waiting to complete each phase.
phase1 300 sec;
phase2 300 sec;
}
remote anonymous
{
#exchange_mode main,aggressive;
exchange_mode main,aggressive,base;
doi ipsec_doi;
#situation identity_only;
verify_identifier off;
send_cert off;
send_cr off;
nonce_size 16;
lifetime time 15 min; # sec,min,hour
#lifetime byte 5 MB;# B,KB,GB
initial_contact on;
support_mip6 off;
proposal_check claim; # obey, strict or claim
# If clients are connecting from dynamic addresses
# set generate_policy to on
generate_policy off;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
sainfo anonymous
{
#pfs_group
