[Sis-SCPS-INTEREST] Latest Version of the SCPS RI

[Marcin Jessa]

Hi Pat.

Could you please send me the latest release?
I have also managed to port SCPS to both FreeBSD and NetBSD 
and run it with tun and tap devices.
Both FreeBSD and NetBSD(from 3.0) have tap and tun in the base system 
so it was a child play to make both work after I patched the SCPS sources.
No need for 3.rd party patches like it's necessarly dealing with Linux :)
I can send you all my patches if you are interested.
Would be great to have them included in the official source.
To be honest it really surprises me BSD's are so forgotten 
being older and more mature compared to Linux...

Cheers,
Marcin.


On Fri, 23 Sep 2005 12:53:42 -0400
"Feighery, Patrick D." <feighery at mitre.org> wrote:

> For those of you that have a copy of the SCPS RI, please read on.
> 
> During the last couple of days, we have found and corrected a bug in
> the SCPS RI gateway which you should be aware of.  Under certain
> conditions it will stop traffic from traversing the gateway.
> 
> Here is a quick synopsis
> 
> The problem only occurs when you are running the gateway under linux
> via the TAP interface and you configure the gateway to not pass non-IP
> based traffic (e.g., IPX, appletalk, etc.)  In our case the problem
> reared its head when the gateway received CISCO's Cisco Discovery
> Protocol (CDP) which operates directly over ethernet. If the gateway
> receives a packet/frame that is not IP based and the gateway is
> configured to not pass it we simply drop it on the floor.  So far so
> good.  Unfortunately we do not free up the memory by placing it back in
> the memory pool.  Bad programmer.  In our case we see a CDP packet
> every 30 seconds or so.  So after about 8 hours or so we have no more
> buffers to receive the packets.  Thus the packets will starting filling
> up the receive queue for the tap interface. After the tap interface is
> full, the ethernet frames can no longer be bridged.  A simple two line
> fix corrects this problem.  For those of you that may be unaware, the
> gateway does have the ability to either allow or deny non-IP based
> traffic from traversing the RF side and thus consuming its resources.
>  
> The newest release of the SCPS RI is version 1.1.119.
> 
> Besides the change listed above, following are some even shorter
> synopses of some changes from the 1.1.113 release - which we have been
> sending out for about a year now.
> 
>   o  Updated some of the existing documentation which was pointed
>      out by some of you to be well.. Antiquated to put it nicely.
> 
>   o  Added some additional documents
> 	o  The SCPS gateway user's guide - which I have been including
> 	   in recent requests.
>       o  A Frequently Asked Questions (FAQ) about the SCPS gateway.
>          If there are additional questions/answers please send them
>          to me and I will include them in future versions of this
>          document.
>       o  Some of you have brought up performance issues with SCPS
>          and Microsoft's file sharing.  This mini-white paper
> 	   discusses the interaction issues with Microsoft's
>          Server Message Block (SMB) protocol used to implement
> 	   their File Sharing over the net, how it performs over
>          large bandwidth*delay paths, and its interaction with SCPS. 
> 
>   O  Fixed some compilation issues with newer versions of gcc.
>      Unfortunately, I am an old K&R C programmer and well.. ensuring
>      correct typing of variables has never been a strong point.
>      Thanks to those who have pointed this out and sent in diffs.
> 
>   O  Fixed minor rate control bug when emitting non TCP based IP
>      traffic.
> 
>   O  Corrected some bookkeeping issues concerning lower level buffer
>      utilization and added some stats which can be log to
>      /var/log/messages. This is how I tracked down the bug mentioned
>      in the first part of the e-mail.
>  
>   O  Changed the default behavior to keep the transport layer source
>      port constant as the gateway creates the two peer transport
>      layer connections.  I originally kept the transport layer source
>      ports different to assist in the debugging of various things.
>      However it was brought to my attention that some testing tools
>      assume the source port received by the test sink apps must be
>      the same as the source port sent the test source app.  To
>      revert to the previous behaving you need to
>      #define CHANGE_SRC_PORT.  This may be significant to some...
> 
> If you already have a copy of the SCPS RI, send me an e-mail and I will
> be happy to reply with the latest release.
> 
> Best Regards
> 
> 	Pat
> 
> _______________________________________________
> Sis-SCPS-INTEREST mailing list
> Sis-SCPS-INTEREST at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest
>