Re: FreeBSD 6.3 gre and traceroute
On Fri, 14 Nov 2008, Robert Noland wrote: Hi, Also just using gre's without the underlying ipsec tunnels seems to work properly. The reason for this to my knowledge is: http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 or looking at recent freebsd code: http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 Look for M_DECRYPTED. Now what happens in your case: you receive an IPSec ESP packet, which gets decryped, that sets M_DECRYPTED on the mbuf passes through various parts, gets up to gre, gets decapsulated is an IP packet (again) gets to ip_input, TTL expired, icmp_error and it's still the same mbuf that originally got the M_DECRYPTED set. Thus the packets is just freed and you never see anything. So thinking about this has nothing to do with gre (or gif for example as well) in first place. It's arguably that passing it on to another decapsulation the flag should be cleared when entering gre() for example. The other question of course is why we do not send the icmp error back even on plain ipsec? Is it because we could possibly leak information as it's not caught by the policy sending it back? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 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
>
Hi,
With a slightly modified libstand/bootp.c - a PR was sent
way back, but you can check
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot
you can control the diskless boot options.
by comenting out kernel= in
/boot/defaults/loader.conf
you can set in the dhcpd.conf.
since most of the tags received via dhcp are placed in kenv,
the crucial options are there!
BTW, we use diskless servers/workstations for 90% of our hosts, the
exception being:
- the dhcp/tftp server
- a 'lagged' server - the router/server get confused :-)
- our mail servers, there is a bug somewhere, where some critical
network resources get deadlocked.
- our developement servers.
the / of the diskless is almost identical to the server, but for
many reasons, I like to keep it appart. The trick to overcome the
read-only problem, is using unionfs for /etc:
in rc.initdiskless:
if [ -e /conf/union ]; then
kldload unionfs
mount_md 4096 /.etc
mount_unionfs -o transparent /.etc /etc
fi
the /conf is nfs mounted from a central site, the location is passed
via dhcp:
confpath=`kenv conf-path`
if [ -n "$confpath" ] ; then
if [ "`expr $confpath : '\(.*\):'`" ] ; then
echo Mounting $confpath on /conf
mount_nfs $confpath /conf
chkerr $? "mount_nfs $confpath /conf"
to_umount="${to_umount} $confpath"
fi
fi
the actual rc.conf is configured like this:
eval `kenv | sed -n 's/^rc\.//p'`
rm -f /etc/rc.conf /etc/rc.conf.local
for fc in $conf0 $conf1 $conf2 $conf3 $conf4 $conf5 $conf6 $conf7 $conf8
$conf9 rc.conf.$hostname
do
ho=`expr $fc : '\(.*\):'`
fl=`expr $fc : '.*/\(.*\)'`
if [ "${ho}" != "" ]; then
mp=`expr $fc : '\(.*\)/.*'`
mount_nfs $mp /mnt > /dev/null 2>&1
if [ -f /mnt/$fl ]; then
echo "# from $fc /mnt/$fl" >> /etc/rc.conf
cat /mnt/$fl >> /etc/rc.conf
fi
umount /mnt > /dev/null 2>&1
elif [ -e /conf/$fc ] ; then
echo "# from /conf/$fc" >> /etc/rc.conf
cat /conf/$fc >> /etc/rc.conf
fi
done
> -- 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]"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TCP Stack Issues Under FreeBSD 7.1
Hi, Anyone else noticing any TCP Stack requests for information under a useraccount with mild to moderate TCP activity on HTTP and other sorts of ports returns zero results back unless you are root. [EMAIL PROTECTED] ~]$ netstat -i reports netstat: kvm not available: /dev/mem: Permission denied ifnet: symbol not defined [EMAIL PROTECTED] ~]$ netstat -an [EMAIL PROTECTED] ~]$ netstat -m 377/823/1200 mbufs in use (current/cache/total) 64/378/442/32768 mbuf clusters in use (current/cache/total/max) 64/315 mbuf+clusters out of packet secondary zone in use (current/cache) 2/386/388/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 230K/2505K/2736K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/525/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 57093 requests for I/O initiated by sendfile 0 calls to protocol drain routines FreeBSD Eden.The-IRC.Com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Sun Nov 2 22:20:01 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THE-IRC i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP Stack Issues Under FreeBSD 7.1
never mind, the TCP Stack is working perfectly under 7.1 unlike 7.0 with ghost entries from different users. It didn't show because root was behiend http. My mistake folks, keep up the good work ;) On Sat, Nov 15, 2008 at 5:26 AM, The-IRC FreeBSD <[EMAIL PROTECTED]>wrote: > Hi, > > > Anyone else noticing any TCP Stack requests for information under a > useraccount with mild to moderate TCP activity on HTTP and other sorts of > ports returns zero results back unless you are root. > > [EMAIL PROTECTED] ~]$ netstat -i reports > netstat: kvm not available: /dev/mem: Permission denied > ifnet: symbol not defined > [EMAIL PROTECTED] ~]$ netstat -an > [EMAIL PROTECTED] ~]$ netstat -m > 377/823/1200 mbufs in use (current/cache/total) > 64/378/442/32768 mbuf clusters in use (current/cache/total/max) > 64/315 mbuf+clusters out of packet secondary zone in use (current/cache) > 2/386/388/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 230K/2505K/2736K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/525/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 57093 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > > > FreeBSD Eden.The-IRC.Com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Sun > Nov 2 22:20:01 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THE-IRC > i386 > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_nyssin undefined
Hi Yesterday AM, 11/14, I cvs'ed the 7-stable sources and did a system build/install. Now all I get is: /lib/ld-elf.so.1: /lib/libc.so.7: Undefined symbol _nyssin. Other than a reinstall, is there any way to recover from this? Thanks Jim Ballantine ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[OT] Waiting for 7.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When does the official version of 7.1 (7.1-RELEASE) release out? Does it have some critical issue? Or how it goes? Just i'm waiting for 7.1 because of i have some plan with 7.1 personally. Cheer up, Ken and the Release Engineering Team! byunghee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkkfLqoACgkQsCouaZaxlv7k4ACeMA8yzbi2dXxAFt5Xcp00wIHd +gkAnAuZv1I019+Ipi0F4VSMH9vjXsvM =Fm2L -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [OT] Waiting for 7.1
Hi, > When does the official version of 7.1 (7.1-RELEASE) release out? Does it > have some critical issue? Or how it goes? Just i'm waiting for 7.1 > because of i have some plan with 7.1 personally. Cheer up, Ken and the > Release Engineering Team! Previously there's been a big ToDO list, I took a quick look to see if I could quote a URL, but only see: http://www.freebsd.org/releases/7.1R/schedule.html lists RC2 builds 29 September 2008 http://www.freebsd.org/releng/index.html November 2008 No matter, re@ will release when ready :-) I'm running 7.1-BETA2 on AMD64, with a load of home built current ports too. No problems with src/, just usual ports/ things. Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: _nyssin undefined
On 2008-Nov-15 12:55:12 -0500, "J. W. Ballantine" <[EMAIL PROTECTED]> wrote: >Yesterday AM, 11/14, I cvs'ed the 7-stable sources and did a >system build/install. Now all I get is: > /lib/ld-elf.so.1: /lib/libc.so.7: Undefined symbol _nyssin. I don't recognize and can't find that symbol in my (older) 7-STABLE sources so I'm not sure what might have triggered it. However, I don't have ld-elf.so.1 in /lib - it's in /libexec. Is that a typo on your part? At what point do you get that error? Can you get to a single user mode shell? The previous ld-elf.so.1 is saved as /libexec/ld-elf.so.1.old - you can use tools in /rescue to rename it (you will need to use chflags to clear the schg flag on /libexec/ld-elf.so.1 before you can overwrite it). Unfortunately, there's no backup of /lib/libc.so.7 so if that's the problem, you will need to recover it from backups or a live filesystem CD. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpEiIzafN6xO.pgp Description: PGP signature
