summaryrefslogtreecommitdiffstats
path: root/c/src/exec/libnetworking/net (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Added port of ppp-2.3.5 from Tomasz Domin <dot@comarch.pl> of ComArch SA.Joel Sherrill1999-11-301-0/+183
| | | | | | | | | | Tomasz only tested this on the mpc823. The official site for the original source for this PPP implementation is: ftp://cs.anu.edu.au/pub/software/ppp NOTE: As of 11/30/1999, the current version of this source is 2.3.10.
* Added debug printf()'s that are commented out. Uncommenting theseJoel Sherrill1999-02-041-0/+3
| | | | | | allows one to trace the enqueueing and dequeueing of messages. This can be used to insure that packets are getting to the boundary between the network stack and the device driver.
* Patch from D. V. Henkel-Wallace <gumby@zembu.com> to make macro nest ↵Joel Sherrill1999-01-041-3/+5
| | | | properly in conditionals
* Patch from Ian Lance Taylor <ian@airs.com>:Joel Sherrill1998-12-103-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From: Eric Norum <eric@skatter.usask.ca> Date: Sat, 5 Dec 98 13:20:51 -0600 What do you think of this patch? It implements your `tap' suggestion in a way that adds support for all ethernet devices with no driver modifications. I also added a return value from the tap function. If the return value is zero, the packet will be passed up the chain as usual. If the return value is non-zero the mbuf holding the packet will be freed and the packet will be dropped. If you like it, please submit it to Joel. I guess there needs to be an addition to the network documentation describing the additional ioctl's -- and a big warning that the tap function is called from a context that holds the network semaphore. Here is Eric's patch. I've tested it a bit, and made a couple of trivial changes. This is certainly better than mine: it should work for all Ethernet drivers. ================================================== The only concern I have about this patch is that the tap function may want to fiddle with the mbuf, calling functions like m_pullup and the like. If those force the networking code to rearrange the mbuf structure, then the caller's call to m_freem may crash. I don't know if this is a realistic concern--I don't know enough about the mbuf layer.
* Fixed many warnings.Joel Sherrill1998-08-203-7/+14
|
* Base filesJoel Sherrill1998-08-1919-0/+7147