Re: Replacing BIND with unbound
On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: Dag-Erling, do you have a timeline for getting started on the ldns/unbound import? I imported the code into the vendor tree, but did not proceed any further as there was still no firm consensus at the time. I believe the conclusion - to the extent that there was one - was that people were fine with tossing out BIND and importing ldns to replace the client bits, as long as we had suitable drop-in replacements for host(1) and dig(1), but there was no consensus on whether to import unbound. I'll start working on getting ldns into head this weekend. I think ldns really is not what we want; can you defer this for a week and we could chat in person, also wtih brooks around, next week? There is a wwaayy larger thing to the picture of resolver libraries, exspecially validating once, which includes standardization, acceptance, application support, etc. and I admit there should be a summary of that on the wiki but isn't yet as some of the things only very last-weekishly materialized for real for us. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
On Tue, 21 Aug 2012, Doug Barton wrote: On 8/21/2012 10:11 AM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: Dag-Erling, do you have a timeline for getting started on the ldns/unbound import? I imported the code into the vendor tree, but did not proceed any further as there was still no firm consensus at the time. I believe the conclusion - to the extent that there was one - was that people were fine with tossing out BIND and importing ldns to replace the client bits, as long as we had suitable drop-in replacements for host(1) and dig(1), but there was no consensus on whether to import unbound. I'll start working on getting ldns into head this weekend. I think ldns really is not what we want; can you defer this for a week and we could chat in person, also wtih brooks around, next week? There is a wwaayy larger thing to the picture of resolver libraries, exspecially validating once, which includes standardization, acceptance, application support, etc. and I admit there should be a summary of that on the wiki but isn't yet as some of the things only very last-weekishly materialized for real for us. Neither importing ldns nor removing BIND is going to have any effect on the stub resolver library in libc. Yes it does as if we are not carefull, we'll neither have a _proper_ validating caching resolver but 4 different resolver libraries 3 of which needing crypto and only 2 with a well known support plan and only 2 with the same interface in base. Can you see why Simon's question is important to not make the current problem worse? (rhetorical for you, Des will answer). Can we make sure if we do this that things like portsnap and freebsd-update will not stop working (using the command line tools for example)? Can we have a longer plan of where we want to be in a year, which parts we need from where and how to get them, and if we feel like it, add names to this? It's strange that others in this thread have asked for it already, not just me yelling stop. And if you have much larger plans for resolver libraries, especially validating ones, it would be great if they were discussed IN PUBLIC, so that those of us who know a little something about the topic can be involved in the discussion BEFORE all the decisions are made, and all the balls start rolling. Do you understand the part about the wiki from above? I can put an ACL on to exclude everyone but the secret cabal, having investigated days the last 18 months on the topic, talked to people on multiple continents, from different projects, ... but I hadn't planned to .. and I am not the only one. The fact that it's not written down is, as I said, things are only no longer totally nebulous since last week. Given the only thing you currently want to do is getting rid of solving the problem of no longer maintaing named in base (which I think no one disagrees with per se) but do not want to invest in any of the other work, I'd highly appreciate a lower noise level so others could in fact move forward in a more productive way. I could have started the wiki page rather than replying for example. Thanks. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
On Mon, 20 Aug 2012, Doug Barton wrote: On 08/06/2012 13:23, Vitaly Magerya wrote: Doug Barton do...@freebsd.org wrote: On 07/07/2012 16:33, Garrett Wollman wrote: The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. [...] ldns (a dependency of unbound) comes with drill, which is a dig-alike tool. I'd like to see us produce a host-alike based on ldns as well, If there still is interest, I've got just that at [1]. This tool, ldns-host, implements all the options of bind9-host (except for debugging ones), and produces close (and often identical) output. There's a list of differences between ldns-host and bind9-host in the man page (see [2]); most items can be fixed if people will request for it. Some more exotic situations where not tested though, so that list is only partial. [1] http://hg.tx97.net/ldns-host/file/ [2] http://manweb.tx97.net/http://hg.tx97.net/ldns-host/raw-file/tip/ldns-host.1 If I didn't already say so, this is awesome! :) Dag-Erling, do you have a timeline for getting started on the ldns/unbound import? We will continue to reject this until there are more firm plans, proper documentation on the security support side, which I cannot remember Simon got an answer for. I continue to say that I am not willing to trade one for another for the sake of just changing the name. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound
On Mon, 20 Aug 2012, Doug Barton wrote: On 08/20/2012 01:55, Bjoern A. Zeeb wrote: We will continue to reject this until there are more firm plans, proper documentation on the security support side, which I cannot remember Simon got an answer for. I gave a clear answer. If there are any pieces missing it's up to Simon to follow up with Dag-Erling. If you did, where was it. My email client shows 1 follow-up to http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039837.html and that was unrelated and not you. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 8. Jul 2012, at 02:44 , Warner Losh wrote: On Jul 7, 2012, at 5:33 PM, Garrett Wollman wrote: On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said: BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation The only reason I want it in the base system is that ports don't cross build very well, but the base system does. That's a weak +1 for keeping something in the base system, but I'll be the first to admit it is a second or third tier argument at best. The real reason you want exactly these tools in base is that otherwise you end up rewriting tiny parts of freebsd-update etc that actually depend on host, etc. to query SRV for SRV records. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 7. Jul 2012, at 23:45 , Doug Barton wrote: On 07/07/2012 16:34, Bjoern A. Zeeb wrote: On 7. Jul 2012, at 23:17 , Doug Barton wrote: Other than authoritative DNS, what features does unbound lack that you want? DNS64 as a start. Personally I would classify that as a highly-specialized request, and would point you to the bind* ports. I acknowledge that others may have a different view. Just to give you an idea - there are US nation-wide networks that depend on it these days. It's become an essential feature unfortunately. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. I'd object to it. Trading one for another without gaining anything does not help us much. Don't get me wrong I have both running for years and even maintain patches for unbound for 2 years now for functionality they do not provide, which named happily gives me. If you want to do this, I would prefer a properly laid out action plan as the import is by far the easiest but the integration into various parts of the system is harder. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 7. Jul 2012, at 23:17 , Doug Barton wrote: On 07/07/2012 14:16, Bjoern A. Zeeb wrote: On 3. Jul 2012, at 12:39 , Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. I'd object to it. Trading one for another without gaining anything does not help us much. Au contraire. It solves the problem of BIND release cycles not matching up with ours. This is a very important problem to solve. Right and unbound et al are better? Bind at least gives us long term support releases these days. We just need to make sure we pick them for releases. I've already written at length as to what I think the dream solution is, but we don't have anyone willing to code that yet, and even if we did, there is no guarantee that we'd get the buy-in to make it happen. In addition to being a good first step, doing this for DNS will also help us shake out the exact issues you allude to below. Don't get me wrong I have both running for years and even maintain patches for unbound for 2 years now for functionality they do not provide, which named happily gives me. Other than authoritative DNS, what features does unbound lack that you want? DNS64 as a start. I don't care about the auth. support really with what is in base; it is nice that it comes for free and it is nice, that I'll not run into port 53 conflicts on single-IP systems but the only thing we really need is a caching resolver. If you want to do this, I would prefer a properly laid out action plan as the import is by far the easiest but the integration into various parts of the system is harder. BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? startup scripts; resolvconf, named.conf - unbound.conf guides for our users, and not solving the issue that we really want a DNSSEC enabled caching resolver with libc APIs for applications to use DNSSEC in base that people are working on. We will probably need a crpyto and most likely also an external dnssec speaking resolver library for this in the future, but which of the 7 it will be we don't know yet. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [jail] Allowing root privledged users to renice
On 25. May 2012, at 16:48 , Sean Bruno wrote: I've been toying with the idea of letting jails renice processes ... how dangerous and/or stupid is this idea? //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - /home/seanbru/ybsd_9/src/sys/kern/kern_jail.c 270a271,275 + int jail_allow_renice = 0; + SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, +jail_allow_renice, 0, +Prison root can renice processes); 3857a3863,3865 + case PRIV_SCHED_SETPRIORITY: + if (!jail_allow_renice) + return (EPERM); I think sysctls are a bad idea given jails have per-jail flags these days. Maybe also only allow re-nicing to be nicer but not less nice? /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 24. May 2012, at 13:47 , Mark Felder wrote: On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd adr...@freebsd.org wrote: Hi, can you please, -please- file a PR? And place all of the above information in it so we don't lose it? I'd be glad to post a PR and assist in helping to get it permanently fixed. I certainly don't want this data to get lost and honestly our business uses FreeBSD on VMWare so much that we really need a permanent fix as much as anyone else :-) The reason I've hesitated to post a PR so far is that I didn't have any truly useful or concrete evidence of where the problem lies. After Dane Foster contacted me and told me he could recreate the crash on demand with his workload it was easier to narrow things down. The suggestion that it was an interrupts issue (by possibly Bjoern Zeeb?) Just for the public archives. Interrupts wasn't me. I might have mentioned disabling cdrom and fdc as good as possible but everything else I cannot remember... and Dane's discovery that his crashes ceased when em0 and mpt0 share an IRQ, but em0 is completely unused was starting to prove there is some strong evidence here in favor of the interrupts issue. Dane, what's the status on your end? Has your fix still been successful? Is it also stable if you simply set hint.mpt.0.msi_enable=1 ? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Page fault when using IPsec with AESNI enabled on 9.0-RELEASE
On 22. May 2012, at 21:14 , Alex wrote: Hi there. I am running FreeBSD 9.0-RELEASE-p1 #18 r235095 amd64 and am experiencing a reproducible page fault when using IPsec with device aesni enabled. Strongswan successfully negotiates the SAs and uses aes256 for ESP, however once a packet is sent, the page fault occurs. This does not happen when aesni is disabled. I have a core dump, the text of which is attached to this email. Should I file a PR for this? Thanks. Sure it's aesni related? kern/164400 ? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tftpd: avoid logging error for pxeboot option negotiation?
On 20. Feb 2012, at 20:09 , Ed Maste wrote: After upgrading a diskless boot server from FreeBSD 6 to 8 I see an error message logged each time a diskless client boots: Feb 20 00:56:38 TPC-D4-35 tftpd[55229]: Got ERROR packet: TFTP Aborted It turns out that the pxeboot client (from Intel) first performs a TFTP read request with the tsize option to which it receives an acknowledgement containing the size of the file to be transferred. Then it sends back an error response to abort the transfer, and sends the read request again (without the tsize option). The sequence of packets is: 1. C-S TFTP Read Request, File: pxeboot, Transfer type: octet, tsize=0 2. S-C TFTP Option Acknowledgement, tsize=239616 3. C-S TFTP Error Code, Code: Not defined, Message: TFTP Aborted 4. C-S TFTP Read Request, File: pxeboot, Transfer type: octet, blksize=1456 5. S-C TFTP Option Acknowledgement, blksize=1456 6. C-S TFTP Acknowledgement, Block: 0 7. S-C TFTP Data Packet, Block: 1 ... I'd like to avoid logging the error here, for the sake of this pxeboot client and any other tftp clients that might check options without actually starting a transfer. Anyone opposed to removing it? (A proposed patch is at http://people.freebsd.org/~emaste/tftpd.diff). Rather than completely ignoring it, can we log it in a different category, so that one would actually still have a chance to see real abort errors? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Processes' FIBs
On 11. Jan 2012, at 15:06 , Oliver Fromme wrote:
Bjoern A. Zeeb wrote:
On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote:
On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote:
Is there a way to find out the default FIB number of a
process (from a shell script)? I've checked the
manpages of ps and procstat, but they don't mention
FIBs. I'm using stable/8, if that matters.
http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.html
Not sure about ps/et al, but you can do it according to that post. Nearly
2 years old now.
To be honest, I prefer not to fumble around in kernel memory
with kgdb in a shell script. Also, it requires root privilege
(setfib does not).
If you are thinking in terms of multiple forwarding information bases, yes
sysctl net.my_fibnum
Thanks. Would it make sense to document that in setfib(1)?
However, I need to find the default FIB number for arbitrary
processes, not necessarily for the calling process.
I'm currently looking at the source code of ps, but adding
a field for the FIB isn't as trivial as I thought because
ps only sees struct kinfo_proc (via sysctl kern.proc.*)
which doesn't contain the FIB. procstat does the same.
I'm currently trying to write a patch that copies p_fibnum
from struct proc to struct kinfo_proc (just like p_nice,
for example). Does that make sense? If so, does the patch
below look reasonable? (I've made it on a stable/8 system,
but it should apply to 9 and 10, too.)
I am not sure it makes too much sense in ps. It might make sense in
sockstat maybe?
Best regards
Oliver
--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.0 +0200
+++ ./sys/sys/user.h 2012-01-11 15:35:50.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#define KI_NSPARE_INT 9
+#define KI_NSPARE_INT 8
#define KI_NSPARE_LONG 12
#define KI_NSPARE_PTR 6
@@ -177,6 +177,7 @@
*/
charki_sparestrings[68];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total */
--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.0 +0200
+++ ./sys/kern/kern_proc.c2012-01-11 15:36:22.0 +0100
@@ -775,6 +775,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
PROC_SLOCK(p);
rufetch(p, kp-ki_rusage);
kp-ki_runtime = cputick2usec(p-p_rux.rux_runtime);
--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.0 +0200
+++ ./bin/ps/keyword.c2012-01-11 15:44:27.0 +0100
@@ -90,6 +90,7 @@
NULL, 0},
{etime, ELAPSED, NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0},
{f, F, NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{ignored, , sigignore, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{inblk, INBLK, NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG,
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Build Option Survey results
Hey, after two years I had the opportunity to run the build option survey, initially done by phk, again. The number of options seems to have grown quite a bit it felt. I have not even looked at the results yet but here they are fresh off the machine: http://people.freebsd.org/~bz/build_option_survey_20120106/ Special thanks go to np, sbruno and bhaga for bringing worm back to life. /bz PS: the last run from 2010 can still be found here: http://people.freebsd.org/~bz/build_option_survey_20100104/ -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ifconfig output: ipv4 netmask format
On Fri, 8 Apr 2011, Warner Losh wrote: Non-contiguous netmasks are *not* legal anymore in IPv4. Just reference the RFC and everyone will agree... *oops* ;-) On the general thread: I'd seriously stop bothering with any decisions that will change the way IPv4 works or has worked or the output tools gave people for 20 or more years unless there is a really good reason. Do not break things just because you don't like it. It's hardcoded into too many brains^Wscripts. just my 0.01cts. PS: I am all for making things more restrictive no longer thinking inet is the default but even that's hard... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Detecting listening servers in multi-ip jails
On Tue, 15 Feb 2011, Dirk Engling wrote:
Hello,
until jails could be bound to several ip addresses, my convenience
feature in ezjail to check for and warn about listening services in the
host system and other jails worked simply by asking:
listeners_ip=`sockstat -4 -l | grep ${ip}:[[:digit:]]`
listeners_all=`sockstat -4 -l | grep *:[[:digit:]]`
Now where ip adresses are not rewritten on listen() calls anymore,
services in jails can bind to 0.0.0.0 as well and will match the latter,
although they don't really cause the trouble I want to warn users about
(unless, of course the jail really is bound to the same ip address and
the service then binds to 0.0.0.0).
Now I can, using nc -z, test if the service really listens. That
allows me to filter and only report those services that actually
respond. However, this is far from clean.
Are there other ways to relibly test for listening services on any port
for a given ip address?
get the pid and use a cross-check on the process; there is no easy
way do it otherwise currently unless you write your own extensions
needing kvm.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On Sun, 30 Jan 2011, Damien Fleuriot wrote: Ok I've loaded the newly patched mfi.ko and booted a MFS image. Here's the relevant snip from dmesg.run : at mfi0: Dell PERC H200 Integrated port 0xfc00-0xfcff mem 0xdf2b-0xdf2b,0xdf2c-0xdf2f irq 16 at device 0.0 on pci1 mfi0: Megaraid SAS driver Ver 3.00 mfi0: firmware stuck in state 0 mfi0: Firmware not in READY state, error 6 I'll have to try mps then, unless someone has an idea about this stuck in state 0 thing. it means that you should ask Dell for the information as the mfi(4) driver needs some special handling to support that exact chip. Probably needs some special initialization and a couple of if ()s, as usual. LSI/Dell are the people to talk to. /bz -- Bjoern A. Zeeb You have to have visions! ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On Sat, 29 Jan 2011, Damien Fleuriot wrote:
Hello lists,
I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server.
It ships with a SATA/SAS h200 RAID controller.
Sadly, the MFI driver doesn't seem to register for this card...
Find below the pciconf -lcvb
--
none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000
rev=0x02 hdr=0x00
vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
class = mass storage
subclass = SAS
bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled
bar [14] = type Memory, range 64, base 0xdf2b, size 65536, enabled
bar [1c] = type Memory, range 64, base 0xdf2c, size 262144, enabled
cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8)
cap 03[d0] = VPD
cap 05[a8] = MSI supports 1 message, 64 bit
cap 11[c0] = MSI-X supports 15 messages in map 0x14
--
I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119:
--
{0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, Dell PERC H200 Integrated},
--
It's 1f1d not 1f1e. I hope it was only a paste problem into email?
Rebuilt the kernel, tried it on the server, still no luck recognizing
the RAID card.
As a last resort I'll be setting the drives to passthrough and using a
software RAID, but I'd much rather this worked out.
Note that mfi actually recognizes Dell's h700 and h800 cards.
Anyone managed to get the h200 card working yet ?
@hackers: please keep me cc'd, I'm not subscribed to this list.
Regards,
--
dfl
___
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: netinet6 little cleanup
On Fri, 7 Jan 2011, joris dedieu wrote: Hi, As I was reading netinet6 code, I found some redundant SYSCTL_DECL. Why are the redundant currently? Scrolling though I am not seeing the duplicate removed. They are just distributed? I don't know if it's really useful but here is a patch to clean it. - remove SYSCTL_DECL(_net_inet6_ip6) and SYSCTL_DECL(_net_inet6) from c files + add them to netinet6/in6_var.h header (like for netinet). Yeah, that's a different thing. /bz -- Bjoern A. Zeeb You have to have visions! ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: flowtable_cleaner/flowtable_flush livelock
On Sat, 20 Nov 2010, Bjoern A. Zeeb wrote: On Sat, 20 Nov 2010, Mikolaj Golub wrote: Hey, On Sat, 20 Nov 2010 17:03:13 + (UTC) Bjoern A. Zeeb wrote: BAZ I think net@ would have been a better initial place but since this BAZ seems to be a problem when interacting with VIMAGE BAZ freebsd-virtualization might be better. BAZ What you could try is: BAZ http://people.freebsd.org/~bz/20100216-10-ft-cv.diff Ah, I have recalled I had already saw this patch but did not understand what the problem was that it fixed, thus did not associated it with my case (actually, I thought you had committed all these patches to the tree long time ago and I was running the kernel with them already :-). BTW, the patch needs updating: in the current flow_full() wakes up flowcleaner too, and flowcleaner sleeps for flowclean_freq instead of 10*hz (see the attached patch). For sure it does; as you can see form the date in the file name, that patch was from the beginning of the year. With the patch I can't reproduce the lock. Only the crash I mentioned in my first letter is observed: Hmm, I guess I should get the updated version comitted then. So I did now. -- Bjoern A. Zeeb You have to have visions! ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: flowtable_cleaner/flowtable_flush livelock
On Sat, 20 Nov 2010, Mikolaj Golub wrote: Hi, Running something like below under VirtualBox (CURRENT, VIMAGE) ... So the question is who is guilty in this situation? ULE? flowtable? Or jail/epair, which should not allow simultaneous entering of flowtable_flush? In general: you for running an experimental feature;-) Seriously, flowtable has a number of different problems: 1) you will leak neighbor entries still 2) I have patches for VIMAGE but if you are running VIMAGE you are advised not to run flowtable. 3) FLOWTABLE should go from GENERIC but that's a different story. I think net@ would have been a better initial place but since this seems to be a problem when interacting with VIMAGE freebsd-virtualization might be better. What you could try is: http://people.freebsd.org/~bz/20100216-10-ft-cv.diff /bz -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: flowtable_cleaner/flowtable_flush livelock
On Sat, 20 Nov 2010, Mikolaj Golub wrote: Hey, On Sat, 20 Nov 2010 17:03:13 + (UTC) Bjoern A. Zeeb wrote: BAZ I think net@ would have been a better initial place but since this BAZ seems to be a problem when interacting with VIMAGE BAZ freebsd-virtualization might be better. BAZ What you could try is: BAZ http://people.freebsd.org/~bz/20100216-10-ft-cv.diff Ah, I have recalled I had already saw this patch but did not understand what the problem was that it fixed, thus did not associated it with my case (actually, I thought you had committed all these patches to the tree long time ago and I was running the kernel with them already :-). BTW, the patch needs updating: in the current flow_full() wakes up flowcleaner too, and flowcleaner sleeps for flowclean_freq instead of 10*hz (see the attached patch). For sure it does; as you can see form the date in the file name, that patch was from the beginning of the year. With the patch I can't reproduce the lock. Only the crash I mentioned in my first letter is observed: Hmm, I guess I should get the updated version comitted then. How do you reproduce the crash? Is it just another ifioctl race as from kern/146250? /bz -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Winbond Watchdog [Was Re: Supermicro BIOS's watchdog feature?]
On Sat, 7 Aug 2010, Xin LI wrote: Hey, a bit unrealted but I faced some of those problems lately as well. On 2010/07/01 00:12, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: Dag-Erling Smørgrav d...@des.no writes: Perhaps the motherboard has additional watchdog hardware? If you disable the watchdog in BIOS, does ichwd still work? If I kill -9 watchdogd the system do reset itself so I think ichwd(4) really works even if BIOS setting is 'Disabled' (but I'm not sure if this method is right? Looking at the code I think the answer is probably Yes though) Yes. This confirms my hypothesis, which is that your motherboard has additional watchdog hardware, and that the BIOS setting controls that, not the ichwd watchdog timer. Just disable the watchdog in BIOS and use ichwd instead. Thanks, you are absolutely correct that they are using another watchdog (on Winbond Super I/O chip). With help from some datasheets floating around the Internet and playing with the motherboard a little bit, now I have a first cut of a watchdog(9) interfaced driver for the chip and have confirmed working on the motherboard. I'm still polishing up the driver, there seems to be no way to figure out the base port address directly (datasheet said it's either 0x2e and 0x4e) so for now I have its device identify method to do some dirty hacks (outb/inb directly) and only check if with appropriate key entered to the port we will get non-0xff value. I'm not sure if that would be acceptable? I'll try to further read the spec and see if we have some better way of doing this and publish the driver code hopefully in the next week. I have a fintek locally but they all basically seem to operate after the same scheme. I had a very simple inb/outb /dev/io based user space solution for it and went to the quick and dirty kernel module. There are not many assertions put in place and it only checks one of the two base ports as I had only done it for me so far. Unfortunately there is no ACPI WDRT entry here (either?). devinfo -r was to some use though. In case it'll help you or someone else I just put it online: http://people.freebsd.org/~bz/20100807-02-wd-fintek-f71882fg.diff /bz -- Bjoern A. Zeeb This signature is about you not me.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: interface for import/export flowtable
On Thu, 22 Jul 2010, alan yang wrote: Hey, Wonder people had implemented interface to import / export flowtable. what exactly do you want to accomplish with that? -- Bjoern A. ZeebFrom August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: elf obj load: skip zero-sized sections early
On Mon, 5 Jul 2010, Andriy Gapon wrote: on 02/07/2010 11:29 Bjoern A. Zeeb said the following: On Fri, 25 Jun 2010, Andriy Gapon wrote: Hey, Proposed patch skips zero sized sections without going into trouble of allocating section entry (progtab), doing zero-sized memory allocs and copies. I observe that sometimes zero-sized set_pcpu sections are produced in module objects, maybe when a module doesn't create any per cpu data of its one, but references external pcpu data. Not sure. [snip] This work is based on np@'s investigation and original patch: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html Have you guys figured this out already? By 'this' - do you mean why that zero-sized section is produced at all? Does it really matter why that happens? Well, no, I was thinking of the workaround and going ahead to commit somehting;) I stated my guess already. Now I see that it is enough to simply include sys/pcpu.h for this to happen. Inline assembly at the start of the said header unconditionally creates the section. If DPCPU_DEFINE is never used in a module, then set_pcpu section remains empty. Neither compiler nor linker have any reason to drop empty sections in the build process for amd64 modules. I am not sure if .section set_pcpu assembly can be made conditional or moved some place else, so that the section is only created when DPCPU_DEFINE is actually used. The same applies to VIMAGE btw. Same technique. /bz -- Bjoern A. ZeebFrom August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: elf obj load: skip zero-sized sections early
On Fri, 25 Jun 2010, Andriy Gapon wrote:
Hey,
Proposed patch skips zero sized sections without going into trouble of
allocating section entry (progtab), doing zero-sized memory allocs and copies.
I observe that sometimes zero-sized set_pcpu sections are produced in module
objects, maybe when a module doesn't create any per cpu data of its one, but
references external pcpu data. Not sure.
Main goal of this patch is to play nice with external debugging tools (e.g.
kgdb) which ignore zero-sized sections outright. Current code effectively
ignores but may apply their alignment to the next non-zero section if its
required alignment is smaller. So the patch should get rid of that side effect
as well as do some very tiny resource conservation.
This work is based on np@'s investigation and original patch:
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html
Have you guys figured this out already?
Adding kib to Cc: in case he can help.
/bz
diff --git a/sys/boot/common/load_elf_obj.c b/sys/boot/common/load_elf_obj.c
index 4b3aaea..6f3b349 100644
--- a/sys/boot/common/load_elf_obj.c
+++ b/sys/boot/common/load_elf_obj.c
@@ -221,6 +221,8 @@ __elfN(obj_loadimage)(struct preloaded_file *fp, elf_file_t
ef, u_int64_t off)
for (i = 0; i hdr-e_shnum; i++)
shdr[i].sh_addr = 0;
for (i = 0; i hdr-e_shnum; i++) {
+ if (shdr[i].sh_size == 0)
+ continue;
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
index a337fd0..b0df57d 100644
--- a/sys/kern/link_elf_obj.c
+++ b/sys/kern/link_elf_obj.c
@@ -555,6 +555,8 @@ link_elf_load_file(linker_class_t cls, const char *filename,
symtabindex = -1;
symstrindex = -1;
for (i = 0; i hdr-e_shnum; i++) {
+ if (shdr[i].sh_size == 0)
+ continue;
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
@@ -677,6 +679,8 @@ link_elf_load_file(linker_class_t cls, const char *filename,
/* Size up code/data(progbits) and bss(nobits). */
alignmask = 0;
for (i = 0; i hdr-e_shnum; i++) {
+ if (shdr[i].sh_size == 0)
+ continue;
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
@@ -737,6 +741,8 @@ link_elf_load_file(linker_class_t cls, const char *filename,
ra = 0;
alignmask = 0;
for (i = 0; i hdr-e_shnum; i++) {
+ if (shdr[i].sh_size == 0)
+ continue;
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
--
Bjoern A. ZeebFrom August on I will have a life. It's now up to you
to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Patch to Makefile.inc1 to mention which kernel config is being installed
On Tue, 5 Jan 2010, David Wolfskill wrote: Attached patch is against head; for the above, I had patched stable/7. Thoughts? INSTKERNNAME rather than INSTALLKERNEL? -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Patch to Makefile.inc1 to mention which kernel config is being installed
On Tue, 5 Jan 2010, David Wolfskill wrote: On Tue, Jan 05, 2010 at 01:59:13PM +, Bjoern A. Zeeb wrote: On Tue, 5 Jan 2010, David Wolfskill wrote: Attached patch is against head; for the above, I had patched stable/7. Thoughts? INSTKERNNAME rather than INSTALLKERNEL? Well, I was interested in knowing which config was being used, not so much what the name of the subdirectory in /boot was going to be. (Default value for INSTKERNNAME is kernel, which isn't something I find useful to report.) Woopps. Cache-corruption;-) The original one is fine then. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Jail on 2 interfaces?
On Tue, 22 Dec 2009, Mel Flynn wrote: Hi, first of all this would find more people to help on freebsd-jail as it has nothing to do with hackers ;-) I don't see this documented in jail(8) nor rc(8) nor defaults/rc.conf, so is it possible to have 2 IP's on 2 ethernet interfaces? And if so, is it settable for rc(8)? The usage case is to have the same jailed proxy server on two seperate internal networks. Ideally, the proxy will use one address for outgoing, so I guess I'll need a default route or dive into the squid config. At present I have: ifconfig_bge0=inet 192.168.177.60 netmask 255.255.255.0 ifconfig_em0=inet 192.168.176.60 netmask 255.255.255.0 ifconfig_em0_alias0=inet 192.168.176.62 netmask 255.255.255.255 jail_squid_rootdir=/usr/squid jail_squid_ip=192.168.177.62 jail_squid_ip_multi0=192.168.176.62 jail_squid_interface=bge0 But this created the IP on bge0 even though one exists on em0. Is it as simple as not specifying the interface and add the 177.62 alias on bge0? Ideally I'd have a jail_$jail_ip_multi$aliasno_interface=foo0, but my main worry is that the jail infrastructure understands the routing involved. From what you are writing I assume that you are on FreeBSD 7.2-Release or later; no official FreeBSD version before had supported multiple-IPs with a jail. What it did was what you were asking for. That's the problem. 1) either use ifconfig 2) or use jail + interfaces 3) but do not mix them (especially not overlapping) So I would suggest to do it like this: # Base system IPs. ifconfig_bge0=inet 192.168.177.60/24 ifconfig_em0=inet 192.168.176.60/24 jail_squid_rootdir=/usr/squid # Either use: jail_squid_ip=bge0|192.168.177.62/32,em0|192.168.176.62/32 # or: jail_squid_ip=bge0|192.168.177.62/32 jail_squid_ip_multi0=em0|192.168.176.62/32 but do not use jail_squid_interface=.. as that will be a global default for that jail. As you can see, I removed the ifconfig_em0_alias0 line. If you want to keep that and mix things then you could do: jail_squid_ip=bge0|192.168.177.62/32 jail_squid_ip_multi0=192.168.176.62/32 again without the jail_squid_interface=.. line. HTH /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Jail on 2 interfaces?
On Wed, 23 Dec 2009, Matthew Seaman wrote: Mel Flynn wrote: Hi, I don't see this documented in jail(8) nor rc(8) nor defaults/rc.conf, so is it possible to have 2 IP's on 2 ethernet interfaces? And if so, is it settable for rc(8)? The usage case is to have the same jailed proxy server on two seperate internal networks. Ideally, the proxy will use one address for outgoing, so I guess I'll need a default route or dive into the squid config. At present I have: ifconfig_bge0=inet 192.168.177.60 netmask 255.255.255.0 ifconfig_em0=inet 192.168.176.60 netmask 255.255.255.0 ifconfig_em0_alias0=inet 192.168.176.62 netmask 255.255.255.255 jail_squid_rootdir=/usr/squid jail_squid_ip=192.168.177.62 jail_squid_ip_multi0=192.168.176.62 jail_squid_interface=bge0 But this created the IP on bge0 even though one exists on em0. Is it as simple as not specifying the interface and add the 177.62 alias on bge0? Ideally I'd have a jail_$jail_ip_multi$aliasno_interface=foo0, but my main worry is that the jail infrastructure understands the routing involved. To do this directly is now possible in 8.0-RELEASE or better. You will need a custom kernel with 'options VIMAGE' and I believe the standard jail startup scripts need a bit of work in order for them to start the jail with the correct command line arguments to enable the vnet functionality. No, that's wrong. FreeBSD 7.2-R and later can do multi-IP jails and have the IPs on multiple interfaces; there is no need for a dedicated network stack. The routing is no much different than if you would do it in the base system with two IPs. if it works there, just putting it in a multi-IP jail with the adresses on the right interface will just work as well. If you want different routing for a jail use setfib with a multi-FIB based kernel (you may need to recompile the kernel for that) but you still won't need mutliple network stacks. Alternatively, you can achieve much the same effect that you want by using a simple one-ip jail and writing firewall rules to redirect traffic into it, and NAT traffic coming out of it. Using firewall NAT with jails is something I often see and usually never understand unless people only have a single IP and want to share that between lots of jails (though if not duplicate services exist, that will just work as well by default these days as well). -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] Improved jail fstab functionality inside rc.d (needs testers and review)
On Sun, 29 Nov 2009, Merijn Verstraaten wrote: My apologies if these are the wrong lists for this sort of thing but it was unclear to me where else to go with additions like this. You may try freebsd-jail@ Make sure to get a review from simon@ for this. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: zero size set_pcpu linker sets
On Tue, 24 Nov 2009, Navdeep Parhar wrote: Hi, objdump -h shows that most, but not all, KLDs on amd64 have a set_pcpu section of size 0. Why? What is the difference between having a 0 sized set_pcpu vs. not having it at all? The kernel linker considers the alignment requirements of these empty sections and advances mapsize/mapbase. This bothers my kgdb (which is slightly modified to deal with amd64 KLDs). So what's your real problem? I'm using the patch shown here as a stopgap measure. I think the correct fix is to not have these empty sections in the KLD to begin with. Right. The problem here is a bug with ld and linker sets and size and aligment calculations the the elf section is started when not all of this is known correctly and it's not fixed later. This came up with that netisr bug where we had seen the misalignment of the dpcpu set. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Changes in IPv6 Configuration
On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote:
Hi,
With the recent changes to /etc/rc.d for network start-up. I was
wondering
what is now correct. The previously working ipv6 configuration no longer
creates a static default route, and I have not been able to figure out why.
After boot, if I manually add the default route for ipv6, all works OK but I
must be missing something to make it happen automatically. Currently, I have
this in my /etc/rc.conf and this does not work. Any help would be appreciated.
ipv6_prefer=YES
ifconfig_re0_ipv6=inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen 64
ipv6_defaultrouter=2001:4d48:ad51:32::3
ipv6_network_interfaces=auto
ipv6_default_interface=re0
can you try this change (just pasted in):
Index: etc/rc.d/routing
===
--- etc/rc.d/routing(revision 197153)
+++ etc/rc.d/routing(working copy)
@@ -132,7 +132,7 @@
if [ -n ${ipv6_static_routes} ]; then
for i in ${ipv6_static_routes}; do
ipv6_route_args=`get_if_var $i ipv6_route_IF`
- route ${_action} -inet6 ${route_args}
+ route ${_action} -inet6 ${ipv6_route_args}
done
fi
/bz
--
Bjoern A. Zeeb What was I talking about and who are you again?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Changes in IPv6 Configuration
On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote:
Hi,
On Sunday 13 September 2009 18:58:02 Bjoern A. Zeeb wrote:
On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote:
Hi,
With the recent changes to /etc/rc.d for network start-up. I was
wondering what is now correct. The previously working ipv6 configuration
no longer creates a static default route, and I have not been able to
figure out why. After boot, if I manually add the default route for ipv6,
all works OK but I must be missing something to make it happen
automatically. Currently, I have this in my /etc/rc.conf and this does
not work. Any help would be appreciated.
ipv6_prefer=YES
ifconfig_re0_ipv6=inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen
64 ipv6_defaultrouter=2001:4d48:ad51:32::3
ipv6_network_interfaces=auto
ipv6_default_interface=re0
can you try this change (just pasted in):
Index: etc/rc.d/routing
===
--- etc/rc.d/routing(revision 197153)
+++ etc/rc.d/routing(working copy)
@@ -132,7 +132,7 @@
if [ -n ${ipv6_static_routes} ]; then
for i in ${ipv6_static_routes}; do
ipv6_route_args=`get_if_var $i ipv6_route_IF`
- route ${_action} -inet6 ${route_args}
+ route ${_action} -inet6 ${ipv6_route_args}
done
fi
/bz
Thank you very much. That change did work and now the IPv6 default
gateway
is being added to the route table on start-up.
Thanks a lot for reporting and testing. I just comitted the
correction.
/bz
--
Bjoern A. Zeeb What was I talking about and who are you again?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need help trying to to use the ntohl() call with in_addr
On Fri, 14 Aug 2009, Max Laier wrote:
On Friday 14 August 2009 05:29:19 bert wiley wrote:
Hi everyone
Im new to list and this question may be out of place. This is my first
post. Im new to freebsd and trying to understand how to create a jail from
some system calls. I followed the jail subsystem description from the
handbook and im having a problem or may be using the call incorrectly. But
here is what im trying to do.
int main()
{
struct in_addr ipaddr;
struct jail myjail;
char path[PATH_MAX];
realpath(/tmp, path);
myjail.version = 1;
myjail.path = path;
myjail.hostname = testjail;
const char *ip;
ip = 192.168.1.142;
inet_aton(ip, ipaddr);
myjail.ip4 = ntohl(ipaddr.s_addr); // I get and error here, invalid
conversion from _uint32_t' to in_addr*
myjail.ip4 = ipaddr.s_addr;// and and error here, invlid
conversion from in_addr_t to in_addr*
}
I know that there is more that needs to be done but this just a test stub
as im trying to work thru the calls and understand whats going on.
Any would be appreciated thanks.
Take a look at the jail(2) man page:
The ``ip4s'' and ``ip6s'' give the numbers of IPv4 and IPv6 addresses
that will be passed via their respective pointers.
The ``ip4'' and ``ip6'' pointers can be set to an arrays of IPv4 and IPv6
addresses to be assigned to the prison, or NULL if none. IPv4 addresses
must be in network byte order.
So you'd do something like the following:
myjail.ip4s = 1;
inet_aton(ip, ipaddr);
myjail.ip4 = ipaddr;
You don't have to switch byte order.
and in that case of 7.2-R or later multi-IP jails the version should
not be 1 either.
I fixed tools/regressions/priv the other day; maybe this helps a bit
as well:
http://svn.freebsd.org/viewvc/base/head/tools/regression/priv/main.c?r1=173679r2=196172
/bz
--
Bjoern A. Zeeb What was I talking about and who are you again?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Jails, loopback interfaces and sendmail
On Thu, 4 Jun 2009, Dirk Engling wrote: Hi, However, grep -R 127.0.0.1 /etc reveals, that sendmail in many places assumes localhost to be on 127.0.0.1 instead of looking it up in /etc/hosts or using 127.0.0.0/8 to identify a local connection. or possibly other methods that would find even more things to be local. I worry that more programmers made those assumptions, possibly breaking more tools. yes, bind tools are another of those things that have problems with various address magics. My question is: Who's the right guy to beg to fix sendmail or alternatively would it be smart to allow each jail to have its own If programmers assume 127.0.0.1 is hte one and only loopback it's because of two things - 1) this has been done in the very old days where people updated the hosts file with uucp to know all hosts in the nwetwork and was never updated. or 2) they are clueless or lazy. concept of 127.0.0.1 on a dummy interface mapped to all jails, that As others mentioned connection from/to 127.0.0.1 will be mapped to the primary address of the jail; if you listen on 127.0.0.1 and the primary address is a public address you will be visible to the world (given your base system routes and permits that address to be reached). But that's been like that since probably 4.0. With the virtual network stack you will be bale to have your own loopback with each jail do not even think about doing something like this; it would never ever hit the tree anymore and it has been done by others already (for you - and others;). /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Jails, loopback interfaces and sendmail
On Thu, 4 Jun 2009, Gregory Shapiro wrote: If programmers assume 127.0.0.1 is hte one and only loopback it's because of two things - 1) this has been done in the very old days where people updated the hosts file with uucp to know all hosts in the nwetwork and was never updated. or 2) they are clueless or lazy. To avoid being labeled clueless or lazy, I'll offer a third option. For sendmail I had much rather thought about option 1) and absolutely not about option 2) as if you have ever known what S5 was and could no longer read your $ sign and 4 on the keyb you know that sendmail people are not lazy or clueless! Back to the OI problem: 8.12.7/8.12.7 2002/12/29 yes, that's not from stone age:( It's quite said, that systems not being able to poperly resolve hostnames are doing emails these days. Anyway, yeah, it's good that it's only config files; nethertheless I don't like it as you probably do not either. Have you ever thought about having those files changed just for FreeBSD? Or had there been porblems on FreeBSD systems with localhost as well? Has it been a special time with localhost and IPv6 that casued problems as 2002 has been rather late in terms of sendmail and resolver etc. What had started to cause those problems? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPsec in GENERIC kernel config
On Mon, 27 Apr 2009, Sam Leffler wrote: Hi, Jan Melen wrote: Hi, Again when I compiled a custom kernel just to enable IPsec in the FreeBSD kernel it came to my mind why is it so that the IPsec is not enabled by default in the GENERIC kernel configuration file? At least for me the GENERIC kernel configuration would do just fine if the IPsec would be enabled in it by default. Now I have to build a custom kernel just for IPsec btw IPsec is even mandatory for a host supporting IPv6. IPsec incurs a performance hit. Fix that and it can be enabled in GENERIC. There is even a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: multi-ip jail patch on freebsd 7
On Sat, 19 Jul 2008, Giulio Ferro wrote: Since the multi-ip jail feature isn't yet part of the base system (why???) I was searching the internet for a suitable patch to apply manually. I couldn't find any. The one I found didn't apply cleanly to a 7 system. Can any of you point me to a working multi-ip jail patch? freebsd-jail@ would be a better list. I would happily point you at one but my webserver is down at the moment. I hope you can waut anther few days as I am swamped... -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I translate IP to hostname in C
On Thu, 22 May 2008, John Timony wrote: Hi, I am writing a c program in FreeBSD,and I can not translate a ip to hostname ,i wonder if there is a function to take this job... You mean like gethostbyaddr()? See also http://www.unixguide.net/network/socketfaq/2.24.shtml for further inspiration on this but slightly different topic. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Documentation on writing a custom socket
On Sun, 9 Mar 2008, Hans Petter Selasky wrote: On Saturday 08 March 2008, Robert Watson wrote: On Sat, 8 Mar 2008, Hans Petter Selasky wrote: For example, do you anticipate using or even needing the routing facilities, and how might you map ISDN telephony parts into the normal network stack infrastructure of addresses, routing, interfaces, etc? Hi Robert, ISDN is very simple. In the ISDN world there is a term called TEI which is the Terminal Entity Identifier. This kind of like an IP address. Terminal Endpoint Identifier ... -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpt driver: check raid status
On Wed, 5 Mar 2008, Cristiano Deana wrote: Hi, I'm using a 7-RELEASE on a Dell PowerEdge 1955, using a mpt driver to manage a hardware raid1. Is there any way to check the status of the raid? Not really. Now it's running on a single disk (the second one failed and has been removed), and the only thing i can see are: mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 in messages. Thanks in advance mpt0: mpt_cam_event: 0x16 MPI_EVENT_SAS_DISCOVERY most likely started mpt0: mpt_cam_event: 0x12 MPI_EVENT_SAS_PHY_LINK_STATUS mpt0: mpt_cam_event: 0x16 MPI_EVENT_SAS_DISCOVERY most likely done mpt0: mpt_cam_event: 0x15 MPI_EVENT_IR2 that could be LD/PD/... state changed mpt0: mpt_cam_event: 0x21 MPI_EVENT_LOG_ENTRY_ADDED mpt0: mpt_cam_event: 0x15 MPI_EVENT_IR2 mpt0: mpt_cam_event: 0x21 MPI_EVENT_LOG_ENTRY_ADDED mpt0: mpt_cam_event: 0x15 MPI_EVENT_IR2 mpt0: mpt_cam_event: 0x21 MPI_EVENT_LOG_ENTRY_ADDED Giving more details would depend on a subtype which is dependend on the event. What we's really need is someone with the specs to write the code and add the printfs, etc. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: doubt about IPSEC - Freebsd 7
On Mon, 26 Nov 2007, Baldur Gislason wrote: Hi, And since we're on this subject... is it possible to do IPSEC over UDP tunnels in FreeBSD now? I have a couple of networks with dumb NAT and need a way to tunnel out of them in a reliable manner. only with the patch, not out of the box. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Fri, 16 Nov 2007, Skip Ford wrote: Hi, How about renaming procstat(1) to proc(1), rolling up all of calling it proc(1), I think, is actually not a good idea either. That is way more confusing for people who still think about /proc and do not know the difference between (1) or (4). I like the procstat as it aligns well with other things like fstat netstat sockstat systat vmstat gstat iostat pmcstat ... I admit we also have some *info tools like ffsinfo/diskinfo/rpcinfo/.. but ``pinfo'' seems to better fit the *stat category of tools;-) I am not able to find anything but a simple C wrapper for /proc/*/stat for linux on the web easily (which I suppose could as well be a sh skript) and cannot even find something like procstat on the linux machines I have access to. But there seems to be a procinfo that seems to as well extract information from /proc/ on linux. So having pinfo or procinfo might more confuse people to expect something differently and even worse might mean to be the same tool with compatible command line. While thinking we should try to aling with other OSes and not confuse users coming from non-BSD worlds, procstat to mee seems to be the thing that would best fit for our tree. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1000+ day uptime 5.3-RELEASE box
On Mon, 12 Nov 2007, Maxim Konovalov wrote: On Mon, 12 Nov 2007, 04:08-0600, Kevin Day wrote: We installed a 5.3-RELEASE box back in 2004, and it's been running pretty hard ever since with no crashes, reboots or anything. We're about to finally take it down to upgrade the OS soon - are there any stats anyone wants to see before we do? I know in the past there have been some I wonder if that code path ever happened musings that maybe I can answer. The system is running lighttpd/php/mysql on a pretty busy website non-stop during that period. Pasted below are some stats that I thought someone might want to see, even if it's just searching the archives later. I have no idea which of these counters have wrapped around. The netstat -m counters definitely don't look right. Email me in the next few days if you want to see something I haven't yet pasted: ts1# uptime 9:35AM up 1076 days, 19 hrs, 1 user, load averages: 0.43, 0.35, 0.31 4.x is way better :-) $ uptime 6:06PM up 1725 days, 23:07, 1 user, load averages: 0.31, 0.30, 0.26 $ uname -r 4.4-RC [ we need to redirect this thread to -chat :-) ] or advocacy like http://lists.freebsd.org/pipermail/freebsd-advocacy/2003-August/000225.html -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it possible to use IPv4 and IPv6 in a same jail?
On Tue, 31 Jul 2007, LI Xin wrote: Hi, Is it possible to use IPv4 and IPv6 in a same jail? Or do I have to write a listening daemon that acts as a proxy that runs in the host? jails do not (yet) support IPv6. I hope to be working on that again by the end of the week. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD OLPC
On Fri, 8 Jun 2007, Diomidis Spinellis wrote: Hi, Is anybody working on running FreeBSD on the One Laptop Per Child platform http://www.laptop.org? I'd be interested to try it, but I wouldn't want to duplicate work. The only thing I've found with a web search are some pictures of an OLPC at BSDCan bz's homepage. The first stumbling block would be booting with OLPC's OFW. Oh that was during the last day's post-conference social event, lateish in a bar and thing was running out of battery and crashed two times... There was a talk about it http://www.bsdcan.org/2007/schedule/events/57.en.html I had seen the presentation at FOSDEM and there was that How Open Source Projects Survive Poisonous People, so I didn't attend. I am not going to comment more on the Software that this thing was running (the built-in camera was working;) but I don't think there is anything BSD related... Considering OFW, Sun released that under a 3 clause BSD license somewhen last year imho. -- 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: SoC: Distributed Audit Daemon project
On Sun, 27 May 2007, Benjamin Lutz wrote: Hi, [ log shippping daemon for audit and other other logs ] [ syslog problems ] sorry I have to cut this short;) What Alexey said - this will be about log shipping not about writing single log records etc. Your syslog problems are outside the scope of this topic as long as it does not come to 'shipping' syslogged log files, i.e. after newsyslog rotated them, to another machine and for that hooking into the distributed log (shipping) daemon. Having a generic, more secure and reliable (local) logging mechnism should be discussed in at least another thread. You may as well think of taking this idea to IETF as RFC 3164 lives there as a Memo these days and it might be a general enough thing for everyone. I wonder if there are no lightwight but more secure and reliable implementations out there already. Maybe time for some research. /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: Multiple IP Jail's patch for FreeBSD 6.2
On Mon, 14 May 2007, Ed Schouten wrote: Hi, * Andre Oppermann [EMAIL PROTECTED] wrote: I'm working on a light variant of multi-IPv[46] per jail. It doesn't create an entirely new network instance per jail and probably is more suitable for low- to mid-end (virtual) hosting. In those cases you normally want the host administrator to excercise full control over IP address and firewall configuration of the individual jails. For high-end stuff where you offer jail based virtual machines or network and routing simulations Marco's work is more appropriate. Is there a way for us to colaborate on this? I'd really love to work on this sort of stuff and I think it's really interesting to dig in that sort of code. I already wrote an initial patch which changes the system call and sysctl format of the jail structures which allow you to specify lists of addresses for IPv4 and IPv6. Not that pjd@ hasn't had a that for IPv4 for a long time the code for v6 is basically in p4. In theory, the only thing that needs to be done in the kernel, is adding bits to the netinet6 code to prevent usage of unauthorized IPv6 addresses (nothing is altered yet). In theory things sound a lot simpler than they are in real world. You'll also need to solve the binding to 0, source address selction, etc. problems. Been there. The problems I had that things paniced for me - cannot remmeber why - and so I started to cleanup the code and assimilate it to what v4 had, which hasn't helped because I hit deeply nested function calls, which returned modified values in error cases or for one code path so things would have been wrong for the second. In the end I had to timeout the project, also because it was clear that vnet would come. I had a short glance at the dflbsd code after they announced it and it looked like that it wouldn't hold up a serious review for all code paths. In theory things sound a lot simpler than they might be. I should talk to andre during and look at your patch after BSDCan. I am pretty much unsure what andre is up to beyond what pjd has (and only needs to be updated to HEAD [I have a local patch for that in case anyone is interested]). /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: Unable to stop a jail
On Fri, 1 Dec 2006, Steven Hartland wrote: Hi, We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? no the jails should really be gone (you should not find any sockets or processes for them after some seconds) - at least it should be that way... See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 -- 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: Phantom Jails
On Fri, 17 Nov 2006, Dirk Engling wrote: Hi, Rumors went around and tales were told about jails magically booing around in prison list, even after they deceased. ... My suggestion would be (I will provide a patch, if discussion produces no major disagreement) to release ucred structs held by sockets as soon as the process dies. They are being used for accounting purposes only, anyway. The same may apply to the other types of phantom jails, as well. I could not create those deliberately and therefore can not exactly spot the proper location to fix. Comments? P.S.: if you want to reproduce a phantom jail try the following: 1) create and start a jail 2) Start a ssh/web/whatever server within the jail 3) Connect to that server from the host system. 4) Keep this connection open while you kill the jail 5) Do a 'jls' and compare its output to ps axuu | grep J 6) Kill the process that connected to the service. 7) Do a 'jls' again. while this works you can also reproduce it if you log out of the jail wait for the sockets to go away entirely and then stop the jail because what keeps the jail up is not a socket but is related to devfs and ?tys. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 -- 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: [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: tun and SIOCSIFADDR
On Mon, 5 Jun 2006, David Gilbert wrote: I read in the if_tun manpage that it supports SIOCSIFADDR (such that it works with ifconfig). I like examples, so I search the ifconfig source code for SIOCSIFADDR. None. Then I search the entire source tree. ppp uses it to set the IPX address. Obviously SIOCSIFADDR is not the preferred way to do this anymore. Hints? SIOCSIFADDR/SIOCSIFDSTADDR was deprecated about 10 years ago. See man 4 netintro /Calls which are now deprecated are . If you want SIOCSIFADDR/SIOCSIFDSTADDR for tun you need a patch I have in my tree. SIOCAIFADDR is what you really want. Look at ppp sources for examples for example. -- 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: tun and SIOCSIFADDR
On Mon, 5 Jun 2006, Bjoern A. Zeeb wrote: On Mon, 5 Jun 2006, David Gilbert wrote: I read in the if_tun manpage that it supports SIOCSIFADDR (such that it works with ifconfig). I like examples, so I search the ifconfig source code for SIOCSIFADDR. None. Then I search the entire source tree. ppp uses it to set the IPX address. Obviously SIOCSIFADDR is not the preferred way to do this anymore. Hints? SIOCSIFADDR/SIOCSIFDSTADDR was deprecated about 10 years ago. See man 4 netintro /Calls which are now deprecated are . If you want SIOCSIFADDR/SIOCSIFDSTADDR for tun you need a patch I have in my tree. SIOCAIFADDR is what you really want. Look at ppp sources for examples for example. oops. I misread IPX for IP but it should apply equally (though I don't have a patch for that). -- 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: Long Uptime
On Tue, 9 Aug 2005, Bob Bomar wrote: I have a machine that is about to turn 700 days uptime, and I have no plans on rebooting it any time soon. I just wanted to see if there was any infomation from the machine that anybody wanted. Well, I think there are enough people around with nnn days uptime (for nnn 500). I myself can think of a handfull of internal machines with such an uptime. In case you are interested in FreeBSD uptimes see for example: http://lists.freebsd.org/pipermail/freebsd-advocacy/2003-August/000225.html PS: In case this thread will continue please consider freebsd-chat or freebsd-advocacy. -- 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: sk0: discard oversize frame (ether type ....)
On Wed, 5 Jan 2005 [EMAIL PROTECTED] wrote: Hi, Using freeBsd 5.3. ... Maybe one of you guys can shed some light on this for me. please update to RELENG_5; it's fixed there already:) -- Greetings 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: execute a user process in the kernel
On Thu, 23 Sep 2004, Gordon David wrote: That's the point. I do not want the userland program to check /dev/fooctl from time to time. I want the kernel to notify the userland program instead. So how shall I do it? Maybe linker_load_file is a better way. man 2 kqueue ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw2 test utility
On Sat, 19 Jun 2004, Viktor Ivanov wrote: count is too high. And sometimes I need to see quickly what a colleague have done to the firewall and why it's not working as expected. use rcs or cvs for tracking changes -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Accessing (the i4b) device driver
On Fri, 30 Apr 2004, Martin Moeller wrote:
I'm totally new to FreeBSD programming, so please forgive my troll-like
question! I'd like to write a nifty little program showing if somebody is
calling me via an ISDN line. In the far future, the program should show the
caller's telephone number.
I am using this ince-quickly-hacked script with c4b and isdnd:
tail -100f /var/log/isdnd.log | perl bin/parse-isdnd-log.pl
--- cut ---
#!/usr/bin/perl
$|=1;
while () {
s/^(\w+ \d+ \d+:\d+:\d+) \w+ \w+\[\d+\]/$1/;
if (/CHD/) {
s/CHD \d+ //;
print $_;
}
}
# End;
--- cut ---
Gives me s.th. like this:
Apr 28 16:30:35: unknown incoming call from NotAvailable to 41 ctrl 3
or
Apr 28 17:23:30: unknown incoming call from 01234567890 to 41 ctrl 3
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
implications of SMP kernel on UP
Hi, what are the implications on running an SMP enabled kernel on a UP machine ? I first thought of things like: - performence (most likely not worth the discussion ?) - additional locking problematic ? - ... ? Or asked the other way round: why would I want to disable SMP on a kernel that is going to run on a UP machine ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
complete in src tree build world w/o /usr/include/** ?
Hi, I once again ran into the problem that a buildworld didn't succeed as unpriv. user without populating some headers to the base system before. But I do not want to populate headers that do not match my installed system on that machine if I am building for another one. This leads to inconsistency. Is there any chance that the whole source tree could be built w/o /usr/include/** ? or should that be the case already ? or why can't it be done ? -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SCM - local tree ?
Hi, how do you all sync your local tree with HEAD ? How do you store your changes locally ? cvs ? directory of patches ? Up to now I have copied a clean src and applied my patchset. This way I always have a clean src and a working copy here. But apart from the IO when copying I do not feel too lucky with this solution. Some best practice examples - or did I miss an article ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
isapnp vs pci card: device_probe_and_attach
Hi, I have put an older isapnp scsi card in my computer. For this card there is (not yet) a driver for FreeBSD. I also had some pci cards in there of course. When trying to load the driver for the pci card I run into device_probe_and_attach: %s%d attach returned 6\n This happens because the isapnp card seems to be on the same irq. I can see this is I kldload a driver skeleton I had written for this isapnp card. Another way to make the pci card get an irq and load ok is to set the irq in question from pci/pnp to isa in the bios so that the pci card will use another one. But I think this might render the isapnp card unusable. Q: is this possible when there is no driver for the isapnp card (loaded) that the pci card fails to get the irq ? Isn't there a way so that the PCI card will use another irq and initialize correctly ? Any comments or pointers to docs on this topics would help me. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interview in Byte with Chris Sontag/SCO and FUD relating toBSDsettlement agreement
On Tue, 17 Jun 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Josef Grosch [EMAIL PROTECTED] writes: : Where can one find a copy of the settlement agreement? I don't think the actual text of the agreement was ever made public. Here's one of the many press releases that a google search turned up: http://www.daemon.org/bsd-releases/misc/USL-lawsuit and here is the other: http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.htm -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Request for documenting IPSec, NAT/divert, ipfw, ipfilter ... inkernel flow ?
Hi, sorry for cross-mailing. Reply-to: set to freebsd-net. I have seen some discussion on freebsd-security etc. about some parts of the subject. I have seen older messages in archives. Regularly the same questions seem to come up. I have not found an all-including description of the answer to s.th. like: Can anybody tell me the order packets get processed in kernel related to IPSec, NAT/divert, ipfw, ipfilter, ... for incoming, outgoing, forwarding... ?. What about bpf, ... ? Is there any chance that some of the gurus can draw one or more ascii arts or xfig or whatever images that show the in kernel packet flow/processing ? Perhaps the doc project would also be happy to include it in the handbook or somewhere else. Would make life much more easier for many people. TIA -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
jail statfs patch
Hi,
attached is a patch for 5.0/HEAD that adds a fine grained option to
control what fs stats can be seen from within jails.
I know that there is also a kernel module available but as I already
had started to work on this I finished it for those people who
preferr it this way.
--- description ---
The patch is derived from a private patch done by
Christian Kratzer for RELENG_4 and the public patches
by Oliver Fromme (see kern/47586).
It adds following sysctl option:
security.jail.statfs_restricted
This fine grained option lets you control what and how
filesystem
statistcs are seen from within jails:
security.jail.statfs_restricted=0
this is the old behaviour where you could see everything
from the
whole host.
security.jail.statfs_restricted=1
this is the default for now. It shows only partitions
related to the
jail. If there is no root partition resp. the jail is on a
shared
partition a ``fake'' root with the correct values but a
stripped
f_mntonname will be shown.
security.jail.statfs_restricted=2
this is almost the same as 1 but it will show a ``full
fake'' for a
shared root mount. It will zero out almost all values and
write
jail-specific ``fakes'' to the others.
security.jail.statfs_restricted=3
this is almost the same as 1 but it will not show a shared
root at
all.
security.jail.statfs_restricted=4
this will not show anything but procfs, devfs, etc. within
the jail.
Be warned that this renders the jail to be almost unusable.
--- /description ---
for some sample output or to download the diff please have look at
http://sources.zabbadoz.net/freebsd/jail.html
PS: I am really happy about all the other people currently annouced
other jail patches. Could you also please update the manpage(s) ? ;-)
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
--- ./sys/kern/kern_jail.c.orig Mon Feb 3 12:57:06 2003
+++ ./sys/kern/kern_jail.c Tue Feb 4 18:54:55 2003
@@ -49,6 +49,11 @@
jail_sysvipc_allowed, 0,
Processes in jail can use System V IPC primitives);
+intjail_statfs_restricted = 1;
+SYSCTL_INT(_security_jail, OID_AUTO, statfs_restricted, CTLFLAG_RW,
+jail_statfs_restricted, 0,
+Processes in jail may not see all currently mounted file systems);
+
/*
* MPSAFE
*/
@@ -76,6 +81,9 @@
mtx_init(pr-pr_mtx, jail mutex, NULL, MTX_DEF);
pr-pr_securelevel = securelevel;
error = copyinstr(j.hostname, pr-pr_host, sizeof pr-pr_host, 0);
+ if (error)
+ goto bail;
+ error = copyinstr(j.path, pr-pr_path, sizeof pr-pr_path, 0);
if (error)
goto bail;
ca.path = j.path;
--- ./sys/kern/vfs_syscalls.c.orig Mon Feb 3 13:12:26 2003
+++ ./sys/kern/vfs_syscalls.c Sun Mar 2 19:31:38 2003
@@ -227,6 +227,10 @@
int error;
struct nameidata nd;
struct statfs sb;
+ int notsu, jrlen;
+
+ if (jail_statfs_restricted = 4 jailed(td-td_ucred))
+ return (ENOENT);
NDINIT(nd, LOOKUP, FOLLOW, UIO_USERSPACE, uap-path, td);
if ((error = namei(nd)) != 0)
@@ -244,9 +248,47 @@
if (error)
return (error);
sp-f_flags = mp-mnt_flag MNT_VISFLAGMASK;
- if (suser(td)) {
+ notsu = suser(td);
+ if (notsu || (jail_statfs_restricted jailed(td-td_ucred))) {
bcopy(sp, sb, sizeof(sb));
- sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0;
+ if (notsu)
+ sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0;
+
+ if (jail_statfs_restricted jailed(td-td_ucred)) {
+ jrlen = strlen(td-td_ucred-cr_prison-pr_path);
+
+ if (strlen(mp-mnt_stat.f_mntonname) jrlen) {
+ switch (jail_statfs_restricted) {
+ case 1:
+ bzero(sb.f_mntonname,
+ sizeof(sb.f_mntonname));
+ *sb.f_mntonname = '/';
+ break;
+ case 2:
+ bzero(sb, sizeof(sb
future of all the jail patches [was: Re: jail statfs patch]
On Mon, 3 Mar 2003, Christian Kratzer wrote: Hi, attached is a patch for 5.0/HEAD that adds a fine grained option to control what fs stats can be seen from within jails. I know that there is also a kernel module available but as I already had started to work on this I finished it for those people who preferr it this way. I think this answer got here by accident but nethertheless it's a good point. Du solltest denke ich trotzdem einen pr aufmachen damit es dafür eine art ticket gibt. Das hilft denke ich dass es aufgenommen wird. Christian asks me to file a PR to better get this tracked and perhaps included in mainstream. I had seen lots of jail discussion here the last months but I think there had been few PR submission. What is the overall opinion on this - file PRs ? What about including (at least some) of the (other) jail patches in HEAD ? What about jail-ng ? [ Perhaps take this discussion to -current ? ] -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
