James Rice wrote:
I work for a medical software company. The software we
sell and support
replaces the TCP/IP transport layer with a proprietary layer that uses
a random, non-standard length, encrypted UDP packet. It's non-routable
but works fine in a local environment. Bad software design I know, but
I didn't write it, I just have to support it. It works really good
except when a Linksys switch or router is involved.
I hate to be a pest, but the phrase "a random, non-standard length,
encrypted UDP packet" doesn't make sense to me.
You can't have a "non-standard length" UDP packet. If it's a UDP
packet
when it's got a length. And if it's a UDP packet inside a valid IP
packet it can't be "non routeable". And I can't envision a way to
create a UDP/IP packet that would in any way have a problem with a hub.
Now, if in fact you're using the mac layer in some non-standard way, or
creating invalid IP or UDP packets then ok. But if they the
encapsulation is valid and the IP and UDP headers are valid there's
virtually no way you could be effected by the hub. (the one exception
might be dropped packets - which your protocol might be sensative to)
Ninety percent of
my customer's network performance problems go away when I pull the
Linksys gear and replace it with Netgear, D-Link, 3Com, AOpen or generic
no-name crap.
I suspect you've got ethernet chip/phy issues, not network layer issues.
I've done a lot of work with 10/100/1000 phy's and it's never been the
contents of the packets which caused a problem. I've seen a lot of
negotiation problems, flow control problems and pci bus interaction
problems but it was never due to packet content.
me, i'm allergic to voodoo. best to find the real cause and fix it.
-brad