Open pfalcon opened 7 years ago
@dpgeorge: FYI.
I still had a case when it stopped, with WiFi TX buffers exhausted.
That's definitely a noticeable issue:
Free WiFi driver buffers of type:
0: 0 (1,2 TX)
1: 0 (4 Mngmt TX(len: 0x41-0x100))
2: 8 (5 Mngmt TX (len: 0-0x40))
3: 4 (7)
4: 7 (8 RX)
lwIP PCBs:
Suspicion lies on packet retransmission issues, e.g. vendor codedrop has pretty magic code like https://github.com/pfalcon/lwip-esp8266/commit/79dc3436960563b201361917917e0f3c18fd65d8
@pfalcon, ack, nice work! It's a shame thought that it's not possible to use lwip "out of the box". Are there plans to upgrade to lwip v2?
Are there plans to upgrade to lwip v2?
Well, the idea is that it will make it possible, but I don't have any specific plans to got that far, more realistic idea is to upgrade minor release by minor release (and even that requires better testing process than we have now).
Well, the idea is that it will make it possible, but I don't have any specific plans to got that far,
Ok. lwip v2 had some changes to how netif's are added/initialised so that makes it difficult to upgrade if Espressif have hidden that initialisation code in a binary blob.
@pfalcon: Great work. I unfortunately never had time to maintain the code I've made. I'm glad you did the work. Our methodology was very similar, I remember spending a lot of time looking at the disassembly of the Esperssif binary blobs too, though :)
Hi @pfalcon, I've been playing around with your reworked fork (https://github.com/pfalcon/esp-lwip) and while it compiles fine for me, there seem to be some missing symbols: os_malloc, os_realloc, os_zalloc, os_free. Those are, as far is I can tell, not provided by esp-open-sdk (I'm using esp-open-sdk based on 2.1.0) and kadamski has defines for them: https://github.com/kadamski/esp-lwip/blob/esp8266-1.4.1/config/lwipopts.h#L40
Are they missing intentionally or am I doing something wrong?
@LongHairedHacker : I don't have time to look into that issue now (or soon), but feel free to provide exact steps on how you got to that issue so it can be investigated later.
Doesn't seem to be any way to create an issue on the /esp-lwip repo directly so I've had to comment here.
Compiled this last night and got some warnings/errors:
implicit definitions for some functions, in particular mem_malloc/mem_calloc/mem_free. Suggest adding #include "mem.h"
to lwipopts.h and using os_malloc/os_calloc/osfree in the defines because vPortMalloc has extra parameters that will cause compile errors when the function is properly defined. the os* versions have those parameters taken care of. This will also solve the problem reported by @LongHairedHacker
error in compiling dhcpserver.c - dhcpserver.h is missing. It's actually there but the path in the .c file is wrong or the file itself is in the wrong place. I wasn't sure which it was so leave it up to you whether to move it or change the path in dhcpserver.c
@kadamski : Thanks for ping-back ;-).
Our methodology was very similar, I remember spending a lot of time looking at the disassembly of the Esperssif binary blobs too, though :)
Well, I've been spending enough time looking at the disassembly too. And if you look e.g. at https://pfalcon.github.io/xtensa-subjects/2.0.0-p20160809/out.html#esf_buf_alloc , you'll see that it allocates different buffer structures than you saw when you looked at that, and there likely were number of changes across SDK evolution. So, for the above particular work I actually didn't look at the disasm, instead following more black-boxish idea that while there're many changes across SDK versions, only some of them would affect lwIP integration. That's still heuristic and I'm not sure whether to continue digging your version, or stick with 1.4.0-rc2 with more or less complete vendor patchset I did initially.
Doesn't seem to be any way to create an issue on the /esp-lwip repo directly
Github by default disables issue tracker in forked projects, considering that any communication should happen upstream. I've enabled it now.
Suggest adding #include "mem.h" to lwipopts.h and using os_malloc/os_calloc/osfree in the defines because vPortMalloc has extra parameters that will cause compile errors when the function is properly defined. the os* versions have those parameters taken care of.
There're various conflicts between lwIP headers and SDK headers. I definitely worked that around for it to be able not just compile, but also run, but it's not fully clean/correct, and might have left in my git stash.
error in compiling dhcpserver.c - dhcpserver.h is missing.
I used dhcpserver from SDK2.0 even for kadamski's upgraded repo. Bits and pieces might have left in git stash too. Generally, the situation with dhcpserver isn't clear - it's unclear what it's licensing is, etc. I'd have an idea to replace Espressif's proprietary version e.g. with one from esp-open-rtos, but that's written with threaded style, so needs conversion to native lwIP API, and then long testing for any possible regressions comparing to proprietary server.
But the current situation is, to remind, that version upgraded from kadamski's work has obvious regressions. So, I'm not sure which version to work with, there're 2 ways:
Both ways are long and boring, but only no.2 is sustainable.
To xref other work:
What i was saying is that if you clone the repo and do the make like in your instructions it breaks. You get warnings (interpreted as errors) about implicit declarations for vPortMalloc etc. and you get an error about not being able to find dhcpserver.h.
If you fix the implicit declaration error by adding mem.h before your define, you then get errors about too few parameters. These are fixed if you use os_malloc instead of vPortMalloc because that expands and supplies values for the extra parameters, and the code is still the same.
If you go looking to fix the missing include, it is there in the tree but is not in the right place. Either it needs to be moved, or the reference in dhcpserver.c needs to be changed to suit.
If you are not expecting the current repo to build then that's fine, but right now it won't complete the build.
The one other thing I did in the makefile was to make it suitable for a non-standalone toolchain by putting in $(SDK_BASE) and pointing to my SDK. I figure it's easier to play with a modified libmain that way while keeping your toolchain operational
@pfalcon have you seen the latest lwIP related commits in ESP_NONOS_SDK from Espressif? Does this start to make life easier for us?
BTW I am trying to get some code out right now but as soon as I am done I'll be jumping into the lwIP2 stuff d-a-v has been working on - this is really good.
@davydnorris: I didn't, I'm still in "reduced performance" mode. If you have any specific links, those would be welcome.
https://github.com/espressif/ESP8266_NONOS_SDK/commit/cf83aba8a5f0a44ce39acb8642904f1d52ce876b
I don't ever remember lwIP source being a part of the SDK, and now it's also in a third party folder of its own with separate build instructions. Is this just what we already know or does this give us some more hints?
There is https://github.com/espressif/esp-lwip now with lwip 2.1.2. I am wondering what I should use ......
Maybe you should try @someburner 's fork https://github.com/someburner/esp-open-sdk/tree/sdk2-lwip212 and report here ?
note: lwIP-2.x is not usable with nonos-sdk firmware (any version) without an adaptation layer so espressif lwIP-2.x is not for us (but for esp8266-rtos-sdk or more generally their IDF subsystem)
https://github.com/kadamski/esp-lwip existed for a long time, but had following issues:
That's why I went for partial solution of https://github.com/pfalcon/esp-open-lwip/ , though rebasing onto upstream was always the goal.
I finally went for that, making followed steps:
Results of this work:
The plan remains to use @kadamski's work, but with my extracted patchset around to investigate any issues.