Problems with Davicom network chip under load.
Hi, I was just attempting to move an iso image between two 4.3-Release machines, the server being a PPro180 with i82559 and the client being a P3-933 with a Davicom network chip. FTP'ing an image from server to client resulted in the client aparrently losing the plot at layer 3 - a ping running simultaneously stops responding at the same time. This proved to be extremely repeatable. Doing ifconfig dc0 down, then up again fixes the problem temporarily. There is nothing in either dmesg nor /var/log/messages about this, and netstat -m shows nothing abnormal. Is this a known problem? RTFM'ing a little I see a recent CVS commit (http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/pci/if_dc.c), version 1.54 "Deal with the condition where we lose link in the middle of transmitting a bunch of frames."? Is this therefore fixed under 4.4? BTW, as a short term fix, the same machine has a realtek chipset so I swopped the configuration over and all is good. Must do the 4.4 upgrade (sigh). Cheers, Dave ---FYI, Configuration-- (a snipped dmesg) FreeBSD 4.3-RELEASE #4: Fri Sep 21 16:08:35 NZST 2001 CPU: Pentium III/Pentium III Xeon/Celeron (930.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 real memory = 134135808 (130992K bytes) avail memory = 127950848 (124952K bytes) Preloaded elf kernel "kernel" at 0xc02a4000. Preloaded elf module "agp.ko" at 0xc02a409c. Pentium Pro MTRR support enabled agp0: mem 0xe000-0xe7ff at device 0.0 on pci0pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at 0.0 irq 11 rl0: port 0xa800-0xa8ff mem 0xdb80-0xdb8000ff irq 5 at device 10.0 on pci0 rl0: Ethernet address: 00:50:bf:25:54:ce miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: port 0xa400-0xa4ff mem 0xdb00-0xdbff irq 10 at device 11.0 on pci0 dc0: Ethernet address: 00:80:ad:72:b6:cc miibus1: on dc0 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto 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
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
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
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: Fwd: MTU table?
On Tue, 18 Sep 2001 09:47, you wrote: > If "route get " shows an MTU of 576, "route delete > " should clear it. Yeah, that does it a treat. Thanks, Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fwd: MTU table?
Hi, I tried this on -questions but to no avail. It strikes me as something that is either dead easy, or can't be done. Does anyone have any ideas? Thanks, Dave -- Forwarded Message -- Subject: MTU table? Date: Mon, 17 Sep 2001 17:40:35 +1200 From: David Preece <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hi, I have a network consisting of: Server (mtu1500)<->(mtu1500)gateway(mtu576)<->Client (mtu1500) The server and gateway are both FreeBSD4.x machines and the client is NT4, hence changing MTU is a bit of a mystery, but I digress. So, the first time the client connects to the server and the server attempts to send back a packet of over 576 bytes, the gateway objects and sends back an ICMP 3(4) saying that the packet can't be forwarded until the MTU is reduced to 576. The server tries again with the new MTU and all is well. The kernel on the server also has the good sense to remember that there's an MTU of 576 bytes on that route and doesn't try anything larger in future. This would be great *except* that I'm trying to turn the whole thing into a factory for ICMP cannot fragment messages. Is there a simple way to flush the route->mtu table on the server? Thanks, Dave --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Your new web site
I don't know about anyone else, but it made my day. At 12:27 AM 6/21/01 -0400: >FRESH AIR TODAY WEB DESIGN >JIM WEAVER & KIM NICE >3071 HWY 101 NORTH >GEARHART, OR 97138 >1-503-738-0657 >1-877-230-7268 Is anyone close enough to drive round and have a quiet word? "Netiquette" for instance. Or "asking for trouble". Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Injecting a packet with explicit route.
Hi, Due to the wonder of IPFW and divert sockets I have been merrily catching packets, modifying them and reinjecting back in from userland to great effect for some time now. What I would like (need) to do is much the same, but being able to explicitly state which route to take (for a packet going outwards), or being able to tell which route a packet came in from (for a packet coming inwards). I suspect the necessary stunts are to have access to sufficiently low level networking to be able to capture and write a packet with layer 2 information, which probably involves netgraph? Can anyone think of another way? Oh, and if I do go to netgraph (in itself not a bad thing), do I have to use a kernel mode debugger - just too addicted to KDevelop I guess. Thanks, Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating BSD bootable CD
At 17:10 19/02/2001 -0700, you wrote: >I'm interested in taking FreeBSD and putting it on a bootable CD for use in >a so-called "appliance". Can anyone recommend a place to start? I started in the handbook, the section on backups and creating a bootable floppy was invaluable. It's also worth trawling the archives of freebsd-small, in particular look for "tinybsd" which (IIRC) is a configurable script for making a small installation of FreeBSD without going to the lengths that pico goes to, crunchgen etc. This is an eminently doable problem, you have a good half dozen valid approaches that can be taken. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Xbox
At 17:37 7/01/01 -0500, you wrote: >Does anyone know enough about Xbox internals to verify that >FreeBSD will or will not be able to run on Xbox without any type of >hardware modification? No, but if you'd like to be into that kind of thing I understand the NetBSD/Dreamcast port is coming along quite nicely. >mohan Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
At 10:12 28/12/00 -0700, you wrote: >Lastly, search for quiet fans from a large supplier. http://www.quietpc.com/ I haven't bought any stuff from them, yet, so I can't vouch other than for their existence. Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
At 15:37 22/12/00 -0800, you wrote: >The question asked is: why you believe ssh is beter >than say telnet. Or what advantages SSH has in general. Sorry, don't have time to reply to this properly. The main evil of ssh is that server authentication is not enforced, making mounting a man-in-the-middle attack basically trivial. As ever, IMHO. Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KB problemo.
At 17:00 22/12/00 -0500, you wrote: >On a reboot I get >bp, then keyboard not found or keyboard error. So, yes >as mentioned just recently on this list, hard switches are _BAD_. So the keyboard controller's toast, is that what we're saying? Presumably you've tried connecting the keyboard directly to eliminate the all too real possiblity that it's the switch that's broken? > Now, aside from purchasing a new mb [snip] >b) use either a >serial port or parellel port to get this machine back up? Ah, man, good one because it's the kind of thing you would have no chance whatsoever of doing under Windows :) The important point here has nothing to do with FreeBSD at all: Will your BIOS let the booting process continue without a keyboard. Or do you get the monster cliche'd "keyboard error, press F1 to continue"? If it won't continue booting, adieu to the motherboard. If it will then I suggest putting the hard drive in another fairly similar machine and configuring BSD to run headless i.e. using a serial port as the console. I have a development box I've been using like this for about six months and have had no problems at all. Doesn't even have a video card in it. So, obviously, you then put the hard drive back in the box with the dead keyboard controller and run a serial cable over to your workstation. Anytime you need to log on, do it over the cable. Problem solved, with extra brownie points because it's secure. Configuring FreeBSD to run headless is a FAQ on -small, and consequently I did a page about it that's hosted in half a dozen places none of which I can remember. Search the archive on -small for "headless" and you'll be there. >Paul H. Dave :) PS. Probably better on -questions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 21:54 19/12/00 -0600, you wrote: > >Presumably it's all going to go a little tits-up when they start getting > >series 8 parts? > >I was about to ask you to explain why this would be a problem, but I suppose >you can't. :) I thought they were using intel 82559's and came with FreeBSD 4.x preinstalled... http://www.bsdi.com/products/pdfs/1200_series.qxd.pdf >Anyway, I haven't heard anything, but this could be an issue >for BSD/OS, too, since the exp(4) driver is shipped to source license >customers... exp? fxp! Oh, I suppose it might be exp in BSD/OS, I dunno. >-s David Preece To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 18:47 19/12/00 -0800, you wrote: >Sergey Babkin wrote: > > > > The drivers are _not_ assets. When I buy a piece of hardware I > > very reasonably expect that it would come with drivers or at > > least the manual on how to write these. It's a part of the deal. > >However, if the device requires software to take on part of the >functionality (examples: WinModems, although I'm not sure whether it's >the driver or the OS that's doing the work there. I also suspect some >OpenGL cards may be like this), then the driver is more likely to be >considered an asset. I was on the point of stepping in with a very similar opinion. While I'm deeply hacked off at Intel for not dropping the NDA on 82559 series 8, causing me to have to think twice about using them in a commercial product, or indeed about using Intel at all, I can see a situation where I do feel it is fair: A lot of the reason why 3dfx (rip), Nvidia et al. often feel they cannot release open source drivers is that a substantial proportion of what these products do takes place on the host processor. Large quantities of research go into the exact division of tasks between host processor and offload processor, hence a large amount of their competitive advantage is derived from the driver code. They cannot afford to release it. Furthermore, AGP represents a substantial bottleneck to them, the protocol by which they get information down it is also of great commercial significance. Asking for open source drivers in these cases is much like asking for open source firmware on the boards themselves, simply not going to happen. To conclude: Open source, preferred. Closed source, OK. No driver whatsoever, bad. Bad bad bad. Should this really still be on -hackers? >Justin Wojdacki David Preece Aside: 82559/8, how does this affect BSDi's pre-installed rackmount boxes? Presumably it's all going to go a little tits-up when they start getting series 8 parts? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Writing Device Drivers
At 13:02 17/12/00 +, you wrote: >Does anyone have any good tips to get started / HowTo's, or some simple >examples >that will give me knowledge like the PC Speaker or something simple like >that? This is turning into a FAQ, but don't worry about it. The usual answer is to take one of the existing drivers and work out what it does. There's also a script for making shell drivers under /usr/share/examples/drivers. As for things like "how does DMA work?", "what exactly is an interrupt and what do I do with it?" or "what's the story with memory ranges and devices then?" then I'm afraid I can't help you there. In fact (to -hackers) this strikes me as one of the more fundamental problems of free software: I would go and write/fix some device drivers (for example the unknown phy in fxp that bothers me so much), except I can't really get a handle on how you're supposed to start on these things. Comments? URL's for IRQ101? Perhaps I should just stop whingeing and go hack with it to see what happens? (probably best). >Jamie Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CD ROM
At 08:44 11/11/00 +, you wrote: >I've got a problem with my CD ROM. The drawer keeps sliding open every >time I try to put a CD into it, it just won't stay shut. Have you got any >ideas? I have one CD ROM that used to do the same thing some of the time. Then more often. Now, nearly 100% of the time. Under Windows it merely fails to mount the disk. The drive now has "F**KED" written across it in indelible felt tip, I have yet to work out why I've not thrown it away. Borrow another drive. Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD in good standing in netcraft survey
Possibly off topic, possibly not. Am I the only one who doesn't really care about uptimes? It would be far more productive to get a top 100 (or whatever) of availability... More interesting would be to test availability based on some dynamic content, a given request with an expected outcome a la F5? I may be forced to hack this together, where's my damn cable modem!!! Dave :) BTW, we didn't fare very well at all in the top *average* uptimes. Sun, OTOH, did. Bugger. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem holes
At 19:16 29/10/00 -0800, you wrote: > Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I > will tell you quite frankly that virtually *nobody* depends on holes > for efficient storage. There are only a few problems where it's > practical some forms of executables, and sparse matrixes. That's > pretty much it. Presumably writing into these holes repeatedly is a none-too-efficient affair (requiring moving all the stuff on either side), or am I missing the point slightly? Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
disklabel madness, make it boot...
It should be easy. I'm trying to get a 24Mb CF card to be a bootable drive from 4.0. I have it wired on the primary IDE as a slave drive, it is therefore ad1 and the following almost works: fdisk -I ad1 #take the whole MSDOS partition table dd if=/dev/zero of=/dev/rad1 bs=1k count=1 #Wipe the existing disk label disklabel -rwB ad1 auto #write a disk label newfs /dev/rad1c #create new file system ...when accompanied by copying over the kernel and other such (hints taken from handbook on making a rescue floppy for backups). The boot blocks run and complain because there's no kernel on ad(0,a), which is fair enough since it's on ad(0,c). So giving it the hint it boots the kernel then complains about failing to mount /sbin/init (which is also on 0,c). Anyway, it became clear to me that 'c' is the 'complete' unix partition and what I needed was an 'a' (or root) partition and that such a thing was set using disklabel (correct?). Anyway, to get a first shot I used /stand/sysinstall and wrote the disklabel, which appeared to then bin out my real drive (which fixed itself on reboot), so this is a significant bug in itself. Anyway, I then got the disklabel, which is currently this: # /dev/rad1c: type: ESDI disk: ad1s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 4 sectors/cylinder: 128 cylinders: 368 sectors/unit: 47200 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a:4720004.2BSD 1024 819216 # (Cyl.0 - 368*) c:472000unused0 0 # (Cyl.0 - 368*) (sorry for the bloat), so we can see the whole disk is turned over to an 'a' partition. I piped this to disk (file, disklabel.24meg) and modified my script to: fdisk -I ad1 dd if=/dev/zero of=/dev/ad1 bs=1k count=1 disklabel -R -B ad1 disklabel.24meg newfs /dev/rad1a #create new file system And while I can mount the filesystem with mount /dev/ad1a if I now set this to be the master drive (and disconnect the other one), I get a 'Missing Operating System' from the BIOS - i.e. where are the boot blocks then?. It appears the -B in disklabel isn't working. Stunts I've tried include setting the disklabel to say 'disk: ad0s1' (for when it restarts being the master on the channel), doing a separate 'disklabel -B ad1' to force the boot blocks on and doing the -B within fdisk (i.e. 'fdisk -IB ad1'). The usual combinations of sleep, coffee and sacrifices to the gods also seem to do nothing. Help help help. I have no idea what I'm doing wrong here and any pointers would be much appreciated. As an aside, and a point of view that will no doubt not prove very popular, is this: I'm not a great hacker, but I'm not crap either and this is driving me up the wall. We are talking DCOM levels of frustration here and I can't help the feeling that the whole thing is just too damn complicated... Anyway, advice _please_ and flames if you really must. Dave :( BTW, -B option in fdisk is ignored if -f is specified, yet there is no command in the configuration file to set boot blocks, what gives?. See fdisk(8). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re:Neil Clayton, Sending personal mail to this list, Sorry.
Idiot. Never forward an email about how terrible Realtek are to a linux freak, they'll completely fail to reply properly. Some people just should not be allowed computers, they may hurt themselves. Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
