Unkillable /sbin/ipfw process
Hi!
I've found easy way to make ipfw(8) to become unkillable even witk kill -9.
It is displayed as running and takes all CPU cycles.
Just run the following script with argument 122 for 8.3/i386
or with 121 for 8.3/amd64.
#!/bin/sh
args=add 60001 count ip from any to {
for i in `jot $1 1`
do
args=${args}127.0.0.$i or
done
args=${args}127.0.1.1 };
ipfw delete 60001
echo ipfw $args
ipfw $args
#EOF
After one /sbin/ipfw is stuck in this state,
all others invocations of /sbin/ipfw (including ipfw show)
add another stuck ipfw process.
See also http://www.freebsd.org/cgi/query-pr.cgi?pr=65961
Eugene Grosbein.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On 30.04.2012 23:14, Adam Strohl wrote: da0 at tws0 bus 0 scbus0 target 0 lun 0 da0: LSI 9750-8iDISK 5.12 Fixed Direct Access SCSI-5 device da0: 6000.000MB/s transfers da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C) Let me know anyone wants to see anything else/has seen this/has any theories! Can you try patch from the r234693, update and reinstall gptboot, does it help? http://svnweb.freebsd.org/base?view=revisionrevision=234693 -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
Thanks Andrey, I've just recompiled /boot/gptboot after updating gpt.c and installed it via: gpart bootcode -p /boot/gptboot -i 1 da0 I still see gptboot: invalid backup GPT header on boot (but it does still boot). On 5/2/2012 12:58, Andrey V. Elsukov wrote: On 30.04.2012 23:14, Adam Strohl wrote: da0 at tws0 bus 0 scbus0 target 0 lun 0 da0:LSI 9750-8iDISK 5.12 Fixed Direct Access SCSI-5 device da0: 6000.000MB/s transfers da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C) Let me know anyone wants to see anything else/has seen this/has any theories! Can you try patch from the r234693, update and reinstall gptboot, does it help? http://svnweb.freebsd.org/base?view=revisionrevision=234693 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jails can't get routing info
On 2. May 2012, at 05:11 , Jason Hellenthal wrote: On Tue, May 01, 2012 at 09:01:33PM +, Bjoern A. Zeeb wrote: On 1. May 2012, at 19:41 , David Thiel wrote: Hello, So, I've been trying to debug an issue running nmap scans within jails, partially documented here: http://seclists.org/nmap-dev/2012/q2/220 On further debugging, it's seeming like jails can't read routing information directly at all: # route get 69.163.203.254 route: writing to routing socket: No such process Now, this is normally done via reading the routing table via something like socket(PF_ROUTE, SOCK_RAW, AF_INET), so one would suspect that this is a problem with raw sockets; but raw sockets are enabled within the jail. netstat is able to read routing information just fine, but I don't think it's doing it via the socket() call. hmm, sure you don't have /dev/mem in the jail? netstat -rn I think is still using libkvm *sigh* and not the sysctl API. Good lord I hope this makes it down to stable/8 Pardon, what do you mean? Anyone know why this behavior might be happening? Without thinking too much (as in if I got the right case) I think you are hitting this one: http://svnweb.freebsd.org/base/head/sys/net/rtsock.c?annotate=234572#l792 -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2
hi,lists for some reasons I need restart system but it suddenly boot failed today. here is the error: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset 16 Can't find root filesystem - giving up ZFS:unexcepted object set type 0 ZFS:unexcepted object set type 0 FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel boot: ZFS:unexcepted object set type0 FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel boot: _ any ideas to resolved it? thanks in advance ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On Wed, May 2, 2012 at 5:03 AM, Adam Strohl adams-free...@ateamsystems.com wrote: Thanks Andrey, I've just recompiled /boot/gptboot after updating gpt.c and installed it via: gpart bootcode -p /boot/gptboot -i 1 da0 I still see gptboot: invalid backup GPT header on boot (but it does still boot). On 5/2/2012 12:58, Andrey V. Elsukov wrote: On 30.04.2012 23:14, Adam Strohl wrote: da0 at tws0 bus 0 scbus0 target 0 lun 0 da0:LSI 9750-8i DISK 5.12 Fixed Direct Access SCSI-5 device da0: 6000.000MB/s transfers da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C) Let me know anyone wants to see anything else/has seen this/has any theories! Can you try patch from the r234693, update and reinstall gptboot, does it help? http://svnweb.freebsd.org/base?view=revisionrevision=234693 Did you try to repair the header ? I saw a similar issue on upgraded boxes that were 7-STABLE upgraded to 9-STABLE. and recovering made the warning go away . I may be way off here but just my 2 cents . % gpart recover da0 -- mark saad | nones...@longcount.org -- mark saad | nones...@longcount.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On 5/2/2012 20:46, Mark Saad wrote: Did you try to repair the header ? I saw a similar issue on upgraded boxes that were 7-STABLE upgraded to 9-STABLE. and recovering made the warning go away . I may be way off here but just my 2 cents . % gpart recover da0 Good thought, but no dice: $ gpart recover da0 da0 recovering is not needed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On 02.05.2012 17:53, Adam Strohl wrote: % gpart recover da0 Good thought, but no dice: $ gpart recover da0 da0 recovering is not needed I already saw several reports about gptboot's complains on 3ware controllers, but don't know what is the problem. The only guess is that a controller incorrectly handles BIOS requests, when gptboot tries to read GPT header from the end of a large virtual disk. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jails can't get routing info
On Tue, May 01, 2012 at 09:01:09PM +, Bjoern A. Zeeb wrote: So, I've been trying to debug an issue running nmap scans within jails, partially documented here: http://seclists.org/nmap-dev/2012/q2/220 On further debugging, it's seeming like jails can't read routing information directly at all: # route get 69.163.203.254 route: writing to routing socket: No such process Now, this is normally done via reading the routing table via something like socket(PF_ROUTE, SOCK_RAW, AF_INET), so one would suspect that this is a problem with raw sockets; but raw sockets are enabled within the jail. netstat is able to read routing information just fine, but I don't think it's doing it via the socket() call. hmm, sure you don't have /dev/mem in the jail? netstat -rn I think is still using libkvm *sigh* and not the sysctl API. Actually I do - in desperation I put a add path '*' unhide in the devfs.rules. Now that I think of it, that is what makes netstat work. But, I still don't understand why route get doesn't work, given that the very existence of the security.jail.socket_unixiproute_only sysctl implies that by default, you should be able to open routing sockets in a jail (presuming raw sockets are enabled, which they are). Anyone know why this behavior might be happening? Without thinking too much (as in if I got the right case) I think you are hitting this one: http://svnweb.freebsd.org/base/head/sys/net/rtsock.c?annotate=234572#l792 Hmm, that seems to relate to pulling via sysctl, which the route command doesn't do. It sounds useful for fixing netstat, though. Thanks, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
24.04.2012 23:10, Andreas Longwitz ?:
There is one limitation I would like to get over. From man 8 setkey:
System that do not perform the port check cannot support multiple
endpoints behind the same NAT. I think this is a FreeBSD kernel restriction:
For the first incoming L2TP packet the IPSEC part of the kernel does not
save the source port in the corresponding SA (maybe a field like
natt_l2tp_port). So the kernel does for outgoing L2TP packets not know
the correct SA, if two ore more SA's with the same IP exists.
I would like to know if the patch mentioned in this thread adresses this
problem.
Thank you very much for your attention.
I've been testing those patches (actually, without your part) and YES
it's a big problem with clients (Android, Windows Mobile) behind the
same NAT. I cannot find the solution yet, but I'm very interested in it.
So, my Androids is some sort of stupid bricks, they do not send NAT-OA
payloads at phase 2, and ipsec-tools fills the SPD with IPs taken from
IDs. But this is not the correct way. IDs contain LAN (which is behind
the NAT) addresses, and FreeBSD cannot route packets to the IPSec crypto
part.
I've made some quick patching of IPSec tools to get my devices working,
but I don't know if they accomodate to the RFCs and ISAKMP. The main
idea is to take NAT-OAi and NAT-OAr addresses not from IDs when we are
using NAT-T, but from real source and destination addresses of the
server and client NATs.
Here is my ipsec-tools patch (i've call it patch-zz-local-2.diff and
place at /usr/ports/security/ipsec-tools/files with two other patches
from kern /146190)
*** src/racoon/pfkey.c 2012-04-13 02:02:02.0 +0300
--- src/racoon/pfkey.c 2012-04-19 12:47:57.0 +0300
***
*** 1195,1200
--- 1195,1202
#ifdef SADB_X_EXT_NAT_T_FRAG
sa_args.l_natt_frag = iph2-ph1-rmconf-esp_frag;
#endif
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa =
%s\n, saddr2str(sa_args.l_natt_oa));
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa_dst =
%s\n, saddr2str(sa_args.l_natt_oa_dst));
}
#endif
***
*** 1483,1488
--- 1485,1492
#ifdef SADB_X_EXT_NAT_T_FRAG
sa_args.l_natt_frag = iph2-ph1-rmconf-esp_frag;
#endif
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa =
%s\n, saddr2str(sa_args.l_natt_oa));
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa_dst =
%s\n, saddr2str(sa_args.l_natt_oa_dst));
}
#endif
/* more info to fill in */
*** src/racoon/isakmp_quick.c 2011-03-14 19:18:13.0 +0200
--- src/racoon/isakmp_quick.c 2012-04-19 17:23:16.0 +0300
***
*** 562,567
--- 562,569
if (daddr == NULL)
goto end;
+ plog(LLV_DEBUG2, LOCATION, NULL, daddr = %s, natoa_src = %s,
natoa_dst = %s\n, saddr2str(daddr), saddr2str(iph2-natoa_src),
saddr2str(iph2-natoa_dst));
+
if (iph2-natoa_src == NULL)
iph2-natoa_src = daddr;
else if (iph2-natoa_dst == NULL)
***
*** 1262,1267
--- 1264,1271
if (daddr == NULL)
goto end;
+ plog(LLV_DEBUG2, LOCATION, NULL, daddr = %s, natoa_src = %s,
natoa_dst = %s\n, saddr2str(daddr), saddr2str(iph2-natoa_src),
saddr2str(iph2-natoa_dst));
+
if (iph2-natoa_dst == NULL)
iph2-natoa_dst = daddr;
else if (iph2-natoa_src == NULL)
***
*** 1309,1314
--- 1313,1345
plogdump(LLV_DEBUG, iph2-id-v, iph2-id-l);
}
+ #ifdef ENABLE_NATT
+ if (iph2-ph1-natt_flags NAT_DETECTED)
+ {
+ struct sockaddr_storage addr;
+ u_int8_t prefix;
+ u_int16_t ul_proto;
+
+ if (iph2-natoa_src == NULL)
+ if (!ipsecdoi_id2sockaddr(iph2-id,
+ (struct sockaddr *)addr,
+ prefix,ul_proto))
+ {
+ iph2-natoa_src = dupsaddr((struct sockaddr
*)addr);
+ plog(LLV_DEBUG2, LOCATION, NULL, natoa_src set from
IDcr2: natoa_src = %s\n, saddr2str(iph2-natoa_src));
+ }
+
+ if (iph2-natoa_dst == NULL)
+ if (!ipsecdoi_id2sockaddr(iph2-id_p,
+ (struct sockaddr *)addr,
+ prefix,ul_proto))
+ {
+ iph2-natoa_dst = dupsaddr((struct sockaddr
*)addr);
+ plog(LLV_DEBUG2, LOCATION, NULL, natoa_dst set from
IDci2: natoa_dst
Re: Support for IPSec NAT-T in transoprt mode
On 2. May 2012, at 18:50 , Zmiter wrote: 24.04.2012 23:10, Andreas Longwitz ?: There is one limitation I would like to get over. From man 8 setkey: System that do not perform the port check cannot support multiple endpoints behind the same NAT. I think this is a FreeBSD kernel restriction: For the first incoming L2TP packet the IPSEC part of the kernel does not save the source port in the corresponding SA (maybe a field like natt_l2tp_port). So the kernel does for outgoing L2TP packets not know the correct SA, if two ore more SA's with the same IP exists. I would like to know if the patch mentioned in this thread adresses this problem. Thank you very much for your attention. I've been testing those patches (actually, without your part) and YES it's a big problem with clients (Android, Windows Mobile) behind the same NAT. I cannot find the solution yet, but I'm very interested in it. So, my Androids is some sort of stupid bricks, they do not send NAT-OA payloads at phase 2, and ipsec-tools fills the SPD with IPs taken from IDs. But this is not the correct way. IDs contain LAN (which is behind the NAT) addresses, and FreeBSD cannot route packets to the IPSec crypto part. I've made some quick patching of IPSec tools to get my devices working, but I don't know if they accomodate to the RFCs and ISAKMP. The main idea is to take NAT-OAi and NAT-OAr addresses not from IDs when we are using NAT-T, but from real source and destination addresses of the server and client NATs. Here is my ipsec-tools patch (i've call it patch-zz-local-2.diff and place at /usr/ports/security/ipsec-tools/files with two other patches from kern /146190) ... It differs from that in kern/146190 in one simple thing. I have problems with the original patch from kern/146190. When there was no NAT-OAi or NAT-OAr values in the kernel space, checksums was calculated at 0, but they were not ignored despite of the sysctl net.inet.esp.esp_ignore_natt_cksum value. The improvement allows to ignore every checksum in esp packets when net.inet.esp.esp_ignore_natt_cksum=1. Just replying to the last one -- you all need to make sure that this will work with a double-NAT (both i and r sitting behind a NAT) and not just i behind a NAT and r sitting there with a globally routable IP. The changes suddenly become a lot more complex. Just my 5cts. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
