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
signature.asc
Description: Digital signature
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users