[PATCH] Make hash.h usable in the kernel
Hello, I'm working on potential consumer of functions from sys/hash.h. Currently, I can't make them work without modyfication in my sample KLD. This is a patch which fixes the problem: http://people.freebsd.org/~wkoszek/patches/hash.h.0.patch It makes following program.. http://people.freebsd.org/~wkoszek/hash.c ..compile without warnings with WARNS=5. If noone objects, I'd like to commit it. Thanks, -- Wojciech A. Koszek [EMAIL PROTECTED] http://FreeBSD.czest.pl/dunstan/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Make hash.h usable in the kernel
On Wed, Oct 11, 2006 at 11:02:41AM +0200, Wojciech A. Koszek wrote:
> Hello,
>
> I'm working on potential consumer of functions from sys/hash.h. Currently, I
> can't make them work without modyfication in my sample KLD. This is a patch
> which fixes the problem:
>
> http://people.freebsd.org/~wkoszek/patches/hash.h.0.patch
>
> It makes following program..
>
> http://people.freebsd.org/~wkoszek/hash.c
>
> ..compile without warnings with WARNS=5. If noone objects, I'd like to
> commit it.
>
This is a wrong fix. A correct fix would be:
%%%
Index: sys/sys/hash.h
===
RCS file: /home/ncvs/src/sys/sys/hash.h,v
retrieving revision 1.2
diff -u -p -r1.2 hash.h
--- sys/sys/hash.h 12 Mar 2006 15:34:33 - 1.2
+++ sys/sys/hash.h 11 Oct 2006 09:38:50 -
@@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len,
* namei() hashing of path name parts.
*/
static __inline uint32_t
-hash32_stre(const void *buf, int end, char **ep, uint32_t hash)
+hash32_stre(const void *buf, int end, const char **ep, uint32_t hash)
{
const unsigned char *p = buf;
@@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch
hash = HASHSTEP(hash, *p++);
if (ep)
- *ep = (char *)p;
+ *ep = (const char *)p;
return hash;
}
@@ -105,7 +105,7 @@ hash32_stre(const void *buf, int end, ch
* as a helper for the namei() hashing of path name parts.
*/
static __inline uint32_t
-hash32_strne(const void *buf, size_t len, int end, char **ep, uint32_t hash)
+hash32_strne(const void *buf, size_t len, int end, const char **ep, uint32_t
hash)
{
const unsigned char *p = buf;
@@ -113,7 +113,7 @@ hash32_strne(const void *buf, size_t len
hash = HASHSTEP(hash, *p++);
if (ep)
- *ep = (char *)p;
+ *ep = (const char *)p;
return hash;
}
Index: share/man/man9/hash.9
===
RCS file: /home/ncvs/src/share/man/man9/hash.9,v
retrieving revision 1.2
diff -u -p -r1.2 hash.9
--- share/man/man9/hash.9 30 Sep 2006 17:09:59 - 1.2
+++ share/man/man9/hash.9 11 Oct 2006 09:39:43 -
@@ -47,9 +47,11 @@
.Ft uint32_t
.Fn hash32_strn "void *buf" "size_t len" "uint32_t hash"
.Ft uint32_t
-.Fn hash32_stre "void *buf" "int end" "char **ep" "uint32_t hash"
+.Fn hash32_stre "void *buf" "int end" "const char **ep" "uint32_t hash"
.Ft uint32_t
-.Fn hash32_strne "void *buf" "size_t len" "int end" "char **ep" "uint32_t hash"
+.Fo hash32_strne
+.Fa "void *buf" "size_t len" "int end" "const char **ep" "uint32_t hash"
+.Fc
.Sh DESCRIPTION
The
.Fn hash32
%%%
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpoOe5Oxx40X.pgp
Description: PGP signature
A way to disable reception of broadcast UDP?
Hi all, Is there a well-known way for a UDP application to tell to the system that it doesn't want to receive broadcast datagrams? E.g., it would be very good for TFTP as required by RFC 1123. In general, accepting broadcast UDP is a security flaw unless the higher proto was specifically designed to work with broadcast. SO_BROADCAST affects sending only, and not reception. Dropping broadcast datagrams in the application is not an option because they can't be told without bogus system-dependent hacks. I found that our network stack would stop passing broadcast datagrams to the application as soon as it bound the socket to a particular address, but the status of this feature is unclear to me. By the way, it's the reason for a funny problem: Samba's nmbd won't work if started from inetd bound to a single IP. I can remember that, when T/TCP was there, the respective option must have been enabled on a socket for reception and transmission, for security reasons. (IIRC there was even a security incident related to that.) Perhaps SO_BROADCAST should be given similar semantics? It could improve security of many UDP applications. Any ideas? Thanks! -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A way to disable reception of broadcast UDP?
On Wed, 11 Oct 2006, Yar Tikhiy wrote: > Is there a well-known way for a UDP application to tell to the > system that it doesn't want to receive broadcast datagrams? E.g., > it would be very good for TFTP as required by RFC 1123. In general, > accepting broadcast UDP is a security flaw unless the higher proto > was specifically designed to work with broadcast. I know this doesn't address your question regarding the stack, but you could immediately benefit by having a firewall rule dropping all IP traffic on the broadcast address (and the network address) via the outside interface. Working here since '98, counting plenty of them. If you also wanted to limit UDP on the inside, that's just as easy. Cheers, Ian > SO_BROADCAST affects sending only, and not reception. Dropping > broadcast datagrams in the application is not an option because > they can't be told without bogus system-dependent hacks. I found > that our network stack would stop passing broadcast datagrams to > the application as soon as it bound the socket to a particular > address, but the status of this feature is unclear to me. By the > way, it's the reason for a funny problem: Samba's nmbd won't work > if started from inetd bound to a single IP. > > I can remember that, when T/TCP was there, the respective option > must have been enabled on a socket for reception and transmission, > for security reasons. (IIRC there was even a security incident > related to that.) Perhaps SO_BROADCAST should be given similar > semantics? It could improve security of many UDP applications. > > Any ideas? Thanks! > > -- > Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A way to disable reception of broadcast UDP?
On Wed, Oct 11, 2006 at 11:07:36PM +1000, Ian Smith wrote: > On Wed, 11 Oct 2006, Yar Tikhiy wrote: > > > Is there a well-known way for a UDP application to tell to the > > system that it doesn't want to receive broadcast datagrams? E.g., > > it would be very good for TFTP as required by RFC 1123. In general, > > accepting broadcast UDP is a security flaw unless the higher proto > > was specifically designed to work with broadcast. > > I know this doesn't address your question regarding the stack, but you > could immediately benefit by having a firewall rule dropping all IP > traffic on the broadcast address (and the network address) via the > outside interface. Working here since '98, counting plenty of them. > > If you also wanted to limit UDP on the inside, that's just as easy. Thanks for your comment! However, there are many kinds of broadcast or multicast traffic that can be coming to a UDP app from the outside or a connected network. Those include datagrams destined to broadcast address for any IP alias on this host, should the aliases belong to different IP networks, all multicast groups this host has joined, etc. All of them can be (and are!) distinguished internally by the local stack with M_MCAST and M_BCAST mbuf flags. This information can be hard to maintain on the border router for a large network, and it's lost when passing network data to the application. That was my point. In addition, I think that filtering broadcasts on the border router is a bit redundant today because modern network stacks just drop directed broadcasts. Local broadcast or multicast traffic is the main problem here. -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em blues
the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) dual cpu. running iperf -c (receiving): freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec freebsd-5.4 0.0-10.0 sec413 MBytes346 Mbits/sec freebsd.6.1 0.0-10.0 sec366 MBytes307 Mbits/sec freebsd-6.2 0.0-10.0 sec344 MBytes289 Mbits/sec btw, iperf -s (xmitting) is slightly better freebsd-4.100.0-10.0 sec664 MBytes558 Mbits/sec freebsd-5.4 0.0-10.0 sec390 MBytes327 Mbits/sec freebsd-6.1 0.0-10.0 sec495 MBytes415 Mbits/sec freebsd-6.2 0.0-10.0 sec487 MBytes408 Mbits/sec so, it seems that as the release number increases, the em throughput gets worse - or iperf is. danny ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel PRO 3945ABG Wireless
Doug Barton wrote .. > On Tue, 10 Oct 2006, Paul Schmehl wrote: > > > Why isn't anyone working on updating it? > > This is a volunteer project. No one has volunteered. > > Doug > I think there are some that would like to contribute but don't know where to begin. I, for one, enjoy wireless networking and would like to contribute to the project but I dont know the OS internals and don't have any real programming experience. Perhaps some basic guidance could set people like myself on the right path? I'm not asking for hand-holding, just something to start with. -Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A way to disable reception of broadcast UDP?
On Wed, 11 Oct 2006, Yar Tikhiy wrote: > On Wed, Oct 11, 2006 at 11:07:36PM +1000, Ian Smith wrote: > > On Wed, 11 Oct 2006, Yar Tikhiy wrote: > > > > > Is there a well-known way for a UDP application to tell to the > > > system that it doesn't want to receive broadcast datagrams? E.g., > > > it would be very good for TFTP as required by RFC 1123. In general, > > > accepting broadcast UDP is a security flaw unless the higher proto > > > was specifically designed to work with broadcast. > > > > I know this doesn't address your question regarding the stack, but you > > could immediately benefit by having a firewall rule dropping all IP > > traffic on the broadcast address (and the network address) via the > > outside interface. Working here since '98, counting plenty of them. > > > > If you also wanted to limit UDP on the inside, that's just as easy. > > Thanks for your comment! However, there are many kinds of broadcast > or multicast traffic that can be coming to a UDP app from the outside > or a connected network. Those include datagrams destined to broadcast > address for any IP alias on this host, should the aliases belong > to different IP networks, all multicast groups this host has joined, > etc. All of them can be (and are!) distinguished internally by the > local stack with M_MCAST and M_BCAST mbuf flags. This information > can be hard to maintain on the border router for a large network, > and it's lost when passing network data to the application. That > was my point. And for once I'd thought I wasn't too far out of my depth :) > In addition, I think that filtering broadcasts on the border router > is a bit redundant today because modern network stacks just drop > directed broadcasts. Local broadcast or multicast traffic is the > main problem here. Thanks for the education. Back to lurking, awaiting a learned response. Cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel PRO 3945ABG Wireless
--On Tuesday, October 10, 2006 22:30:29 -0700 Doug Barton <[EMAIL PROTECTED]> wrote: On Tue, 10 Oct 2006, Paul Schmehl wrote: Why isn't anyone working on updating it? This is a volunteer project. No one has volunteered. I'd volunteer if I had a clue. I'm not a programmer, and my only exposure to C/C++ is two semesters a while ago. I doubt you want me writing device drivers. :-) I understand that the guy who was writing the driver had some sort of disagreement with someone and dropped the project. He's still maintaining the driver for OpenBSD. I'm wondering how much work it would take to adapt what's in OBSD CVS to FBSD and get the thing working? Is it a simple matter of fixing paths so they point to the right source and header files? Or is there more to it? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: Intel PRO 3945ABG Wireless
On Wednesday 11 October 2006 17:32, Yuri Lukin wrote: > Doug Barton wrote .. > > > On Tue, 10 Oct 2006, Paul Schmehl wrote: > > > Why isn't anyone working on updating it? > > > > This is a volunteer project. No one has volunteered. > > > > Doug > > I think there are some that would like to contribute but don't > know where to begin. I, for one, enjoy wireless networking > and would like to contribute to the project but I dont > know the OS internals and don't have any real programming > experience. Perhaps some basic guidance could set people > like myself on the right path? I'm not asking for hand-holding, > just something to start with. There are three things that need to be done here: 1) Adapt the bus interface. This is not too much work and should boil down to a couple of sed(1)s and a few manual edits. Check drivers that are in OpenBSD and FreeBSD and compare, or just check existing drivers. The DRIVER(9) manual page and jmg@'s paper[1,2] should provide additional insight. 2) Use firmware(9) to load the ucode - as far as I understand the device needs firmware as well. This shouldn't be much work and can be taken verbatim from iwi(4). 3) Adapt the net80211 interface. This one's a bit tricky since OpenBSD went a different way with their 80211 implementation. Again, looking at existing drivers (esp. ath(4) as the reference implementation and iwi(4) as a driver from OpenBSD that was also retrofitted into FreeBSD) should give an idea what is done how. In the end, you won't know what problems you come across until you start with it. I can help with questions regarding 2 & 3, but will be busy for the next two months and don't have a 3945 to test with, either. [1] http://www.bsdcan.org/2006/papers/freebsd.driver.pdf [2] http://www.bsdcan.org/2006/papers/freebsd.device.driver.slides.pdf -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpFy5UcENZQ1.pgp Description: PGP signature
Re: em blues
On 10/11/06, Danny Braniss <[EMAIL PROTECTED]> wrote: the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) dual cpu. running iperf -c (receiving): freebsd-4.100.0-10.0 sec936 MBytes785 Mbits/sec freebsd-5.4 0.0-10.0 sec413 MBytes346 Mbits/sec freebsd.6.1 0.0-10.0 sec366 MBytes307 Mbits/sec freebsd-6.2 0.0-10.0 sec344 MBytes289 Mbits/sec btw, iperf -s (xmitting) is slightly better freebsd-4.100.0-10.0 sec664 MBytes558 Mbits/sec freebsd-5.4 0.0-10.0 sec390 MBytes327 Mbits/sec freebsd-6.1 0.0-10.0 sec495 MBytes415 Mbits/sec freebsd-6.2 0.0-10.0 sec487 MBytes408 Mbits/sec so, it seems that as the release number increases, the em throughput gets worse - or iperf is. You arent measuring em, you're measuring RELEASES on your hardware, is this a surprise on a P3, no. I still do 930ish Mb/s on a P4 with a PCI-E or PCI-X adaptors running 6.1, in fact can do that with a 4 port adaptor I believe. Regards, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em blues
On Wed, 11 Oct 2006 16:06:17 +0200, in sentex.lists.freebsd.net you wrote: >the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) >dual cpu. > >running iperf -c (receiving): > >freebsd-4.10 0.0-10.0 sec936 MBytes785 Mbits/sec >freebsd-5.40.0-10.0 sec413 MBytes346 Mbits/sec >freebsd.6.10.0-10.0 sec366 MBytes307 Mbits/sec >freebsd-6.20.0-10.0 sec344 MBytes289 Mbits/sec > >btw, iperf -s (xmitting) is slightly better >freebsd-4.10 0.0-10.0 sec664 MBytes558 Mbits/sec >freebsd-5.40.0-10.0 sec390 MBytes327 Mbits/sec >freebsd-6.10.0-10.0 sec495 MBytes415 Mbits/sec >freebsd-6.20.0-10.0 sec487 MBytes408 Mbits/sec > >so, it seems that as the release number increases, the em >throughput gets worse - or iperf is. Hi, What is your setup for testing ? For me, with a couple of em NICs back to back I get iperf -c 1.1.1.2 Client connecting to 1.1.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 1.1.1.1 port 57584 connected with 1.1.1.2 port 5001 [ 3] 0.0-10.0 sec 1.06 GBytes914 Mbits/sec 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Mon Oct 9 23:22:10 EDT 2006 One is a Pentium(R) 4 CPU 3.00GHz and the other an AMD 3800 X2 Going the other way is about the same (900Mb) ---Mike > >danny > > >___ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "[EMAIL PROTECTED]" Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 [EMAIL PROTECTED], (http://www.tancsa.com) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Make hash.h usable in the kernel
On Wed, 11 Oct 2006, Ruslan Ermilov wrote:
On Wed, Oct 11, 2006 at 11:02:41AM +0200, Wojciech A. Koszek wrote:
I'm working on potential consumer of functions from sys/hash.h. Currently, I
can't make them work without modyfication in my sample KLD. This is a patch
which fixes the problem:
...
This is a wrong fix. A correct fix would be:
%%%
Index: sys/sys/hash.h
===
RCS file: /home/ncvs/src/sys/sys/hash.h,v
retrieving revision 1.2
diff -u -p -r1.2 hash.h
--- sys/sys/hash.h 12 Mar 2006 15:34:33 - 1.2
+++ sys/sys/hash.h 11 Oct 2006 09:38:50 -
@@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len,
* namei() hashing of path name parts.
*/
static __inline uint32_t
-hash32_stre(const void *buf, int end, char **ep, uint32_t hash)
+hash32_stre(const void *buf, int end, const char **ep, uint32_t hash)
{
const unsigned char *p = buf;
I think this would break passing ep in almost all callers, in the same
way that "fixing" the corresponding arg in the strtol(3) family would
break almost all callers. Callers want and need to pass char **, but
char ** is not compatible with const char **. Callers want to do this
because it's easier to write "char *end; ... &end", and they often
need to do this so that they can modify the resulting *end. Changing
the prototype forces all callers to use "const char **end; ... &end",
and then if they want to modify *end, to convert `end' to plain char *.
Modifying *end is only valid if the original string is modifyable, and
this case ends up needing lots of ugly casting away of const, which
leads to compiler warnings, which lead to even uglier things like the
__DECONST() mistake to "fix" the warnings.
Similarly for the strchr(3) family.
@@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch
hash = HASHSTEP(hash, *p++);
if (ep)
- *ep = (char *)p;
+ *ep = (const char *)p;
return hash;
}
Doesn't this cause a cast-qual warning in the kernel?
@@ -105,7 +105,7 @@ hash32_stre(const void *buf, int end, ch
* as a helper for the namei() hashing of path name parts.
*/
static __inline uint32_t
-hash32_strne(const void *buf, size_t len, int end, char **ep, uint32_t hash)
+hash32_strne(const void *buf, size_t len, int end, const char **ep, uint32_t
hash)
Line too long.
Bruce
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with IBM NetXtreme 1000-T GigaEthernet Adapter
David / list, Some new developments/leads on this issue:- On 8/21/06, Senandung Mendonan <[EMAIL PROTECTED]> wrote: > If you could attach a dump of dmesg that shows the messages from the > driver that might help too. Here's the dmesg for the dual-port version:- pci5: on pcib4 bge0: mem 0xdcff-0xdcff irq 48 at device 1.0 on pci5 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:10:18:11:2a:0d bge1: mem 0xdcfe-0xdcfe irq 49 at device 1.1 on pci5 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:10:18:11:2a:0a After deploying on a few servers, we realized some of the servers work OK, and some not, although the cards are apparently same model, with same dmesg shown above. Upon closer inspection, we found out that the two NICs' chipsets differ in minor revision:- 1. The working NIC:- Broadcom BCM5704CKRB TS0341 P13 706741 B (manufactured 23/12/2004, older revision of the same BCM5704C chipset supported by the FreeBSD bge driver. ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/old-23-12-2004.jpg ) 2. The intermittent NIC:- Broadcom BCM5704CKRB CS0424 P20 723153B B (unknown manufacture date, but probably newer than the working NIC). ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/new.jpg ) I have yet to try a 6.2 kernel, the site has no internet connections and a bit far, so takes a while for me to try that. In the meantime, perhaps with the chipset details you have some ideas? Thanks. --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..") ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pf.conf + altq problem
Dear list.
My pf.conf not working.
I have pf in bridge machine with xl2 to internet firewall and xl1 to
internal switch. Bridging is ok.
This my simple pf.conf
me="172.16.0.228"
altq on xl1 bandwidth 100% cbq queue {me,dflt}
queue mebandwidth 8Kb
queue dflt bandwidth 16Kb cbq (default)
block log on {xl1,xl2} all
pass out log on xl1 from $me to any keep state
pass log on xl2 from $me to any keep state queue (me)
This rule is match when i try to connect to iperf server
# tcpdump -nett -i pflog0 | grep 172.16.0.228
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG
1160655756.150048 rule 3/(match) pass in on xl2: 172.16.0.228.44405 >
128.6.231.102.5001: [|tcp] (DF)
1160655756.150059 rule 2/(match) pass out on xl1: 172.16.0.228.44405 >
128.6.231.102.5001: [|tcp] (DF)
But iperf tell me that this connection is 24.4 Kbits/Sec. (more than
8Kbps)
[EMAIL PROTECTED] beastie]# iperf -c lss.rutgers.edu
Client connecting to lss.rutgers.edu, TCP port 5001
TCP window size: 16.0 KByte (default)
[ 3] local 172.16.0.228 port 44408 connected with 128.6.231.102 port
5001
[ 3] 0.0-16.1 sec 48.0 KBytes 24.4 Kbits/sec
I'm expecting that iperf report it equal with the bandwidth that i
assign to (me) queue pipe.
Is there any thing wrong or i missed something here ???
Please help me
regards
Reza
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
