RE: FreeBSD ipsec tunnel mode packet lost
Thanks Yvan for the help The problem got solved by changing the in security policy, on SGW, from ipsec level require to use, but I'm still not clear what the real issue was. Why we can't use require on it. Thanks, -Original Message- From: VANHULLEBUS Yvan [mailto:va...@freebsd.org] Sent: Wednesday, September 30, 2009 6:08 PM To: Zaidi, Abbas Cc: freebsd-net@freebsd.org; Ansari, Fakhir; Khan, Fayyaz Subject: Re: FreeBSD ipsec tunnel mode packet lost On Wed, Sep 30, 2009 at 01:16:47PM +0200, Zaidi, Abbas wrote: > Hi Hi. > I am having this strange problem establishing tunnel between FreeBSD and > linux, my network setup is [the setup] > Once the SAs get negotiated I send a ping request from FreeBSDe to > Linuxe. The packets get an ipsec header applied at FreeBSDr reaches > Linuxe a reply to packet comes back at Link1::e interface of FreeBSDr > and then packet gets lost. > > I am not using gif. Do I need it? Probably not. > I don't think any thing is wrong with ipsec as the seq of both in and > out sa are incrementing on every echo request reply. please check output of "netstat -s" (mainly sections esp, ipsec6, ip6), and see if some counters increase for each dropped packet. [...] > There is one strange thing about security policies as of linux in case > of tunnel there are 3 policies added (in, out, fwd) where as in FreeBSD > it only shows 2 (in, out). This is specific to Linux's IPsec stack implementation, just forget anything related to "fwd". Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: RE: FreeBSD ipsec tunnel mode packet lost
On Thu, Oct 01, 2009 at 10:00:35AM +0200, Zaidi, Abbas wrote: > Thanks Yvan for the help > > The problem got solved by changing the in security policy, on SGW, from > ipsec level require to use, but I'm still not clear what the real issue > was. Why we can't use require on it. This sounds like you still have some configuration issues Are you sure your traffic is still encrypted Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic in soabort
2009/4/25 Robert Watson :
>
> On Fri, 24 Apr 2009, pluknet wrote:
>
>> 2009/4/23 Robert Watson :
>>>
>>> On Thu, 23 Apr 2009, pluknet wrote:
>>>
Please, give me comment on this. The panic is on 6.2-REL. Is it known to
be fixed in the latter releases?
>>>
>>> It may well be -- there have been quite significant architectural
>>> improvements to socket life cycle (etc) between 6.2 and 7.x releases, which
>>> may well close the race causing this panic. However, we'll probably need to
>>> learn a bit more in order to decide for sure. Could you convert the
>>> trapping instruction pointer to file+offset in the source code?
>>
>> Looks I've lost the corresponding kernel.debug. Anyway I have such bt the
>> first time.
>
> If you run into this again, let me know. Also, are you using accept filters
> on the box?
>
Got it again (this time on 6.4-p5).
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x104
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06a3425
stack pointer = 0x28:0xef764bb0
frame pointer = 0x28:0xef764bbc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 74303 (proftpd)
db> bt 74303
Tracing pid 74303 tid 101039 td 0xcaa08820
_mtx_lock_sleep(ccd50768,caa08820,0,0,0) at _mtx_lock_sleep+0x9d
soabort(ccd506f4) at soabort+0x82
soclose(d1aa8b20) at soclose+0x21a
soo_close(c9f50a20,caa08820) at soo_close+0x63
fdrop_locked(c9f50a20,caa08820,caf78a00,ef764ca8,c06875f3,...) at
fdrop_locked+0xd0
fdrop(c9f50a20,caa08820,caa08820,ef764c64,c0689055,...) at fdrop+0x41
closef(c9f50a20,caa08820,0,ef764d38,cad8f648,...) at closef+0x42f
kern_close(caa08820,a,ef764d30,c08e1d4b,caa08820,...) at kern_close+0x20d
close(caa08820,ef764d04) at close+0x10
syscall(bfbf003b,3b,bfbf003b,8150034,811a434,...) at syscall+0x2bf
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp =
0xbfbfe6bc, ebp = 0xbfbfe6d8 ---
db> show proc 74303
Process 74303 (proftpd) at 0xcad8f648:
state: NORMAL
uid: 36830 gids: 36830
parent: pid 95478 at 0xc8e6
ABI: FreeBSD ELF32
arguments: proftpd: fatich_1 - 93.118.217.18: IDLE
threads: 1
101039 Run CPU 2 proftpd
(gdb) list *(soabort+0x82)
0xc06ea2a6 is in soabort (/usr/src/sys/kern/uipc_socket.c:510).
505 int error;
506
507 error = (*so->so_proto->pr_usrreqs->pru_abort)(so);
508 if (error) {
509 ACCEPT_LOCK();
510 SOCK_LOCK(so);
511 sotryfree(so); /* note: does not decrement
the ref count */
512 return error;
513 }
514 return (0);
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic in soabort
2009/10/1 pluknet :
> 2009/4/25 Robert Watson :
>>
>> On Fri, 24 Apr 2009, pluknet wrote:
>>
>>> 2009/4/23 Robert Watson :
On Thu, 23 Apr 2009, pluknet wrote:
> Please, give me comment on this. The panic is on 6.2-REL. Is it known to
> be fixed in the latter releases?
It may well be -- there have been quite significant architectural
improvements to socket life cycle (etc) between 6.2 and 7.x releases, which
may well close the race causing this panic. However, we'll probably need
to
learn a bit more in order to decide for sure. Could you convert the
trapping instruction pointer to file+offset in the source code?
>>>
>>> Looks I've lost the corresponding kernel.debug. Anyway I have such bt the
>>> first time.
>>
>> If you run into this again, let me know. Also, are you using accept filters
>> on the box?
>>
>
> Got it again (this time on 6.4-p5).
P.S.
It's funny to say: I got it on two boxes nearly simultaneously.
Both from proftpd. See also my first mail (the same).
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address = 0x104
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc06a3425
> stack pointer = 0x28:0xef764bb0
> frame pointer = 0x28:0xef764bbc
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = resume, IOPL = 0
> current process = 74303 (proftpd)
>
> db> bt 74303
> Tracing pid 74303 tid 101039 td 0xcaa08820
> _mtx_lock_sleep(ccd50768,caa08820,0,0,0) at _mtx_lock_sleep+0x9d
> soabort(ccd506f4) at soabort+0x82
> soclose(d1aa8b20) at soclose+0x21a
> soo_close(c9f50a20,caa08820) at soo_close+0x63
> fdrop_locked(c9f50a20,caa08820,caf78a00,ef764ca8,c06875f3,...) at
> fdrop_locked+0xd0
> fdrop(c9f50a20,caa08820,caa08820,ef764c64,c0689055,...) at fdrop+0x41
> closef(c9f50a20,caa08820,0,ef764d38,cad8f648,...) at closef+0x42f
> kern_close(caa08820,a,ef764d30,c08e1d4b,caa08820,...) at kern_close+0x20d
> close(caa08820,ef764d04) at close+0x10
> syscall(bfbf003b,3b,bfbf003b,8150034,811a434,...) at syscall+0x2bf
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp =
> 0xbfbfe6bc, ebp = 0xbfbfe6d8 ---
> db> show proc 74303
> Process 74303 (proftpd) at 0xcad8f648:
> state: NORMAL
> uid: 36830 gids: 36830
> parent: pid 95478 at 0xc8e6
> ABI: FreeBSD ELF32
> arguments: proftpd: fatich_1 - 93.118.217.18: IDLE
> threads: 1
> 101039 Run CPU 2 proftpd
>
> (gdb) list *(soabort+0x82)
> 0xc06ea2a6 is in soabort (/usr/src/sys/kern/uipc_socket.c:510).
> 505 int error;
> 506
> 507 error = (*so->so_proto->pr_usrreqs->pru_abort)(so);
> 508 if (error) {
> 509 ACCEPT_LOCK();
> 510 SOCK_LOCK(so);
> 511 sotryfree(so); /* note: does not decrement
> the ref count */
> 512 return error;
> 513 }
> 514 return (0);
>
> --
> wbr,
> pluknet
>
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Why not work whois -6 ?
FreeBSD 8.0-BETA4 amd64 # whois -6 2a01:d0::1 whois: connect(): Connection refused In man whois written: -6 Use the IPv6 Resource Center (6bone) database. It contains net- work names and addresses for the IPv6 network. There are ideas on how to define membership of a particular block of ipv6? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why not work whois -6 ?
On 1 Oct 2009, at 16:09, Vladislav V. Prodan wrote: FreeBSD 8.0-BETA4 amd64 # whois -6 2a01:d0::1 whois: connect(): Connection refused In man whois written: -6 Use the IPv6 Resource Center (6bone) database. It contains net- work names and addresses for the IPv6 network. There are ideas on how to define membership of a particular block of ipv6? The 6bone whois server is dead AFAIK. Try whois -h whois.ripe.net 2a01:d0::1 -- Rui Paulo ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
vimage-assigning interface to jail
I am experimenting with a vimage-enabled 8.0 kernel with multiple jails. I use the rc.d method to start jails, because of the warning in /etc/rc.d/jails about security. I would like to associate a vnet stack with each jail, and use netgraph to bridge the service jails to the physical interface. The ifconfig vnet additions allow an interface to be assigned to a particular jail; however, I do not know how to create a vimage separate from a jail as they are now unified (vimage -c creates both vnet and jail). I have also not had success passing the vnet parameter in rc.conf, which Julian mentioned might be as simple as "jail_xxx_extra_params". Is there a way to create a vimage w/o a jail and assign it to a jail w/ ifconfig vnet, or to pass the vnet parameter in rc.conf to the jails? I sincerely appreciate the work that's been done on vimage. I'm looking forward to netstat being updated to work with vimage. Thanks in advance. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
The following reply was made to PR kern/138666; it has been noted by GNATS. From: "Vladislav V. Prodan" To: bug-follo...@freebsd.org Cc: univers...@ukr.net Subject: Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy Date: Fri, 02 Oct 2009 00:31:39 +0300 Memtest86 + v2.01 said that with memory so good. P.S. Hynix 2Gb + Hynix 2Gb + Aeneon 1Gb + Aeneon 1Gb ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/139113: commit references a PR
The following reply was made to PR kern/139113; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/139113: commit references a PR
Date: Fri, 2 Oct 2009 01:35:09 + (UTC)
Author: qingli
Date: Fri Oct 2 01:34:55 2009
New Revision: 197695
URL: http://svn.freebsd.org/changeset/base/197695
Log:
Previously, if an address alias is configured on an interface, and
this address alias has a prefix matching that of another address
configured on the same interface, then the ARP entry for the alias
is not deleted from the ARP table when that address alias is removed.
This patch fixes the aforementioned issue.
PR: kern/139113
MFC after: 3 days
Modified:
head/sys/netinet/in.c
Modified: head/sys/netinet/in.c
==
--- head/sys/netinet/in.c Fri Oct 2 01:07:28 2009(r197694)
+++ head/sys/netinet/in.c Fri Oct 2 01:34:55 2009(r197695)
@@ -1060,6 +1060,8 @@ in_scrubprefix(struct in_ifaddr *target)
!(target->ia_ifp->if_flags & IFF_LOOPBACK)) {
error = ifa_del_loopback_route((struct ifaddr *)target,
(struct sockaddr *)&target->ia_addr);
+ /* remove arp cache */
+ arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr);
}
if ((target->ia_flags & IFA_ROUTE) == 0) {
@@ -1082,8 +1084,6 @@ in_scrubprefix(struct in_ifaddr *target)
prefix = target->ia_addr.sin_addr;
mask = target->ia_sockmask.sin_addr;
prefix.s_addr &= mask.s_addr;
- /* remove arp cache */
- arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr);
}
IN_IFADDR_RLOCK();
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
FreeBSD ARM network speed
Hi All, I am continuing my work on CNX11XX/STR91XX (more info about the work: http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two important things left are the Flash/CFI driver, and network problem. The Flash/CFI in theory should be easy, but I will read more about it to make sure that I will not mess the boot loader part. And now about the network. The network speed is now around half of Linux on the same hardware. FTP-ing from the device to my computer (uploading 30 mb file), the speed is about 1.6-2 megabyte/second (the high speed is on the second time when the data is already cached). On Linux, I can upload the same file with the speed of about 3-4 megabyte/second. Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A I have two question: 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? If it is slower, then how much slower is it? I can not find a comparison of network speed on Freebsd arm and Linux ARM. I am interested if anyone can provide me the comparison between Linux and Freebsd on NSLU2 or some other device. Just for information, changing some kernel options in the Linux version (such as the scheduler used) makes the network speed varies greatly (i think the variation is more than 30%, so in certain configuration it can be a slow as the current FreeBSD version). The network in Linux 2.4 kernel is faster than Linux 2.6. 2. What should I do to make the network faster (especially the sending from device part, to make it usable as a media server)? Here are the things that I have done: - using the scatter/gather feature of the hardware (this improves the speed a little bit) - using checksum offloading feature of the hardware (this improves the speed a little bit) - using task_queue for sending (this improves the speed a lot) - I have disabled spinlock debugging, and other debugging except for the DDB - I have used the -O2 optimization flag - I have checked that there is no error/retransmission (using wireshark), so all the packets are sent and received correctly - I have disabled IPV6 (here is my current configuration: http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/conf/CNS11XXNAS&REV=3) The specification for the STR9104 SoC is available on Cavium website for those who are interested, but it is not very clear, so in developing the network driver, I followed the logic used by the Linux driver (the initialization sequence, etc). The current code is at http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 Here is how the sending part works on STR9104: - In the initialization part, I allocate a ring, the size of the ring is 256 entries (same as Linux version). - When being asked to send a packet, I will do the following thing: - stop the network TX DMA - put the address of each segment of the packet to the ring, and set a flag so that the entry in the ring will be sent by hardware - start the network TX DMA obviously there is a cleaning up part (freeing mbuf) that should be done. The network driver can generate interrupt when a packet has been sent (but can't tell which entry was sent). In the Linux version, this interrupt is not used, the clean up is done just after starting the TX DMA, at the send of the sending function, and I do the same in the FreeBSD driver . Usually only one entry that needs to be removed, so it is quite fast. Is there something obvious (or not so obvius) that I've missed? -- Regards Yohanes http://yohan.es/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
