ng_eiface hangs on 4.6RC
Hello! I updated to 4.6-RC on May 22. Posted to freebsd-stable no response, so cross posting to net. Am testing ng_eiface, new netgraph node added in this release. I find that it is not in sys/conf/[files|options] but the ng_eiface.[ch] are present in netgraph directory and in Release notes. After cvsup'ing, I added the required lines in sys/conf/[files|options] and did buildkernel and installkernel. Also modified sys/modules/netgraph to install ng_eiface.ko However on running the following command the system hangs and I have to hard reboot the PC. Any idea ? (I also made /usr/sbin/ngctl; but I did not do a complete buildworld. Could that be a problem ?) Command causing hang = ngctl mkpeer fxp0: eiface divert ether Thanks! Naga To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Question about Dummynet and Diffserv
On Wed, May 22, 2002 at 05:38:57PM -0700, Crist J. Clark wrote:
>
> No. sbin/ipfw is just the userland command for modifying rules. The
> actual firewall code lives in sys/netinet/ip_fw.{c,h}.
Hi,
I merged from -CURRENT to my -STABLE tree some changes made in October 2000 to
sys/netinet/ip_fw.{c,h} and sbin/ipfw/ipfw.c which add ipfw
filtering based on iptos.
However, from reading the documentation, it seems that only the
older IP TOS precedence values are supported for filtering.
Is it possible to use ipfw to filter based on any Diffserv codepoint value?
This is from the man page:
" iptos spec
Match if the IP header contains the comma separated list
of service types specified in spec. The supported IP
types of service are:
lowdelay (IPTOS_LOWDELAY), throughput (IPTOS_THROUGHPUT),
reliability (IPTOS_RELIABILITY), mincost (IPTOS_MINCOST),
congestion (IPTOS_CE). The absence of a particular type
may be denoted with a `'!.
"
Thanks.
--
Craig RodriguesDistributed Systems and Logistics, Office 6/304
[EMAIL PROTECTED] BBN Technologies, a Verizon company
(617) 873-4725 Cambridge, MA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
RE: UDLR and DVB-S
I have some interest in UDLR, but alas I am no programmer either. UDCast appears to have the first commercially available UDLR implementation, and if I am not mistaken, I believe they have it running on FreeBSD. I also think Emmanuel Duros wrote FreeBSD drivers for a few DVB-S cards while at Inria. I might be able to lend out some DVB-S hardware if someone wants to seriously tackle writing a driver for FreeBSD and commits it to open source... Later, --Lee > -Original Message- > From: Christophe Prevotaux [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 08, 2002 8:10 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: UDLR > > > Hi, > > I have once asked if someone would be interested in implementing UDLR > and DVMRP and include it in FreeBSD ? > > Julian Elischer mentioned it would be fairly trivial to implement as a > node in Netgraph. However I am no programmer. > > I was wondering if no one had interest in UDLR ? I understand > that today's > broadband access do not require these unidirectional links, > but I can't > believe no one needs this, since they are also plenty of > other use for it > apart from the fact it can be used for unidirectional link (one way > internet access (uplink is done thru a modem or a different kind of > internet access link)) > > If someone is interested in develloping this, there is some > code source > available (it is FreeBSD Release 2.2.x. based and has not > been maintained > for a long time). > > Receivers boards > > DVB-S PCI adapter drivers are also needed for devices from > any of these > manufacturers > > http://www.coship.com/English/products/cdvbany2010s.htm > http://www.broadlogic.com > http://www.pentamedia.com > http://www.twinhan.com.tw > > who might be ready to lend or give out hardware in order to help > devellopement of these drivers. > > Uplink boards > = > These boards must be able to: > > - Transmit IP packet over DVB/MPEG 2 transport stream > > - Variable maximum data rate determined by external clock generator, > transparent for reception cards > > - ISA Bus > > As of today I have not found (yet) transmit (uplink) boards > manufacturer > > As for uplink boards the devellopement of such drivers are to > be a problem > since it is very unlikely that anyone as a personal space > segment on a DVB > capable satellite and the necessary hardware > > However if anyone has ideas on how to build a test cheap unit > for uplink > and downlink testing locally , please let me know. > > Also since Bill Fenner is both part of the UDLR IETF BOARD > and member of > the Mbone FreeBSD Team, we have a great source of internal > knowledge in > this protocol etc...(In the event that Bill agrees to help > (of course)) > > http://people.freebsd.org/~fenner/ > > I have contacted the author of the RFC for UDLR Emmanuel > Duros but as of > now it is to no avail since he has not answered my email (it has been > several months) > > Here are some pointers to some available literature and source code: > > What is UDLR (Short introduction) > = > http://www.actconferences.com/sif2002/abstract/udlr.htm > > RFCs , Drafts and Charter > = > http://www.ietf.org/html.charters/udlr-charter.html > > http://www.ietf.org/internet-drafts/draft-ietf-udlr-pppoe-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-udlr-multicast- issues-00.txt http://www.ietf.org/internet-drafts/draft-ietf-udlr-security-00.txt http://www.ietf.org/internet-drafts/draft-ietf-udlr-dvmrp-conf-02.txt http://www.ietf.org/rfc/rfc3077.txt http://www.ietf.org/rfc/rfc1075.txt Source code === http://www-sop.inria.fr/rodeo/personnel/eduros/manu.html -- -- === Christophe PrevotauxEmail: [EMAIL PROTECTED] HEXANET SARLURL: http://www.hexanet.fr/ Z.A.C Les CharmillesTel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 79 08 02 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NFS don't set sopt.sopt_dir sometimes... Maybe sosetopt()should?
At 9:28 PM -0700 5/22/02, Semen A. Ustimenko wrote: >Looks like nfs_socket.c and nfs_syscalls.c lack strings > > sopt.sopt_dir = SOPT_SET; > >when setting TCP_NODELAY and SO_KEEPALIVE. For SO_KEEPALIVE, it doesn't >matter, sosetopt() doesn't examine it, but TCP_NODELAY is actually >ignored. > >Obviously, it's easy to add these lines, but maybe it's better to make >sosetopt() set sopt_dir for callers? This came up with SMB (and NFS) in Darwin. Changing both caller and callee is the robust choice in our case as old loadable kernel module binaries with new kernels will get fixed, and vice-versa. If you have the luxury of not considering out-of-sync kernel loadables then I envy you :) -- Conrad Minshall, [EMAIL PROTECTED], 408 974-2749 Apple Computer, Mac OS X Core Operating Systems To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ip src address in outgoing ipv4 multicast packets
* Rob ([EMAIL PROTECTED]) [020522 20:30]: > I was just wondering why the src address is set to the host group in > outgoing multicast packets on RELENG_4? As far as I can tell, rfc1054 > says that the src address should be set to that of the host, not the > host group (6.2). The behavior exists in 4.5-release also. > > I noticed this because linux seems to reject mc packets with a multicast > source address (which is also incorrect according to section 7.2). > > Looking at the source, it seems trivial to get the correct (?) behavior. > Is there some reason why we shouldn't do this? If anyone cares I just submitted a pr with an attached patch which will fix this problem. What is a good avenue to get this incorporated into the main tree? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38473 -r To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ip src address in outgoing ipv4 multicast packets
In my 4.6-RC system, I do not have problems with RIPv2 and OSPFv2 packets. I tried zebra routing daemon just now and RIP multicast packets with 224.0.0.9 have proper source address of the interface originating them and OSPFv2 HELLO multicast packets with dst 224.0.0.5 have proper src address of the interface originating them. When you say src address is set to host group, what application generates them? What is the src and dest address ? I quickly checked Rich Stevens vol II. Looks like the code has been like this since old days. Is the application setting the src address as mc group intentionally? Regards Naga. - Original Message - From: "Rob" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 8:22 PM Subject: Re: ip src address in outgoing ipv4 multicast packets > * Rob ([EMAIL PROTECTED]) [020522 20:30]: > > I was just wondering why the src address is set to the host group in > > outgoing multicast packets on RELENG_4? As far as I can tell, rfc1054 > > says that the src address should be set to that of the host, not the > > host group (6.2). The behavior exists in 4.5-release also. > > > > I noticed this because linux seems to reject mc packets with a multicast > > source address (which is also incorrect according to section 7.2). > > > > Looking at the source, it seems trivial to get the correct (?) behavior. > > Is there some reason why we shouldn't do this? > > > If anyone cares I just submitted a pr with an attached patch which will > fix this problem. What is a good avenue to get this incorporated into > the main tree? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38473 > > -r > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ng_fwdswitch netgraph node
Hello, I tweaked a little the one2many node to realize some different kind of packet switching node. I needed something that would help me to split over different IDS sensors data coming from span/mirroring session done on the network. At first I tried to glue some bpf nodes but I had no luck since performance was very poor and I had tons of packets lost (p3 866MHz, ~100kpt/s inbound). The fwdswitch node, could be imagined as a 'many2many' node but monodirectional only: packets flow from 'in' hooks to 'out' hooks only. The decision about which 'out' hook to choose to forward a packet is taken going through a forwarding table that associates an IPaddress/netmask to an output hook index. Packets that are not matched or frames that are not IP packets will be forwarded to the 'default' hook. I just finished to fix it, made some documentation so it is still incomplete, requires cleanup and has some bugs in the configuration part, but it is nicely working. Let me know if it can be of any interest. It's downloadable at http://elisa.utopianet.net/~rlucia/devel/ng_fwdswitch/ It will compile on 4-STABLE. Ciao :) Rocco -- Rocco Lucia - [EMAIL PROTECTED] Iscanet Internet Services http://elisa.utopianet.net/~rluciaSystem and Network Admin C6E6 AC9A 1361 FB38 B47A 2792 9FC4 C52F 7A68 4468 Free unices for a free world. Support *BSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
