PPP setup

Thanks for the info. I included the modem driver, and got a little further.

The problem I am having now, is the PPP stack does not wait for the modem to connect before trying to bring up the link. The example you cited is for PPP listen, but my application dials out. Do you see a problem with this sequence?:

ppp_connect ("5551212","user","password"); while(!ppp_is_up()) ; file_upload(); ppp_close ();

Debug shows that PPP starts trying to send frames before the modem has connected. I set a breakpoint in the modem driver function modem_process() where it returns __TRUE, and it does not reach that point before PPP starts trying to send frames.

Thanks for any help.

Dave

Thanks for the info. I included the modem driver, and got a little further.

The problem I am having now, is the PPP stack does not wait for the modem to connect before trying to bring up the link. The example you cited is for PPP listen, but my application dials out. Do you see a problem with this sequence?:

ppp_connect ("5551212","user","password"); while(!ppp_is_up()) ; file_upload(); ppp_close ();

Debug shows that PPP starts trying to send frames before the modem has connected. I set a breakpoint in the modem driver function modem_process() where it returns __TRUE, and it does not reach that point before PPP starts trying to send frames.

Thanks for any help.

Dave

If nothing else, your little example rewrite doesn't take into account that the connect will fail.

I knew somebody would point that out. It's just an example to show the problem, not real code.

Thanks
Dave

Well, the small examples have an extraordinary way of sneaking themselves into production code somehow :)

Point taken, not this time though :-)

I should also mention that I am running RTX with round robin task switching, and there is also an ethernet interface.

I tried calling modem_dial() directly, and without even calling PPP_connect() it starts to try to send IPCP frames!

What triggers the PPP daemon to start the link negotiation?

Dave

Another observation: adjusting the timeouts for PPP in netconfig appears to have no effect. The initial packets are sent 2 seconds apart, even when I set all the timeouts to 10 seconds.

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!

Dave

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?

Dave

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!

Dave

The PPP framing problem appears to be real. I've submitted a support request. Anybody else have a problem with this?

Dave

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.

Dave

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.

Dave

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