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
+#include
+
+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
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,7 @@
#include
#include
#include
+#include
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
#include
#include/* pcb.h included via sys/user.h */
+#include
#include
#ifdef PERFMON
#include
@@ -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/* get p_md off stack */
+ popl%edx/* restore edx */
2:
/* This must be done after loading the user LDT. */
--- i386/sys_machdep.c.orig Wed Sep 19 02:16:22 2001
+++ i386/sys_machdep.c Wed Sep 19 04:34:30 2001
@@ -
Re: JKH Project: x86: pcb_ext
"Andrew R. Reiter" wrote: > 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 :-/ No, I just happened to miss the same shortcut recently, so I noticed it. :-) 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
uptime and w utilities lie about real uptime
>Submitter-Id: current-users
>Originator:Vladimir B. Grebenschikov
>Organization: TSB "Russian Express"
>Confidential: no
>Synopsis: uptime and w utilities lie about real uptime
>Severity: non-critical
>Priority: low
>Category: bin
>Class: sw-bug
>Release: FreeBSD 5.0-CURRENT i386
>Environment:
System: FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Sep 19
20:26:25 MSD 2001 [EMAIL PROTECTED]:/usr/src.local/sys/i386/compile/VBOOK i386
>Description:
Just after very fast boot uptimealways shows more than 30 sec.
looking to src/usr/bin/w/w.c:
if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1 &&
boottime.tv_sec != 0) {
uptime = now - boottime.tv_sec;
uptime += 30;
== ^
days = uptime / 86400;
uptime %= 86400;
hrs = uptime / 3600;
uptime %= 3600;
mins = uptime / 60;
secs = uptime % 60;
(void)printf(" up");
why utility increases uptime on 30 seconds ??
Is any real reasons for it ?
>How-To-Repeat:
Boot and run uptime
>Fix:
--- src/usr.bin/w.c.origThu Sep 20 15:20:01 2001
+++ src/usr.bin/w.c Thu Sep 20 15:20:11 2001
@@ -450,7 +450,6 @@
if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1 &&
boottime.tv_sec != 0) {
uptime = now - boottime.tv_sec;
- uptime += 30;
days = uptime / 86400;
uptime %= 86400;
hrs = uptime / 3600;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: uptime and w utilities lie about real uptime
"Vladimir B.Grebenschikov" wrote:
>
> >Submitter-Id: current-users
> >Originator:Vladimir B. Grebenschikov
> >Organization: TSB "Russian Express"
> >Confidential: no
> >Synopsis: uptime and w utilities lie about real uptime
> >Severity: non-critical
> >Priority: low
> >Category: bin
> >Class: sw-bug
> >Release: FreeBSD 5.0-CURRENT i386
> >Environment:
> System: FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Sep 19
>20:26:25 MSD 2001 [EMAIL PROTECTED]:/usr/src.local/sys/i386/compile/VBOOK i386
>
> >Description:
>
> Just after very fast boot uptimealways shows more than 30 sec.
>
> looking to src/usr/bin/w/w.c:
>
> if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1 &&
> boottime.tv_sec != 0) {
> uptime = now - boottime.tv_sec;
> uptime += 30;
> == ^
> days = uptime / 86400;
> uptime %= 86400;
> hrs = uptime / 3600;
> uptime %= 3600;
> mins = uptime / 60;
> secs = uptime % 60;
> (void)printf(" up");
>
> why utility increases uptime on 30 seconds ??
> Is any real reasons for it ?
>From my reading of this, it seems to want to round the uptime to
the nearest minute -- afterall, w and uptime both only show the uptime
in minutes (well, days, hours, and minutes)
--
Michael Sinz Worldgate Communications [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: uptime and w utilities lie about real uptime
Michael Sinz writes:
> > if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1 &&
> > boottime.tv_sec != 0) {
> > uptime = now - boottime.tv_sec;
> > uptime += 30;
> > == ^
> > days = uptime / 86400;
> > uptime %= 86400;
> > hrs = uptime / 3600;
> > uptime %= 3600;
> > mins = uptime / 60;
> > secs = uptime % 60;
> > (void)printf(" up");
> >
> > why utility increases uptime on 30 seconds ??
> > Is any real reasons for it ?
>
> >From my reading of this, it seems to want to round the uptime to
> the nearest minute -- afterall, w and uptime both only show the uptime
> in minutes (well, days, hours, and minutes)
not exactly right:
...
DUMMYNET initialized (010124)
Waiting 2 seconds for SCSI devices to settle
SMP: AP CPU #1 Launched!
Mounting root from ufs:/dev/da0s2a
da0 at ahc0 bus 0 target 12 lun 0
da0: Fixed Direct Access SCSI-3 device
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
Enter full pathname of shell or RETURN for /bin/sh:
# mount -a
# uptime
3:12PM up 42 secs, 3 users, load averages: 0.21, 0.05, 0.02
#
42sec instead of more realistic 12sec
looking into w.c more:
if (days > 0)
(void)printf(" %d day%s,", days, days > 1 ? "s" : "");
if (hrs > 0 && mins > 0)
(void)printf(" %2d:%02d,", hrs, mins);
else if (hrs > 0)
(void)printf(" %d hr%s,", hrs, hrs > 1 ? "s" : "");
else if (mins > 0)
(void)printf(" %d min%s,", mins, mins > 1 ? "s" : "");
else
(void)printf(" %d sec%s,", secs, secs > 1 ? "s" : "");
}
--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot proccess
Jean-Christophe Varaillon wrote: > > Hi, > > Newbie, I need to understand the differents steps of a booting process > from the 2 floppies (kern.flp & mfsroot.flp). > > How it comes and the FreeBSD machine can understand the fact that it has > to find kern.flp & mfsroot.flp from the floppy, uncompress them, load them > in the RAM and make them running ? > > In short, which program gives enough knowledge to the microprocessor (?) > and allow him to use kern.flp & mfsroot.flp in order to boot and make the > operating system running. apropos boot -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] wow regex humor... I'm a geek To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/30680: uptime and w utilities lie about real uptime
On Thu, Sep 20, 2001 at 03:21:08PM +0400, Vladimir B.Grebenschikov wrote: > why utility increases uptime on 30 seconds ?? > Is any real reasons for it ? It adds 30 because it wants to round the number of minutes to the nearest minute, instead of rounding down. Unfortunately this isn't a sensible thing to do if you are also going to display the number of seconds. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No tools on 4.4-RELEASE ISO?
Is the tools directory supposed to be missing on the 4.4 CDs? I downloaded the full disk 1 ISO yesterday and burned it only to discover that fdimage.exe was nowhere to be found on the CD. This is not a good thing when you have to create boot floppies because your BIOS refuses to acknowledge the existance of your CD-ROM. Strangely the documentation on the CD still references fdimage and the floppies are still on there, I guess you are supposed to have a net connection and get anything you need from the FTP site? -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: uptime and w utilities lie about real uptime
It's rounding to minutes when it shouldn't, uptime only displays seconds for very short uptimes, and then always rounds to minutes. Your patch causes it to truncate, which is probably the right thing to do, the alternative would be: if (uptime > 60) uptime += 30; That way it won't start rounding until a full minute has passed, allowing the first 60 seconds to be displayed properly. This has less of a chance of breaking things depending on the rounding, but I would hope ther are none of those. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Hello, I am installing freebsd 4.2 and at the point of configuring the DHCP, it crashes with a Signal 11. Assist please. Or is there a site I could visit for troubleshooting Thanks Desperately yours damie Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re:
[Please ask questions at the FreeBSD-Questions mailing list. Hackers is reserved for discussing development.] damie odessa wrote: > Hello, > > I am installing freebsd 4.2 and at the point of configuring the DHCP, > it crashes with a Signal 11. Assist please. > Did you install from ports? Had you lloked at the core? > Or is there a site I could visit for troubleshooting > As stated above, try at FreeBSD-Questions. HTH -Christoph Sold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH Project: x86: pcb_ext
On 20-Sep-01 Julian Elischer wrote: > Peter Wemm wrote: >> >> John Baldwin wrote: >> > >> > On 19-Sep-01 Peter Wemm wrote: >> > > The more I think about it, the right place may be the kse, since that >> > > outlives >> > > the threads and is per-cpu unlike the process. >> > > >> > > Or, we just say "no pcb extensions for kse processes". >> > >> > 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 >> > ar >> e >> > used for very few things anyways. LDT's are another matter and can be >> > moved >> > w/o a problem. >> >> The main two things we seem to use the per-process TSS stuff for are: >> Fine grained IO port permission bitmap >> VM86 mode >> I think we can well do without the complexity of mixing KSE with those two. > > > I could IMAGINE a vm86 version that ran the control/exception > thread on another processor as a different thread. (though who would write > it?) > I could also imagine a muli-threaded program doing IO to a device as a > userland > driver. > > but of course hey'd need to be writen explicitly for it.. > >> >> 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? What you will have to do for the LDT reload (an LDT is per-process, not per-thread) is perform a context switch (or possibly just a LDT reload) on all processors running threads from thsi process. We already do this in a way when we change an LDT that is shared, IIRC. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need testers, Broadcom BCM570x gigE driver
Ack. Ok, I realized that I forgot to upload a couple of files to http://www.freebsd.org/~wpaul/Broadcom/4.x yesterday. The brgphy driver needs an updated version of the miidevs file, and the ones generated from it. I have placed these on the web site along with all the other stuff. In addition to the steps I mentioned yesterday for installing the driver, you'll need to copy the updated miidevs files to /sys/dev/mii. Also: if you're going to perform tests, please tell me everything about how you do them. Tell me what hardware you're using. Tell me exactly which card you have. Tell me what software you're using to perform tests. If you observe a problem, don't evaluate it for me: just tell me what you see and let me work it out. I don't want to hear people say "it drops packets." Tell me how you observed the packets being dropped. I'm going to cook up a -current version of the code presently. Watch this space. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need testers, Broadcom BCM570x gigE driver
There is now a -current version of the bge driver at the following URL: http://www.freebsd.org/~wpaul/Broadcom/5.x The brgphy driver in -current has already been updated so support the BCM5401 and BCM5411 PHYs, so no other changes are necessary. Share and enjoy. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compiling top in SMP
On Tue, Sep 18, 2001 at 08:00:35PM -0500, Hassan Halta wrote: > Hello, > > I hope some person will be able to help in this problem. I have a > SMP enviorment with 2 CPUs, and things are working just fine, and the > kernel recognizes everything. But The only problem that's top is > misbehaving. However, it recognizes that there are 2 CPUs in the systems, > but in the top stats it shows that every process is 0.00% of the CPU. > Which's not true at all, we ran some testing to hammer the CPU and > processes that should take 99.9% of the CPU, but it's always stuck on > 0.00%. I tried to compile top which exists in /usr/src/contrib/top/ and it > turns out that it's missing some modules of lists so that it can go ahead > and compile, so I got that list, and got the codes for that, and tried to > compile, but top just doesn't compile. I am not sure if I am in the right > track by compiling top on the system. I was also wondering if there's > another way to solve that problem. You don't compile things in /usr/src/contrib in FreeBSD, that's just where parts of the vendor code live. Top is rebuilt from usr.bin/top. Make sure your userland is in sync with your kernel; if you update your kernel sources and rebuild your kernel, you must rebuild world as well, otherwise some things (like top) are likely to stop working. Kris PGP signature
ipfw and dummynet
I tried "questions" for this but no answer. I am attempting to use ipfw and dummynet to instrument some network traffic tests. I am running freebsd 4.3 release and have built the kernel with ipfirewall, dummynet, and default to enabled. For a simple test, I added a pipe "ipfw add pipe 1 icmp from any to any". When I ping this machine, I can do "ipfw pipe 1 show" and watch the counters increment, but the machine doing the pinging does not see a response to the ping. That's my first question. Next, when I try to delete the pipe, "ipfw pipe 1 delete", it won't delete. The only way I can get rid of it is to do a flush. That's the second question. Third question, if I type "ipfw pipe 1 config bw 10Bytes/s", I would expect the bw to be limited and the counters to reflect this limit. The counters indicate no change in the 64 byte/s generated by my windows client. I have read the man pages for ipfw, dummynet, and ipfirewall. If these are obvious questions, I would appreciate a pointer to a good reference. Thanks -- Logically speaking, logic is not the answer. Rick Norman [EMAIL PROTECTED] 408 742 1619 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re:
You may want to install FreeBSD-4.4, it was released yesterday, so this means that you are attempting to install something two versions behind. There are security issues with 4.2... damie odessa wrote: > Hello, > > I am installing freebsd 4.2 and at the point of configuring the DHCP, it > crashes with a Signal 11. Assist please. > > Or is there a site I could visit for troubleshooting > > > > Thanks > > > > Desperately yours > > > > damie jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - "Religious fundamentalism is the biggest threat to international security that exists today." United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sendto not sending what I asked...
Hi, I'm trying to write a raw (SYN) packet with sendto. I've opened the socket with socket(AF_INET, SOCK_RAW, IPPROTO_RAW), the result is checked and it is unbound. A buffer and a sockaddr_in are formed then sent down the socket with sendto(sck,pBuffer,40,0,(struct sockaddr *)&sin,sizeof(sin)) and the packet captured using ethereal. While the packet does send, with the correct source and destination addresses, the buffer I pass is appended as data on the end of an IP packet with unknown protocol, rather than replacing the IP and TCP headers (i.e. appending the ethernet header) as I had hoped. Has anyone seen this before? Is there a socket option I have missed? I've R'dTFM till I'm blue in the face, and all the examples I can find seem to be for Linux on big endian machines :( Cheers, Dave PS. No, not a packet kiddie. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendto not sending what I asked...
* David Preece <[EMAIL PROTECTED]> [010920 17:35] wrote: > Hi, > > I'm trying to write a raw (SYN) packet with sendto. I've opened the socket > with socket(AF_INET, SOCK_RAW, IPPROTO_RAW), the result is checked and it is > unbound. A buffer and a sockaddr_in are formed then sent down the socket with > sendto(sck,pBuffer,40,0,(struct sockaddr *)&sin,sizeof(sin)) and the packet > captured using ethereal. While the packet does send, with the correct source > and destination addresses, the buffer I pass is appended as data on the end > of an IP packet with unknown protocol, rather than replacing the IP and TCP > headers (i.e. appending the ethernet header) as I had hoped. > > Has anyone seen this before? Is there a socket option I have missed? I've > R'dTFM till I'm blue in the face, and all the examples I can find seem to be > for Linux on big endian machines :( It would help if you'd provided what you think you're sending and what the other end is actually seeing. Without that I can't help much except to suggest that you make sure you're using htons/htonl in the right spot and on the right size types. I used htons instead of htonl on a 32 bit datum and it took me a good half a day to figure out what i had done wrong. > PS. No, not a packet kiddie. none of us are... really. >;) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendto not sending what I asked...
On Fri, 21 Sep 2001 10:47, you wrote:
> > the
> > buffer I pass is appended as data on the end of an IP packet with unknown
> > protocol, rather than replacing the IP and TCP headers (i.e. appending
> > the ethernet header) as I had hoped.
> It would help if you'd provided what you think you're sending and
> what the other end is actually seeing.
Sure, The contents of the buffer are:
struct packet
{
ip ipbit;
tcphdr tcpbit;
};
//fill in some basics of the packet we are about to send
packet pkt;
pkt.ipbit.ip_v=4;
pkt.ipbit.ip_hl=5;
pkt.ipbit.ip_tos=0;
pkt.ipbit.ip_len=htons(40);
pkt.ipbit.ip_off=0;
pkt.ipbit.ip_ttl=64;
pkt.ipbit.ip_p=6;
pkt.ipbit.ip_src.s_addr=/*inet_addr(argv[4])*/inet_addr("10.0.0.102");
pkt.ipbit.ip_dst.s_addr=/*inet_addr(argv[2])*/inet_addr("10.0.0.103");
pkt.tcpbit.th_dport=/*htons(atoi(argv[3]))*/htons(80);
pkt.tcpbit.th_ack=0;
pkt.tcpbit.th_x2=0;
pkt.tcpbit.th_off=5; //20 bytes, no options
pkt.tcpbit.th_flags=TH_SYN;
pkt.tcpbit.th_win=htons(65535); //advertise a big window
pkt.tcpbit.th_urp=0;
[snip, fast forward to later in the code]
//fill in random bits of packet
pkt.ipbit.ip_id=/*rand()%65536*/htons(0x1234);
pkt.tcpbit.th_sport=/*htons(1024+rand()%64511)*/htons(0x4321);
pkt.tcpbit.th_seq=/*rand()*/htonl(0x12345678);
//find checksums
pkt.ipbit.ip_sum=0;
pkt.tcpbit.th_sum=0;
pkt.ipbit.ip_sum=in_cksum((unsigned short*)(void*)&pkt,20);
pkt.tcpbit.th_sum=tcpsum(&pkt.ipbit);
where both in_cksum and tcpsump have been used before and appear to work :)
the sin structure is filled out:
sockaddr_in sin;
bzero(&sin,sizeof(struct sockaddr_in));
sin.sin_family=AF_INET;
sin.sin_addr.s_addr=pkt.ipbit.ip_dst.s_addr;
sin.sin_port=pkt.tcpbit.th_dport;
finally I send with this (where pBuffer is just put in to give the debugger
something to look at).
void* pBuffer=&pkt;
sendto(sck,pBuffer,40,0,(struct sockaddr *)&sin,sizeof(sin));
OK, so at this point the contents of the buffer are:
0xbfbff9dc: 0x450x000x000x280x120x340x000x00
0xbfbff9e4: 0x400x060x530xd00x0a0x000x000x66
0xbfbff9ec: 0x0a0x000x000x670x430x210x000x50
0xbfbff9f4: 0x120x340x560x780x000x000x000x00
0xbfbff9fc: 0x500x020xff0xff0xee0xf80x000x00
And the packet that actually gets sent:
00 d0 b7 1b b2 6c 00 80 ad 72 b6 cc 08 00 45 00
0010 00 3c 1f dd 00 00 ff ff 86 19 0a 00 00 66 0a 00
0020 00 67 45 00 00 28 12 34 00 00 40 06 53 d0 0a 00
0030 00 66 0a 00 00 67 43 21 00 50 12 34 56 78 00 00
0040 00 00 50 02 ff ff ee f8 00 00
So here we have the two hardware addresses (ending 0xb6 0xcc, top line),
marking as IP protocol (0x08 0x00), then the IP packet written by the OS
(0x45 0x00 top line, to 0x00 0x67 on the third line) followed by the buffer I
provided for a total length of 60 bytes. Interestingly the IP packet written
by the OS has a protocol of 0xff=unknown (the 0x17th byte).
>Without that I can't help
> much except to suggest that you make sure you're using htons/htonl
> in the right spot and on the right size types.
Yeah, been bitten by this before, but in my experience providing a packet
with broken checksums results in it either not being sent, or being ignored
by the recipient. This behaviour is entirely new and suggests there's
something I don't understand about the interface onto the OS since if I was
wanting to send a packet of data over IP without declaring which protocol it
was for, this would be a pretty good way of doing it :)
Oh, experience yes, I have worked with divert sockets before, but not raw -
hence the confusion.
Cheers,
Dave
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Raw sockets: Stevens shall provide.
Thanks for your help, as suggested the combination of IP_HDRINCL and reading Stevens seems to have me back on the right path. Part of the confusion was the Linux implementation of IP_HDRINCL appears to need the hardware addresses writing as well, consequently there are lots of examples of this being done in order to forge arp replies etc - not what I needed. Or rather, it was actually. Anyway, the code is now refusing to send packets entirely, which is actually good because it implies a checksum is broken somewhere and that's a bug, not a misunderstanding about the API. Thanks again, Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ASSISTANCE NEEDED URGENTLY!
MR ANTHONY PETERS EMAIL:[EMAIL PROTECTED] DEAR FRIEND, I AM MR ANTHONY PETERS, A ONE TIME PERSONAL ASSISTANT TO AN EXPATRIATE DIAMOND ENGINEER IN THE NIMBA COUNTY MINES OF SIERRA-LEON. I AM SEEKING YOUR ASSISTANCE IN A BUSINESS THAT WOULD NEED YOUR CONFIDENTIALITY TRUST AND SUPPORT. MY BOSS WAS KILLED WITH HIS ENTIRE FAMILY OF A WIFE AND THREE CHILDREN DURING THE REVOLUTIONARY UNITED FRONT RAID ON THE NIMBA COUNTY DIAMOND QUARRY OF 1993 WHERE ALMOST SIXTY PEOPLE WERE KILLED.PRIOR TO HIS DEATH, I ASSISTED HIM IN DEPOSITING A HUGE SUM OF MONEY WITH A PRIVATE SECURITY FIRM IN EUROPE.SINCE HIS DEATH,I HAVE TRIED TO CONTACT HIS FAMILY TO NO AVAIL, I HAVE NOT SEEN NOR HEARD FROM ANYBODY CONCERNING HIM. RECENTLY THE SECURITY COMPANY IN EUROPE WHERE THE EXISTENCE OF THE DEPOSIT WAS CONFIRMED TO ME, I WAS THEN ASKED TO PRODUCE HIS NEXT OF KIN TO CLAIM THIS DEPOSIT. I NEED YOUR HELP IN CLAIMING THIS DEPOSIT AS HIS NEXT OF KIN.I HAVE ALL THE PAPERS TO SUCCESSFULLY IMPLEMENT THIS, ALL I ASK, IS YOUR CO-OPERATION AND TRUST. IF YOU ARE INTERESTED,REACH ME BY RETURN MAIL FOR A MORE COMPREHENSIVE BRIEF OF THIS PROJECT. THANK YOU MR ANTHONY PETERS __ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ASSISTANCE NEEDED URGENTLY!
Removed spammer from cc list... If you found this amusing see: http://www.buddyweiserman.com/ it's sorta amusing. :) * Anthony Peters <[EMAIL PROTECTED]> [010920 20:19] wrote: > > MR ANTHONY PETERS > EMAIL:[EMAIL PROTECTED] > > DEAR FRIEND, > > I AM MR ANTHONY PETERS, A ONE TIME PERSONAL ASSISTANT > TO AN EXPATRIATE DIAMOND ENGINEER IN THE NIMBA COUNTY > MINES OF SIERRA-LEON. I AM SEEKING YOUR ASSISTANCE IN > A BUSINESS THAT WOULD NEED YOUR CONFIDENTIALITY TRUST > AND SUPPORT. > > MY BOSS WAS KILLED WITH HIS ENTIRE FAMILY OF A WIFE > AND THREE CHILDREN DURING THE REVOLUTIONARY UNITED > FRONT RAID ON THE NIMBA COUNTY DIAMOND QUARRY OF 1993 > WHERE ALMOST SIXTY PEOPLE WERE KILLED.PRIOR TO HIS > DEATH, I ASSISTED HIM IN DEPOSITING A HUGE SUM OF > MONEY WITH A PRIVATE SECURITY FIRM IN EUROPE.SINCE HIS > DEATH,I HAVE TRIED TO CONTACT HIS FAMILY TO NO AVAIL, > I HAVE NOT SEEN NOR HEARD FROM ANYBODY CONCERNING HIM. > RECENTLY THE SECURITY COMPANY IN EUROPE WHERE THE > EXISTENCE OF THE DEPOSIT WAS CONFIRMED TO ME, I WAS > THEN ASKED TO PRODUCE HIS NEXT OF KIN TO CLAIM THIS > DEPOSIT. > I NEED YOUR HELP IN CLAIMING THIS DEPOSIT AS HIS NEXT > OF KIN.I HAVE ALL THE PAPERS TO SUCCESSFULLY IMPLEMENT > THIS, ALL I ASK, IS YOUR CO-OPERATION AND TRUST. > IF YOU ARE INTERESTED,REACH ME BY RETURN MAIL FOR A > MORE COMPREHENSIVE BRIEF OF THIS PROJECT. > > THANK YOU > > MR ANTHONY PETERS > > > > > > > __ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendto not sending what I asked...
> pkt.ipbit.ip_sum=in_cksum((unsigned short*)(void*)&pkt,20); > pkt.tcpbit.th_sum=tcpsum(&pkt.ipbit); You need to do the TCP checksum first. It changes the payload (the TCP checksum). The IP checksum includes all data, so must be done after the payload changes are done. -Les -- Les Biffle (480) 585-4099[EMAIL PROTECTED] http://www.les.safety.net/ Network Safety Corp., 5831 E. Dynamite Blvd., Cave Creek, AZ 85331 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendto not sending what I asked...
Les Biffle wrote: > > pkt.ipbit.ip_sum=in_cksum((unsigned short*)(void*)&pkt,20); > > pkt.tcpbit.th_sum=tcpsum(&pkt.ipbit); > > You need to do the TCP checksum first. It changes the payload (the TCP > checksum). The IP checksum includes all data, so must be done after the > payload changes are done. i think this is incorrect. the IP checksum only includes the IP header and any IP options. therefore order should not matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendto not sending what I asked...
come to think of it... perhaps you are not calculating the tcp checksum correctly because of the tcp/ip pseudo header. i no longer have the code that was posted, but thinking back i believe this might be the case. Matt Finlay wrote: > Les Biffle wrote: > > > > pkt.ipbit.ip_sum=in_cksum((unsigned short*)(void*)&pkt,20); > > > pkt.tcpbit.th_sum=tcpsum(&pkt.ipbit); > > > > You need to do the TCP checksum first. It changes the payload (the TCP > > checksum). The IP checksum includes all data, so must be done after the > > payload changes are done. > > i think this is incorrect. the IP checksum only includes the IP header and > any IP options. therefore order should not matter. > > 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
More grief in raw packet land - Can someone commit this patch?
OK, Apologies for my slowness, it's just been one of those slow days. Y'know not enough coffee, too much food? Like that. One of our cats didn't help at about 2am either. So I get a TCP packet together and send it through (the now correctly optioned) socket. sendto fails and returns -1, derefencing __error() gives us 22=EINVAL. A little searching around reveals this to be a prevention of user error fix that went in at some point comparing the length of the buffer sent to sendto and the stated length of the IP packet - if there was a difference the packet doesn't get sent, presumably to prevent the random contents of memory being spilled across the network. This is all good, but as Pascal Bouchareine points out in PR21737 (http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21737) the part of the raw IP code that is responsible for this doesn't convert network to host byte order first and consequently the comparison will always fail for valid packets. This effectively stops anyone from being able to spoof TCP/UDP packets since it is impossible to have both the correct checksum, and get past this length check thing. Unless the length of the packet is 'symmetrical' in hex, but I digress. I've just applied Pascal's suggested patch (althought I just went in and did it manually) to my 4.3-Release development machine and it works fine. Can someone commit this patch to -current, or -stable, or do whatever it is you do :) Cheers, Dave BTW: A personal note - I used to code for windows, and increasingly have crawled down the abstraction layers throught my career (mainly trying to get away from API of the week and get on with writing quality code). This is the first time I've actually gone into the source, fixed it, and made my previously broken kernel work properly. It feels unbelievable, I can't believe what Ethereal is telling me just happened. I may be going to pick up some of those 'junior kernel hacker' tasks soon and see what I can do with them. But not yet, deadlines and baby are coming :) Anyway, over the last 18 months I have _SO_ become a convert. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: No tools on 4.4-RELEASE ISO?
On Thu, 20 Sep 2001, Jason Andresen wrote: > Is the tools directory supposed to be missing on the 4.4 CDs? > I downloaded the full disk 1 ISO yesterday and burned it only to > discover that fdimage.exe was nowhere to be found on the CD. This is > not a good thing when you have to create boot floppies because your > BIOS refuses to acknowledge the existance of your CD-ROM. Strangely > the documentation on the CD still references fdimage and the floppies > are still on there, I guess you are supposed to have a net connection > and get anything you need from the FTP site? > > No tools directory on the mini.iso either--so I guess you need to download fdimage.exe (in a common tools directory) and whatever else from tools you want. fips, osbsbeta, whatever. Annelise -- Annelise Anderson Author of: FreeBSD: An Open-Source Operating System for Your PC Book Website: http://www.bittreepress.com/FreeBSD/introbook/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: No tools on 4.4-RELEASE ISO?
On Thu, Sep 20, 2001 at 10:00:03PM -0700, Annelise Anderson wrote: > On Thu, 20 Sep 2001, Jason Andresen wrote: > > > Is the tools directory supposed to be missing on the 4.4 CDs? > > I downloaded the full disk 1 ISO yesterday and burned it only to > > discover that fdimage.exe was nowhere to be found on the CD. This is > > not a good thing when you have to create boot floppies because your > > BIOS refuses to acknowledge the existance of your CD-ROM. Strangely > > the documentation on the CD still references fdimage and the floppies > > are still on there, I guess you are supposed to have a net connection > > and get anything you need from the FTP site? > > > > > No tools directory on the mini.iso either--so I guess you need > to download fdimage.exe (in a common tools directory) and whatever > else from tools you want. fips, osbsbeta, whatever. I seem to recall these programs were owned by WCCDROM (then BSDi, then WRS), and there may have been problems in putting them on the ISO now that WRS isn't responsible for the "official ISO" creation. If so, the WRS CD release should probably end up containing them. Kris PGP signature
Re: No tools on 4.4-RELEASE ISO?
> I seem to recall these programs were owned by WCCDROM (then BSDi, then Naw, I'd long since prunted tools/ to just the stuff that was freely redistributable. Murray simply forgot to put it on the ISOs he created. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw sockets: Stevens shall provide.
On Fri, Sep 21, 2001 at 12:05:20PM +1200, David Preece wrote:
> Thanks for your help, as suggested the combination of IP_HDRINCL and reading
> Stevens seems to have me back on the right path. Part of the confusion was
> the Linux implementation of IP_HDRINCL appears to need the hardware addresses
> writing as well, consequently there are lots of examples of this being done
> in order to forge arp replies etc - not what I needed. Or rather, it was
> actually.
>
> Anyway, the code is now refusing to send packets entirely, which is actually
> good because it implies a checksum is broken somewhere and that's a bug, not
> a misunderstanding about the API.
>
I didn't follow the thread, but the error may be caused by supplying some
header fields in incorrect byte order. Some fields are expected in host
byte order, and some are in net byte order, e.g. the ip_id (if non-zero).
I wrote the demo program that uses IP_HDRINCL option, attached.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct udppacket {
struct ip ip;
struct udphdr uh;
char data[IP_MAXPACKET - sizeof(struct ip) - sizeof(struct udphdr)];
};
/*
struct ip {
};
struct udphdr {
u_short uh_sport; # source port
u_short uh_dport; # destination port
u_short uh_ulen;# udp length
u_short uh_sum; # udp checksum
};
*/
int
main(void)
{
int s;
int hincl = 1;
struct udppacket packet;
struct sockaddr_in to;
bzero(&to, sizeof to);
to.sin_len = sizeof to;
to.sin_family = AF_INET;
to.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
to.sin_port = 0;
bzero(&packet, offsetof(struct udppacket, data));
packet.ip.ip_v = IPVERSION;
packet.ip.ip_hl = sizeof(packet.ip) >> 2;
packet.ip.ip_len = sizeof(packet.ip) + sizeof(packet.uh);
packet.ip.ip_id = 0;
packet.ip.ip_off = 0;
packet.ip.ip_ttl = MAXTTL;
packet.ip.ip_p = IPPROTO_UDP;
packet.ip.ip_src.s_addr =
packet.ip.ip_dst.s_addr = htonl(INADDR_LOOPBACK);
if ((s = socket(AF_INET, SOCK_RAW, 0)) == -1)
err(1, "socket");
if (setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl)) == -1)
err(1, "setsockopt(IP_HDRINCL)");
if (sendto(s, &packet, 28, 0, (struct sockaddr *)&to, sizeof to) == -1)
err(1, "sendto");
return (0);
}
Re: No tools on 4.4-RELEASE ISO?
On Thu, 20 Sep 2001, Kris Kennaway wrote: > > On Thu, 20 Sep 2001, Jason Andresen wrote: > > > > > Is the tools directory supposed to be missing on the 4.4 CDs? > > I seem to recall these programs were owned by WCCDROM (then BSDi, then > WRS), and there may have been problems in putting them on the ISO now > that WRS isn't responsible for the "official ISO" creation. If so, > the WRS CD release should probably end up containing them. > I get this with strings: Borland C++ - Copyright 1991 Borland Intl. Version 1.5 Copyright (c) 1996-7 Robert Nordier fdimage.exe is available in various linux and OpenBSD directories that turn up with google...guess you just need a bootable cdrom these days... Annelise -- Annelise Anderson Author of: FreeBSD: An Open-Source Operating System for Your PC Book Website: http://www.bittreepress.com/FreeBSD/introbook/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
any reason to use m_devget in the "dc" driver ?
Does anyone know of specific reasons to use m_devget() to extract received packets from the rx buffer in the "dc" driver, as opposed to passing up the mbuf and just replacing it with a fresh one in the controller's queue ? Other drivers just happily do the latter, including the "de" driver, so there seems to be no problem with the chipset in handling this ? Bill, any comments ? cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
