About nge NIC problem
Hi,I have trouble in using nge NIC(LinkSys EG1032) to support Novell and Applein FreeBSD 4.5.The apple software is netatalk 1.5.3.1. And the novell netware software isMARS_NWE.The TCP/IP and the Samba work well on the nge.Do you have any experiance on netatalk and MARS_NWE of the nge NIC?Please help. Best RegardsOuyang KaiGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com Hi, I have trouble in using nge NIC(LinkSys EG1032) to support Novell and Apple in FreeBSD 4.5. The apple software is netatalk 1.5.3.1. And the novell netware software is MARS_NWE. The TCP/IP and the Samba work well on the nge. Do you have any experiance on netatalk and MARS_NWE of the nge NIC? Please help. Best Regards Ouyang Kai
Re: Thread-safe resolver [patches for review]
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > > You may also want to consider the use of a .init and .fini
> > > section for the code, to permit the creation of an initial
> > > lookup context chunk; this is kind of a tradeoff, but it will
> > > mean that a server will not have to do the recheck each time.
> > > The .fini section would aloow auto-cleanup. This may be a
> > > necessity for a long running program that uses a shared object
> > > to perform the thread creation and lookup (you could leak
> > > memory, otherwise).
> >
> > Could you please elaborate how exactly memory could be leaked in this
> > case, if the program does correctly shut down all its threads?
>
> Create PIC object foo.so.
> Link PIC object foo.so against libc.so.
> Call dlopen to load module foo.so into program "bob".
> Call function in foo.so from program "bob".
> Function in foo.so creates two threads, one for IPv4 lookup,
> another for IPv6 lookup to cause lookups to proceed
> concurrently.
> Lookup completes.
> Unload module foo.so.
> -> leak memory in libc.so image
This scenario doesn't look as a legitimate way to do things for me.
Let's inspect what will happen when you are unloading a PIC module,
which has one or more threads running. There are two possibilities:
either thread scheduler (libc_r) was linked with the program itself
and therefore loaded with it, or it was linked with PIC module and
loaded along with that module. In the first case, after you have
dlclose'd the PIC module, dynamic linker will unmap module's code from
memory, but the thread scheduler will remain running and on the next
attempt to pass control to the thread in your PIC module will probably
get SIGBUS due to the fact that code is no longer mapped. In the
second case, you'll unload module along with thread scheduler, but
thread-scheduling signals setup will remain in place, so that shortly
you will get the same SIGBUS, when the kernel will be trying to
delivery signal to no longer mapper region.
In either case, you will get the problem much more serious than memory
leak.
> The assumption (which is potentially wrong) is that the program
> will correctly shut down all its threads, when in fact it was a
> module not under the programs control that created and used the
> threads.
I do not quite agree. In such case, the module should probably have
destructor function, either placed into the fini section, or to be
explicitly called by the program before dlclose().
> The leak depends on:
>
> 1) A pool of worker threads being created and left around
> or the purpose of simultaneous resolution
>
> 2) The parent shutting down the module without explicitly
> dealing with the threads (basically, code which would
> need to live in ".fini" of the foo.so, and could not be
> automatically triggered on unload of foo.so any other way).
>
> I think that parallel IPv6/IPv4 resolution presented as a single
> serial interface is a high probability implementation with the
> support for threaded access to the resolver, particularly with
> the Mozilla code acting the way it does.
>
> > I also would like to hear from you whether or not you think that we
> > need all those gethostbyXXX_r(3) functions.
>
> No. I don't think any of the _r functions are needed, so long
> as the results are not cached by pointer instead of a copy,
> before passing them from one thread to another. It's a risk on
> the clobber case of a call with a cached reference outstanding
> but not processed by another thread which is not an issue with
> the _r functions, which require that you pass the storage down.
>
> Of course, if you pass down per thread storage, you could have
> the same problem if you didn't copy rather than reference the
> results before passing to another thread by address.
>
> Given that, per thread allocations ("thread local storage")
> makes more sense than allocate/free fights between threads
> based on who's responsible for owning the memory after an
> inter-thread call. 8-).
Thank you for the explanation!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
Maxim Sobolev wrote: > This scenario doesn't look as a legitimate way to do things for me. > Let's inspect what will happen when you are unloading a PIC module, > which has one or more threads running. There are two possibilities: > either thread scheduler (libc_r) was linked with the program itself > and therefore loaded with it, or it was linked with PIC module and > loaded along with that module. In the first case, after you have > dlclose'd the PIC module, dynamic linker will unmap module's code from > memory, but the thread scheduler will remain running and on the next > attempt to pass control to the thread in your PIC module will probably > get SIGBUS due to the fact that code is no longer mapped. In the > second case, you'll unload module along with thread scheduler, but > thread-scheduling signals setup will remain in place, so that shortly > you will get the same SIGBUS, when the kernel will be trying to > delivery signal to no longer mapper region. Unless you have a single exported API from the .so that takes a single request, and does simultaneous lookups. The result will be two inactive threads hanging on a condition variable which will never come true, because the function which makes it true in order to trigger the parallel lookup has been unloaded. Basically, a sleep is a sleep, and it doesn't matter if the code that caused it is there any more or not, if you never get a wakeup. To use an analogy, it doesn't matter if the SIGHUP handler will cause a core dump, if you never get a SIGHUP, does it? > In either case, you will get the problem much more serious than memory > leak. Assuming, incorrectly, that you are talking to the threads directly, rather than to a proxy function. The calling program need not be threaded or support threads. > > The assumption (which is potentially wrong) is that the program > > will correctly shut down all its threads, when in fact it was a > > module not under the programs control that created and used the > > threads. > > I do not quite agree. In such case, the module should probably have > destructor function, either placed into the fini section, or to be > explicitly called by the program before dlclose(). Uh, that's exactly the argument I was making: use a .fini section to clean up the per thread memory allocations. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
Daniel Eischen wrote: > > On Mon, 12 Aug 2002, Maxim Sobolev wrote: > > Folks, > > > > Attched please find two patches based on bin/29581 PR to make FreeBSD > > resolver thread-safe. They represent two approaches to reach this goal > > - the first is to introduce reentrant versions of the standard > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > Why do you need uthread_resolv.c? You should be able to thread > calls by checking __isthreaded. Just keep everything in libc. > If there are missing stubs for some pthread_* routines (I think > everything you need is in -current's libc), then add them. I did that, but I can't fugure out correct way to get _thread_run and _thread_initial symbols into libc from libc_r. Any ideas? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Wrong paths for named-xfer (STABLE/CURRENT)
Hi, We noted that named-xfer does not work in STABLE and CURRENT. Named does look for it in /usr/local/libexec than in /usr/libexec. But named-xfer gets installed into /usr/libexec. I guess the paths are just plain wrong here in the Makefile. I made a patch: --- contrib/bind/bin/named/Makefile.origTue Aug 13 13:05:29 2002 +++ contrib/bind/bin/named/Makefile Tue Aug 13 13:05:32 2002 @@ -33,9 +33,9 @@ EXE= YACC = yacc -d SYSLIBS = -ll -lutil -DESTBIN = /usr/local/bin -DESTSBIN = /usr/local/sbin -DESTEXEC = /usr/local/libexec +DESTBIN = /usr/bin +DESTSBIN = /usr/sbin +DESTEXEC = /usr/libexec DESTMAN = /usr/share/man DESTHELP= /usr/share/misc DESTETC= /etc We don't install named into /usr/local, do we ? Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wrong paths for named-xfer (STABLE/CURRENT)
On Tue, Aug 13, 2002 at 01:15:56PM +0200, Martin Blapp wrote: > > Hi, > > We noted that named-xfer does not work in STABLE and CURRENT. > Named does look for it in /usr/local/libexec than in /usr/libexec. > > But named-xfer gets installed into /usr/libexec. > > I guess the paths are just plain wrong here in the Makefile. > > I made a patch: > > --- contrib/bind/bin/named/Makefile.orig Tue Aug 13 13:05:29 2002 > +++ contrib/bind/bin/named/Makefile Tue Aug 13 13:05:32 2002 > @@ -33,9 +33,9 @@ > EXE= > YACC = yacc -d > SYSLIBS = -ll -lutil > -DESTBIN = /usr/local/bin > -DESTSBIN = /usr/local/sbin > -DESTEXEC = /usr/local/libexec > +DESTBIN = /usr/bin > +DESTSBIN = /usr/sbin > +DESTEXEC = /usr/libexec > DESTMAN = /usr/share/man > DESTHELP= /usr/share/misc > DESTETC= /etc > > We don't install named into /usr/local, do we ? We don't use Makesfile inside src/contrib. See src/usr/sbin/named/Makefile.inc where the values are correct. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wrong paths for named-xfer (STABLE/CURRENT)
Hi, > > We don't install named into /usr/local, do we ? > > We don't use Makesfile inside src/contrib. Thanks very much ! > See src/usr/sbin/named/Makefile.inc where the values are correct. Ahh know I see what happened. I went one time into src/contrib last week and typed make at the wrong place. Then pathnamed.h was accidently generated. >From a normal build, this file was used and - bang ... :/ Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP routing question
Hi, I want to do the following: 1. Create "n" IPSEC VPN tunnels 2. Create "n" VLAN pseudo interfaces 3. Route IP Packets based on their arrival iface/tunnel out through a corresponding tunnel/iface. For example, I want to route all packets received through VPN tunnel "2" out through VLAN "2," and all packets received on VLAN "2" out through VPN "2," without regard to source or destination IP Addresses. I don't want to examine the IP Addresses of any of the routed packets, but only want to make the routing decision based on arrival interface. Does anyone have any ideas or suggestions? Please? -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
Port for Sun Grdiware 5.3
Is there any port of Sun Gridware 5.3 for FreeBSD? I found the source code is open and there're binaries for several arch/OS's there but couldn't see any FreeBSD port. http://gridengine.sunsource.net Let me know if you have any information about that. Thanks, Alp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question (fwd)
I tried to send this directly however it seems your provider is blocking something like 203.0.0.0/8...or I'm just unlucky... Andrew -- Forwarded message -- Date: Wed, 14 Aug 2002 00:46:27 +1000 (EST) From: Andrew <[EMAIL PROTECTED]> To: Les Biffle <[EMAIL PROTECTED]> Subject: Re: IP routing question On Tue, 13 Aug 2002, Les Biffle wrote: > I don't want to examine the IP Addresses of any of the routed packets, > but only want to make the routing decision based on arrival interface. You might get away with ipfw rulles using via and next-hop. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Les Biffle wrote: > 1. Create "n" IPSEC VPN tunnels > 2. Create "n" VLAN pseudo interfaces > 3. Route IP Packets based on their arrival iface/tunnel out through > a corresponding tunnel/iface. > > For example, I want to route all packets received through VPN tunnel "2" > out through VLAN "2," and all packets received on VLAN "2" out through > VPN "2," without regard to source or destination IP Addresses. > > I don't want to examine the IP Addresses of any of the routed packets, > but only want to make the routing decision based on arrival interface. > > Does anyone have any ideas or suggestions? Please? IPsec tunnel mode won't work, since SAs aren't represented as Interfaces. I'm not aware of any routing daemon that can use inbound interfaces as a parameter in its forwarding decision, otherwise using IPIP tunnels together with IPsec transport mode (draft-touch-ipsec-vpn-04.txt) might have worked with whatever daemon does that. You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, but then you say you don't want to look at IP addresses... So no, I don't see how it can be done under your constraints. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
SCSI device emulation using SCSI host controller
Hi! I beg you all pardon for a question not related directly to FreeBSD, but if the answer is ``yes'', then I believe FreeBSD will be in deal. The question is: "Can I emulate a SCSI device (tape, if that matters) using usual SCSI host controller and specific software, or I will definitely need specific hardware?" Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
(snip) > You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, > but then you say you don't want to look at IP addresses... I'm happy to look at outside addresses, just not the ones on the inside. I would also consider matching up endpoint (VPN gateway or "outside") address and SPI to know which SA a packet is arriving on, for the inbound-through-tunnel direction, and then use the vlan interface name to help select the departing tunnel, if possible. > So no, I don't see how it can be done under your constraints. Well, not perhaps without some nethacks in the kernel. I've certainly done that before, but would prefer something more vanilla. Thanks, -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: SCSI device emulation using SCSI host controller
Yes. sys/cam/scsi/scsi_target* /usr/share/examples/scsi_target On Tue, 13 Aug 2002, Semen A. Ustimenko wrote: > Hi! > > I beg you all pardon for a question not related directly to FreeBSD, but > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > The question is: "Can I emulate a SCSI device (tape, if that matters) > using usual SCSI host controller and specific software, or I will > definitely need specific hardware?" > > Thanks! > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI device emulation using SCSI host controller
On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > Hi! > > I beg you all pardon for a question not related directly to FreeBSD, but > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > The question is: "Can I emulate a SCSI device (tape, if that matters) > using usual SCSI host controller and specific software, or I will > definitely need specific hardware?" You'll need either the right Adaptec or QLogic controller, but yes, it can be done with FreeBSD. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SysV IPC related question
Hi all.
I was wondering why we have a struct mymsg in , when many
utilities defined their own version of it. I am curious about this
because our stock version of struct mymsg:
struct mymsg {
long mtype; /* message type */
char mtext[1];/* message body */
};
Why do we have a value of [1] in the mtext array? Are we meant to
define a struct mymsg at all!?
Thanks.
Regards.
--
Hiten Pandya
http://www.unixdaemons.com/~hiten
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
On Tue, 13 Aug 2002, Les Biffle wrote: > Hi, > > I want to do the following: > > 1. Create "n" IPSEC VPN tunnels > 2. Create "n" VLAN pseudo interfaces > 3. Route IP Packets based on their arrival iface/tunnel out through > a corresponding tunnel/iface. > > For example, I want to route all packets received through VPN tunnel "2" > out through VLAN "2," and all packets received on VLAN "2" out through > VPN "2," without regard to source or destination IP Addresses. incoming packets should be selectabl in ipfw by using the clause "in recv gif0" or "in recv vlan0" then you should be able to redirec thtem using the 'fwd' command assuming gif0 has a remote end (of the tunnel) at 1.1.1.1 and a packet arrived on vlan0, and the machine you want to forward to on vlan0 is 2.2.2.2 the following ipfw commands should work (not tested).. fwd 1.1.1.1 ip from any to any in recv vlan0 the reverse packets should be redirected by: fwd 2.2.2.2 ip from any to any in recv gif0 As I say, this has not been tested.. let uis know what happens so that others can do this if it works > > I don't want to examine the IP Addresses of any of the routed packets, > but only want to make the routing decision based on arrival interface. > > Does anyone have any ideas or suggestions? Please? > > -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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Julian Elischer wrote: > On Tue, 13 Aug 2002, Les Biffle wrote: >>I want to do the following: >> >>1. Create "n" IPSEC VPN tunnels >>2. Create "n" VLAN pseudo interfaces >>3. Route IP Packets based on their arrival iface/tunnel out through >>a corresponding tunnel/iface. >> >>For example, I want to route all packets received through VPN tunnel "2" >>out through VLAN "2," and all packets received on VLAN "2" out through >>VPN "2," without regard to source or destination IP Addresses. > > incoming packets should be selectabl in ipfw by using the > clause > "in recv gif0" Minor point: IPsec tunnel mode tunnels aren't gif tunnels - he'd need to use IPIP tunnels + IPsec transport mode in that case (see draft-touch-ipsec-vpn04.txt), which I recommend anyway, of course :-) I hadn't thought of using the ipfw "in" selector, good idea! Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Routing table: removing an invalid entry
On Mon, 12 Aug 2002, Len Conrad wrote: > Sorry, I can't find anything in the archives, and two submissions to > -questions got nothing. > > how to remove a route when the destination is totally fubar? [...] > # route delete "64\&0x7f01" > route: bad address: 64\&0x7f01 You mean the ones with bogus netmasks? Give the netmask in the 'route delete' arguments. route delete 64 netmask 0x7f01 That might work :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Les Biffle wrote: > > You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, > > but then you say you don't want to look at IP addresses... > > I'm happy to look at outside addresses, just not the ones on the inside. > I would also consider matching up endpoint (VPN gateway or "outside") > address and SPI to know which SA a packet is arriving on, for the > inbound-through-tunnel direction, and then use the vlan interface name > to help select the departing tunnel, if possible. > > > So no, I don't see how it can be done under your constraints. > > Well, not perhaps without some nethacks in the kernel. I've certainly > done that before, but would prefer something more vanilla. One short answer is to not set a default route, per se. I know this is ugly, but it fixes the IPSec tunnel problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SysV IPC related question
Hiten Pandya wrote:
> I was wondering why we have a struct mymsg in , when many
> utilities defined their own version of it. I am curious about this
> because our stock version of struct mymsg:
>
> struct mymsg {
> long mtype; /* message type */
> char mtext[1];/* message body */
> };
>
> Why do we have a value of [1] in the mtext array? Are we meant to
> define a struct mymsg at all!?
This is the message contents. It is an overlay structure. The
[1] is the same thing that, in the current ANSI C standard, you
would define in terms of [0].
The point is that you have a structure that sonsists of a long
followed by an indeterminate number of bytes. You cast the
combination to a pointer to a structure of this type, and you
can reference the long as mymsgp->mtype, and the contents as
mymsgp->mtype.
Please leave it alone. 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Terry Lambert wrote: > Les Biffle wrote: > >>>You could use the draft-touch-ipsec-vpn-04.txt together with ipfw rules, >>>but then you say you don't want to look at IP addresses... >> >>I'm happy to look at outside addresses, just not the ones on the inside. >>I would also consider matching up endpoint (VPN gateway or "outside") >>address and SPI to know which SA a packet is arriving on, for the >>inbound-through-tunnel direction, and then use the vlan interface name >>to help select the departing tunnel, if possible. >> >> >>>So no, I don't see how it can be done under your constraints. >> >>Well, not perhaps without some nethacks in the kernel. I've certainly >>done that before, but would prefer something more vanilla. > > > > One short answer is to not set a default route, per se. > > I know this is ugly, but it fixes the IPSec tunnel problem. I don't think we have the same definition of "the IPSec tunnel problem." Mine is "tunnel mode SAs aren't interfaces, and IPsec duplicates encapsulation and firewalling techniques that are (better) handled outside IPsec", see draft-touch-ipsec-vpn. Having or not having a default route won't matter, since you'll have more specific routes that match before the default route would be picked. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: SysV IPC related question
--- Terry Lambert <[EMAIL PROTECTED]> wrote:
> Hiten Pandya wrote:
> > I was wondering why we have a struct mymsg in , when many
> > utilities defined their own version of it. I am curious about this
> > because our stock version of struct mymsg:
> >
> > struct mymsg {
> > long mtype; /* message type */
> > char mtext[1];/* message body */
> > };
> >
> > Why do we have a value of [1] in the mtext array? Are we meant to
> > define a struct mymsg at all!?
>
> This is the message contents. It is an overlay structure. The
> [1] is the same thing that, in the current ANSI C standard, you
> would define in terms of [0].
>
> The point is that you have a structure that sonsists of a long
> followed by an indeterminate number of bytes. You cast the
> combination to a pointer to a structure of this type, and you
> can reference the long as mymsgp->mtype, and the contents as
> mymsgp->mtype.
>
> Please leave it alone. 8-).
OK. One more question; so, is there any particular reason why our cousin
NetBSD doesnt use this "overlay" structure? Also, the NetBSD SysV Msg
regression tool defines its own struct mymsg; and doesnt have one standard
in the header file.
Also, if possible, could you outline some situations where this would be
used? Help will be very appreicated.
Thanks.
-- Hiten
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Terry Lambert wrote: > Lars Eggert wrote: > >>I don't think we have the same definition of "the IPSec tunnel problem." >>Mine is "tunnel mode SAs aren't interfaces, and IPsec duplicates >>encapsulation and firewalling techniques that are (better) handled >>outside IPsec", see draft-touch-ipsec-vpn. >> >>Having or not having a default route won't matter, since you'll have >>more specific routes that match before the default route would be picked. > > > As you say, SA's are not interfaces. Try pinging over the link > from hosts on either side of the tunnel, e.g.: > > 10.0.1.15/8<--->10.0.1.1/810.0.2.1/8<>10.0.2.11/8 > public IP #1<--->public IP #2 > > Ping #1<> works > Ping #2<--->broken > > Get rid of the default route, and ping #2 starts working. That looks like a routing issue on the tunnel endpoint that's independent from IPsec - what's in the routing table? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: SysV IPC related question
Hiten Pandya wrote:
> OK. One more question; so, is there any particular reason why our cousin
> NetBSD doesnt use this "overlay" structure? Also, the NetBSD SysV Msg
> regression tool defines its own struct mymsg; and doesnt have one standard
> in the header file.
I don't know why NetBSD doesn't have this. Perhaps they are
unconcerned with the portability of code using SYSV message
queues, when it comes to internal structure packing.
I would think directly casting it to a long in the kernel would
be a bad thing on Alpha, with certain source code in user space.
I expect that they define it for the regression test so that
they can actually do regression on these cases.
> Also, if possible, could you outline some situations where this would be
> used? Help will be very appreicated.
It's because if you don't ask for a specific meswsage type (e.g.
it is important for you to get messages in the order they were
sent), then you can't control which message will be returned in
your message buffer passed to msgrcv(2).
Example:
--
struct mymsg {
longmtype;
charmtest[1];
};
#define MTYPE_A 75
struct msg_a {
longmtype;
int id;
charname[ 8];
};
#define MTYPE_B 76
struct msg_b {
longmtype;
charmsg[ 16];
struct stat data;
};
typedef union {
struct mymsgmymsg;
struct msg_aa;
struct mdg_bb;
} msg_t;
msg_t msg;
/* p3 = 0 :== receive any message */
if ( msgrcv(msqid, &msg, sizeof(msg), 0, 0) == -1) {
perror("msgsnd");
exit( 3);
}
switch( msg.mymsg.mtype) {
case MTYPE_A:
printf( "name=%s, id = %d\n",
msg.a.name,
msg.a.id);
break;
case MTYPE_B:
printf( "Result '%s', size= %d\n",
msg.b.msg,
msg.b.data.st_size);
break;
default:
printf "Unrecognized message type: %d\n",
msg.mymsg.mtype);
break;
}
--
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Lars Eggert wrote: > Terry Lambert wrote: > > As you say, SA's are not interfaces. Try pinging over the link > > from hosts on either side of the tunnel, e.g.: > > > > 10.0.1.15/8<--->10.0.1.1/810.0.2.1/8<>10.0.2.11/8 > > public IP #1<--->public IP #2 > > > > Ping #1<--> works > > Ping #2<->broken > > > > Get rid of the default route, and ping #2 starts working. > > That looks like a routing issue on the tunnel endpoint that's > independent from IPsec - what's in the routing table? Now? Not a default route, that's for sure... 8-) 8-) ;^). I traced the problem down to the cloning of routes, and given the opacity of the code, and the fact I had a workaround avaiable, didn't bother chasing it further. The response packets got *back* to 10.0.1.1, but 10.0.1.1 did not forward them on the local net to 10.0.1.15, but pushed them out the default interface instead. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP routing question
Lars Eggert wrote: > I don't think we have the same definition of "the IPSec tunnel problem." > Mine is "tunnel mode SAs aren't interfaces, and IPsec duplicates > encapsulation and firewalling techniques that are (better) handled > outside IPsec", see draft-touch-ipsec-vpn. > > Having or not having a default route won't matter, since you'll have > more specific routes that match before the default route would be picked. As you say, SA's are not interfaces. Try pinging over the link from hosts on either side of the tunnel, e.g.: 10.0.1.15/8<--->10.0.1.1/8 10.0.2.1/8<>10.0.2.11/8 public IP #1<--->public IP #2 Ping #1<> works Ping #2<--->broken Get rid of the default route, and ping #2 starts working. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Port for Sun Grdiware 5.3
--- Alp ATICI <[EMAIL PROTECTED]> wrote: > Is there any port of Sun Gridware 5.3 for FreeBSD? I know that "Ron Chen" and several other people worked on the port. They have it working but not sure about whether the source was checked in or not. You can search for "freebsd" in the archive: http://gridengine.sunsource.net/servlets/SearchList > I found the source code is open and there're binaries for several > arch/OS's there but couldn't see any FreeBSD port. Also, I've heard they were looking for people to be the maintainer, anyone?? > > http://gridengine.sunsource.net > > Let me know if you have any information about that. > Thanks, > > Alp > Rayson __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Port for Sun Gridware 5.3
I made a search at the site you mentioned before but got nothing relevant. Does anyone have the link to the port? Do you know how it performs in general? Efficient? not? Thanks, Alp On Tue, 13 Aug 2002, Rayson Ho wrote: > I know that "Ron Chen" and several other people worked on the port. > They have it working but not sure about whether the source was checked > in or not. > > You can search for "freebsd" in the archive: > http://gridengine.sunsource.net/servlets/SearchList > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI device emulation using SCSI host controller
"Kenneth D. Merry" wrote: > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > Hi! > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > using usual SCSI host controller and specific software, or I will > > definitely need specific hardware?" > > You'll need either the right Adaptec or QLogic controller, but yes, it can > be done with FreeBSD. Or Symbios (now LSI Logic). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI device emulation using SCSI host controller
On Tue, Aug 13, 2002 at 21:12:59 -0400, Sergey Babkin wrote: > "Kenneth D. Merry" wrote: > > > > On Tue, Aug 13, 2002 at 23:41:14 +0700, Semen A. Ustimenko wrote: > > > Hi! > > > > > > I beg you all pardon for a question not related directly to FreeBSD, but > > > if the answer is ``yes'', then I believe FreeBSD will be in deal. > > > > > > The question is: "Can I emulate a SCSI device (tape, if that matters) > > > using usual SCSI host controller and specific software, or I will > > > definitely need specific hardware?" > > > > You'll need either the right Adaptec or QLogic controller, but yes, it can > > be done with FreeBSD. > > Or Symbios (now LSI Logic). Has anyone done any target mode code for their boards? I know they're probably capable of it, but AFAIK, the sym(4) driver doesn't support target mode and I didn't see anything in the mpt(4) commit that indicated that it supports target mode either. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP monitoring
Greetings, I'm interested in developing a fairly proprietary IP monitoring solution (I want to look for specific trends in specific packets.) Will there be considerable gains from writing some sort of kernel module, vs. a userspace solution? I've never hacked the kernel or written any sort of kernel module before, but I'm eager to do so. What is the most low level API for this sort of thing, to avoid API overhead, if I should do it in user space? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP monitoring
Also, forgot to mention, I will need to look inside TCP streams, and know which user owns them, and which packets pertain to which TCP stream, which is why I was thinking a module would be more suitable. If I did this in user space, I'd have to reconstruct the streams myself (but as I understand, that isn't amazingly difficult.) sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Port for Sun Gridware 5.3
"Ron Chen" posted the patch: http://gridengine.sunsource.net/servlets/ReadMsg?msgId=4171&listName=dev But the best place to ask is the SGE mailing list. Rayson --- Alp ATICI <[EMAIL PROTECTED]> wrote: > I made a search at the site you mentioned before but got > nothing relevant. > > Does anyone have the link to the port? > Do you know how it performs in general? Efficient? not? > > Thanks, > Alp > > On Tue, 13 Aug 2002, Rayson Ho wrote: > > I know that "Ron Chen" and several other people worked on the port. > > They have it working but not sure about whether the source was > checked > > in or not. > > > > You can search for "freebsd" in the archive: > > http://gridengine.sunsource.net/servlets/SearchList > > > __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP monitoring
On Tue, 13 Aug 2002, Sean Hamilton wrote: > Also, forgot to mention, I will need to look inside TCP streams, and know > which user owns them, and which packets pertain to which TCP stream, which > is why I was thinking a module would be more suitable. If I did this in user > space, I'd have to reconstruct the streams myself (but as I understand, that > isn't amazingly difficult.) If you do it in user space it's a lot easier to debug. It can be done, of course, in both places, but general IO is easy in userspace too (for user interaction, if you need it). You can also make such a thing portable in user space, which is hard to do in the kernel. The downside is, there's copies of the data to consider (more work to be done means less time to do it in), so you might have too much traffic under some conditions, depending on what you're doing. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP monitoring
On Tue, 13 Aug 2002, Sean Hamilton wrote: > Also, forgot to mention, I will need to look inside TCP streams, and know > which user owns them, and which packets pertain to which TCP stream, which > is why I was thinking a module would be more suitable. If I did this in user > space, I'd have to reconstruct the streams myself (but as I understand, that > isn't amazingly difficult.) > > sh pcap(3) does fast usermode packet capture via BPF ports/net/libnids does TCP stream reassembly Running things in the kernel does not automatically make them fast unless your CPU usage is maxed by boundary crossings. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
