mark@alias.UUCP (Mark Andrews) (10/26/89)
Recently, I have seen references to an ethernet filter for BSD systems written at Stanford: On 4.3 BSD systems, these functions are implemented using the Stanford enetfilter device driver in the user-contributed software. Is this filter available anywhere. I don't have easy access to the internet, so if it is not too big, I would appreciate it if someone could mail it to me. Thanks, Mark ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research, Toronto, Canada Phone: (416)-362-9181 UUCP: mark%alias@csri.utoronto.ca
cdash@boulder.Colorado.EDU (Charles Shub) (10/28/89)
In article <561@alias.UUCP> mark@alias.UUCP (Mark Andrews) writes: >Recently, I have seen references to an ethernet filter for BSD systems >written at Stanford: > > On 4.3 BSD systems, these functions are implemented using > the Stanford enetfilter device driver in the user-contributed > software. > >Is this filter available anywhere. I don't have easy access to the internet, so >if it is not too big, I would appreciate it if someone could mail it to me. we attempted to add this, and had some problems because there were some changes in 4.3 that weren't made to the filter code. As i recall, there was a problem with MCLGET having been redefined. We put together a fix that works most of the time. has anybody REALLY made the fix. we are runing Mt. Xinu 4.3+NFS and doing a strings on vmunix reveals 4.3 BSD UNIX #0: Wed Aug 31 14:48:24 MDT 1988 charlie shub cdash@boulder.Colorado.EDU -or- ..!{ncar|nbires}!boulder!cdash or even cdash@colospgs (BITNET) -or- (719) 593-3492 charlie shub cdash@boulder.Colorado.EDU -or- ..!{ncar|nbires}!boulder!cdash or even cdash@colospgs (BITNET) -or- (719) 593-3492
bart@videovax.tv.tek.com (Bart Massey) (10/30/89)
In article <13253@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: > we attempted to add this, and had some problems because there were some > changes in 4.3 that weren't made to the filter code. As i recall, there was > a problem with MCLGET having been redefined.... Actually, if you're concerned about the correctness of that section of the code, you can always just def it out -- it's "just" an efficiency win, which tries to use mbuf page clusters instead of plain old mbufs, to avoid user-space copies. Here's the code I'm using with 4.3 "Tahoe". Note that MCLGET used to always be called with "MCLGET(m,1)", and is now called with just "MCLGET(m)" -- *yet the semantics of MCLGET() changed in a major way at the same time the superfluous extra argument was eliminated*, confusing me, at least, for some time. IMHO this was a semantic botch -- the new MCLGET() should have a different name. Anyway, have fun -- of course this is kernel code, and neither I nor Tektronix will be responsible if it causes the erasure of all your disks and tapes... :-) Bart Massey Tektronix, Inc. TV Systems Engineering M.S. 58-639 P.O. Box 500 Beaverton, OR 97077 (503) 627-5320 ..tektronix!videovax.tv.tek.com!bart ---around line 559 in /sys/net/enet.c--- ... if (m == NULL) panic( "enwmove: out of mbufs" ); #if 1 /* * this is how I'm doing it for 4.3 tahoe */ /* big enough to use a page */ if (iov->iov_len >= MCLBYTES && enPageClusters) { enprintf(ENDBG_TEMP)("enwmove: using page cluster\n"); MCLGET(m); len = m->m_len; } else { len = MIN(MLEN, iov->iov_len); m->m_len = len; } error = uiomove(mtod(m, caddr_t), len, UIO_WRITE, uio); #else /* * this is how it was done before 4.3 tahoe */ if (iov->iov_len >= CLBYTES) { /* big enough to use a page */ register struct mbuf *p; MCLGET(p, 1); if (p == 0) goto nopages; m->m_off = (int)p - (int)m; len = CLBYTES; } else { nopages: len = MIN(MLEN, iov->iov_len); } error = uiomove(mtod(m, caddr_t), len, UIO_WRITE, uio); m->m_len = len; #endif *mp = m; mp = &(m->m_next); ...