We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm attempting to get PPP working. I have a socketmodem connected to an LPC2468 on uart 1. have the serial driver working.
Do I need to include Std_Modem.c in my project?
Where do I make changes to support my particular modem?
I'm not finding this obvious.
Dave
The sequence you use seems correct to me. However it might have something to do with the RTX kernel you are using. All TCPnet requests shall be sent from only one task, because TCPnet is not a multithreading application.
Try to disable the Ethernet interface and test only PPP. Important is that you do not start using a TCP socket before the ppp link is up (ppp_is_up() must return TRUE).
Franc,
It seems to have been the threading issue. I was initializing in a different thread. After moving those calls to the same thread it is behaving as expected.
It's still not connecting properly but I think that's a modem issue I have to solve.
Thanks for your help!
I'm afraid I have a new problem. I want to open a tcp session on the ethernet interface while the ppp interface is down. It works fine for sockets that are listening, but when I to open a socket to send, it seems the data is routed to ppp:
PPP: Sending PPP frame... PPP ERR: IPCP down, discarding TX frame.
How can I make sure the frames are sent to the ethernet interface? I know the interfaces should be on different subnets, but when the ppp interface is down, what subnet is it on?
I tried turning off "use default gateway on remote network:, and that fixed the problem in my last post. I still find it very odd that the stack would send packets to an interface that is down.
Now I have Another Problem.
I suspect that the PPP stack does not handle back-to-back flags (0x7e) properly. I was getting nothing but these messages:
PPP ERR: Frame too short
To test the theory, I tried stripping out every second 0x7e at the serial driver level, and the stack started working! Not well, but well enough to FTP a small file successfully.
If this is valid, it's a pretty serious bug. It's allowable to use a shared flag between PPP frames, but it certainly is not required!
The PPP framing problem appears to be real. I've submitted a support request. Anybody else have a problem with this?
Same problem but dropping a ~ every 2 do not work properly. I push a dummy ~ as the very first char in the RX buffer. It seams that there is an unalignement in the PPP framing scheme. My app works like this:
~~FRAME~~FRAME~~FRAME~~...... the first ~ is dummy
My app do not works like this:
~FRAME~~FRAME~~FRAME~~...... dropping every 2nd ~ the PPP still goes up with lot of retrans but then for example if you ping the board it responds only to even icmp packets (PPP decodes 1 frame every 2).
let me know your opinion.
I've been corresponding with Keil support. They agree there is a problem, but they have not fixed it yet.
Hello,
Did the patch fix this problems for you guys?
I updated my version of RL-ARM and am having PPP issues of a different sort. I seem to be able to successfully exchange PPP packets but cannot establish a connection over a null-modem link to a windows PC. I put a forum post up and emailed Keil, but no one has replied:
http://www.keil.com/forum/docs/thread11281.asp
Any chance you might have some suggestions for me?
Any help would be greatly appreciated, Eric
They fixed the framing problem. However, it still won't connected to a Cisco NAS (Cisco 7206VXR). It fails during LCP parameter negotiation.
Due to this and other problems with the stack, we have made the decision to cut our losses and go with a stack from another vendor.
Okay, thank you. I really appreciate this.
My real use for the stack is to connect with a cellular modem and I have been seeing some LCP errors.
-Eric