diskless+pxe notes
Hi,
i finally decided to try and use pxeboot to replace the etherboot
method I was using so far for diskless setups.
The goal is to fully share the server's root and /usr directories,
as documented in diskless(8). I'd like to share the following
notes, hopefully to go in the manpage.
cheers
luigi
-- root path configuration -
There seems to be a well known problem in pxeloader, see
kern/106493 , where pxeloader defaults to using a root path of
/pxeroot when offered "/" . The patch suggested in
http://www.freebsd.org/cgi/query-pr.cgi?pr=106493
is trivial and judging from it I believe this is addressing a
true bug and not a feature. Fortunately there is a workaround
(suggested in the PR) which is using "//" as a root path.
- sharing /boot with the server ---
I believe it is quite useful to share the whole root
partition between the server and the diskless client.
This would require at a minimum some conditional code
in loader.conf (or loader.rc, etc) so that at least you
point to different kernels.
A minimalistic approach can be adding this line to /boot/loader.conf
bootfile="kernel\\${loaddev};kernel"
The variable $loaddev contains the name of the load device,
which is "pxe0" in the case of pxeboot, and disk* in other
cases when loading from the local disk.
If you make sure that there is no 'kernel.disk*' on the
directory, and instead there is a kernel.pxe0 in the same
directory, then the diskless machines and the server will boot
from the proper file.
Unfortunately i don't know how to implement a conditional
in /boot/loader.conf -- otherwise one could do much nicer things
such as differentiate which modules to load and so on.
--- pxeloader bug in 7.x ---
Also worth mentioning is an annoying bug in pxeloader as compiled
on 7.x, see http://www.freebsd.org/cgi/query-pr.cgi?pr=118222
i.e. the pxeloader in 7.x fails to proceed and prints a message
"can't figure out which disk we are booting from".
The workaround is using a pxeloader from FreeBSD6 works.
I guess this is a compiler-related problem (given that 6.x uses gcc 3.4
as a compiler, while 7.x uses gcc 4.2).
-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 gre and traceroute
On Fri, 2008-11-14 at 10:25 -0800, Julian Elischer wrote: > Stephen Clark wrote: > > Stephen Clark wrote: > > > > > 10.0.129.1 FreeBSD workstation > > ^ > > | > > | ethernet > > | > > v > > 10.0.128.1 Freebsd FW "A" > > ^ > > | > > | gre / ipsec > > | > > v > > 192.168.3.1 FreeBSD FW "B" > > ^ > > | > > | ethernet > > | > > v > > 192.168.3.86 linux workstation > > > > >> Also just using gre's without the > >> underlying ipsec tunnels seems to > >> work properly. > > > This is the crux of the matter. > IPSEC happens INSIDE the IP stack. The IP stack is responsible for > the ICMP generation so it is much more likely that there is an > interaction there. > > Now is there an IPSEC rule to make sure that the ICMP packet can get > back? It could b ehtat in teh IP stack there is some confusion as to > whether the return packet should be encrypted or not and it might get > dropped. > > the code involved is in /sys/netinet and /sys/netipsec but you'll > probably regret looking in there ;-) Right, I don't really know the IPSEC code, but I was told by someone who is familiar with it that this is a known problem and that the use of GRE is not relevant. Hopefully he will have a moment to respond to this thread with a bit more detail. robert. > > > >> > >> > > Another data point I had been using option FILTER_GIF I tried a kernel > > without that option and it behaved the same. > > > > Steve > > > signature.asc Description: This is a digitally signed message part
Re: FreeBSD 6.3 gre and traceroute
Stephen Clark wrote: Stephen Clark wrote: 10.0.129.1 FreeBSD workstation ^ | | ethernet | v 10.0.128.1 Freebsd FW "A" ^ | | gre / ipsec | v 192.168.3.1 FreeBSD FW "B" ^ | | ethernet | v 192.168.3.86 linux workstation Also just using gre's without the underlying ipsec tunnels seems to work properly. This is the crux of the matter. IPSEC happens INSIDE the IP stack. The IP stack is responsible for the ICMP generation so it is much more likely that there is an interaction there. Now is there an IPSEC rule to make sure that the ICMP packet can get back? It could b ehtat in teh IP stack there is some confusion as to whether the return packet should be encrypted or not and it might get dropped. the code involved is in /sys/netinet and /sys/netipsec but you'll probably regret looking in there ;-) Another data point I had been using option FILTER_GIF I tried a kernel without that option and it behaved the same. Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 gre and traceroute
Julian Elischer wrote:
Stephen Clark wrote:
Stephen Clark wrote:
10.0.129.1 FreeBSD workstation
^
|
| ethernet
|
v
10.0.128.1 Freebsd FW "A"
^
|
| gre / ipsec
|
v
192.168.3.1 FreeBSD FW "B"
^
|
| ethernet
|
v
192.168.3.86 linux workstation
Also just using gre's without the underlying ipsec tunnels seems to
work properly.
This is the crux of the matter.
IPSEC happens INSIDE the IP stack. The IP stack is responsible for
the ICMP generation so it is much more likely that there is an
interaction there.
Now is there an IPSEC rule to make sure that the ICMP packet can get
back? It could b ehtat in teh IP stack there is some confusion as to
whether the return packet should be encrypted or not and it might get
dropped.
the code involved is in /sys/netinet and /sys/netipsec but you'll
probably regret looking in there ;-)
Another data point I had been using option FILTER_GIF I tried a kernel
without that option and it behaved the same.
Steve
I agree I put a diag in ip_input.c
if (ip->ip_ttl <= IPTTLDEC) {
icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS,
0, 0);
return;
and sure enough it is calling icmp_error, but I think it can't figure out
how to route the packet back. I been looking at my SPD to see if I can make some
adjustment to the policy that would help.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 ipsec and traceroute doesn't work as good as Linux -why?
Holger Kipp wrote:
On Fri, Nov 14, 2008 at 09:31:24AM -0500, Stephen Clark wrote:
Dear Stephen,
I don't want to be rude, but looking at your description I don't see
what's wrong with the behaviour, but it seems you don't understand what
'* * *' really means.
How does traceroute work? Well, it sends out a packet with time to live
(TTL) set to one. on the first hop, this will be reduced by each hop that
it passes through, and if TTL reaches zero, a time exceeded message will
be send back. Then another packet is send with TTL increased by one to
identify the next hop and so on.
If no answer is received, print out a '*' and try again (up to three tries
by default).
This process will stop if the last hop replies. It does not stop (or only
after eg. 30 hops) if the last hop does not reply.
Why is it that we sometimes do not get a reply? Possible answers:
- fw-rules block these traceroute packages
- routing for the answer packet is not set correctly
- with IP-tunnel, the packet is not routed through the tunnel because
it does not enter the ruleset from an external interface. This might
be true for your firewalls.
- ...
So routing and fw-settings are very important here. You might want to
check that first, before complaining ;-)
In your setup you have not given both external and internal FW addresses.
You might not want to have the FW be exposed on its internal interface
to the remote network, instead you might want to have a transparent tunnel.
Regards,
Holger
10.0.129.1 FreeBSD workstation
^
|
| ethernet
|
v
internal 10.0.128.1 Freebsd FW "A"
public ip address
^
|
| ipsec
|
v
public ip address
internal 192.168.2.1 Linux FW "B"
^
|
| ethernet
|
v
192.168.2.20 linux workstation
from 192.168.2.20 Linux<->ipsec<->FreeBSD
traceroute -I 10.0.129.1
traceroute to 10.0.129.1 (10.0.129.1), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.434 ms 0.425 ms 0.423 ms
2 * * *
3 sclark (10.0.129.1) 42.418 ms 42.419 ms 42.727 ms
traceroute -I 10.0.128.1
traceroute to 10.0.128.1 (10.0.128.1), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.398 ms 0.504 ms 0.505 ms
2 10.0.128.1 (10.0.128.1) 36.066 ms 36.052 ms 37.800 ms
traceroute 10.0.129.1
traceroute to 10.0.129.1 (10.0.129.1), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.484 ms 0.464 ms 0.447 ms
2 * * *
3 sclark (10.0.129.1) 41.406 ms 41.391 ms 47.812 ms
traceroute 10.0.128.1
traceroute to 10.0.128.1 (10.0.128.1), 30 hops max, 60 byte packets
1 (192.168.2.1) 0.473 ms 0.444 ms 0.427 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * *^C
from 10.0.129.1 FreeBSD<->ipsec<->Linux
sudo traceroute 192.168.2.20
traceroute to 192.168.2.20 (192.168.2.20), 64 hops max, 40 byte packets
1 HQFirewallRS.com (10.0.128.1) 0.761 ms 2.551 ms 4.017 ms
2 * * *
3 192.168.2.20 (192.168.2.20) 19.956 ms 27.425 ms 27.487 ms
sclark:~
$ sudo traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 64 hops max, 40 byte packets
1 HQFirewallRS.com (10.0.128.1) 8.069 ms 2.952 ms 4.050 ms
2 home (192.168.2.1) 26.338 ms 22.132 ms 24.233 ms
sclark:~
$ sudo traceroute -I 192.168.2.20
traceroute to 192.168.2.20 (192.168.2.20), 64 hops max, 60 byte packets
1 HQFirewallRS.com (10.0.128.1) 0.714 ms 0.806 ms 0.221 ms
2 home (192.168.2.1) 25.260 ms 25.312 ms 25.868 ms
3 192.168.2.20 (192.168.2.20) 36.477 ms 24.828 ms 24.903 ms
sclark:~
$ sudo traceroute -I 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 64 hops max, 60 byte packets
1 HQFirewallRS.com (10.0.128.1) 2.219 ms 1.889 ms 4.491 ms
2 home (192.168.2.1) 26.172 ms 25.706 ms 24.981 ms
tracerouteing to Linux never just gives a * * *, * * *, * * *, etc
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hi Holger,
Thanks for the reply. During my test I had the firewalls on all system disabled,
The problem is the FreeBSD FW does not respond correctly even if I use the -I
option on traceroute which uses ICMP packets instead of UDP packets.
And I agree it looks to be some kind of routing problem - I put a diag in the
freebsd kernel ip_input.c
if (ip->ip_ttl <= IPTTLDEC) {
icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS,
0, 0);
return;
to make sure it w
Re: FreeBSD 6.3 ipsec and traceroute doesn't work as good as Linux -why?
On Fri, Nov 14, 2008 at 09:31:24AM -0500, Stephen Clark wrote: Dear Stephen, I don't want to be rude, but looking at your description I don't see what's wrong with the behaviour, but it seems you don't understand what '* * *' really means. How does traceroute work? Well, it sends out a packet with time to live (TTL) set to one. on the first hop, this will be reduced by each hop that it passes through, and if TTL reaches zero, a time exceeded message will be send back. Then another packet is send with TTL increased by one to identify the next hop and so on. If no answer is received, print out a '*' and try again (up to three tries by default). This process will stop if the last hop replies. It does not stop (or only after eg. 30 hops) if the last hop does not reply. Why is it that we sometimes do not get a reply? Possible answers: - fw-rules block these traceroute packages - routing for the answer packet is not set correctly - with IP-tunnel, the packet is not routed through the tunnel because it does not enter the ruleset from an external interface. This might be true for your firewalls. - ... So routing and fw-settings are very important here. You might want to check that first, before complaining ;-) In your setup you have not given both external and internal FW addresses. You might not want to have the FW be exposed on its internal interface to the remote network, instead you might want to have a transparent tunnel. Regards, Holger > 10.0.129.1 FreeBSD workstation > ^ > | > | ethernet > | > v > 10.0.128.1 Freebsd FW "A" > ^ > | > | ipsec > | > v > 192.168.2.1 Linux FW "B" > ^ > | > | ethernet > | > v > 192.168.2.20 linux workstation > > from 192.168.2.20 Linux<->ipsec<->FreeBSD > > traceroute -I 10.0.129.1 > traceroute to 10.0.129.1 (10.0.129.1), 30 hops max, 60 byte packets > 1 192.168.2.1 (192.168.2.1) 0.434 ms 0.425 ms 0.423 ms > 2 * * * > 3 sclark (10.0.129.1) 42.418 ms 42.419 ms 42.727 ms > > traceroute -I 10.0.128.1 > traceroute to 10.0.128.1 (10.0.128.1), 30 hops max, 60 byte packets > 1 192.168.2.1 (192.168.2.1) 0.398 ms 0.504 ms 0.505 ms > 2 10.0.128.1 (10.0.128.1) 36.066 ms 36.052 ms 37.800 ms > > traceroute 10.0.129.1 > traceroute to 10.0.129.1 (10.0.129.1), 30 hops max, 60 byte packets > 1 192.168.2.1 (192.168.2.1) 0.484 ms 0.464 ms 0.447 ms > 2 * * * > 3 sclark (10.0.129.1) 41.406 ms 41.391 ms 47.812 ms > > traceroute 10.0.128.1 > traceroute to 10.0.128.1 (10.0.128.1), 30 hops max, 60 byte packets > 1 (192.168.2.1) 0.473 ms 0.444 ms 0.427 ms > 2 * * * > 3 * * * > 4 * * * > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * *^C > > > > from 10.0.129.1 FreeBSD<->ipsec<->Linux > sudo traceroute 192.168.2.20 > traceroute to 192.168.2.20 (192.168.2.20), 64 hops max, 40 byte packets > 1 HQFirewallRS.com (10.0.128.1) 0.761 ms 2.551 ms 4.017 ms > 2 * * * > 3 192.168.2.20 (192.168.2.20) 19.956 ms 27.425 ms 27.487 ms > > sclark:~ > $ sudo traceroute 192.168.2.1 > traceroute to 192.168.2.1 (192.168.2.1), 64 hops max, 40 byte packets > 1 HQFirewallRS.com (10.0.128.1) 8.069 ms 2.952 ms 4.050 ms > 2 home (192.168.2.1) 26.338 ms 22.132 ms 24.233 ms > > sclark:~ > $ sudo traceroute -I 192.168.2.20 > traceroute to 192.168.2.20 (192.168.2.20), 64 hops max, 60 byte packets > 1 HQFirewallRS.com (10.0.128.1) 0.714 ms 0.806 ms 0.221 ms > 2 home (192.168.2.1) 25.260 ms 25.312 ms 25.868 ms > 3 192.168.2.20 (192.168.2.20) 36.477 ms 24.828 ms 24.903 ms > > sclark:~ > $ sudo traceroute -I 192.168.2.1 > traceroute to 192.168.2.1 (192.168.2.1), 64 hops max, 60 byte packets > 1 HQFirewallRS.com (10.0.128.1) 2.219 ms 1.889 ms 4.491 ms > 2 home (192.168.2.1) 26.172 ms 25.706 ms 24.981 ms > > tracerouteing to Linux never just gives a * * *, * * *, * * *, etc > > -- > > "They that give up essential liberty to obtain temporary safety, > deserve neither liberty nor safety." (Ben Franklin) > > "The course of history shows that as a government grows, liberty > decreases." (Thomas Jefferson) > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple panics with 7.1-PRERELEASE amd64/i386 and varnish
Le 06/11/2008 16:05, Herve Boulouis a ?crit: > Le 06/11/2008 11:29, Herve Boulouis a ?crit: > > I just tried to reboot one of the boxes without kern.ipc.maxpipekva=104857600 > to check for kva problems > but crashes persists, though the stack is completely different now. This time > I included all the corrupt > parts of the stack that I had stripped in my original email but they are > similar (from frame 18 to end). > > Any ideas ? We just found the same kind of crash with a 7.0-STABLE i386 from August so there is a serious bug in the kernel making varnish with file backend totaly unusable on FreeBSD 7. Backtrace : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x52 fault code = supervisor read, page not present instruction pointer = 0x20:0xc093b90a stack pointer = 0x28:0xe4475ad0 frame pointer = 0x28:0xe4475ad0 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 = 34 (syncer) trap number = 12 panic: page fault cpuid = 0 Uptime: 28m52s Physical memory: 1011 MB Dumping 148 MB: 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc071b3a6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc071b67e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc09ec2dc in trap_fatal (frame=0xe4475a90, eva=82) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc09ec54b in trap_pfault (frame=0xe4475a90, usermode=0, eva=82) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc09ecf32 in trap (frame=0xe4475a90) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc09d31cb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc093b90a in vm_object_pip_add (object=0x0, i=1) at /usr/src/sys/vm/vm_object.c:273 #8 0xc078c207 in cluster_wbuild (vp=0xc4616564, size=16384, start_lbn=3, len=3) at /usr/src/sys/kern/vfs_cluster.c:925 #9 0xc07829a6 in vfs_bio_awrite (bp=0xd7fde3bc) at /usr/src/sys/kern/vfs_bio.c:1668 #10 0xc091593e in ffs_syncvnode (vp=0xc4616564, waitfor=3) at /usr/src/sys/ufs/ffs/ffs_vnops.c:283 #11 0xc0910e8d in ffs_sync (mp=0xc4209b30, waitfor=3, td=0xc4044660) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1234 #12 0xc079d4ef in sync_fsync (ap=0xe4475cd4) at /usr/src/sys/kern/vfs_subr.c:3217 #13 0xc0a01392 in VOP_FSYNC_APV (vop=0xc0affa60, a=0xe4475cd4) at vnode_if.c:1007 #14 0xc079dcd5 in sched_sync () at vnode_if.h:538 #15 0xc06f77f4 in fork_exit (callout=0xc079d5d0 , arg=0x0, frame=0xe4475d38) at /usr/src/sys/kern/kern_fork.c:781 #16 0xc09d3240 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) I kept the vmcores (i386 and amd64) if someone needs them. Regards, -- Herve Boulouis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.3 ipsec and traceroute doesn't work as good as Linux -why?
10.0.129.1 FreeBSD workstation ^ | | ethernet | v 10.0.128.1 Freebsd FW "A" ^ | | ipsec | v 192.168.2.1 Linux FW "B" ^ | | ethernet | v 192.168.2.20 linux workstation from 192.168.2.20 Linux<->ipsec<->FreeBSD traceroute -I 10.0.129.1 traceroute to 10.0.129.1 (10.0.129.1), 30 hops max, 60 byte packets 1 192.168.2.1 (192.168.2.1) 0.434 ms 0.425 ms 0.423 ms 2 * * * 3 sclark (10.0.129.1) 42.418 ms 42.419 ms 42.727 ms traceroute -I 10.0.128.1 traceroute to 10.0.128.1 (10.0.128.1), 30 hops max, 60 byte packets 1 192.168.2.1 (192.168.2.1) 0.398 ms 0.504 ms 0.505 ms 2 10.0.128.1 (10.0.128.1) 36.066 ms 36.052 ms 37.800 ms traceroute 10.0.129.1 traceroute to 10.0.129.1 (10.0.129.1), 30 hops max, 60 byte packets 1 192.168.2.1 (192.168.2.1) 0.484 ms 0.464 ms 0.447 ms 2 * * * 3 sclark (10.0.129.1) 41.406 ms 41.391 ms 47.812 ms traceroute 10.0.128.1 traceroute to 10.0.128.1 (10.0.128.1), 30 hops max, 60 byte packets 1 (192.168.2.1) 0.473 ms 0.444 ms 0.427 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * *^C from 10.0.129.1 FreeBSD<->ipsec<->Linux sudo traceroute 192.168.2.20 traceroute to 192.168.2.20 (192.168.2.20), 64 hops max, 40 byte packets 1 HQFirewallRS.com (10.0.128.1) 0.761 ms 2.551 ms 4.017 ms 2 * * * 3 192.168.2.20 (192.168.2.20) 19.956 ms 27.425 ms 27.487 ms sclark:~ $ sudo traceroute 192.168.2.1 traceroute to 192.168.2.1 (192.168.2.1), 64 hops max, 40 byte packets 1 HQFirewallRS.com (10.0.128.1) 8.069 ms 2.952 ms 4.050 ms 2 home (192.168.2.1) 26.338 ms 22.132 ms 24.233 ms sclark:~ $ sudo traceroute -I 192.168.2.20 traceroute to 192.168.2.20 (192.168.2.20), 64 hops max, 60 byte packets 1 HQFirewallRS.com (10.0.128.1) 0.714 ms 0.806 ms 0.221 ms 2 home (192.168.2.1) 25.260 ms 25.312 ms 25.868 ms 3 192.168.2.20 (192.168.2.20) 36.477 ms 24.828 ms 24.903 ms sclark:~ $ sudo traceroute -I 192.168.2.1 traceroute to 192.168.2.1 (192.168.2.1), 64 hops max, 60 byte packets 1 HQFirewallRS.com (10.0.128.1) 2.219 ms 1.889 ms 4.491 ms 2 home (192.168.2.1) 26.172 ms 25.706 ms 24.981 ms tracerouteing to Linux never just gives a * * *, * * *, * * *, etc -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 gre and traceroute
Stephen Clark wrote: Robert Noland wrote: On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: Julian Elischer wrote: Stephen Clark wrote: Julian Elischer wrote: you will need to define the setup and question better. thanks.. cleaning it up a bit more... 10.0.129.1 FreeBSD workstation ^ | | ethernet | v 10.0.128.1 Freebsd FW "A" ^ | | gre / ipsec | v 192.168.3.1 FreeBSD FW "B" ^ | | ethernet | v 192.168.3.86 linux workstation $ sudo traceroute 192.168.3.86 traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms 2 * * * 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms No response from the FreeBSD "B" box. When I do a tcpdump on "B" of the gre interface I see UDP packets with a TTL of 1 but no ICMP response packets being sent back. If I do the traceroute from the linux workstation 192.168.3.86 I get similar results - I don't see a response from the FreeBSD "A" box. could you try using just GRE encasulation? (i.e. turn off IPSEC for now) I think that is much more likely to be where the problem is.. I'll have to set this up to test it. The ttl exceeded is triggered from one of two places. Either netinet/ip_fastfwd.c if fast_forwarding is enabled or in netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't your problem though... If ttl were not being decremented, the packet would just be forwarded on to the next hop (IP_STEALTH), which would just make the firewalls invisible. The fact that you are seeing * * * indicates that you are not receiving the ttl exceeded message for the packet sent with that particular ttl. I still think that the issue you are seeing is that one way or another the generated ICMP response isn't making it back onto the tunnel. Either via security policy, firewall or routing. Your right, when I do a tcpdump on the gre interface I see the udp packet come in with a ttl=1 but I don't see a response icmp packet. I have tested this with all the firewalls disabled to make sure the icmp packet was not being blocked. I just ran another test and did tcpdump on all the other interfaces to make sure the icmp's were not being misrouted, it seems they are not being generated for some reason. Also just using gre's without the underlying ipsec tunnels seems to work properly. robert. What code in the FreeBSD kernel is responsible for generating the response ICMP dest unreachable message? Another data point I had been using option FILTER_GIF I tried a kernel without that option and it behaved the same. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 build failure in rescue/ (iconv?)
Ignore this, turned out that PEBCAK. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS crashes on heavy threaded environment
Xin LI wrote: > Xin LI wrote: >> Hi, Pawel, > >> We can still reproduce the ZFS crash (threading+heavy I/O load) on a >> fresh 7.1-STABLE build, in a few minutes: > >> /usr/local/bin/iozone -M -e -+u -T -t 128 -S 4096 -L 64 -r 4k -s 30g -i >> 0 -i 1 -i 2 -i 8 -+p 70 -C Yes, this is known. >> I have included a backtrace output from my colleague who has his hands >> on the test environment. Should there is more information necessary >> please let us know and we wish to provide help on this. > > Further datapoint. The system used to run with untuned loader.conf, and > my colleague just reported that with the following loader.conf, the > problem can be triggered sooner: > > vm.kmem_size_max=838860800 > vm.kmem_size_scale="2" These two settings only serve to calculate vm.kmem_size, so you could simply skip them and adjust vm.kmem_size directly. > The system is running FreeBSD/amd64 7.1-PRERELEASE equipped with 8GB of > RAM with GENERIC kernel. You can tune vm.kmem_size to near 2 GB on your machine and OS version. signature.asc Description: OpenPGP digital signature
Re: System deadlock when using mksnap_ffs
On Thu, Nov 13, 2008 at 05:08:10PM +0100, Greg Byshenk wrote: > On Wed, Nov 12, 2008 at 08:42:00PM -0800, Jeremy Chadwick wrote: > > > The rest of the below information is good -- but I'm confused about > > something: is there anyone out there who can use mksnap_ffs on a > > filesystem (/usr is a good test source) and NOT experience this > > deadlocking problem? Literally *every* FreeBSD box I have root access > > to suffers from this problem, so I'm a little baffled why we end-users > > need to keep providing debugging output when it should be easy as pie > > for a developer to do "dump -0 -L -a -f /path/fs.dump /usr" and watch > > their system wedge. > > As an answer to the question (and additional information), I am > experiencing the problem, but not on all filesystems. > > This is under FreeBSD 7.1-PRERELEASE #7: Thu Nov 6 11:29:52 CET 2008, > amd64 (from sources csup'ed immediately prior to the build). > > I have four filesystems used for data storage: > > /dev/da1p196850470 7866026 81236408 9%/export/mail > /dev/da1p2 1937058312 972070320 81002332855%/export/home > /dev/da1p3 1937058312 79027008 1703066640 4%/export/misc > /dev/da1p4 2598991534 271980564 211909164811%/export/spare > > I can successfully mksnap_ffs the first (smaller) partition, but an > attempt to do so on any of the others causes a lock. > > Note: this is a lockup, not a "slow". The system becomes unresponsive > to any input, and there is no hard drive activity, and this does not > change over a period of more than 12 hours. As a followup to my own post, after reading this discussion, I applied the patches and rebuild my system last night. As of today, with the patched ffs_snapshot.c, I can now make snapshots of all the filesystems listed above. It takes rather a long time, but that is to be expected, I think, and the snapshots finish normally. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
