I've been looking for some technical descriptions on how DirecPC works
from a TCP/IP point of view. Does anyone out there have some
references? I have not been able to find anything too detailed, and
from what I have been told, they are not too forthcoming when
contacted directly.
I know the rough outline. The customer sends out traffic over a normal
PPP link (since the customer has no uplink to the DirecPC satellite)
to a separate ISP. The traffic has a spoofed source address set to
some DirecPC server at their ground site(s). Thus, the third-party
target's response goes to DirecPC who send it over their satellite
link back to the customer using the wide satellite pipe instead of the
narrow PPP pipe.
But I'm curious about the details. First things first, anyone know how
the DirecPC link is established? That is, how the customer tells
DirecPC what his IP address is? I assume this must all happen over the
PPP-link, or at least the two-way PPP-link is used for bootstrapping.
Now once things are going, what kind of predictive ACKing games does
DirecPC play?
The reason I am curious is that I'm trying to figure out what kinds of
things ISPs, or any Internet access provider (say the user is dialing
into a corporate RAS), can do to break or accomodate DirecPC. The
obvious things that come to mind are egress filtering and NAT. In
addition to any technical information that can help me figure this out
for myself, experience others have had with these same problems would
also be helpful.
Thanks a lot for any help.
I'm not sure how many users are on the legacy system still, but
the latest DirecPC service "DIRECWAY" is actually two-way satellite
connectivity without the need for a dial uplink.
-c
Well there are some two way dish solutions for consumers now that don't
need a dial-uplink. I think dishnetwork has such a thing as does direct
tv. Doesn't help much but does help people in remote areas.
If you don't get an answer here, you might want to try the isp-satellites list.
http://isp-lists.isp-planet.com/isp-satellites/
Also, there are a -few- knowledgable folks on alt.satellite.direcpc.
Good luck...I'd be interested in hearing the description myself.
--Michael
Scott,
Just an f.y.i., Charlie Ergan (DishNetwork) said he couldn't see how the business
plan could succeed and pulled out of StarBand. They are currently in Chap. 11.
http://65.186.192.177/liarband/ch11.html
--Michael
Ah didn't know that. Seems like it has some possibilities but I agree I
think it would be hard to make money in the consumer space. Direct-tv is
doing it according to some other posts I read here but again I think
direct-tv's installed base is 3 or 4 times that of dish. To bad they didn't
merge.
This is AFAIK _not_ what DirectPC does, but have you taken a look at
RFC3077 and the UDLR draft
http://www.ietf.org/internet-drafts/draft-ietf-udlr-experiments-00.txt ?
This covers the complications of doing IP over very assymetric links as part of the IP, including
both multicast and TCP issues.
Regards
Marshall Eubanks
Crist J. Clark wrote:
Yeah, this helped. It showed me that their protocol is totally
broken.
They do an GRE- or IPIP-like encapsulation, but then set the protocol
field to that of the encapsulated packet. Or if the encapsulated
packet is not TCP, UDP, or ICMP, they set the outer protocol to TCP.
This will totally break behind NAT when the NATing device changes the
source IP address and then "fixes" the TCP or UDP checksum due to the
pseudo-header change. Either the NATing device drops the packet when
the intial checksum is wrong or it mangles the payload, which isn't
really TCP.
Who designs these things? And what were they smoking when they did?
Crist,
I am a contributor of RFC3077 and we will have a IETF meeting in Atlanta. I will discuss the issue which you wrote below at the UDLR-WG meeting. Now we are preparing a updated draft which support the operation the network employing RFC3077.
Thank you.
Jun Takei
Crist J. Clark wrote: