Re: FW: IPMI kernel module errors on 6.x
Hi Doug, I added 'device ipmi' added to kernel config file Output (ACPI enabled) ipmi0: on isa0 ipmi0: KCS mode found at mem 0xca2 alignment 0x4 on isa ipmi0: KCS: initial state: 00 ipmi0: KCS: Failed to start write ipmi0: KCS Error retry exhausted ipmi0: KCS: Failed to start write ipmi0: KCS Error retry exhausted ipmi0: KCS: Failed to start write ipmi0: KCS Error retry exhausted ipmi0: Failed GET_DEVICE_ID: 5 Output (ACPI disabled) ipmi0: on isa0 ipmi0: KCS mode found at mem 0xca2 alignment 0x4 on isa ipmi0: KCS: initial state: 00 ipmi0: KCS: Failed to start write ipmi0: KCS Error retry exhausted ipmi0: KCS: Failed to start write ipmi0: KCS Error retry exhausted ipmi0: KCS: Failed to start write ipmi0: KCS Error retry exhausted ipmi0: Failed GET_DEVICE_ID: 5 The two look the same, but there is a definite change on the last line of the initial and new output. Doug Ambrisko wrote: Raymond Sundland writes: | I purchased a new Supermicro Superserver SS6015B-T (motherboard is X7DBR-E) | about 3 weeks ago with the IPMI module (part called SIMSO) and have had a | hard time getting the IPMI functionality to work in RELENG_6. | | Particularly, when I attempt to 'kldload ipmi' I get the following output in | dmesg: | | ipmi0: on isa0 | ipmi0: KCS mode found at mem 0xca2 alignment 0x4 on isa | ipmi0: KCS: Failed to start write | ipmi0: KCS Error retry exhausted | ipmi0: KCS: Failed to start write | ipmi0: KCS Error retry exhausted | ipmi0: KCS: Failed to start write | ipmi0: KCS Error retry exhausted | ipmi0: Timed out waiting for GET_DEVICE_ID | | >From the dmesg, it appears it's finding the IPMI device, but unable to | interact with it. Meanwhile, no device shows up in /dev so ipmitool does | not work, either. | | For reference, here is my uname: | | FreeBSD exodus 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #9: Fri Nov 10 10:56:39 | PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EXODUS amd64 | | This is a RELENG_6 build with a CVSUP done just before the compile date of | the kernel. | | The SIMSO IPMI card itself works, I can access it via the web management | console, I just can not get the kernel driver to work with it. Any help | and/or references would be greatly appreciated. Could you try it static in the kernel and then with and without ACPI enabled? Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Path MTU Discovery when routing over IPSec connections
Bjoern A. Zeeb wrote: On Wed, 15 Nov 2006, Tom Judge wrote: I'll handle this. From your patch I assume you are on RELENG_6. In HEAD that part had been re-written already. I have to check if the entire code path could be MFCed or just your change needs to be applied but it'll has to wait until after 6.2-RELEASE. I do not want to break any other (edge) case there just before the release and I guess re@ wouldn't want me to either;) /bz Thanks for dealing with this. The patch is indeed against RELENG_6, I may be able to setup a test network to test any patches if this would be helpful. Regards Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Path MTU Discovery when routing over IPSec connections
On Wed, 15 Nov 2006, Tom Judge wrote: Hi, I have been looking into some problems with PMTU Discovery when routing packets over IPSec (gif) tunnels, I have submitted the details to the open PR I'll handle this. From your patch I assume you are on RELENG_6. In HEAD that part had been re-written already. I have to check if the entire code path could be MFCed or just your change needs to be applied but it'll has to wait until after 6.2-RELEASE. I do not want to break any other (edge) case there just before the release and I guess re@ wouldn't want me to either;) /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FW: IPMI kernel module errors on 6.x
Raymond Sundland writes: | I purchased a new Supermicro Superserver SS6015B-T (motherboard is X7DBR-E) | about 3 weeks ago with the IPMI module (part called SIMSO) and have had a | hard time getting the IPMI functionality to work in RELENG_6. | | Particularly, when I attempt to 'kldload ipmi' I get the following output in | dmesg: | | ipmi0: on isa0 | ipmi0: KCS mode found at mem 0xca2 alignment 0x4 on isa | ipmi0: KCS: Failed to start write | ipmi0: KCS Error retry exhausted | ipmi0: KCS: Failed to start write | ipmi0: KCS Error retry exhausted | ipmi0: KCS: Failed to start write | ipmi0: KCS Error retry exhausted | ipmi0: Timed out waiting for GET_DEVICE_ID | | >From the dmesg, it appears it's finding the IPMI device, but unable to | interact with it. Meanwhile, no device shows up in /dev so ipmitool does | not work, either. | | For reference, here is my uname: | | FreeBSD exodus 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #9: Fri Nov 10 10:56:39 | PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EXODUS amd64 | | This is a RELENG_6 build with a CVSUP done just before the compile date of | the kernel. | | The SIMSO IPMI card itself works, I can access it via the web management | console, I just can not get the kernel driver to work with it. Any help | and/or references would be greatly appreciated. Could you try it static in the kernel and then with and without ACPI enabled? Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Multipath support for FreeBSD
Hello, Is there any patch to a kernel level multipath solution for FreeBSD 6 out there? Or does anyone think in implement that in a near future? So far as I know, there is an old patch for FreeBSD 4.8 ... for FreeBSD 6 I can simulate a multipath with ipfw prob or with pf load-balancing, but its not exactly what Im looking for. OpenBSD 4.0 has now support for equal-cost multipath by default, but I needed an unequal-cost multipath solution, like linux can do (iproute2 weight based multipath). Any help/clues for a FreeBSD solution? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipv6 connection hash function wanted ...
Max Laier wrote:
> Oops, I missed one requirement:
> /*
> * IMPORTANT: the hash function for dynamic rules must be commutative
> * in source and destination (ip,port), because rules are bidirectional
> * and we want to find both in the same bucket.
> */
OK, then you have to perform a commutative operation on
source and destination ("xor" or "add"), then run crc32
on the result.
> AFAICT, the attached has this property, but I have no idea if it adds
> sufficient entropy to the result - it looks like it, though.
It's not exactly what I had in mind. You are xor'ing all
components with each other first, which makes it easier
for an attacker to construct a collision: He just has
to generate one 32bit part (e.g. the lower 32 bits of
his address) so that the result of the xor stays the same.
It's trivial to do that. Then the result of the crc32
will also be the same, of course.
You should xor source and destination as a whole, i.e.
create an artifical (ip,port) struct that contains the
xor'ed source and destination, then call crc32 on the
20 bytes of that struct. The random key can be used as
initialization vector for crc32_raw(), like you did in
your patch.
However, there's still a problem: If the attacker can
guess our port number, he can set his port number in a
way that it will result in the same xor value. If his
and our IP address are also the same, the total result
will be the same again.
A simple solution is to multiply the port numbers (with
a 32bit result) instead of xor'ing them. Multiplication
is commutative, but in most cases the attacker won't be
able to generate an integer port number P2 in a way that
P2 * P1 will equal a certain number, because in most cases
that number won't be evenly divisible by P1. Of course
there are a few cases left where it is possible to
generate such an integer number P2. To defeat the
attackers for those few cases, too, you should add another
random key to both port numbers before multiplication.
OK, to summarize:
1. Calculate src_ip xor dst_ip [result is 16 bytes].
2. Calculate (src_port + pkey) * (dst_port + pkey)
[result is 4 bytes, using 32bit modulo arithmetics].
3. Run crc32_raw on the resulting 20 bytes, using ckey
as initialization vector.
pkey and ckey are two different 32bit random values that
are generated once at boot.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
C++: "an octopus made by nailing extra legs onto a dog"
-- Steve Taylor, 1998
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipv6 connection hash function wanted ...
On Wed, Nov 15, 2006 at 01:53:12PM +0100, Max Laier wrote: > AFAICT, the attached has this property, but I have no idea if it adds > sufficient entropy to the result - it looks like it, though. You should do at least some bit shifting on the arguments as typical ipv6 addresses are by default MAC based and larger shipments of the same hardware often have similiar enough MACs to create collisions. I think what Olliver meant was more to use an input of 128bit for crc32, after xoring src, dst and secret. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf kernel module
Garrett Cooper wrote: > Something else I should have mentioned. Statically building components > into the kernel makes operation faster overall, I don't think there's a measurable difference in speed. > but increases the > required memory for your machine, whereas using modules is more > expensive time-wise, but you can load portions of the kernel piece by > piece, instead of load the entire kernel into main memory. In the case discussed here (bpf), memory is not an issue, because the bpf module -- if it existed -- would have to be loaded permanently anyway, or otherwise pflogd wouldn't work. In fact, a kernel module requires a small amount of additional memory, compared to the same code compiled statically into the kernel. It's not a big deal, though. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipv6 connection hash function wanted ...
On Wednesday 15 November 2006 12:26, Oliver Fromme wrote:
> Max Laier wrote:
> > David Malone wrote:
> > > Assuming you don't want to use one of the standard cryptographic
> > > ones (which I can imagine being a bit slow for something done
> > > per-packet), then one option might be to use a simpler hash that
> > > is keyed. Choose the key at boot/module load time and make it hard
> > > to produce collisions unless you know the key.
> >
> > That's exactly what I am looking for ... now I need someone[tm] -
> > with better Math-Knowledge than mine - to write such a thing down in
> > a simple formula :-) i.e. take those bits from there and there and
> > XOR them with your canary yada-yada-yada ...
>
> In that case, simply use crc32 (available from libkern.h)
> and xor with a random key generated at boot time. crc32
> is fast to calculate and has the properties that you need.
Oops, I missed one requirement:
/*
* IMPORTANT: the hash function for dynamic rules must be commutative
* in source and destination (ip,port), because rules are bidirectional
* and we want to find both in the same bucket.
*/
AFAICT, the attached has this property, but I have no idea if it adds
sufficient entropy to the result - it looks like it, though.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: ip_fw2.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.153
diff -u -r1.153 ip_fw2.c
--- ip_fw2.c 6 Nov 2006 13:42:04 - 1.153
+++ ip_fw2.c 15 Nov 2006 12:36:34 -
@@ -230,6 +230,7 @@
static ipfw_dyn_rule **ipfw_dyn_v = NULL;
static u_int32_t dyn_buckets = 256; /* must be power of 2 */
static u_int32_t curr_dyn_buckets = 256; /* must be power of 2 */
+static u_int32_t hash_nonce = 0;
static struct mtx ipfw_dyn_mtx; /* mutex guarding dynamic rules */
#define IPFW_DYN_LOCK_INIT() \
@@ -642,12 +643,19 @@
hash_packet6(struct ipfw_flow_id *id)
{
u_int32_t i;
- i = (id->dst_ip6.__u6_addr.__u6_addr32[2]) ^
+
+ i = (id->dst_ip6.__u6_addr.__u6_addr32[0]) ^
+ (id->dst_ip6.__u6_addr.__u6_addr32[1]) ^
+ (id->dst_ip6.__u6_addr.__u6_addr32[2]) ^
(id->dst_ip6.__u6_addr.__u6_addr32[3]) ^
+ (id->src_ip6.__u6_addr.__u6_addr32[0]) ^
+ (id->src_ip6.__u6_addr.__u6_addr32[1]) ^
(id->src_ip6.__u6_addr.__u6_addr32[2]) ^
(id->src_ip6.__u6_addr.__u6_addr32[3]) ^
(id->dst_port) ^ (id->src_port);
- return i;
+ i = crc32_raw(&i, sizeof(i), hash_nonce);
+
+ return (i);
}
static int
@@ -4360,6 +4368,7 @@
uma_zdestroy(ipfw_dyn_rule_zone);
return (error);
}
+ hash_nonce = arc4random();
ip_fw_ctl_ptr = ipfw_ctl;
ip_fw_chk_ptr = ipfw_chk;
callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL);
pgpkc5EmS5WoQ.pgp
Description: PGP signature
Re: Ramdisk support
Aditya Godbole wrote: > Oliver Fromme wrote: > > Aditya Godbole wrote: > > > Is there any ramdisk support in freebsd, as there is in netbsd? > > > What are the alternatives if I want to mount a root filesytem from ram? > > > > You mean a diskless setup? I think there's a detailed > > description of diskless setups in the FreeBSD Handbook. > > You might also want to look at the diskless(8) manpage. > > I was looking for something like initrd support of Linux or the > mdsetimage of NetBSD. The boot loader can pre-load the root filesystem image as an md(4) device, similar to loading a splash screen. The kernel option to enable that feature is called MD_ROOT, and I think it's even enabled by default in the GENERIC kernel. You can also put the image of the root file system into the kernel itself, so it doesn't have to be loaded separately. The kernel option to allocate appropriate space is called MD_ROOT_SIZE. > I have no disc or network card support for my hardware at the moment. Then where are you booting from? At least your kernel has to come from somewhere, i.e. you need either networking or some kind of media (disk, USB stick or similar). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ramdisk support
On Wed, Nov 15, 2006 at 05:25:36PM +0530, Aditya Godbole wrote: > On 11/15/06, Oliver Fromme <[EMAIL PROTECTED]> wrote: > >Aditya Godbole wrote: > > > Is there any ramdisk support in freebsd, as there is in netbsd? > > > What are the alternatives if I want to mount a root filesytem from ram? > > > >You mean a diskless setup? I think there's a detailed > >description of diskless setups in the FreeBSD Handbook. > >You might also want to look at the diskless(8) manpage. > > > > Hi, > > I was looking for something like initrd support of Linux or the > mdsetimage of NetBSD. > I have no disc or network card support for my hardware at the moment. > Well, how are you going to boot your system without a disk and network then? We support disk booting, and diskless (network) booting, also support CD-ROM and floppy booting. What of these do you need? Like others have said, we can load kernels with an embedded root filesystem image; the image can either be read-write or read-only; in the latter case, it can also be compressed with geom_uzip(4). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpjZoVUXmcH7.pgp Description: PGP signature
Re: ipv6 connection hash function wanted ...
Oliver Fromme wrote: > Max Laier wrote: > > David Malone wrote: > > > Assuming you don't want to use one of the standard cryptographic > > > ones (which I can imagine being a bit slow for something done > > > per-packet), then one option might be to use a simpler hash that > > > is keyed. Choose the key at boot/module load time and make it hard > > > to produce collisions unless you know the key. > > > > That's exactly what I am looking for ... now I need someone[tm] - with > > better Math-Knowledge than mine - to write such a thing down in a simple > > formula :-) i.e. take those bits from there and there and XOR them with > > your canary yada-yada-yada ... > > In that case, simply use crc32 (available from libkern.h) > and xor with a random key generated at boot time. crc32 > is fast to calculate and has the properties that you need. Uhm, sorry, after reading that sentence again and thinking about it, it seems to be misleading. You have to xor with a random key _first_, and _then_ calculate the crc32 value. If you did it the other way, the random key would not prevent from collisions at all, because: same_crc ^ same_key == same_hash. ;-) Suppose a malicious user is able to create two different sets of connections parameters (P1 and P2) which have the same CRC32 value (without using a key): P1 != P2 crc32(P1) == crc32(P2) If you xor (or add) the random key K to the parameters, it will change the outcome of the crc32 calculation in different ways: crc32(P1 ^ K) != crc32(P2 ^ K) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bpf kernel module
Quoting Garrett Cooper <[EMAIL PROTECTED]> (from Tue, 14 Nov 2006 11:19:11 -0800): Something else I should have mentioned. Statically building components into the kernel makes operation faster overall, but increases the required memory for your machine, whereas using modules is more expensive time-wise, but you can load portions of the kernel piece by piece, instead of load the entire kernel into main memory. As Oliver How did you measure/tested this and what are the numbers? Bye, Alexander. -- Each of us bears his own Hell. -- Publius Vergilius Maro (Virgil) http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD on DVD
Hello, In case you really want a DVD with FreeBSD you can make one yourself using this guide: http://www.pa.msu.edu/~tigner/bsddvd.html Which worked fine when I tried it a while back. Cheers, Ralph. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ramdisk support
On 11/15/06, Oliver Fromme <[EMAIL PROTECTED]> wrote: Aditya Godbole wrote: > Is there any ramdisk support in freebsd, as there is in netbsd? > What are the alternatives if I want to mount a root filesytem from ram? You mean a diskless setup? I think there's a detailed description of diskless setups in the FreeBSD Handbook. You might also want to look at the diskless(8) manpage. Hi, I was looking for something like initrd support of Linux or the mdsetimage of NetBSD. I have no disc or network card support for my hardware at the moment. -- aditya ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipv6 connection hash function wanted ...
Max Laier wrote: > David Malone wrote: > > Assuming you don't want to use one of the standard cryptographic > > ones (which I can imagine being a bit slow for something done > > per-packet), then one option might be to use a simpler hash that > > is keyed. Choose the key at boot/module load time and make it hard > > to produce collisions unless you know the key. > > That's exactly what I am looking for ... now I need someone[tm] - with > better Math-Knowledge than mine - to write such a thing down in a simple > formula :-) i.e. take those bits from there and there and XOR them with > your canary yada-yada-yada ... In that case, simply use crc32 (available from libkern.h) and xor with a random key generated at boot time. crc32 is fast to calculate and has the properties that you need. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ramdisk support
Aditya Godbole wrote: > Is there any ramdisk support in freebsd, as there is in netbsd? Sure. To mount a 200 MB swap-backed memory filesystem on /tmp, add this lie to /etc/fstab: md /tmp mfs rw,async,nosuid,-s200m,-m0 0 0 > What are the alternatives if I want to mount a root filesytem from ram? You mean a diskless setup? I think there's a detailed description of diskless setups in the FreeBSD Handbook. You might also want to look at the diskless(8) manpage. Best regards Oliver PS: Such questions are more appropriate for the freebsd- questions list. They're not really "hacker" questions. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] Path MTU Discovery when routing over IPSec connections
I have been looking into some problems with PMTU Discovery when routing packets over IPSec (gif) tunnels, I have submitted the details to the open PR kern/91412 but have had no response as to whether my patch is the correct solution to the problem. The problem occurs when sys/netinet/ip_input.c constructs the ICMP Host Unreachable message with an MTU hint. Triggered when a packet that is to be routed over the IPSec link is larger than the MTU on the link and has the Don't Fragment bit set. There is a block of code that is specific to IPSec (gif) MTU discovery which attempts to calculate the MTU size of the link by working out the size of the IPSec header and subtracting this from the MTU of the transmission interface and the gif IP header. However the code fails to retrieve a fully populated security policy which means that the code block designed to calculate the MTU never gets run. The code then breaks out of the case statement and transmits the ICMP packet with the MTU hint set to 0. If the break is removed from IPSec code the MTU calculation is carried out by the non IPSec code successfully. This begs the question whether the IPSec code is even needed as the normal code works fine? Network Layout: Box 1 - Router 2 --(Ipsec tunnel)-- Router 3 --(lan) --- Box 2 |(lan) |-- Router 1 Box 1: FreeBSD 5.4 Router [123]: FreeBSD 6.1 Box 2: Linux 2.6 Tests to reproduce the error: PING Test from box 1 to box 2 with do not fragment set and a packet larger than the path MTU: box1# ping -s 1280 -D box2 PING box2 (10.0.0.79): 1280 data bytes 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 051c b454 0 40 01 c9fc 172.17.1.48 10.0.0.79 36 bytes from router2 (172.17.3.6): frag needed and DF set (MTU 0) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 1c05 b454 0 3f 01 cafc 172.17.1.48 10.0.0.79 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 051c b45f 0 40 01 c9f1 172.17.1.48 10.0.0.79 36 bytes from router2 (172.17.3.6): frag needed and DF set (MTU 0) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 1c05 b45f 0 3f 01 caf1 172.17.1.48 10.0.0.79 ^C --- box2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss PING Test from box 1 to box 2 with do not fragment set and a packet smaller than the path MTU: box1# ping -s 1200 -D box2 PING box2 (10.0.0.79): 1200 data bytes 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 04cc b472 0 40 01 ca2e 172.17.1.48 10.0.0.79 1208 bytes from 10.0.0.79: icmp_seq=0 ttl=61 time=111.017 ms 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 04cc b479 0 40 01 ca27 172.17.1.48 10.0.0.79 1208 bytes from 10.0.0.79: icmp_seq=1 ttl=61 time=110.419 ms ^C --- box2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 110.419/110.718/111.017/0.299 ms box1# Relevent interface configuration on box1 (from ifconfig): em0: flags=8843 mtu 1500 options=b inet 172.17.1.48 netmask 0x broadcast 172.17.255.255 ether 00:0f:1f:fa:d1:b5 media: Ethernet autoselect (1000baseTX ) status: active Relevent interface configuration on router2 (from ifconfig): em0: flags=8943 mtu 1500 options=b inet 172.17.3.6 netmask 0x broadcast 172.17.255.255 ether 00:c0:9f:12:13:1b media: Ethernet autoselect (1000baseTX ) status: active gif0: flags=8051 mtu 1280 tunnel inet 63.174.xxx.xxx --> 82.195.xxx.xxx inet 192.168.174.10 --> 192.168.174.9 netmask 0xfffc Patch: Index: sys/netinet/ip_input.c === --- sys/netinet/ip_input.c (revision 24) +++ sys/netinet/ip_input.c (working copy) @@ -1990,8 +1990,8 @@ #else /* FAST_IPSEC */ KEY_FREESP(&sp); #endif - ipstat.ips_cantfrag++; - break; +// ipstat.ips_cantfrag++; +// break; } } #endif /*IPSEC || FAST_IPSEC*/ Tests after the patch has been applied: PING Test from box 1 to box 2 with do not fragment set and a packet larger than the path MTU: box1# ping -s 1280 -D box2 PING box2 (10.0.0.79): 1280 data bytes 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 051c b454 0 40 01 c9fc 172.17.1.48 10.0.0.79 36 byt
Re: Ramdisk support
On Wed, Nov 15, 2006 at 01:35:14PM +0530, Aditya Godbole wrote: > On 11/15/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > >> What are the alternatives if I want to mount a root filesytem from ram? > > > >man mdconfig > > > > I'm sorry, I couldn't quite get what I was looking for from the > manpage. How do I use mdconfig to mount the root filesystem? See related documentation, e.g. md(4). Kris pgpuKlzqeGXnQ.pgp Description: PGP signature
Re: Ramdisk support
On 11/15/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > What are the alternatives if I want to mount a root filesytem from ram? man mdconfig I'm sorry, I couldn't quite get what I was looking for from the manpage. How do I use mdconfig to mount the root filesystem? -- aditya ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
