Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make PPPoS run (again) after latest lwip changes #1028

Closed
wants to merge 2 commits into from
Closed

Make PPPoS run (again) after latest lwip changes #1028

wants to merge 2 commits into from

Conversation

loboris
Copy link

@loboris loboris commented Sep 22, 2017

There was a problen running PPPoS after latest changes to lwip (#1017).
This simple patch makes it run again.

@CLAassistant
Copy link

CLAassistant commented Sep 22, 2017

CLA assistant check
All committers have signed the CLA.

@projectgus
Copy link
Contributor

projectgus commented Sep 26, 2017

Hi @loboris,

I haven't had time to look at this properly yet (sorry), but this seems to revert some changes that were required to allow APSTA modes to coexist & route properly (ie allow the ESP32 to route to the internet via a STA interface while sending/receiving packets on the AP interface).

Is it possible there is some other way to configure routes & addresses in LWIP to make the PPPoS interface work correctly?

@loboris
Copy link
Author

loboris commented Sep 26, 2017

I'll try some other solutions.

Usualy, we use PPPoS when we have no WiFi Internet connection and STA mode is not used (and canno't be used), so APSTA mode is also not used. In that case, we connect to the Internet via GSM/PPPoS and (eventualy) use AP mode to connect to the ESP32 (and possibe route the traffic to the Internet).

@danicampora
Copy link
Contributor

@loboris I think this should be made to work also when APSTA is used. I'll have a look as well.

@loboris
Copy link
Author

loboris commented Oct 2, 2017

In PPPoS gw address is set to 10.64.64.64, we can check it in ip4_route function (ip4.c) and return the netif if other checks fail.
This shouldn't affect APSTA (not tested yet).

@projectgus
Copy link
Contributor

Hmm, that's an interesting fix but I don't think hardcoding interface-specific addresses in the IP stack routing layer is a good idea.

It should be possible to externally configure LWIP's routes so that it knows what your preferences for routing are.

@loboris
Copy link
Author

loboris commented Oct 3, 2017

I'm avare that it is a dirty fix, for now it's working for me until I (or someone else) find the better solution.

@danicampora
It should be written in hex: 0x4040400A (gw address 10.64.64.64)

Dmitry4Bh added a commit to Dmitry4Bh/esp-idf that referenced this pull request Oct 11, 2017
Pointer tcpip_api_call *m  should be converted to pppapi_msg* instead of pppapi_msg_msg*
in pppapi_do_ppp_set_default(), pppapi_do_ppp_free() and so on.

It solve this issue espressif#1028
so there is no need to patch ip4.c because now netif_defauilt is setted correctly.
Also it prevents memory corruption when pppapi_free() is called.
@loboris
Copy link
Author

loboris commented Oct 12, 2017

Better solution found:
#1100

@loboris loboris closed this Oct 12, 2017
@loboris loboris deleted the pppos branch October 12, 2017 07:04
igrr pushed a commit that referenced this pull request Nov 13, 2017
Pointer tcpip_api_call *m  should be converted to pppapi_msg* instead of pppapi_msg_msg*
in pppapi_do_ppp_set_default(), pppapi_do_ppp_free() and so on.

It solve this issue #1028
so there is no need to patch ip4.c because now netif_defauilt is setted correctly.
Also it prevents memory corruption when pppapi_free() is called.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants