PPP with PPPD over GSM link - PPP

This is a discussion on PPP with PPPD over GSM link - PPP ; Hi, excuse my poor English, Iīm developing C++ aplication and I want to use PPP protocol over a GSM comunication line. I have an API with send and receive functions for the GSM comunication. I want to use a library ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: PPP with PPPD over GSM link

  1. PPP with PPPD over GSM link

    Hi,

    excuse my poor English,

    Iīm developing C++ aplication and I want to use PPP protocol over a
    GSM comunication line. I have an API with send and receive functions
    for the GSM comunication.

    I want to use a library for encapsulating data to send, and then send
    to GSM, but I donīt find any library for this purpose, so I need to
    use the ppp daemon.

    I search in the pppd man, and I see the pty with the record option and
    then use the pppdump for view the file.

    But I get lost when I try to implementate some solution.
    How can I send data to the pppd and take the ppp-packed-data into a
    file to send via API function? And How can I put the API receive data
    (suposed to be ppp-packed-data) to the ppplink and take the unpacked
    data?

    Thanks.


  2. Re: PPP with PPPD over GSM link

    jombocito@gmail.com writes:
    > Iīm developing C++ aplication and I want to use PPP protocol over a
    > GSM comunication line. I have an API with send and receive functions
    > for the GSM comunication.


    Ouch.

    > But I get lost when I try to implementate some solution.
    > How can I send data to the pppd and take the ppp-packed-data into a
    > file to send via API function? And How can I put the API receive data
    > (suposed to be ppp-packed-data) to the ppplink and take the unpacked
    > data?


    You have at least two choices, assuming you're planning to stick with
    the architecture outlined above. Pick one:

    - Use the pppd 'pty' option, and specify your program as the
    "script" to run. Pppd will exec your program and send you
    AHDLC-encoded PPP data on your stdin, and will expect PPP from you
    on stdout.

    - Allocate a pty pair inside your program. Open the slave side, and
    fork and exec pppd with the slave side open on stdin. pppd will
    run PPP on the pseudo terminal, and the data will appear on the
    master side.

    I don't normally use C++, so you're on your own there.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: PPP with PPPD over GSM link

    First of all, thanks for your sugestions.

    I have a question about data flow in this solution:
    James Carlson wrote:
    > - Use the pppd 'pty' option, and specify your program as the
    > "script" to run. Pppd will exec your program and send you
    > AHDLC-encoded PPP data on your stdin, and will expect PPP from you
    > on stdout.
    >


    When I want to send for example "Hello world", I need to execute "echo
    Hello world > /dev/ppp0" for sending data to the ppp0 interface, then
    the pppd send to my program in HDLC-encoded PPP data, and I take this
    data and send with the GSM API functions. it's OK?
    But when I receive some HDLC-encoded PPP data from the GSM API function
    how can I send it to the pppd?

    In other words, how can I access to the ppp0 input and output?

    Thank you.


  4. Re: PPP with PPPD over GSM link

    jombocito@gmail.com writes:
    > When I want to send for example "Hello world", I need to execute "echo
    > Hello world > /dev/ppp0" for sending data to the ppp0 interface,


    No, that almost certainly won't work. /dev/ppp0 (what platform are
    you on?) is a network interface. You can't write plain ASCII text to
    a network interface.

    "ping 1.2.3.4" (or some relevant address) makes more sense here.

    > then
    > the pppd send to my program in HDLC-encoded PPP data, and I take this
    > data and send with the GSM API functions. it's OK?


    That part is.

    > But when I receive some HDLC-encoded PPP data from the GSM API function
    > how can I send it to the pppd?


    Write it to your standard output stream.

    > In other words, how can I access to the ppp0 input and output?


    You don't (and shouldn't) access ppp0 at all. You read and write your
    own standard input and output streams. Pppd sets those up as pipes
    and injects them into the master side of a pty pair, with the PPP
    processing configured (as if on a regular terminal) on the slave side.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  5. Re: PPP with PPPD over GSM link


    It seems that I'm quiet lost .

    I go to enumerate the events sort by time:
    1) run in the ppp server-> pppd pty 'my_aplication' silent
    2) run in the ppp client-> pppd pty 'my_aplication'
    3) the ppp in the client will start negotiating the configuration(LCP
    packets), the pppd will send HDLC-encoded LCP packet to my_aplication
    standard input.
    4) my_aplication in the client side takes the pppd generated
    HDLC-encoded LCP packet and send with the GSM API function
    5) my_aplication in the server side takes the HDLC-encoded LCP packet
    with the GSM API function and send to the standard output to the pppd
    6) now the server responses to the configuration ( steps 3-5 inverting
    roles)
    7) ...
    8) link is now up
    9) How can I do if my aplication wants to send some clear-data? But not
    a ping, for example the "hello world" string.

    Thank you for your help.


  6. Re: PPP with PPPD over GSM link

    jombocito@gmail.com writes:
    > It seems that I'm quiet lost .
    >
    > I go to enumerate the events sort by time:
    > 1) run in the ppp server-> pppd pty 'my_aplication' silent
    > 2) run in the ppp client-> pppd pty 'my_aplication'


    PPP is peer-to-peer, so there's no "server" or "client," but ok.

    > 3) the ppp in the client will start negotiating the configuration(LCP
    > packets), the pppd will send HDLC-encoded LCP packet to my_aplication
    > standard input.


    That's almost correct. As noted above, PPP is peer-to-peer. Both
    sides will begin negotiation at the same time by sending LCP
    Configure-Request messages to each other.

    PPP is symmetric.

    > 4) my_aplication in the client side takes the pppd generated
    > HDLC-encoded LCP packet and send with the GSM API function


    Yes.

    > 5) my_aplication in the server side takes the HDLC-encoded LCP packet
    > with the GSM API function and send to the standard output to the pppd


    Right.

    > 6) now the server responses to the configuration ( steps 3-5 inverting
    > roles)


    No. As above, PPP is symmetric. As described in RFC 1661, you _must_
    provide a simultaneous bi-directional communications path at all
    times. Both sides need to be able to send packets to the other.

    It doesn't just ping-pong back and forth as you're suggesting.

    > 7) ...
    > 8) link is now up


    Good so far.

    > 9) How can I do if my aplication wants to send some clear-data? But not
    > a ping, for example the "hello world" string.


    I can't really parse that question.

    Once the link is up, PPP provides a network interface, just like (say)
    Ethernet. How would you send "hello world" to an Ethernet?

    Once IPCP has negotiated (one of the protocols inside of PPP), you'll
    have a new IP interface on the system. You can then send packets over
    it (subject to the configuration of your local routing table) in the
    usual way for whatever operating system you're using. (Most have BSD
    sockets, but I don't think you've provided any details yet, so I can
    only guess.)

    The application you're describing above is just a pipe -- it connects
    the lower end of PPP (where bytes come out) to a particular physical
    layer transport (apparently GSM in this case). That's all it can
    really do. Asking about injecting data here is like asking about
    injecting data into the middle of any network driver; it doesn't make
    sense. This application shouldn't be sending any such data on its
    own.

    Why do you want to send plain text (rather than IP packets) over a
    network interface? What exactly are you trying to accomplish? Please
    be specific.

    (Not that I've used them, but I had thought that GSM devices provided
    a serial interface rather than just "an API," and PPP normally runs
    atop that serial interface. I don't understand why you have an
    application in the middle here at all. It seems a bit kludgy to me.)

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  7. Re: PPP with PPPD over GSM link

    Hello James Carlson,

    James Carlson wrote:
    > PPP is peer-to-peer, so there's no "server" or "client"


    Ok, I didn't know about this but I was thinking that if I put one of
    the pppds with the "silent" option, this one was the "virtual server"
    and the other one the was "virtual client"

    > > 9) How can I do if my aplication wants to send some clear-data? But not
    > > a ping, for example the "hello world" string.

    >
    > I can't really parse that question.
    >
    > Once the link is up, PPP provides a network interface, just like (say)
    > Ethernet. How would you send "hello world" to an Ethernet?
    >
    > Once IPCP has negotiated (one of the protocols inside of PPP), you'll
    > have a new IP interface on the system. You can then send packets over
    > it (subject to the configuration of your local routing table) in the
    > usual way for whatever operating system you're using. (Most have BSD
    > sockets, but I don't think you've provided any details yet, so I can
    > only guess.)


    Well, but I donīt want to send IP packets because this insert big
    overhead in a poor speed line and I dont need the IP functionality.


    > The application you're describing above is just a pipe -- it connects
    > the lower end of PPP (where bytes come out) to a particular physical
    > layer transport (apparently GSM in this case). That's all it can
    > really do. Asking about injecting data here is like asking about
    > injecting data into the middle of any network driver; it doesn't make
    > sense. This application shouldn't be sending any such data on its
    > own.


    Ok, very clear. Sorry.

    > Why do you want to send plain text (rather than IP packets) over a
    > network interface? What exactly are you trying to accomplish? Please
    > be specific.


    I am working in an embeeded system with a arm-linux installed, for
    access periphericals functionality another company provides me dinamic
    libraries for accesing the diferent periphericals. One of this
    peripherical is the GSM modem. I can send plain text over GSM with this
    libraries, but I think to send the data with the PPP over GSM to use
    the autentification and compresing options in an already tested and
    standard protocol.

    After your very usefull help I see two posibilities:
    1) implement the compresion and autentification, and create my own
    protocol forgotting PPP
    2) use a PPP suported protocol to send the data. I have read in the RFC
    3772 (very good document, thanks) about mounting Vendor-Specific
    Protocol (VSP) over/inside the PPP, this can be a solution?

    Thank you.


  8. Re: PPP with PPPD over GSM link

    On 2005-09-15, jombocito@gmail.com wrote:
    > I am working in an embeeded system with a arm-linux installed, for
    > access periphericals functionality another company provides me dinamic
    > libraries for accesing the diferent periphericals. One of this
    > peripherical is the GSM modem. I can send plain text over GSM with this
    > libraries, but I think to send the data with the PPP over GSM to use
    > the autentification and compresing options in an already tested and
    > standard protocol.


    Are you using GSM's Circuit Switched Data (CSD) or packet services like
    GPRS or SMS?

    (I hope your not fiddling with some GSM internal data sending modes --
    since your asking here instead of 3gpp I don't think so

    Are you connecting to another network or to another GSM/PSTN terminal?

    It seems to me that you're very much re-inventing the wheel here. If
    you have a CSD connection to some other terminal or modem or what ever,
    It's a character transmitting interface with which you can send character
    streams like 'hello world\n' (if encoded and integrity checked properly,
    since there might be errors after the data exits the digital GSM
    network, which is supposed to be error free to the applications) or
    if you connect both ends to a PPP stack, you can do TCP/IP etc. networking
    through the connection.

    I don't know much about the Linux or pppd internals, but if your doing
    CSD or GPRS through a third party library without existing Linux
    integration, I'd try to add the third party library as a serial port to
    Linux. I find it very likely that the physical connection from the
    Linux device to the GSM modem resembles an RS232 connection or if it
    doesn't (shared memory plus interrupt lines) then the library interface
    resembles RS232 -- so there might be working drivers around already.

    Just my 2 Euro cents...

    -Mikko

  9. Re: PPP with PPPD over GSM link

    jombocito@gmail.com writes:
    > Well, but I donīt want to send IP packets because this insert big
    > overhead in a poor speed line and I dont need the IP functionality.


    Though I'd likely agree with the "poor speed line" part, I strongly
    disagree that IP necessarily inserts "big overhead." Before deciding
    that this is true, you might want to measure or compute the actual
    overhead involved.

    For instance, if you use TCP, and you have VJ compression and regular
    PPP header enabled on your link, then typical messages will have about
    7 octets worth of overhead -- meaning that a 100 octet message will be
    sent as 107 octets on the wire. (Your mileage will certainly vary.)

    It sounds to me like you may be attempting to optimize something that
    hasn't actually been measured. That's rarely, if ever, a good idea.

    If you're not interested in creating a network interface, though, I'm
    puzzled as to why you're trying to get PPP working on this interface.
    That's pretty much the whole point of PPP -- it's a way to make
    network protocols work over point-to-point connections.

    If you're not intending to do networking, then what's the point of
    having PPP?

    > I am working in an embeeded system with a arm-linux installed, for
    > access periphericals functionality another company provides me dinamic
    > libraries for accesing the diferent periphericals. One of this
    > peripherical is the GSM modem. I can send plain text over GSM with this
    > libraries, but I think to send the data with the PPP over GSM to use
    > the autentification and compresing options in an already tested and
    > standard protocol.


    OK, that provides a *bit* more information, but still not enough to be
    useful.

    What does the application look like? What is running on the peer? Do
    you have control over both ends of the connection? When your
    application is deployed, will you always have control over both ends?
    What authentication is necessary in this environment?

    What sort of data will be passed over the link? How is the
    application coded and what APIs does it expect to use?

    Are there any networking applications in use -- e.g., name services,
    browsers, file transfer, or the like?

    If the only reason you're using PPP is to get the authentication and
    data compression options on an otherwise plain text link, that seems
    like a somewhat dubious goal to me, but look at RFC 1963 for one
    "standard" way to do it.

    > After your very usefull help I see two posibilities:
    > 1) implement the compresion and autentification, and create my own
    > protocol forgotting PPP


    Yes.

    > 2) use a PPP suported protocol to send the data. I have read in the RFC
    > 3772 (very good document, thanks) about mounting Vendor-Specific
    > Protocol (VSP) over/inside the PPP, this can be a solution?


    Perhaps. The point of VSP is really to allow vendors who are using
    PPP for the usual reasons already (e.g., network traffic) to implement
    vendor-specific features on those links in an interoperable manner.

    For instance, if you had a regular PPP connection running IPCP (with
    TCP/IP), and you had some sort of proprietary, non-TCP/IP link
    management interface, you might want to send your messages over VSP.
    It might be a way to perform out-of-band management of the remote DCE
    device.

    It wasn't really designed for carrying bulk user data, but I guess
    there's nothing actually stopping you from doing that.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  10. Re: PPP with PPPD over GSM link

    Hello Mikko Rapeli,

    Mikko Rapeli ha escrito:
    > Are you using GSM's Circuit Switched Data (CSD) or packet services like
    > GPRS or SMS?


    I'm using GSM with data call, no GPRS nor SMS.

    > Are you connecting to another network or to another GSM/PSTN terminal?


    to another GSM Terminal, this one controlled by AT commands.

    > It seems to me that you're very much re-inventing the wheel here. If
    > you have a CSD connection to some other terminal or modem or what ever,
    > It's a character transmitting interface with which you can send character
    > streams like 'hello world\n' (if encoded and integrity checked properly,
    > since there might be errors after the data exits the digital GSM
    > network, which is supposed to be error free to the applications) or
    > if you connect both ends to a PPP stack, you can do TCP/IP etc. networking
    > through the connection.


    Now I have this clear, thanks to James Carlson.

    But I want to use the PPP framing, autentication and compression (if
    its posible) functionalities, for my data packets.

    I can use UDP/IP for sending my data packets, but I think that the
    UDP/IP funtionality is not usefull for me, I dont want my packets to be
    routed, and my packets go in order, so I think that using a protocol
    like IP that is designed for a very more complex enviroment is a
    resources waste. If there is no other solution its posible to take this
    way, but I prefer to evade this solution because the GSM line is slow
    and expensive.

    > I don't know much about the Linux or pppd internals, but if your doing
    > CSD or GPRS through a third party library without existing Linux
    > integration, I'd try to add the third party library as a serial port to
    > Linux. I find it very likely that the physical connection from the
    > Linux device to the GSM modem resembles an RS232 connection or if it
    > doesn't (shared memory plus interrupt lines) then the library interface
    > resembles RS232 -- so there might be working drivers around already.


    I would think about this, this can give more independent code, but
    libraries provides me with a event handler to manage the GSM modem
    status, and functions for managing the GSM modem funtionalities so I
    think that is more powerfull than a virtual serial port.

    Thank you for your suggestions.


  11. Re: PPP with PPPD over GSM link

    James Carlson writes:
    > jombocito@gmail.com writes:
    > > Well, but I donīt want to send IP packets because this insert big
    > > overhead in a poor speed line and I dont need the IP functionality.

    >
    > Though I'd likely agree with the "poor speed line" part, I strongly
    > disagree that IP necessarily inserts "big overhead." Before deciding
    > that this is true, you might want to measure or compute the actual
    > overhead involved.
    >
    > For instance, if you use TCP, and you have VJ compression and regular
    > PPP header enabled on your link, then typical messages will have about
    > 7 octets worth of overhead -- meaning that a 100 octet message will be
    > sent as 107 octets on the wire. (Your mileage will certainly vary.)


    I didnt know that the VJ compression can compress from 40 Bytes (TCP+IP
    headers) to 7 bytes. This is a good notice, it can be a solution for
    the overhead requirement. Now I'm worried about the processor overwork
    It seems a joke, but not at all. The VJ compression only compress
    the header of the TCP/IP and I need to compress my data too,
    encapsulate and calculate TCP/IP datagram checksums is a CPU work that
    I really dont need to do.

    I'm working with a embedded sistem limited in processing capacity.

    > If you're not interested in creating a network interface, though, I'm
    > puzzled as to why you're trying to get PPP working on this interface.
    > That's pretty much the whole point of PPP -- it's a way to make
    > network protocols work over point-to-point connections.
    >
    > If you're not intending to do networking, then what's the point of
    > having PPP?


    If I don't use PPP, and I want to autenticate and construct frames, I
    need to build a protocol very similar to PPP, with a frame start and
    end characters, with a character-stuff and a autentication process,
    this needs to separate Data frames from control/autentication frames,
    so control information is needed to send.

    I see that PPP implements this all and more and is a very used
    standard, so why don't use it?.

    I search for a PPP frame construct library but I only see the linux
    kernel PPP module code, and the pppd code. So I decide search the
    posibility of using pppd to my objetive.

    > OK, that provides a *bit* more information, but still not enough to be
    > useful.
    >
    > What does the application look like? What is running on the peer? Do
    > you have control over both ends of the connection? When your
    > application is deployed, will you always have control over both ends?
    > What authentication is necessary in this environment?
    >
    > What sort of data will be passed over the link? How is the
    > application coded and what APIs does it expect to use?


    The aplication gives online information or status files of a controled
    peripherical.
    On the peer will be another little aplication. And I will have control
    over both ends of the connection always.
    With GSM I have the phone number authentication but It seems not
    enought, I think to use CHAP for more security.
    The data packets over the PPP frame is little protocol for read online
    data or status files.

    > Are there any networking applications in use -- e.g., name services,
    > browsers, file transfer, or the like?


    No.

    > If the only reason you're using PPP is to get the authentication and
    > data compression options on an otherwise plain text link, that seems
    > like a somewhat dubious goal to me, but look at RFC 1963 for one
    > "standard" way to do it.


    I have read the RFC1963, and the PPP-SDTP/SDCP transport protocol can
    be the solution for me, its implement more functionality that I really
    need, for example multilink, but this options are negotiable, and the
    minimal version is usefull to me.
    But when I try to search more information about how to implement it, I
    get nothing but links to the RFC, where can I get information for
    including this in my system?

    Why is a dubius goal? Is there a easier way to do the same?

    > Perhaps. The point of VSP is really to allow vendors who are using
    > PPP for the usual reasons already (e.g., network traffic) to implement
    > vendor-specific features on those links in an interoperable manner.
    >
    > For instance, if you had a regular PPP connection running IPCP (with
    > TCP/IP), and you had some sort of proprietary, non-TCP/IP link
    > management interface, you might want to send your messages over VSP.
    > It might be a way to perform out-of-band management of the remote DCE
    > device.
    >
    > It wasn't really designed for carrying bulk user data, but I guess
    > there's nothing actually stopping you from doing that.


    Ok. This can be the last option.

    I don't want to abuse of your help, if I find the way to implement the
    solutions PPP-SDTP/SDCP, or VSP ok, else I implement it my self and
    post my results.

    Thank you for all.


  12. Re: PPP with PPPD over GSM link

    jombocito@gmail.com writes:
    > I didnt know that the VJ compression can compress from 40 Bytes (TCP+IP
    > headers) to 7 bytes.


    Actually, it compresses better than that. The 7 bytes overhead
    included PPP framing as well. (Roughly; there's also a 0.78% per-byte
    overhead for escaping, on average with random data.)

    > This is a good notice, it can be a solution for
    > the overhead requirement. Now I'm worried about the processor overwork
    > It seems a joke, but not at all. The VJ compression only compress
    > the header of the TCP/IP and I need to compress my data too,
    > encapsulate and calculate TCP/IP datagram checksums is a CPU work that
    > I really dont need to do.


    In general, worrying about CPU and memory -- except perhaps for things
    that have geometric or worse complexity -- is a losing proposition.
    The reason is that over very short periods of time, commodity CPUs get
    much faster, but software and protocols themselves don't change.

    In other words, if you're designing for the hardware of today, you're
    probably designing for a dinosaur. The solution will look quaint in a
    short period of time. And, by then, you'll have deployed it and
    you'll have a *much* harder time upgrading it, because any upgrade
    will cause a "flag day" change for your users.

    But, if you're insistent on designing a protocol to overcome temporary
    hardware limitations, you have a lot of company. Don't let me try to
    dissuade you.

    > I'm working with a embedded sistem limited in processing capacity.


    A common refrain.

    > If I don't use PPP, and I want to autenticate and construct frames, I
    > need to build a protocol very similar to PPP, with a frame start and
    > end characters, with a character-stuff and a autentication process,
    > this needs to separate Data frames from control/autentication frames,
    > so control information is needed to send.
    >
    > I see that PPP implements this all and more and is a very used
    > standard, so why don't use it?.


    And TCP/IP handles all sorts of messaging and retransmit issues, and
    provides a well-known and highly portable API, so why not use it?

    If you're going to skip TCP/IP and do your own thing here, then I'd
    suggest writing an extension to the kernel bits that allows you to
    inject arbitrary messages into the stream. It doesn't look too hard
    to do, but since you're essentially using the software other than the
    way it was intended to be used, you're pretty much on your own.

    > I search for a PPP frame construct library but I only see the linux
    > kernel PPP module code, and the pppd code. So I decide search the
    > posibility of using pppd to my objetive.


    That part was a good choice. Rewriting PPP from scratch is a pain.

    > The aplication gives online information or status files of a controled
    > peripherical.
    > On the peer will be another little aplication. And I will have control
    > over both ends of the connection always.
    > With GSM I have the phone number authentication but It seems not
    > enought, I think to use CHAP for more security.
    > The data packets over the PPP frame is little protocol for read online
    > data or status files.


    I guess I remain doubtful of the apparent contention that this
    application will always (and for all time) do only these simple
    things, and just never use or talk to any other software or systems,
    and thus have no interoperability constraints at all.

    My experience is otherwise. If this is a useful application, then
    long after you're gone, someone else will be called on to maintain it,
    and will likely have to adapt it to do things you didn't envision,
    such as connecting to some commercial PPP server rather than your
    modified one.

    If it's not a useful application, then it probably doesn't matter much
    what it does ...

    > I have read the RFC1963, and the PPP-SDTP/SDCP transport protocol can
    > be the solution for me, its implement more functionality that I really
    > need, for example multilink, but this options are negotiable, and the
    > minimal version is usefull to me.
    > But when I try to search more information about how to implement it, I
    > get nothing but links to the RFC, where can I get information for
    > including this in my system?


    All you'll likely get is the RFC. I don't think anyone anywhere
    actually implemented it. (If anyone did, it's probably buried in some
    Adtran box ...)

    But it does solve the problem of serial transport over PPP.

    > Why is a dubius goal? Is there a easier way to do the same?


    It's a dubious goal because it seems to me that you've done part of
    the job, adopting a decent interoperable standard for the link layer,
    but then punted on the rest by asserting that only a non-standard
    "simpler" extension rather than any standard neworking protocol can
    solve your problems.

    What benefit did you really get from choosing PPP for authentication
    and compression? Isn't PPP sort of complicated for that?

    I suspect that if you can do data compression at all on this tiny
    machine, then TCP/IP is a breeze. Data compression consumes *far*
    more CPU horsepower and memory to implement than TCP/IP.

    But, perhaps all you want is the authentication. In that case, given
    everything else you've said, I suspect you may as well just ditch the
    whole thing and write a tiny challenge/response implementation as part
    of your own little protocol.

    After all, the only other bits remaining here are in PPP negotiation
    and LCP, and since you say you control both ends of the connection,
    this is worthless to you. There's nothing to negotiate.

    > I don't want to abuse of your help, if I find the way to implement the
    > solutions PPP-SDTP/SDCP, or VSP ok, else I implement it my self and
    > post my results.


    I'm not going to find it "ok" or not; that's for you to do.

    My main advice here is to avoid the temptation to use PPP for "some"
    of the features, discarding the rest. But if you still feel that this
    is right for your situation, then drive on.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  13. Re: PPP with PPPD over GSM link

    Hello,

    James Carlson writes:
    > jombocito@gmail.com writes:
    > > This is a good notice, it can be a solution for
    > > the overhead requirement. Now I'm worried about the processor overwork
    > > It seems a joke, but not at all. The VJ compression only compress
    > > the header of the TCP/IP and I need to compress my data too,
    > > encapsulate and calculate TCP/IP datagram checksums is a CPU work that
    > > I really dont need to do.

    >
    > In general, worrying about CPU and memory -- except perhaps for things
    > that have geometric or worse complexity -- is a losing proposition.
    > The reason is that over very short periods of time, commodity CPUs get
    > much faster, but software and protocols themselves don't change.
    >
    > In other words, if you're designing for the hardware of today, you're
    > probably designing for a dinosaur. The solution will look quaint in a
    > short period of time. And, by then, you'll have deployed it and
    > you'll have a *much* harder time upgrading it, because any upgrade
    > will cause a "flag day" change for your users.
    >
    > But, if you're insistent on designing a protocol to overcome temporary
    > hardware limitations, you have a lot of company. Don't let me try to
    > dissuade you.


    Good arguments, you have convenced me. I will see if my system can
    support this work else I implement a little protocol with
    autentication.

    > > I don't want to abuse of your help, if I find the way to implement the
    > > solutions PPP-SDTP/SDCP, or VSP ok, else I implement it my self and
    > > post my results.

    >
    > I'm not going to find it "ok" or not; that's for you to do.
    >
    > My main advice here is to avoid the temptation to use PPP for "some"
    > of the features, discarding the rest. But if you still feel that this
    > is right for your situation, then drive on.


    Excuse me, I think that I had express very bad. I only want to say that
    now I see much more clear the problem/solutions and that I was
    searching the way to implement the solutions (PPP-SDTP/SDCP or VSP) my
    self but if didn't find this solutions I implement the solution in the
    aplication.

    Thanks for all your help. I will evaluate if my system can support
    PPP+IP+TCP+vj compresion+ data compression, else I will find another
    solution.

    Good bye.


+ Reply to Thread