Re: [lwip-users] Advise on PPPoS implementation

[Raivis]

Hi,

I re-implemented on Unix system with threading, the code is basically 99% identical as the one I'm running on stm32.

I double checked the priorities, and they are the same as on unix system. All relative to default thread priority

Also I only used tcpip_init() to initialize it, as far as I know I never touched raw LwIP API after that.

However, by saying that, I just managed to get it working on stm32, by transferring my unix lwipopts.h config file to the stm32 and adding some stm32 specific defines to it.

Honestly I'm not sure why it works, and what caused the issue, maybe you as an expert can get an idea why it works by quickly glancing at the two config files:

Here is the original stm32 lwipopts.h:

https://pastebin.com/LEueShJv

And here is the one which started working

https://pastebin.com/6E2mXCXr

Thanks

Best Regards.

Raivis Strogonovs

On Fri, Nov 3, 2017 at 6:17 PM, Sylvain Rochet <address@hidden> wrote:

Hi,

On Thu, Nov 02, 2017 at 11:15:18PM +0000, Raivis wrote:
> Hi,
>
> I tested with UDP, and it didn't work.
>
> But, whole day, I've been working on porting the PPP GSM interface to unix
> system. Took me a while since, I hadn't worked with LwIP at this detail
> before.
>
> Thankfully, I can confirm it works on my linux machine, but not on stm32.
> So I've probably made a mistake somewhere with stm32.
>
> Now that I have a working system, I can compare it to stm32 and see
> what goes wrong, and try to solve it. My main suspect is the way I'm
> using HAL layer for serial transmission. (which is still odd, since
> PPP get's the IP)

This is not necessarily odd, the stack path is totally different between
a tx packet which source is the PPP stack itself and a tx packet which
source is external to lwIP such as a UDP or a TCP packet generated from
your user code. If you look closely at the PPP source you will see that
the path distinction actually goes down to the PPP low level protocol
(oS,oE,oL2TP).

And it matters, it matters a lot, frames sent by the PPP stack itself
are mostly driven by received packets (we are negotiating with a
classical do-don't-will-won't manner), meaning tx caller is called in
the exact same context of the rx context. Rationale is the same for
packets sent from user applications, they are sent from the current user
application context (unless you are using one of messagebox driven APIs
indeed). Context for both output paths *MUST* *BE* the same.

The more you say, the more I am suspecting a usual violation of lwIP
contexts (threads, interrupt handlers) requirements. Are you sure you
are using the proper PPPoS input API for your case ? Are you sure you
are not using lwIP RAW API outside your lwIP core context ?

Sylvain

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users