TCPnet: switching between PPP and Ethernet at runtime

Thanks, Darren.

This is exactly what I am observing.

Thanks, Darren.

This is exactly what I am observing.

I am still having no luck getting PPP to acquire DNS servers. However, I have made some headway on switching between ethernet and PPP. If someone with TCPnet experience would like to comment on these changes, I would appreciate it. I am particularly interested in if I might have created some instability in TCPnet.

All changes are made in Net_Config.c. I have compiled with both PPP and Ethernet enabled. Here are my changes:

I have changed the definition of netif_cfg from this:

U8 const netif_cfg = (PPP_GETIP<<5 | SLIP_DEFGW<<4 | PPP_DEFGW<<3 | SLIP_ENABLE<<2 | PPP_ENABLE<<1 | ETH_ENABLE);

To this (making it no longer a constant):

U8 netif_cfg = (PPP_GETIP<<5 | SLIP_DEFGW<<4 | PPP_DEFGW<<3 | SLIP_ENABLE<<2 | PPP_ENABLE<<1 | ETH_ENABLE);

Then I have added this function, which modifies netif_cfg to use PPP as its default, or not (on the fly).

void TogglePPP_DefGW(unsigned char bPPP_Default)
{
   if (bPPP_Default > 1)
      return;           //invalid value
   else
      netif_cfg = (PPP_GETIP<<5 | SLIP_DEFGW<<4 | bPPP_Default <<3 | SLIP_ENABLE<<2 | PPP_ENABLE<<1 | ETH_ENABLE);
}

This seems to have the desired effect. When I want to use ethernet, (if TCPnet is currently active, I first close all sockets) I do the following:
1) call TogglePPP_DefGW(0)
2) call init_TcpNet()

When I want to use PPP (again, if TCPnet is already active, I first close all sockets), I do the following:
1) call TogllePPP_DefGW(1)
2) call init_TcpNet()

Your code show you call TogglePPP_DefGW(0) or TogglePPP_DefGW(1).

But the TogglePPP_DefGW() function does not check the received parameter for the value 0 or 1. It looks for bPPP_Default > 1, where larger than 1 is invalid. Where is the test for 0 or 1?

Next thing - netif_cfg is declared const. That means no-modifyable. So how would TogglePPP_DefGW() be able to modify it?

You are writing "This seems to have the desired effect." which implies that you have compiled and tested. But if you have compiled and tested and found it to work - how can then the posted code contain these errors?

Hi Per,

You are right that netif_cfg is declared as a constant. However, I changed it away from being a constant (see the note in my previous post about that).

Also, TogglePPP_DefGW( ) modifies netif_cfg by using its passed parameter in the "netif_cfg =" statement (third variable to the right of netif_cfg).

What I am concerned about, in regards to stability, is that I have changed netif_cfg to no longer be a constant. So far everything is working fine though.

"Also, TogglePPP_DefGW( ) modifies netif_cfg by using its passed parameter in the "netif_cfg =" statement (third variable to the right of netif_cfg)."

Sorry, I missed that one.

Without seeing the full source of the stack, it is hard to know if the stack has some code that relies on the variable being const.

Yeah, that is the problem that I am having...

Hi Eric Severson

You echo my issues on the closed source stack as a user its hard having to second guess how it operates a lot of the time.

Darren

"You echo my issues on the closed source stack as a user its hard having to second guess how it operates a lot of the time."

Recently had a conversation with our local Keil distributor about getting the source to the TCP stack.

We could get it for 10000 euros. Yes, that's four zeros there!

I'm now starting to consider alternatives.

Probably a lot of companies that already has considered alternatives. It can be quite dangerous to depend on non-trivial closed-source libraries.

It would have been more reasonable to just have an NDA and a _way_ lower price for the source. For that price, I would expect to own the rights to the source and be allowed to sell modified versions of the stack to other customers...

It would have been more reasonable to just have an NDA and a _way_ lower price for the source.

My sentiments also...

Yes, I agree with all of this.

For the record -- Keil said that my little tweak ought to be safe so long as it is done BEFORE calling init_TcpNet().

In regards to an alternative: for a while I have been wishing to use Adam Dunkel's uIP. The only catch, for me, is that I need PPP in addition to Ethernet. Well, I see these guys claim to have uIP working with PPP:
savannah.nongnu.org/.../lwip

I haven't had time to look into this too much yet: especially in regards to if any licensing fee may be required for commercial use. But even if there is one, I have to think it would be less than Keil's fee. Also, I don't know if anyone has ported this in to a Keil uVision project and glued it into the standard Ethernet drivers for our MCUs.

If any of you do look into it, I would be very interested to hear what you have to say. If/when I get a chance to dig in to it, I'll be sure to post my results. It'd be great if we could share some source code for getting it going in uVision. Feel free to contact me: erics at the domain of forwardpay dot com.

By the way - is it €10000 per seat, like there is for RL-ARM, to get access to the source code for RTX?

"...is it 10000 euro per seat..."

Sorry, they didn't say.

I work for a small company, I'm the only firmware bod, and one license is sufficient. So it never occured to me to ask the question.