Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!odin!hwajin From: hwajin@daahoud.wpd.sgi.com (Hwa-jin Bae) Newsgroups: comp.realtime Subject: Re: VxWorks ethernet output Message-ID: Date: 25 Mar 91 14:26:15 GMT References: <7152@munnari.oz.au> Sender: news@odin.corp.sgi.com (Net News) Organization: Protocol Engines Inc., Mountain View, CA Lines: 46 In-Reply-To: summer@brahma.trl.oz.au's message of 25 Mar 91 05:13:51 GMT >>>>> On 25 Mar 91 05:13:51 GMT, summer@brahma.trl.oz.au (Mark Summerfield - Switching) said: Mark> I have an annoying problem with VxWorks' etherOutput() function Mark> (VxWorks running on a Motorola MVME-147S CPU board). As part Mark> of a LAN bridging system, I need to transmit packets with arbitrary Mark> source addresses. If I use etherOutput() to do this, the interface's Mark> output routine (I assume) replaces the contents of the source address Mark> field with the address of the CPU board that VxWorks is running on. etherOutput() routine assumes that you're passing a complete etherent frame, with ethernet header all intact. Whatever is in the header already as part of the frame with be sent as is. It does no alteration of ethernet source address in the header based on your CPU board address. Mark> I have a workaround, which involves adding an output hook routine Mark> (with etherOutputHookAdd()) which inserts the desired source address Mark> (it seems that the hook routine is called after the replacement, directly Mark> before the packet is transmitted). This wastes time, space (admittedly Mark> not much) and requires a really shabby trick of storing a pointer Mark> in the destination address field so that the correct packet header can Mark> be found by the hook routine. etherOutputHookAdd() has really nothing to do with the header source address field at all. etherOutputHookAdd() routine can be used to add a "hook" routine of your own that can be called whenever an ethernet frame is sent out on the network. That is, the interface driver will forward a copy of an ethernet frame you're trying to send to your "hook" routine right before it is actually sent out. Depending on the return value of your "hook" routine the driver may or may not send the frame out. This facility is useful primarily for debugging, statistics gathering, and output filtering. Mark> In short, I don't like it, and hope that there's a better way! The Mark> situation is possibly complicated by the fact that I want the VxWorks Mark> network interface to continue to function normally as well. Has Mark> anybody successfully tackled this problem before? Mark> Thanks in advance for any help, Good luck. *hwajin -- Hwa Jin Bae hwajin@{pei.com, wrs.com, cdp.igc.org, unisoft.com} Protocol Engines, Inc. Mountain View, CA