Also Sprach Florian Lindauer >>Sorta...the L2TP version 2 protocol is defined to only carry PPP >>frames as its payload...so carrying anything other than PPP would >>be...uhm..."odd." That being said...if the upper layer >>protocol/serial connection, were to look enough like PPP, then most >>L2TP implementations, including l2tpd, could conceivably carry that >>data. It would be a matter of making your data stream look enough >>like PPP that L2TP implementations wouldn't know the difference. Odd, >>and non-standard at best.
>It is no option to "design" the protocol to "look like" ppp in any way >- we really would need a fully transparent connection to do any data >exchange (call it protocol or not) that a given device on the other end >(not designed by us) may possibly want to perform over the pure modem >link. Yeah, that's not gonna happen with L2TP. >Just wondering: if the l2tp-level only looks if the data stream "looks >like" ppp, but not really does some active data manipulation (?), what >is this restriction good for at all? Well...there are a couple of things that L2TP does with the PPP frames. First, you'll note that it deals with PPP frames, so it looks for the PPP frame delimiters, or some other similar mechanism, to know where each PPP frame begins and ends, so it knows what to package up in a packet and send on to the other endpoint. Second, L2TP will, potentially, at least, look into the PPP frame and convert to or from a "bit-stuffed" frame...ie, a frame that has certain characters escaped in order to avoid sending any modem control characters over the line. This is another way that the L2TP tunnel is not really fully transparent to the upper protocols. >>Probably the best way to carry serial data streams in the way that you >>are proposing would be to just use a basic TCP connection. I don't >>know of any need for anything as complex as L2TP to do what you're >>asking. >Hm, we need the DOP to perform the dial out to the devices. And the >DOP is addressed via l2tp by our system. Perhaps I should ask if there >is another way to use it alternatively and get a raw modem connection >switched through, but I doubt it, and then why would I need l2tpd at >all, being able to run the pppd on such a connection? OK...so you're wanting to use L2TP because it has the ability to signal the DOP to dial, and what number to dial, and such...while TCP doesn't have that ability (at least, not within the confines of TCP itself)...fair enough. I think you're going to have more luck using a TCP connection to the DOP and find another way to signal the phone number dialing, than with trying to get L2TP to transparently carry your data. >And in our case it would be the l2tp-implementation on the DOP (which >has some problems anyways..). That doesn't sound good. :) >Again the same kind of question: why does l2tp need to know the type of >payload, what does it do with the data, is l2tp (at least the >implementation in a DOP) some kind of a "PPP-Proxy", i.e. the >communication of the two pppd is not necessarily put through >1:1/unchanged? As I mentioned, it can do some changes to the PPP frames that its handed...which is really a layering violation, but there are reasons that it was so designed, so you can't just treat it as a transparent data stream unfortunately. The L2TP end systems would need to know what the payload is just as a general principle. Any protocol layer will carry, in some manner, the nature of the next higher layer (if there is one), for example, IP headers have a protocol field that tell the IP implementation whether the payload is a TCP, UDP, or some other protocol, packet. TCP headers have port numbers to indicate to the TCP implementation which process is responsible for dealing with that packet (usually corresponding to an upper layer protocol, but not always). Its just a general principle, that if you're going to mux different protocols over a single communications channel, then the transport mechanism has to have some sort of signaling mechanism to let the other end-point know which protocol is being carried by that specific packet. It may be that a communications channel can carry either PPP or a transparent data stream (hypothetical here), and that the signalling information is statically configured into each end-point rather than actually having a field in the header of the transport protocol to indicate it. You could conceivably do this with L2TP, but that would require configuring your DOP to match, and it doesn't sound like you can do that. >OK, I see you might want to tell me to read a good book on l2tp - but >you can practise here for writing you own :) Thanks for your help! Actually...I think it might be more productive for you to go read the manuals for this DOP, so you can be aware of *its* capabilities...once you know what its capable of, then you can come up with software on a server system to handle it for the most part. Besides...there are quite a few people *much* more competent to write a book on L2TP, PPP, and other protocol issues that we're dealing with...at least a couple of them are on this list! :) (Feel free to speak up folks...you might be able to explain some of this stuff in a way that I'm not coming up with that he can understand better ;) -- Jeff McAdams Email: [EMAIL PROTECTED] Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
msg00063/pgp00000.pgp
Description: PGP signature
