Re: ipfilter 4.13 - http traffic going thru ftp proxy
On Wed, 11 Jul 2007 09:42:22 -0400, Stephen Clark wrote > viper wrote: > > >On Tue, 10 Jul 2007 15:59:46 -0400, Stephen Clark wrote > > > > > >>Hello List, > >> > >>I posted a while ago that our testers of our network appliance were > >>complaining > >>that browsing was slower when using our appliance based on 6.x as > >>compared to > >>our appliance using 4.9 FreeBSD. > >> > >>Well it turns out they were right! After spending much time trying > >>to figure out what was going on we discovered that all http traffic > >>was being routed thru the ipf ftp proxy module. > >> > >>Does anyone know why this is happening? > >> > >>Here is 4.9 > >> > >>H101491# ipnat -l > >>List of active MAP/Redirect filters: > >>map rl1 from 192.168.1.0/24 to any -> 10.0.133.44/32 proxy port ftp ftp/tcp > >>map rl1 from 192.168.1.0/24 to any -> 10.0.133.44/32 portmap tcp/udp > >>4:6 > >>map rl1 from 192.168.1.0/24 to any -> 10.0.133.44/32 > >> > >>List of active sessions: > >>MAP 192.168.1.9 2949 <- -> 10.0.133.44 40075 [64.154.83.47 80] > >>MAP 192.168.1.9 2948 <- -> 10.0.133.44 40074 [209.67.78.5 > >>80] MAP 192.168.1.9 2947 <- -> 10.0.133.44 40073 > >>[216.168.252.103 443] MAP 192.168.1.9 2946 <- -> 10.0.133.44 > >> 40072 [65.243.74.133 80] MAP 192.168.1.9 2945 <- -> > >>10.0.133.44 40071 [216.168.252.103 443] MAP 192.168.1.9 2944 > >> <- -> 10.0.133.44 40070 [66.155.171.116 80] MAP 192.168.1.9 > >>2943 <- -> 10.0.133.44 40069 [64.9.212.6 80] MAP 192.168.1.9 > >> 2942 <- -> 10.0.133.44 40068 [209.104.135.123 80] MAP > >>192.168.1.9 2941 <- -> 10.0.133.44 40067 [65.243.74.133 80] > >>MAP 192.168.1.9 2940 <- -> 10.0.133.44 40066 [65.243.74.133 > >>80] MAP 192.168.1.9 2939 <- -> 10.0.133.44 40065 > >>[65.243.74.133 80] MAP 192.168.1.9 2938 <- -> 10.0.133.44 > >>40064 [216.239.51.95 80] MAP 192.168.1.9 2924 <- -> 10.0.133.44 > >>40050 [64.233.169.99 80] MAP 192.168.1.9 2922 <- -> > >>10.0.133.44 40048 [64.233.169.99 80] MAP 192.168.1.9 2920 <- > >> -> 10.0.133.44 40046 [64.233.169.147 80] MAP 192.168.1.9 > >> 1031 <- -> 10.0.133.44 40045 [198.6.1.2 53] MAP 192.168.1.9 > >> 2884 <- -> 10.0.133.44 40012 [207.159.120.157 80] > >> > >> > >> > >> > > > > > > > >>Here is 6.2 > >>Notice in the mappings for port 80 the source port is not being > >>mapped into the 4:6 range. Also notice that the ftp proxy > >>thought it found something and dumps out some diags. > >> > >> > > > > > > > >>H101490# ipnat -l > >>List of active MAP/Redirect filters: > >>map rl1 from 192.168.1.0/24 to any -> 10.0.133.77/32 proxy port ftp ftp/tcp > >>map rl1 from 192.168.1.0/24 to any -> 10.0.133.77/32 portmap tcp/udp > >>4:6 > >>map rl1 from 192.168.1.0/24 to any -> 10.0.133.77/32 > >> > >>List of active sessions: > >>MAP 192.168.1.881397 <- -> 10.0.133.77 1397 [64.154.83.47 80] > >>MAP 192.168.1.881396 <- -> 10.0.133.77 1396 [209.67.78.5 > >>80] MAP 192.168.1.881395 <- -> 10.0.133.77 1395 > >> [216.168.252.103 443] MAP 192.168.1.881394 <- -> 10.0.133.77 > >> 1394 [216.168.252.103 443] MAP 192.168.1.881393 <- -> > >>10.0.133.77 1393 [65.243.74.144 80] MAP 192.168.1.881392 <- > >> -> 10.0.133.77 1392 [65.243.74.144 80] MAP 192.168.1.88 > >>1378 <- -> 10.0.133.77 1378 [64.233.169.103 80]proxy > >>ftp/6 use -54 flags 0proto 6 flags 0 bytes 0 pkts 0 > >>data YES size 312FTP Proxy:passok: 1Client: > >>seq 0 (ack 0) len 0 junk 0 cmds 0 > >>buf [\000] > >>Server: > >>
src/sys/netinet/in_pcb.c(rev. 1.165.2.6)
Hi all. I am just want ask question only out of curiosity. Are there any reasons why a file src/sys/netinet/in_pcb.c(rev. 1.165.2.6) is not included to RELEASE_6_2? What a kind of race condition closing that revision. Thanks to help me :-) [Vladimir] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 6.2-RELEASE + MPD 4.1 = Fatal trap 12: page fault while in kernelmode
Hi!
Again NULL pointer in m_copyx.
Looks like similar to PR kern/108963.
Are there any suggestions or ideas?
___
Best regards,
Vladimir
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexey Sopov
Sent: Tuesday, February 20, 2007 10:58 PM
To: [EMAIL PROTECTED]
Subject: 6.2-RELEASE + MPD 4.1 = Fatal trap 12: page fault while in kernelmode
Hi!
Yesterday I've updated my FreeBSD 6.0-RELEASE + mpd-4.0b4 up to
FreeBSD 6.2-RELEASE + mpd-4.1. And today I have a Fatal Trap.
Could you please help me to figure out what the problem consists in?
I folowed instructions described in handbook:
[intel][root]~# kgdb /usr/obj/usr/src/sys/router/kernel.debug
/var/crash/vmcore.77
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[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".
Unread portion of the kernel message buffer:
<6>external: promiscuous mode enabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0596202
stack pointer = 0x28:0xe4fabb18
frame pointer = 0x28:0xe4fabb4c
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 = 12 (swi4: clock sio)
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 2047MB (524032 pages) 2032 2016 2000 1984 1968 1952 1936 1920 1904
1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664
1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424
1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184
1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912
896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608
592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304
288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc04772e7 in db_fncall (dummy1=-1067884030, dummy2=0, dummy3=1,
dummy4=0xe4fab92c "")
at /usr/src/sys/ddb/db_command.c:492
#2 0xc0477780 in db_command_loop () at /usr/src/sys/ddb/db_command.c:350
#3 0xc0479600 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222
#4 0xc0572252 in kdb_trap (type=0, code=0, tf=0xe4fabad8) at
/usr/src/sys/kern/subr_kdb.c:473
#5 0xc06ffae4 in trap_fatal (frame=0xe4fabad8, eva=12) at
/usr/src/sys/i386/i386/trap.c:828
#6 0xc06ffdeb in trap_pfault (frame=0xe4fabad8, usermode=0, eva=12)
at /usr/src/sys/i386/i386/trap.c:745
#7 0xc0700235 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1352, tf_esi = 0, tf_ebp =
-453330100, tf_isp = -453330172, tf_ebx = -940045504, tf_edx = 20, tf_ecx =
1396, tf_eax = 44, tf_trapno = 12, tf_err = 0, tf_eip = -1067884030, tf_cs =
32, tf_eflags = 66054, tf_esp = 256, tf_ss = -453330040})
at /usr/src/sys/i386/i386/trap.c:435
#8 0xc06ec0ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#9 0xc0596202 in m_copym (m=0x0, off0=1396, len=1376, wait=1)
at /usr/src/sys/kern/uipc_mbuf.c:397
#10 0xc061804a in ip_fragment (ip=0xcd365820, m_frag=0xe4fabc20, mtu=-940045504,
if_hwassist_flags=0, sw_csum=3073) at /usr/src/sys/netinet/ip_output.c:975
#11 0xc061a846 in ip_output (m=0xc6894300, opt=0xcd365820, ro=0xe4fabbec,
flags=1, imo=0x0,
inp=0x0) at /usr/src/sys/netinet/ip_output.c:804
#12 0xc0609742 in dummynet_send (m=0xc66b9e00) at
/usr/src/sys/netinet/ip_dummynet.c:771
#13 0xc0609a32 in dummynet (unused=0x0) at
/usr/src/sys/netinet/ip_dummynet.c:753
#14 0xc0563590 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290
#15 0xc053a15f in ithread_loop (arg=0xc6391760) at
/usr/src/sys/kern/kern_intr.c:682
#16 0xc0538cbd in fork_exit (callout=0xc053a040 , arg=0x2c,
frame=0x2c)
at /usr/src/sys/kern/kern_fork.c:821
#17 0xc06ec14c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
(kgdb) list *0xc0596202
0xc0596202 is in m_copym (/usr/src/sys/kern/uipc_mbuf.c:400).
395 MBUF_CHECKSLEEP(wait);
396 if (off == 0 && m->m_flags & M_PKTHDR)
397 copyhdr = 1;
398 while (off > 0) {
399 KASSERT(m != NULL, ("m_copym, offset > size of mbuf
chain"));
400 if (of
Re: Strange freeze on -STABLE
>On random time periods my box freezes, but not like the usual way when I >can't do anything. >It drops all network connections (this box is also router), so I can't >connect with SSH anymore Check for zonelimit. Was patch at Mon Mar 12 12:13:52 2007. "MFC: Don't block on the socket zone limit during the socket() syscall which can lock up a system otherwise; instead, return ENOBUFS as documented, which matches the FreeBSD 4.x behavior." As far as me is concerned, panics disappeared, but there is they appeared freeze __ Best regards, VipeR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
src/sys/contrib/ipfilter/netinet/ip_state.c rev 1.38
Hi everyone. I check in cvs src/sys/contrib/ipfilter/netinet/ip_state.c I saw the following : "Sun Dec 24 02:18:36 2006 UTC (3 months ago) by darrenr TCP Window scaling was being recognised but the recorded settings were being clobbered and thus effectively disabled. MFC after: 7 days" Today is 29 March 2007. Who can MFC that rev. to STABLE_6. Thanks. __ Best regards, VipeR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/UPDATING
Hi, I had a similar query about just this very thing when 4.4 just went into release mode and Warner Losh had replied to the post saying that UPDATING in different tags (namely RELENG_4 and RELENG_4_4) are maintained independantly of each other, so one UPDATING could differ to the other. Makes sense when the releng_4_4 tag is security updates only and shouldnt as many contain strange errors/workarounds as releng_4 would. HTH PsyV On Wed, 31 Oct 2001, Jochem Kossen wrote: > > That's weird...I just cvsup'ed (RELENG_4), and the latest thing with me > is: > > 20010814: > The pci attachment for pcic device was merged from current. > > Are you sure you didn't add it yourself? ;) > > On Tue, Oct 30, 2001 at 11:15:48PM +0100, Eric Veraart wrote: > > The latest thing added to my UPDATING is: > > > > 20010915: > > FreeBSD 4.4-RELEASE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
