DHCP server error when soft-AP client connects with recompiled liblwip.a

[luisfer.rigoni]

After cloning RTOS repository (tag v1.4.0, commit efd2819) and recompiling liblwip.a, then always a soft-AP client connects causes following exception.
I use sample code provided in viewtopic.php?f=31&t=227.

Code: Select all

SDK version:1.4.0(c599790)
mode : softAP(5e:cf:7f:12:2e:cf)
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
add if1
bcn 100
add 1
aid 1
station: 0c:e7:25:d8:38:60 join, AID = 1
Fatal exception (3):
epc1=0x4024f233
epc2=0x00000000
epc3=0x40105af3
epcvaddr=0x4024d92c
depc=0x00000000
tn_add=0x4024f230
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 26044, room 16
tail 12
chksum 0xe6
ho 0 tail 12 room 4
load 0x3ffe8000, len 2128, room 12
tail 4
chksum 0xab
load 0x3ffe8850, len 1408, room 4
tail 12
chksum 0x8a
csum 0x8a

The eagle.S excerpt pointed by epc1 shows:

Code: Select all

4024f230:       ffd821          l32r    a2, 4024f190 <dhcp_start+0xc8>
4024f233:       000232          l8ui    a3, a2, 0
4024f236:       010242          l8ui    a4, a2, 1

If disabling DHCP with wifi_softap_dhcps_stop(); at the end of user_init(), the module don't crashes.

I compile liblwip with

Code: Select all

cd third_party/
./make_lib.sh lwip

I compile my source with

Code: Select all

make BOOT=none APP=0 SPI_SPEED=40 SPI_MODE=QIO SPI_SIZE_MAP=2

I flash module with

Code: Select all

esptool.py --port /dev/ttyUSB0 write_flash 0x00000 eagle.flash.bin 0x20000 eagle.irom0text.bin 0xFE000 blank.bin

My module is ESP-07 with 8MBits =1MBytes
PS: Using liblwip binary provided in lib folder, there's no runtime problem

[osteinjr]

Hi Luis,

I have the same problem using the ESP-01 (512Bytes and 1MBytes). If I compiled LWIP provide in SDK source code with my code, when my device try to connect with ESP occours a Fatal exception (3). I compiled too, using the VirtualBox image provided by Espressif to isolate the environment problem and the problem also happens. Very frustrating .

[osteinjr]

Hi Luis,

To fix DHCP server, you need to remove ICACHE_RODATA_ATTR from dhcpserver to magic_cookie.

Best regards
Orlando

index f483b64..d1dbba2 100644
--- a/third_party/lwip/core/dhcpserver.c
+++ b/third_party/lwip/core/dhcpserver.c
@@ -14,7 +14,7 @@
////////////////////////////////////////////////////////////////////////////////////
//static const uint8_t xid[4] = {0xad, 0xde, 0x12, 0x23};
//static u8_t old_xid[4] = {0};
-static const u32_t magic_cookie ICACHE_RODATA_ATTR STORE_ATTR = 0x63538263;
+static const u32_t magic_cookie STORE_ATTR = 0x63538263;
static struct udp_pcb *pcb_dhcps = NULL;
static struct ip_addr broadcast_dhcps;
static struct ip_addr server_address;

[luisfer.rigoni]

Hi Orlando,

Thanks for your response. It actually worked!!!

Do you know what means ICACHE_RODATA_ATTR?
There's a way to disable it globally?

[vinicius.vbf]

Thank you all! Just had the exactly same problem. Quick question: why were you recompiling lwip? My reason is because I was having some issues with multicasting, but just found out that the real problem was I was not zeroing the sockaddr_in structure before setting the correct values. Go figure. Some garbage data cost me a few hours.

[luisfer.rigoni]

Hi Vinicius,

We were recompiling lwip to enable PPPoS and IP Forwarding to create (not accomplished yet...) a transparent bridge network topology proposed in viewtopic.php?f=65&t=1981

[solomonC]

Thanks a lot man! Solved my problem! I don't know what long road I would've had to take if I hadn't found this answer! I couldn't have debugged this with my present level of expertise.