Re: CMOS clock won't do 2000
In message [EMAIL PROTECTED] Brian
Beattie writes:
: I have an older 486 system, running 3.4R that has a cmos clock that seems
: to be unwilling to accept years out side the range 94-99. The bios seems
: willing to set dates between 1994-2099, but after reboot any year not
: between 94-99 is converted to {20,19}94.
ntpdate on boot is what we use in the village for this sort of thing.
We run ntp at other times.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning up semaphores in kernel
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers */
SEMMNS, /* # of semaphores in system */
SEMMNU, /* # of undo structures in system */
SEMMSL, /* max # of semaphores per id */
SEMOPM, /* max # of operations per semop call */
SEMUME, /* max # of undo entries per process */
SEMUSZ, /* size in bytes of undo structure */
SEMVMX, /* semaphore maximum value */
SEMAEM /* adjust on exit max value */
};
You probably want to increase either SEMMNI or SEMMNS.
I've noticed that but why are they so "round"? Is there any corelation
between all these numbers? I don't want to break my kernel by guessing.
options SEMMAP=31
options SEMMNI=11
options SEMMNS=61
options SEMMNU=31
options SEMMSL=61
options SEMOPM=101
options SEMUME=11
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning up semaphores in kernel
SEMMNI is the number of semaphore ids, i.e., the number of times you
can call 'semget()' without deleting any semaphores. SEMMNS is the
actual number of semaphores in the system, which should be = SEMMNI.
Of course, you can ask 'semget()' to give you up to SEMMSL semaphores
on each call, so SEMMNS should usually be larger than SEMMNI.
Ideally, if you know the max number of semaphores that a program
obtains via a semget call, set SEMMSL to that value. Then, if you
know the max number of semid's that are in use at any given time, then
set SEMMNI to that value. Then compute SEMMNS = SEMMNI*SEMMNS. This
will guarantee you have enough, as long as your usage information is
accurate.
Personally, I would just bump up SEMMNI and SEMMNS by 20% (or
whatever). Your documentation that came with your application should
give you an idea of it's semaphore usage. Use that as the guide as to
what to set these things to as a starting point.
-Brian
Andrey Novikov wrote:
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers */
SEMMNS, /* # of semaphores in system */
SEMMNU, /* # of undo structures in system */
SEMMSL, /* max # of semaphores per id */
SEMOPM, /* max # of operations per semop call */
SEMUME, /* max # of undo entries per process */
SEMUSZ, /* size in bytes of undo structure */
SEMVMX, /* semaphore maximum value */
SEMAEM /* adjust on exit max value */
};
You probably want to increase either SEMMNI or SEMMNS.
I've noticed that but why are they so "round"? Is there any corelation
between all these numbers? I don't want to break my kernel by guessing.
options SEMMAP=31
options SEMMNI=11
options SEMMNS=61
options SEMMNU=31
options SEMMSL=61
options SEMOPM=101
options SEMUME=11
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: CMOS clock won't do 2000
On Sun, 13 Feb 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] Brian
Beattie writes:
: I have an older 486 system, running 3.4R that has a cmos clock that seems
: to be unwilling to accept years out side the range 94-99. The bios seems
: willing to set dates between 1994-2099, but after reboot any year not
: between 94-99 is converted to {20,19}94.
ntpdate on boot is what we use in the village for this sort of thing.
We run ntp at other times.
I'm hopeing to run picobsd-router on this machine so adding extra
executables may not be possible. I grabbed the y2k test/fix from the BIOS
site (Phoenix bought Award). I includes a windoze95 fix, that seems to
adjust the clock on boot by running something from config.sys.
Brian Beattie| The only problem with
[EMAIL PROTECTED] | winning the rat race ...
www.aracnet.com/~beattie | in the end you're still a rat
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
sysctl for stack execute?
Is there a sysctl for FreeBSD which prevents execution in the stack segment? (ie. to prevent attacks from getting root) I'm using 3.4R. -- Dru Nelson Director of Network Operations http://www.egroups.com/ Voice: 415-546-2740 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl for stack execute?
On Sun, Feb 13, 2000 at 01:29:46PM -0800, Dru Nelson wrote: Is there a sysctl for FreeBSD which prevents execution in the stack segment? (ie. to prevent attacks from getting root) I'm using 3.4R. Atsuo Ohki sent a mail to -hackers on Feb 05 with a kernel-patch doing exactly this. The subject of the mail was "some guard against stack overflow attack". There were some problems with it though, like it breaking KLDs (read the reply by Matt Dillon). bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Setting the default gw (with c)
Greetings !
I have a question, I need to write a small program that sets the default
gw. It is written in C and I have looked at several way to do it. One
way is using ioctl but that way seems a little "old" and not very well
documented. Here is a simple snippet of my code, now when I run it I get
an error "error 22" invalid arg. Does anyone have experience with this
and can point out what I am doing wrong ? I did have it to where it
would work but the kernel never added my netmask to the routing table.
So the route would kinda "hang" their and not do anything. I did tell it
that it was being sent but. also the flags never where set proper on
the route (when doing route -dvn flush )
Any help would be great ! (oh if this looks familiar, I learned this
from reading both ruote.c and netstat.c. )
struct rt_data_msg{
struct rt_msghdr add_rtm;
union{
struct sockaddr sa;
struct sockaddr_in sin;
struct sockaddr_dl sdl;
}rt_dst, rt_gate, rt_mask;
};
int set_droute(char *gw){
int sockfd, i, err = 0;
int flags = 0, r_addrs = 0;
u_long inits;
char t_gw[32];
register int l;
struct rt_data_msg add_rt;
pid_t pid;
/* check to see if we have a gateway address or quit */
if(!gw){
ERR("set_droute: FREEBSD no route sent ! %d");
return(BAD);
}
else{
/* convet this address if not valid quit */
if((inet_aton(gw, so_gate.sin.sin_addr)) 0){
ERR("set_droute: FREEBSD route not valid ! %d");
return(BAD);
}
}
memset(add_rt, 0, sizeof(struct rt_data_msg));
/* check to see if thier is an existing route or not make an
entry from scratch */
if( (i = get_droute(t_gw)) == BAD){
/* make the address and netmasks */
if((inet_aton("0.0.0.0", add_rt.rt_mask.sin.sin_addr))
0){ err++; }
if((inet_aton("0.0.0.0", add_rt.rt_dst.sin.sin_addr))
0) { err++; }
if((inet_aton(gw, add_rt.rt_gate.sin.sin_addr)) 0){
err++; }
if(err 0){
ERR("get_droute: FREEBSD cannot set mask or dst
or gw invalid addresses %d");
return(BAD);
}
inits = RTV_EXPIRE;
inits |= RTV_RPIPE;
inits |= RTV_SPIPE;
inits |= RTV_SSTHRESH;
r_addrs = RTAX_DST;
r_addrs |= RTAX_GATEWAY;
r_addrs |= RTAX_NETMASK;
flags = RTF_UP;
flags |= RTF_GATEWAY;
flags |= RTF_STATIC;
flags |= RTF_PRCLONING;
/* add thier size */
#define ADD_SIZE(w) l = ROUNDUP(w.sa.sa_len)
#define ROUNDUP(a)((a) 0 ? (1 + (((a) - 1) | (sizeof(long) - 1)))
: sizeof(long));
ADD_SIZE(add_rt.rt_dst);
ADD_SIZE(add_rt.rt_gate);
ADD_SIZE(add_rt.rt_mask);
/* add their address family */
#define ADD_FAM(x) x.sin.sin_family = AF_INET;
ADD_FAM(add_rt.rt_dst);
ADD_FAM(add_rt.rt_gate);
ADD_FAM(add_rt.rt_mask);
ADD_FAM(add_rt.rt_genmask);
/* set up all of the flags and tables */
#define RD add_rt.add_rtm
RD.rtm_msglen = l;
RD.rtm_version = RTM_VERSION;
RD.rtm_type = RTM_ADD;
RD.rtm_flags = flags;
RD.rtm_addrs = rtm_addrs;
RD.rtm_inits = RTF_GATEWAY;
RD.rtm_pid = pid = getpid();
RD.rtm_seq = ++SEQ;
if( (sockfd = socket(PF_ROUTE, SOCK_RAW, 0)) 0){
ERR("set_droute: FREEBSD cannot open socket
%d");
}
/* send it to the kernel */
i = write(sockfd, (char *)add_rt, l);
syslog(LOG_ERR, "errno = %d ", errno);
}
else{
/* get a buffer for the data */
ERR("get_droute returned ok %d ");
}
return(GOOD);
}
Thank you
nathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for de driver (full-duplex packet loss problems)
On Fri, Feb 11, 2000 at 03:59:49PM -0500, Jim Mercer wrote: i hear that there are some patches which might fix some serious packet loss problems with the de driver in 100mbps fullduplex. i am running 3.4 (synced to stable via cvsup). with the mailing list archives down, i can't do my own search, but i was hoping someone on these lists could give me some pointers. Try www.deja.com and search the muc.lists.freebsd.* hierarchy. Just one question I always ask people trying to get things working at full-duplex, is the card plugged into a hub at the other end? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Proposal for CD reorganisation for 4.0
Hi, I was thinking (I know, I know, I shouldn't do that, it's bad for me ;)... Since we now have 3000+ ports, what are the chances of getting a special "FreeBSD Ports Distfiles" CD-ROM subscription set, which would just contain the distfiles? Since this set would be fairly low maintainance (just dump a copy of the FTP site onto CD :) it could be released at a low cost and with a fairly frequent update interval. I'm sure plenty of people would go for something which worked out to around $5 per month, including a lot of Linux people, since the CD would not have anything specific to FreeBSD on it. NetBSD and OpenBSD people should also be interested. This would also make the 4.0 set easier to get onto 4 disks, and it would do out of date slower (since the packages are prebuilt for that snapshot of -CURRENT). Another advantage is that we might be able to get rid of some NO_CDROMs, since the distfiles CD set would be around the cost of the media. Regards, -Jeremy -- |If I was not so weak, if I was not so cold, --+-- If I was not so scared of being broken, growing old, |I would be. I would be... frail. | - jars of clay / much afraid / frail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for CD reorganisation for 4.0
It's something we've been considering. :) Hi, I was thinking (I know, I know, I shouldn't do that, it's bad for me ;)... Since we now have 3000+ ports, what are the chances of getting a special "FreeBSD Ports Distfiles" CD-ROM subscription set, which would just contain the distfiles? Since this set would be fairly low maintainance (just dump a copy of the FTP site onto CD :) it could be released at a low cost and with a fairly frequent update interval. I'm sure plenty of people would go for something which worked out to around $5 per month, including a lot of Linux people, since the CD would not have anything specific to FreeBSD on it. NetBSD and OpenBSD people should also be interested. This would also make the 4.0 set easier to get onto 4 disks, and it would do out of date slower (since the packages are prebuilt for that snapshot of -CURRENT). Another advantage is that we might be able to get rid of some NO_CDROMs, since the distfiles CD set would be around the cost of the media. Regards, -Jeremy -- |If I was not so weak, if I was not so cold, --+-- If I was not so scared of being broken, growing old, |I would be. I would be... frail. | - jars of clay / much afraid / frail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for de driver (full-duplex packet loss problems)
On Sun, Feb 13, 2000 at 06:05:55PM -0500, Crist J. Clark wrote: with the mailing list archives down, i can't do my own search, but i was hoping someone on these lists could give me some pointers. Try www.deja.com and search the muc.lists.freebsd.* hierarchy. i'll poke about there. Just one question I always ask people trying to get things working at full-duplex, is the card plugged into a hub at the other end? actually, we started with cross over cables, and then suspecting them, tried jacking into a number of 10mbp and 10/100mbps hubs. still getting various problems (from high packet loss to not being able to sync up 100bps/fullduplex). -- [ Jim Mercer [EMAIL PROTECTED] +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for de driver (full-duplex packet loss problems)
Jim Mercer wrote: On Sun, Feb 13, 2000 at 06:05:55PM -0500, Crist J. Clark wrote: Just one question I always ask people trying to get things working at full-duplex, is the card plugged into a hub at the other end? actually, we started with cross over cables, and then suspecting them, tried jacking into a number of 10mbp and 10/100mbps hubs. still getting various problems (from high packet loss to not being able to sync up 100bps/fullduplex). Be warned that hubs don't play the full-duplex tune. You have have to use a crossover or a full-duplex switch. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rpath and inter library deps
Hello, I have a problem with shared libraries that need a shared library by themselves (FreeBSD-3.4-STABLE): imagine a shared library `libfoo.so'. This library depends on the X11 lib and therefore has a `libX11.so.6' NEEDED entry. On this system `libX11.so.6' was installed into '/vol/X11/lib', so `libfoo.so' has also an RPATH of '/vol/X11/lib'. `libfoo.so' itself was installed into '/vol/foo/lib'. Now, I want to link a binary against `libfoo.so': My object code does NOT contain a reference to `libX11.so', so linking with '-L/vol/foo/lib -R/vol/foo/lib -lfoo' should be correct. But the linker fails to resolve the references of `libfoo.so' to libX11 unless I specify '-L/vol/X11/lib -R/vol/X11/lib'. I think this should be considered as a bug. Any other opinions? BTW, how does the FreeBSD runtime linker uses RPATHs it finds in shared libraries? Does it use an RPATH only for satisfying the needs of the library in which the RPATH was found, or are all RPATHs concatenated? Björn Fischer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Loadable Code Modules?
howdy! i was wondering if FreeBSD had a kind of like DLL capability? i'd like to be able to do something as follows: // ... construct char *fileName moduleHandle = loadCodeModule(fileName); (char *)(*fn char *) myfn; // ii'm pretty sure i screwed that up myfn = getFunctionAddress(moduleHandle, "doSomethignCool"); // use fn releaseModule(moduleHandle); does such a thing exist in FreeBSD? If not, where would one start looking to add such functionality? thanks. marc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
