Re: Assembly, Kernels and Bootstraps
On Wed, 31 Jul 2002, Ryan Sommers wrote: :Greetings, : :Recently I became interested in researching and learning whatever I could :about how a computer boots and what is involved. There are probably better :places to get this information but since FreeBSD is my development :environment of choice I thought I would start here. : :I just have a few questions that if you could take a few minutes to answer :you would make my day. : :Several of the sites I have visited on assembly say it isn't needed :anymore. Is it still needed to write a bootstrap? : :Where is a good starting point to just read through some of the Kernel :source? Where is the entry point? I'm on all x86 architecture. : Ever think about reading the intel manuals? -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: reboot frm ddb
On Thu, 27 Jun 2002, Danny Braniss wrote: :hi, : how can i reboot - from the serial console - once im in the kernel :debugger? : :thanks, : : danny : If you're on a new enough version of FreeBSD (excuse my lack of knowing which exact version provide this feature), you can just type reset at the ddb prompt and have it reboot. Otherwise, you'll probably just have to: call cpu_reset -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: reboot frm ddb
On Thu, 27 Jun 2002, Sergey Lyubka wrote: :On Thu, Jun 27, 2002 at 12:27:37PM -0400, Andrew R. Reiter wrote: : On Thu, 27 Jun 2002, Danny Braniss wrote: : : :hi, : :how can i reboot - from the serial console - once im in the kernel : :debugger? : : : :thanks, : : : :danny : : : : If you're on a new enough version of FreeBSD (excuse my lack of knowing : which exact version provide this feature), you can just type reset at : the ddb prompt and have it reboot. Otherwise, you'll probably just have : to: call cpu_reset : : :BTW, if the page fault in kernel mode occurs. :is it any way to sync discs before reset ? : If you call boot(0) -- that should try to sync for you. --- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
On Wed, 15 May 2002, Alfred Perlstein wrote: :* Terry Lambert [EMAIL PROTECTED] [020515 01:36] wrote: : Alfred Perlstein wrote: : As Terry stated you can't do that, however you could cache that the : VNODE has a lock, that would reduce the requirement for calling the : ADVLOCK VOP. : You'd really have to know when the lock list went to NULL, to get : any benefit out of it, since locking would still end up being per-file : sticky. You could post-check after every successful unlock... but to : cache the remote state would mean another RPC to ask for locks, which : would just be front-loading the expense, instead of back-loading it. : :[snip] : :He could also maintain a local cache of this per vnode, basically :maintain a mirror of the lock list locally in order to see if a remote :op must be done. Isn't this sorta like coda? -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel hacker task: Floppy driver mode handling.
Someone already doing this? If not, I'm down.
On Tue, 11 Dec 2001, Poul-Henning Kamp wrote:
:
:There exists a patch for adding a mode to our floppy driver to
:add DEC RX50 media handling.
:
:The crucial part of this is the addition of this line:
:{ 10,2,0xFF,0x10,80, 800,1,FDC_300KBPS,1,0x2E,1 }, /* 400K DEC RX50 */
:
:But if one examines the fd.c driver, one cannot help but notice that the
:handling of densities is a bit convoluted, to put it mildly.
:
:I'm looking for a volounteer to do this, it is a quite simple job and
:I am quite sure that practically everybody has the hardware they need to
:do this :-)
:
:Cleaning it up consists of the following steps:
:
:1. Define a new set of (bitmap) macros to distinguish the drive type:
: #define FD_3S 0x0001 /* 3.5 single density */
: #define FD_5S 0x0002 /* 5.25 single density */
: ...
:And use these instead of the FD_1200 and similar in
:struct fd_data-type.
:
:2. Augment the struct fd_type with two new fields:
: int minor; /* minor device encoding */
: int drives; /* bitmap of compatible drives (FD_[35][SD]) */
:And fill these fields out in the fd_types[NUMTYPES] array.
:Add a termination entry at the end of the table so the
:NUMTYPES, NUMDENS, and FD_%d[5_25] #defines can be eliminated.
:
:3. Change the _clone code to use the new minor field instead of
:the private table it uses now. (Eliminate and avoid any
:use of NUMTYPES, NUMDENS and FD_%d[5_25]).
:
:4. Change the code in Fdopen to examine the drives field in the
:fd_types[] array instead of the hardcoded switch. (Eliminate
:and avoid any use of NUMTYPES, NUMDENS and and FD_%d[5_25]);
:
:5. Remove any other use of NUMTYPES, NUMDENS and FD_%d[5_25]
:
:6. Add the rx50 entry from above to the table to show how simple
:that is now.
:
:7. Make it possible to define a new mode from userland with an ioctl.
:(hint: instead of the index, put a pointer to the struct fd_type into
:the fd_data structure.)
:
:Preferably, send one patch per step rather than one huge patch since that
:will make reviewing easier.
:
:First volounteer to send me email gets the assignment.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
:FreeBSD committer | BSD since 4.3-tahoe
:Never attribute to malice what can adequately be explained by incompetence.
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with unsubscribe freebsd-hackers in the body of the message
:
--
Andrew R. Reiter
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Patch #3 (TCP / Linux / Performance)
On Sun, 2 Dec 2001, Lamont Granquist wrote: : :What is the remaining bottleneck in these tests? CPU? Interrupts? What :would you need to do to get that closer to the theoretical limit :(something around 920 Mbs for GigE IIRC)? Well, for one thing, I'd imagine that per-byte and per-copy overheads still exist since we're not in a zero-copy environment. -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patch #3 (TCP / Linux / Performance)
: :Ahh, but there are patches floating around that do support zero-copy. :Just ask Ken Merry and Drew Gallatin. I don't think they've been integrated :due to lack of testing time, but they've existed for 2 or so years now. : http://people.freebsd.org/~ken/zero_copy/ -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bugmeister discussion list
I thought it was normal process for a new FreeBSD mailing list to be hosted on another site until it was deemed beneficial to have @FreeBSD.org host it. Cheers, Andrew On Thu, 22 Nov 2001, Doug Barton wrote: :On 22 Nov 2001, Dag-Erling Smorgrav wrote: : : [apologies to those who receive multiple copies of this message] : : I've set up a [EMAIL PROTECTED] mailing list : : Any reason this can't/shouldn't be a freebsd.org mailing list? : :-- :We will not tire, we will not falter, and we will not fail. : - George W. Bush, President of the United States : September 20, 2001 : : Do YOU Yahoo!? : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-hackers in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPFW module
Yes, there is an open pr regarding this. In -current all this is fixed, but I know ipfw and, iirc, nfs modules have these problems in 4.4. Andrew On Fri, 9 Nov 2001, Dimitar Peikov wrote: : :This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my :kernel configuration file. After installing all I try to 'kldload ipfw' which :complains that ipfw module is already in kernel, but kldstat reports that :module is being loaded! Then I've decided to kldunload it Kernel panic : reboot! : :It is regular to kernel crash if ipfw is loaded as module, but why when it was :build into kernel? In that case it would be good kldload/kldunload to exit! :Why kldload loads module in case that it is compiled in kernel? : :-- :Dimitar Peikov :Programmer Analyst :Globalization Group :We Build e-Business : :RILA Solutions :27 Building, Acad.G.Bonchev Str. :1113 Sofia, Bulgaria : :phone: (+359 2) 9797320 :phone: (+359 2) 9797300 :fax: (+359 2) 9733355 :http://www.rila.com : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-net in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging question
On Tue, 30 Oct 2001, Mark Santcroos wrote: :How can I see in what piece of the kernel it is looping? :(I know about where it is, but not exactly) : Use ddb to set a break -- you may need to do this upon boot (boot -d) *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: apmd fixes
While fixing/adding that, might as well go ahead and fix the signal
handler enque_signal(). I don't believe using err() in in a signal
handler is recommended as it could possible allow for undefined behavior
to occur.
Andrew
On Sun, 14 Oct 2001, Walter C. Pelissero wrote:
:Here are a couple of patches to apmd (as of FreeBSD 4.4-STABLE) to fix
:a bug and add a feature necessary on my Vaio PCG-XG9.
:
:The fix is to handle properly termination signals (currently ignored).
:
:The feature is the -s option that lets you fake POWERSTATECHANGE when
:the BIOS doesn't report it. This enables you to do fancy things like
:reducing the LCD backlight brightness when you unplug the power
:supply. Something like this in apmd.conf:
:
:apm_event POWERSTATECHANGE {
: exec /bin/sh /usr/local/bin/my-preferred-power-state-change-script;
:}
:
:
:Here is the patch:
:
:--- /usr/home/wcp/tmp/apmd/apmd.c Fri Oct 12 20:22:34 2001
:+++ /usr/src/usr.sbin/apmd/apmd.c Sat Oct 13 14:58:35 2001
:@@ -55,7 +55,7 @@
: extern intyyparse(void);
:
: int debug_level = 0;
:-int verbose = 0;
:+int verbose = 0, soft_power_state_change = 0;
: const char*apmd_configfile = APMD_CONFIGFILE;
: const char*apmd_pidfile = APMD_PIDFILE;
: int apmctl_fd = -1, apmnorm_fd = -1;
:@@ -464,7 +464,6 @@
: int
: proc_signal(int fd)
: {
:- int rc = -1;
: int sig;
:
: while (read(fd, sig, sizeof sig) == sizeof sig) {
:@@ -476,8 +475,7 @@
: break;
: case SIGTERM:
: syslog(LOG_NOTICE, going down on signal %d, sig);
:- rc = 1;
:- goto out;
:+ return -1;
: case SIGCHLD:
: wait_child();
: break;
:@@ -486,9 +484,7 @@
: break;
: }
: }
:- rc = 0;
:- out:
:- return rc;
:+ return 0;
: }
: void
: proc_apmevent(int fd)
:@@ -548,6 +544,8 @@
:* the event-caught state.
:*/
: if (last_state != AC_POWER_STATE) {
:+ if (soft_power_state_change fork() == 0)
:+exit(exec_event_cmd(events[PMEV_POWERSTATECHANGE]));
: last_state = AC_POWER_STATE;
: for (p = battery_watch_list ; p!=NULL ; p = p - next)
: p-done = 0;
:@@ -642,7 +640,7 @@
: char*prog;
: int logopt = LOG_NDELAY | LOG_PID;
:
:- while ((ch = getopt(ac, av, df:v)) != EOF) {
:+ while ((ch = getopt(ac, av, df:vs)) != EOF) {
: switch (ch) {
: case 'd':
: daemonize = 0;
:@@ -653,6 +651,9 @@
: break;
: case 'v':
: verbose = 1;
:+ break;
:+ case 's':
:+ soft_power_state_change = 1;
: break;
: default:
: (void) err(1, unknown option `%c', ch);
:
:
:--
:walter pelissero
:http://www.pelissero.org
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with unsubscribe freebsd-hackers in the body of the message
:
*-.
| Andrew R. Reiter
| [EMAIL PROTECTED]
| It requires a very unusual mind
| to undertake the analysis of the obvious -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, Peter Wemm wrote: : :One comment: : :- cmpl$0, PCB_USERLDT(%edx) /* if there is one */ :+ movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */ :+ lealP_MD(%eax), %eax/* get mdproc from proc */ :+ cmpl$0, MD_LDT(%eax)/* if there is one */ : : :This can be written as: : movlTD_PROC(%ecx), %eax : cmpl$0, P_MD+MD_LDT(%eax) : :This is evaluated at assemble time. Yea, Kinda dumb on my part :-/ : :And this change: :movl %eax,PCPU(CURRENTLDT) /* store what we have */ : jmp 2f : :-1:pushl %edx/* call a non-trusting routine */ :+1:pushl %eax/* call a non-trusting routine */ : callset_user_ldt/* to check and load the ldt */ :- popl%edx :+ popl%eax : 2: : :is not good.. you still need to save %edx since set_user_ldt is free :to trash it (%edx is the secondary return value from a C function). : Hmm interesting. Thanks. :eg: :0xc02e75c4 set_user_ldt+36: mov0x10(%ebx),%edx :0xc02e75c7 set_user_ldt+39: mov%edx,(%eax,%ecx,1) :0xc02e75ca set_user_ldt+42: mov0x14(%ebx),%edx :0xc02e75cd set_user_ldt+45: mov%edx,0x4(%eax,%ecx,1) : :The code after this in swtch.s depends on %edx being preserved. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] :All of this is for nothing if we don't go to the stars - JMS/B5 : : *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: JKH Project: x86: pcb_ext
Peter,
Attached is the fix wrt your previous email. Again, can be found in
www.watson.org/~arr/fbsd-patches/
Cheers,
Andrew
--- include/pcb.h.orig Wed Sep 19 02:07:48 2001
+++ include/pcb.h Wed Sep 19 02:08:37 2001
@@ -61,7 +61,6 @@
int pcb_dr6;
int pcb_dr7;
- struct pcb_ldt *pcb_ldt; /* per process (user) LDT */
union savefpu pcb_save;
u_char pcb_flags;
#defineFP_SOFTFP 0x01/* process using software fltng pnt emulator
*/
--- include/pcb_ext.h.orig Wed Sep 19 02:07:54 2001
+++ include/pcb_ext.h Wed Sep 19 02:10:37 2001
@@ -43,20 +43,9 @@
struct vm86_kernel ext_vm86; /* vm86 area */
};
-struct pcb_ldt {
- caddr_t ldt_base;
- int ldt_len;
- int ldt_refcnt;
- u_long ldt_active;
- struct segment_descriptor ldt_sd;
-};
-
#ifdef _KERNEL
int i386_extend_pcb __P((struct thread *));
-void set_user_ldt __P((struct pcb *));
-struct pcb_ldt *user_ldt_alloc __P((struct pcb *, int));
-void user_ldt_free __P((struct pcb *));
#endif
--- include/proc.h.orig Wed Sep 19 02:07:59 2001
+++ include/proc.h Wed Sep 19 03:28:55 2001
@@ -38,6 +38,15 @@
#define_MACHINE_PROC_H_
#include machine/globals.h
+#include machine/segments.h
+
+struct proc_ldt {
+caddr_t ldt_base;
+int ldt_len;
+int ldt_refcnt;
+u_long ldt_active;
+struct segment_descriptor ldt_sd;
+};
/*
* Machine-dependent part of the proc structure for i386.
@@ -46,6 +55,15 @@
};
struct mdproc {
+ struct proc_ldt *md_ldt;/* per-process ldt */
};
+
+#ifdef _KERNEL
+
+void set_user_ldt __P((struct mdproc *));
+struct proc_ldt *user_ldt_alloc __P((struct mdproc *, int));
+void user_ldt_free __P((struct thread *));
+
+#endif /* _KERNEL */
#endif /* !_MACHINE_PROC_H_ */
--- i386/genassym.c.origWed Sep 19 02:16:34 2001
+++ i386/genassym.c Wed Sep 19 13:03:45 2001
@@ -63,6 +63,7 @@
#include vm/pmap.h
#include vm/vm_map.h
#include sys/user.h
+#include sys/proc.h
#include net/if.h
#include netinet/in.h
#include nfs/nfsproto.h
@@ -76,6 +77,7 @@
#include machine/sigframe.h
#include machine/globaldata.h
#include machine/vm86.h
+#include machine/proc.h
ASSYM(P_VMSPACE, offsetof(struct proc, p_vmspace));
ASSYM(VM_PMAP, offsetof(struct vmspace, vm_pmap));
@@ -92,6 +94,9 @@
ASSYM(TD_PROC, offsetof(struct thread, td_proc));
ASSYM(TD_INTR_NESTING_LEVEL, offsetof(struct thread, td_intr_nesting_level));
+ASSYM(P_MD, offsetof(struct proc, p_md));
+ASSYM(MD_LDT, offsetof(struct mdproc, md_ldt));
+
ASSYM(KE_FLAGS, offsetof(struct kse, ke_flags));
ASSYM(KEF_ASTPENDING, KEF_ASTPENDING);
@@ -126,7 +131,6 @@
ASSYM(PCB_EIP, offsetof(struct pcb, pcb_eip));
ASSYM(TSS_ESP0, offsetof(struct i386tss, tss_esp0));
-ASSYM(PCB_USERLDT, offsetof(struct pcb, pcb_ldt));
ASSYM(PCB_GS, offsetof(struct pcb, pcb_gs));
ASSYM(PCB_DR0, offsetof(struct pcb, pcb_dr0));
ASSYM(PCB_DR1, offsetof(struct pcb, pcb_dr1));
--- i386/machdep.c.orig Wed Sep 19 02:16:39 2001
+++ i386/machdep.c Wed Sep 19 04:57:31 2001
@@ -103,6 +103,7 @@
#include machine/md_var.h
#include machine/pc/bios.h
#include machine/pcb_ext.h /* pcb.h included via sys/user.h */
+#include machine/proc.h
#include machine/globals.h
#ifdef PERFMON
#include machine/perfmon.h
@@ -880,8 +881,8 @@
struct trapframe *regs = td-td_frame;
struct pcb *pcb = td-td_pcb;
- if (pcb-pcb_ldt)
- user_ldt_free(pcb);
+ if (td-td_proc-p_md.md_ldt)
+ user_ldt_free(td);
bzero((char *)regs, sizeof(struct trapframe));
regs-tf_eip = entry;
--- i386/swtch.s.orig Wed Sep 19 02:16:14 2001
+++ i386/swtch.sThu Sep 20 03:51:55 2001
@@ -246,7 +246,8 @@
/* XXX FIXME: we should be restoring the local APIC TPR */
#endif /* SMP */
- cmpl$0, PCB_USERLDT(%edx) /* if there is one */
+ movlTD_PROC(%ecx), %eax /* load struct proc from CURTHREAD */
+ cmpl$0, P_MD+MD_LDT(%eax) /* see if md_ldt == 0 */
jnz 1f /* then use it */
movl_default_ldt,%eax /* We will use the default */
cmplPCPU(CURRENTLDT),%eax /* check to see if already loaded */
@@ -255,9 +256,11 @@
movl%eax,PCPU(CURRENTLDT) /* store what we have */
jmp 2f
-1: pushl %edx/* call a non-trusting routine */
- callset_user_ldt/* to check and load the ldt */
- popl%edx
+1: pushl %edx/* save edx */
+ pushl P_MD+MD_LDT(%eax) /* passing p_md - set_user_ldt */
+ callset_user_ldt/* check and load the ldt */
+ popl%eax
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, John Baldwin wrote: : :Each thread would need its own TSS, and to preserve existing semantics, we :would have to change the TSS of all threads for each TSS related syscall. In :light of that, I vote in favor of no TSS's for kse processes since TSS's are :used for very few things anyways. LDT's are another matter and can be moved :w/o a problem. Currently fixing a bug in my patch for moving ldt - mdproc (in struct proc), when done I will let you know -- should be mid-day today. Cheers, Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: JKH Project: x86: pcb_ext
On Wed, 19 Sep 2001, Julian Elischer wrote: : : We still would need to sync LDT reloads.. : :that's more of a worry for me. :Do we still have separate a LDT for threads? : LDT is per process therefore, in the patch I made, I moved pcb_ldt out of struct pcb and into mdproc (which is in struct proc). I've asked Peter to take a look at it and jhb, however, it is located at: http://www.watson.org/~arr/fbsd-patches/ldt-2-mdproc.diff Cheers, Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel-loadable Root Kits
:Instead of worrying after the module has been loaded it's much safer :to run the kernel in securelevel=1 when modules cannot be loaded :without a reboot to single-user mode. : Not entirely true. They are called kernel bugs... Not the proper url for this, but good enough: http://julianor.tripod.com/freebsd-kernel-bof.txt *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: can't generate vnode_if.h automatically
Essentially, you should compile this module in the modules directory of the kernel source. This will solve your problems in the easiest manner. sorry for short answer.. driving all night back from HAL sleep. andrew On Sun, 12 Aug 2001, Rohit Grover wrote: :Hello, : :I am writing a module which needs to include 'sys/vnode.h'. vnode.h :tries to include vnode_if.h. I checked the Makefiles of some other :modules requiring vnode.h (eg. 'vn', 'nfs') and discovered that they :add vnode_if.h to to the variable 'SRCS'. This automagically generates :vnode_if.h in the current directory while running make for these :modules. : :I copied the makefile from one of these modules and changed 'SRCS' to :point to my sources. 'vnode_if.h' was included in 'SRCS' in my :makefile too. Unfortunately, this did not work for me. vnode_if.h was :not generated before compiling my sources and therefore my build :failed. : :Interestingly, when I executed the command 'make depend', :vnode_if.h was correctly created for me. I'd like to know why I don't :need to do a 'make depend' for modules like 'vn' or 'nfs' before :building them. : :regards, :Rohit. : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-hackers in the body of the message : *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Dell OptiPlex GX100 onboard video
Hi, Yes, I know this has been discussed in the past on this but I couldn't find any solutions so I'd like to actually assist in the solution. Unfortunately at work I was given a Dell OptiPlex GX100 which has an on-board video card that I've yet to see anyone get work under FreeBSD 4.x. I hear -CURRENT has support, but when I ask around, no one can point me to the exact code that supports it so that I may perhaps attempt to backport it to 4.x. Can anyone tell me if it's a myth that the onboard card is not supported in 4.x but is in, what will be, 5.0? If anyone has done any real work with this I'd appreciate being contacted. Also, if I've completly missed a post regarding this issue that solves it, I would appreciate a link :-) Thanks, andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: your mail
On 23 Jul 2001 [EMAIL PROTECTED] wrote:
static int write_file(struct proc *p, void *arg) {
struct write_args *wstructure;
struct open_args *ostructure;
ostructure-path=/tmp/blehfile;
ostructure-flags = O_CREAT;
ostructure-mode = 0;
wstructure-fd = open(p, ostructure);
#1 bad form calling syscalls like this within the kernel -- just doesnt
make sense
#2 open(2) will attempt to do a copyinstr rather than a copystr and that
is not correct.
wstructure-buf = Testing\n;
wstructure-nbytes = 8;
return write(p, wstructure);
}
same idea with this write function and the buf parameter.
Im not sure why, but that code crashes. Was created with:
echo Hi /tmp/blehfile. Also, is there an official freebsd kernel hackers
guide? Kernel programming is very interesting. ;-)
While it's not the best, check out:
http://www.daemonnews.org/200010/blueprints.html
Andrew
*-.
| Andrew R. Reiter
| [EMAIL PROTECTED]
| It requires a very unusual mind
| to undertake the analysis of the obvious -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: KLD parameters
This was discussed before... I think if you want it, implement it. :-/ andrew On Thu, 19 Jul 2001, Eugene L. Vorokov wrote: Hello, it seems that I can't pass any parameters to a KLD module when I load it (i.e., some command line). Am I missing something, or if not, why is it like that, on purpose or just no one was willing to implement that ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [ANNOUNCE] SPY-1.1 - syscall monitoring kernel module
I'd really be interested in the results from the kernel security BoF from USENIX (sine I missed it) and seeing how we can apply any of the resultant ideas into SPY, ie. utilize interfaces or styles. Anyone know where we could find the BoF information? Robert? Andrew On Wed, 11 Jul 2001, Andrzej Bialecki wrote: Hi, I just uploaded an updated version of the SPY, which is a kernel module that allows to selectively monitor and/or block execution of any syscalls. This version works on relatively current -CURRENT (after the struct proc changes). You can get it from: http://people.freebsd.org/~abial See also the detailed description there. I should be able also to provide a version for 4-STABLE soon, depending on my time and availability of the machine... Enjoy! -- Andrzej // // Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: automated checking of Security Advisories
On Tue, 24 Apr 2001, Kris Kennaway wrote: pkg_version may be a logical place to stick this functionality since it already has code for parsing version numbers. Ya... I think it would be wise to somehow include validating of the security advisories too when doing these checks. Im not sure how this tool will know which packages are vulnerable (Im assuming a config file of sorts), but it would be a smart thing to include some pgp key validation of each of the advisory vulns the tool is looking for. Just a small thing... :-) Kris *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCP intercept?
In light of this, I would say that it would be cool to put into the ipfw
or ipf code seeing as how there are already hooks into the network stack
in the code. I am not sure how people will take the ipfw implementation
soley because I know there was alot of hacking being done to it in the
recent months (??). Im also not sure how well Darren would take the code
written if it was done for ipf.
Otherwise, you'll have to add some more hooks into the stack code
(tcp_{input,output}.c and perhaps others) and then handle it that way.
Im not really familiar with how (un)successful TCP intercept has been with
Cisco, but I would find that as a cool option :-)
Take it easy,
Andrew
On Mon, 23 Apr 2001, Alex Pilosov wrote:
In cisco terminology, 'tcp intercept' is what the 'ip and tcp reassembly'
part of ipnat does (without port/address rewriting). For example, a router
in the middle which is doing the intercept will have to buffer/reassemble
tcp stream and only forward packets after they are confirmed good.
Example: packets with a wrong sequence number will be bounced at the
router. On ciscos, tcp-intercept can also rate-limit syn packets...
I'm not sure if it can be enabled in ipnat separately, but hell, if
someone wants to do it...
On Sun, 22 Apr 2001, Andrew R. Reiter wrote:
What's TCP intercept?
On Mon, 23 Apr 2001, E.B. Dreger wrote:
Greetings all,
I'm no kernel hacker, and trying to think of useful little projects to
change that. ;-)
AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already working
on this? Would it be of interest to anyone? My initial thoughts are that
it should be implemented in the same neighborhood as stateful firewall
code, as the two are rather closely related.
Eddy
---
Brotsman Dreger, Inc.
EverQuick Internet / EternalCommerce Division
Phone: (316) 794-8922
---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
*-.
| Andrew R. Reiter
| [EMAIL PROTECTED]
| It requires a very unusual mind
| to undertake the analysis of the obvious -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
*-.
| Andrew R. Reiter
| [EMAIL PROTECTED]
| It requires a very unusual mind
| to undertake the analysis of the obvious -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: TCP intercept?
What's TCP intercept? On Mon, 23 Apr 2001, E.B. Dreger wrote: Greetings all, I'm no kernel hacker, and trying to think of useful little projects to change that. ;-) AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already working on this? Would it be of interest to anyone? My initial thoughts are that it should be implemented in the same neighborhood as stateful firewall code, as the two are rather closely related. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-..... | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
FreeBSD implements a very sophisticated VM balancing algorithm. Nobody's complaining about it so I don't think we need to really change it. Most of the other UNIXes, including Linux, are actually playing catch-up to FreeBSD's VM design. I remember hearing/viewing a zero-copy networking patch for 4.2... Anyone else seen this? If it's already part of the tree, ignore me :-) Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
man pages for format string functions
hi, I actually apologize if this is a repeat mail.. I admittedly did not look through the archives to see if this has been mentioned. Anyway... Im wondering if there should be a change in perhaps either stdarg(3), or all of the functions that contain format string parameters to state a warning about misusage. For example, in stdarg(3) it says: If there is no next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), random errors will occur. While I realize not everyone is using user-input'd format strings when they pass them to these functions, but perhaps a bit more of a clarification/note/warning could be mentioned here, such as: ... random errors will occur which might lead to a security risk. I am fairly poor with wording man pages, as you can see, but I think it might be worth while just to point this out. Thoughts? Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: man pages for format string functions
Sure, I will try to get this done this morning.. (flying to CanSecWest this afternoon) .. if not, I will get it done this evening. On Tue, 27 Mar 2001, Kris Kennaway wrote: On Tue, Mar 27, 2001 at 02:13:03PM -0500, Andrew R. Reiter wrote: I am fairly poor with wording man pages, as you can see, but I think it might be worth while just to point this out. Thoughts? I've wanted to do this, but so far haven't had time. Do you think you could submit a patch? Don't worry about wording, that can easily be tweaked. Kris *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLD'fying PCI device driver!
Could you send the load handler function src? On Thu, 15 Feb 2001, Satyajeet Seth wrote: Hi I am trying to convert my PCI device driver into a KLD. So far I have done the following: 1. Built the kernel without the static linked device driver. 2. Added entries to Makefiles in /sys/modules and /sys/modules/xxx. 3. Did "make all install" in /sys/modules directory. 4. Tried loading the KLD. I got the following error: "Fatal trap 12: page fault while in kernel mode" Any ideas as to what could be going wrong? Thanks Satya To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-............. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wanted: documentation on KLD modules
Hello, this might help: http://www.daemonnews.org/200010/blueprints.html Andrew On Thu, 15 Feb 2001, [iso-8859-1] Mårten Wikström wrote: I'm trying to convert a PCI network interface device driver to a KLD module. However, the driver is depending on a pseudo-device and the pseudo-device is in turn dependent on the device driver. How do I specify dependencies between KLD modules and what type of module shall they be? Are there any documents describing KLD in more depth than the tutorial in the FreeBSD handbook and the man page for KLD? I've search the net but haven't found anything yet. Any help appreciated thanks Mårten To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-..... | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IEEE 1394/Firewire
Plz search -hackers On Fri, 5 Jan 2001 [EMAIL PROTECTED] wrote: Does anyone know if any work is being done on this? Especially the TCP/IP over firewire (rfc2734), which would make it nice and easy to network up my vaio with my desktop PC :) -- Simon Dick[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-..... | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
[Sorry for lack of message in this reply but I accidently rm'd the original emails to reply to :-) ] One thing I've done in the past is if it's convenient in a section of code to hijack a function pointer in the kernel, then hijack it so that it will call your code... Silly, and not always really useful... But, Ive done it before *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Source code of the dynamic loader
sys/kern/kern_linker.c n Tue, 19 Dec 2000, Sven C. Koehler wrote: Hello! I am interested in the internals of FreeBSD's dynamic loader; where in the src module should I look for the appropriate source code? Best Regards, Sven C. Koehler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-..... | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCTP implementation and pccard.conf change for Cisco 802.11B 340 series cards
Any others at IETF? I am not far from where it's being held and getting a mini-freebswd group together for food would rule ;) Email me off list if you're there! On Mon, 11 Dec 2000, Jonathan "Taz" Mischo wrote: I am currently at IETF 49, where I have moved from my old wi card to the new Cisco 342, which is an an card, since Cisco acquired them. The 342 does 128-bit or less encryption at 11 meg, thus it was a worthy investment. However, pccard.conf does not have an entry for the card, since it was JUST released. The appropriate entry is: #Cisco 340 series 802.11B wireless NICs card "Cisco Systems" "340 Series Wireless LAN Adapter" config 0x5 "an" ? insert /etc/pccard_ether $device remove /sbin/ifconfig $device delete This allows the Cisco 34x cards to work, including the 342. One caveat, however...I haven't looked at the source, yet, but it is pretty safe to assume that 128-bit at 11meg support is not in the driver. I will take a look at this when I have some spare time, but since I am currently tied up with writing SCTP reference code for a linux kernel (this was not my choice...it is my job), I may not have a ton of time for a bit of time. If anyone can work on this, it'd be appreciated. On a second note, I am willing to lead the SCTP implementation team for FBSD, if there is not already one in place. We will be releasing the first developer's release of the SCTP reference code (it will not be complete, but it currently works, and still will) on January 19th, 2001. At that point, we should be able to get the implementation under way. Have a good day, -Taz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-............. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patching live kernels
afaik, Yes. There are two articles that I know of that deal with the specifics of modifying binaries to inject ones own code. The first is one that deals mostly with libbfd (binary file descriptor) and linux. iirc, libbfd worked a great deal better under linux than under FreeBSD. I recall that libbfd under FreeBSD only supported a.out format. (yikes!) This article can be viewed at: http://phrack.infonexus.com/search.phtml?viewarticle=p56-9 The second article that I know of deals with hijacking functions in the kernel even if they do not have a function ptr to them. Obviously functions that have ptrs to them can easily be hijacked via a KLD (check out the examples.tar.gz in the Daemonnews article on KLDs). However, I am not sure if the author has yet published this article and I don't feel it my place to publish it for him. Perhaps, silvio, the author, will want to publish it here ;) Anyway, hope this helps. Andrew On Sun, 10 Dec 2000, Alfred Perlstein wrote: Ok, sometimes we find a bug in a particular release where what's needed is a function replaced with fixed code. I'm wondering if it's possible to: 1) look at the kernel symbol table for a particular function in a particular object file (static functions would be even better?) 2) replace the first instruction in the function with a jmp to our newly loaded code 3) have our newly loaded code be "anonymous" meaning no symbols from it enter the kernel symbol namespace (i want to be able to re-patch a patched kernel) Is it possible? Are there any takers? :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-............. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Packet Header Filtering
Look at ipproto switch table... That might help you find some function pointers that would be logical to hijack in order to do this sort of thing. it's in /usr/src/sys/netinet/*.c somewhere. andrew On Fri, 8 Dec 2000, Alwyn Goodloe wrote: We are about to begin a little project that has the following requiremnet. Perform IP packet filtering in the following way : i) look at an ip packet header. If some conditions are met let the packet pass otherwise reject the packet. ii) Look at ip packet headers of established connections and when certain conditions are met tear down the connection. Obviously this isn't the kind of thing we will be using the usual firewall software, at least not as I understand the software. What I want to know from you FreeBSD hackers is: i) if anyone has done something similar do you have any advice. ii) Anyone know where I should start hacking. Would it be best to try to hack the firewall code or the ipforwarding code Any such advise would be helpful. Alwyn Goodloe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-..... | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FireWire Device Driver
hihi. I was reading back emails of -hackers from like july '99 and a guy from Japan had been working on a very promising FireWire device driver ... Anyway, the other night I had picked up a really awesome book that goes into detail on FireWire and had basically decided to work on it myself (until I realized someone had already started work on it!)... However, the last email that was seemingly sent regarding this issue was one by jkh in which he gives a major value for the device driver,... and asks when it should be ready for use with -current. I have emailed the guy from japan and have received no response... so I am wondering if anyone else knows what's up with the firewire situation and whether I should go ahead and pick up work on it? Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bpf.c select fix for review
Please don't use a java/c++-ism like bdStart... atleast call it bdstart.
Thanks,
Andrew
On Mon, 16 Oct 2000, Peter Van Epp wrote:
While working on the new argus version I discovered that there is a
bug in the /sys/net/bpf.c code if you are doing select with a timeout (which
tcpdump isn't). Basically if you set up tcpreplay on another machine and send
a less than full buffer (9 packets 2300 bytes in my case) to a FreeBSD 4.1
RELEASE machine, argus won't see the packets. It turns out that because it
is using select (and not immediate mode) the partially full buffer won't get
passed up to libpcap. The OpenBSD folks have a partial fix (which only gets
the first packet up and leaves the other 8 dangling). I ported that to FreeBSD
and then made a fix which appears to work based on what their code looked to
be trying to do (as opposed to what it does which is incorrect).
Basically at receive packet time the tick counter is stored in a
variable in the capture structure. When the select/poll timeout occurs it
checks if the current tick time is then the last received packet count +
the timeout value. If so it rotates the (partially full) packet buffer and
signals to wake up the process. While this appears to work (and match the
Solaris behavior on the same file) I figured I'd see if anyone sees a glaring
hole in the fix before submitting a bug report on it.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
*** /sys/net/bpf.c.orig Sat Oct 14 19:00:59 2000
--- /sys/net/bpf.cMon Oct 16 09:30:24 2000
***
*** 1054,1061
if (events (POLLIN | POLLRDNORM)) {
if (d-bd_hlen != 0 || (d-bd_immediate d-bd_slen != 0))
revents |= events (POLLIN | POLLRDNORM);
! else
! selrecord(p, d-bd_sel);
}
splx(s);
return (revents);
--- 1054,1076
if (events (POLLIN | POLLRDNORM)) {
if (d-bd_hlen != 0 || (d-bd_immediate d-bd_slen != 0))
revents |= events (POLLIN | POLLRDNORM);
! else {
! /*
! * If there is a timeout and no data in the hold buffer
! * see if there has been data in the capture buffer
! * for more than a timeout interval. If so rotate the
! * buffer to push the packets to the user.
! */
! if ((d-bd_slen != 0) (d-bd_hlen == 0)) {
! if ((d-bd_rtout != -1)
! (d-bd_rdStart + d-bd_rtout) ticks) {
! ROTATE_BUFFERS(d);
! revents |= events (POLLIN | POLLRDNORM);
! }
! } else
! selrecord(p, d-bd_sel);
!
! }
}
splx(s);
return (revents);
***
*** 1219,1224
--- 1234,1245
*/
(*cpfn)(pkt, (u_char *)hp + hdrlen, (hp-bh_caplen = totlen - hdrlen));
d-bd_slen = curlen + totlen;
+
+ /*
+ * Mark the time the last packet was seen for poll timeout processing.
+ */
+
+ d-bd_rdStart = ticks;
}
/*
*** /sys/net/bpfdesc.h.orig Sat Oct 14 19:16:07 2000
--- /sys/net/bpfdesc.hSat Oct 14 19:21:54 2000
***
*** 69,74
--- 69,75
struct bpf_if * bd_bif; /* interface descriptor */
u_long bd_rtout; /* Read timeout in 'ticks' */
+ u_long bd_rdStart; /* when the read started */
struct bpf_insn *bd_filter; /* filter code */
u_long bd_rcount; /* number of packets received */
u_long bd_dcount; /* number of packets dropped */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
*-.....
| Andrew R. Reiter
| [EMAIL PROTECTED]
| "It requires a very unusual mind
| to undertake the analysis of the obvious" -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
OOPS Re: bpf.c select fix for review
woops.. I meant bd_rdstart.
On Mon, 16 Oct 2000, Peter Van Epp wrote:
While working on the new argus version I discovered that there is a
bug in the /sys/net/bpf.c code if you are doing select with a timeout (which
tcpdump isn't). Basically if you set up tcpreplay on another machine and send
a less than full buffer (9 packets 2300 bytes in my case) to a FreeBSD 4.1
RELEASE machine, argus won't see the packets. It turns out that because it
is using select (and not immediate mode) the partially full buffer won't get
passed up to libpcap. The OpenBSD folks have a partial fix (which only gets
the first packet up and leaves the other 8 dangling). I ported that to FreeBSD
and then made a fix which appears to work based on what their code looked to
be trying to do (as opposed to what it does which is incorrect).
Basically at receive packet time the tick counter is stored in a
variable in the capture structure. When the select/poll timeout occurs it
checks if the current tick time is then the last received packet count +
the timeout value. If so it rotates the (partially full) packet buffer and
signals to wake up the process. While this appears to work (and match the
Solaris behavior on the same file) I figured I'd see if anyone sees a glaring
hole in the fix before submitting a bug report on it.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
*** /sys/net/bpf.c.orig Sat Oct 14 19:00:59 2000
--- /sys/net/bpf.cMon Oct 16 09:30:24 2000
***
*** 1054,1061
if (events (POLLIN | POLLRDNORM)) {
if (d-bd_hlen != 0 || (d-bd_immediate d-bd_slen != 0))
revents |= events (POLLIN | POLLRDNORM);
! else
! selrecord(p, d-bd_sel);
}
splx(s);
return (revents);
--- 1054,1076
if (events (POLLIN | POLLRDNORM)) {
if (d-bd_hlen != 0 || (d-bd_immediate d-bd_slen != 0))
revents |= events (POLLIN | POLLRDNORM);
! else {
! /*
! * If there is a timeout and no data in the hold buffer
! * see if there has been data in the capture buffer
! * for more than a timeout interval. If so rotate the
! * buffer to push the packets to the user.
! */
! if ((d-bd_slen != 0) (d-bd_hlen == 0)) {
! if ((d-bd_rtout != -1)
! (d-bd_rdStart + d-bd_rtout) ticks) {
! ROTATE_BUFFERS(d);
! revents |= events (POLLIN | POLLRDNORM);
! }
! } else
! selrecord(p, d-bd_sel);
!
! }
}
splx(s);
return (revents);
***
*** 1219,1224
--- 1234,1245
*/
(*cpfn)(pkt, (u_char *)hp + hdrlen, (hp-bh_caplen = totlen - hdrlen));
d-bd_slen = curlen + totlen;
+
+ /*
+ * Mark the time the last packet was seen for poll timeout processing.
+ */
+
+ d-bd_rdStart = ticks;
}
/*
*** /sys/net/bpfdesc.h.orig Sat Oct 14 19:16:07 2000
--- /sys/net/bpfdesc.hSat Oct 14 19:21:54 2000
***
*** 69,74
--- 69,75
struct bpf_if * bd_bif; /* interface descriptor */
u_long bd_rtout; /* Read timeout in 'ticks' */
+ u_long bd_rdStart; /* when the read started */
struct bpf_insn *bd_filter; /* filter code */
u_long bd_rcount; /* number of packets received */
u_long bd_dcount; /* number of packets dropped */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
*-.....
| Andrew R. Reiter
| [EMAIL PROTECTED]
| "It requires a very unusual mind
| to undertake the analysis of the obvious" -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: kld/cdev won't compile
Marc, Yes... This is known. I know I sent in a send-pr awhile back.. but it's not a big priority, in my opinion. HOWEVER, you can see working examples and a tutorial at: http://www.subterrain.net/~awr/KLD-Tutorial/intro.html This will also be in daemonnews on the 1st. Andrew On Fri, 29 Sep 2000, Marc Tardif wrote: I'm currently running 4.1-RELEASE and can't compile the code in: /usr/share/examples/kld/cdev/module The command "make" returns the following to stderr: cdevmod.c:142: macro `DEV_MODULE' used with too many (6) args cdevmod.c:84: `nostop' undeclared here (not in a function) cdevmod.c:84: initializer element is not constant cdevmod.c:84: (near initialization for `my_devsw.d_poll') cdevmod.c:85: `noreset' undeclared here (not in a function) cdevmod.c:85: initializer element is not constant cdevmod.c:85: (near initialization for `my_devsw.d_mmap') cdevmod.c:86: `nodevtotty' undeclared here (not in a function) cdevmod.c:86: initializer element is not constant cdevmod.c:86: (near initialization for `my_devsw.d_strategy') cdevmod.c:87: warning: initialization from incompatible pointer type cdevmod.c:88: warning: initialization makes integer from pointer without a cast cdevmod.c:89: warning: initialization from incompatible pointer type cdevmod.c:90: warning: initialization from incompatible pointer type cdevmod.c:91: `noparms' undeclared here (not in a function) cdevmod.c:91: initializer element is not constant cdevmod.c:91: (near initialization for `my_devsw.d_flags') cdevmod.c:93: warning: excess elements in struct initializer cdevmod.c:93: warning: (near initialization for `my_devsw') cdevmod.c:94: warning: excess elements in struct initializer cdevmod.c:94: warning: (near initialization for `my_devsw') cdevmod.c:95: warning: excess elements in struct initializer cdevmod.c:95: warning: (near initialization for `my_devsw') cdevmod.c:96: warning: excess elements in struct initializer cdevmod.c:96: warning: (near initialization for `my_devsw') cdevmod.c:98: warning: excess elements in struct initializer cdevmod.c:98: warning: (near initialization for `my_devsw') cdevmod.c:142: warning: initialization makes pointer from integer without a cast cdevmod.c:142: warning: initialization makes pointer from integer without a cast cdevmod.c:78: warning: `my_devsw' defined but not used cdevmod.c:113: warning: `cdev_load' defined but not used Also, "grep include cdevmod.c" returns: #include sys/param.h #include sys/systm.h #include sys/kernel.h #include sys/module.h #include sys/conf.h #include "cdev.h" but none of those include files contain "nostop", "noreset", etc. As for DEV_MODULES, the code in /usr/src/sys only uses 3 args, so I'm stumped on that one. Suggestions to solve these problems would be most appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message *-----..... | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
