home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vxworks / 1176 < prev    next >
Encoding:
Text File  |  1993-01-07  |  2.1 KB  |  54 lines
  1. Newsgroups: comp.os.vxworks
  2. Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!news!cod!healy
  3. From: healy@nosc.mil (Mike Healy)
  4. Subject: Re: Forwarding of MAC broadcasts
  5. Message-ID: <1993Jan7.215612.8985@nosc.mil>
  6. Organization: Naval Ocean Systems Center, San Diego
  7. References: <9301071938.AA09078@kuwait.whizkids>
  8. Date: Thu, 7 Jan 1993 21:56:12 GMT
  9. Lines: 43
  10.  
  11. In article <9301071938.AA09078@kuwait.whizkids> billb%kuwait@sun.com (Bill Baumann) writes:
  12. >VxWorks is causing problems by forwarding broadcast messages.
  13. >
  14. >Here's the deal : I have a development system that is broadcasting over
  15. >FDDI to a specific IP address.  The IP address is a Unix box, and the
  16. >FDDI MAC address is a broadcast.  I'm using the AP Labs driver.
  17. >
  18. >On my analyzer I see the broadcast message being retransmitted by the VxWorks
  19. >based cage.  The messages are UDP/IP, so the Unix machine sees both the
  20. >broadcast, and the retransmitted message.
  21. >
  22. >It appears to me that VxWorks is doing IP forwarding of broadcast messages.
  23. >This is a definate no no.
  24. >
  25. >Does anyone have any experience with this?
  26. >
  27. >Does anyone know how to turn this behavior off?
  28. >
  29. >Thanks BillB.
  30. >
  31.  
  32. I ran into something similar just this morning. We are using UDP/IP
  33. broadcast datagrams for one of our protocols. We have a multiprocessor
  34. system in which each ethernet port is handling a different simulation
  35. protocol (DIS, SIMNET, ...). I found that in the board with the non-
  36. UDP/IP protocol, where my input hook would return any UDP/IP 
  37. broadcast datagrams to the vxWorks's protocol stack, the other board 
  38. was receiving the broadcast datagram twice. I thought the board was 
  39. forwarding the datagram onto the backplane network and that's why the 
  40. other board was getting the datagram twice - the original datagram 
  41. from the ethernet, and then the same datagram forwarded over the 
  42. backplane network. However, this post seems to indicate a more 
  43. pathological situation.
  44.  
  45. My fix was to trap these bad boys in my ethernet hook input and toss 
  46. them, but obviously this is not general purpose and somewhat of a 
  47. kludge. 
  48.  
  49. This sounds like a job for . . . WRS!! :-)
  50.  
  51. Mike Healy
  52.  
  53. healy@nosc.mil
  54.