ESP8266 Community Forum

Follow Up:

I managed to get the 0.9.6b1 to run. After the following init-squence I connect to the SSID an start to ping the IP:

--------- snip ---------

AT+RST

OK

ets Jan 8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x40100000, len 1320, room 16
tail 8
chksum 0xb8
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0xd9
load 0x3ffe8308, len 412, room 0
tail 12
chksum 0xb9
csum 0xb9

2nd boot version : 1.3(b3)
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 4Mbit
jump to run user1

rl
ready
AT+GMR
AT version:0.22.b1.0
SDK version:0.9.6(b1)

OK
AT+CIFSR
+CIFSR:STAIP,"192.168.131.150"
+CIFSR:STAMAC,"18:fe:34:9b:c6:85"

OK
--------- snip ---------

Ping stops after 8 replys:

$ ping 192.168.131.150
PING 192.168.131.150 (192.168.131.150) 56(84) bytes of data.
64 bytes from 192.168.131.150: icmp_seq=1 ttl=255 time=94.5 ms
64 bytes from 192.168.131.150: icmp_seq=2 ttl=255 time=9.23 ms
64 bytes from 192.168.131.150: icmp_seq=3 ttl=255 time=235 ms
64 bytes from 192.168.131.150: icmp_seq=4 ttl=255 time=165 ms
64 bytes from 192.168.131.150: icmp_seq=5 ttl=255 time=79.5 ms
64 bytes from 192.168.131.150: icmp_seq=6 ttl=255 time=9.36 ms
64 bytes from 192.168.131.150: icmp_seq=7 ttl=255 time=3.24 ms
64 bytes from 192.168.131.150: icmp_seq=8 ttl=255 time=1.77 ms
^C
--- 192.168.131.150 ping statistics ---
85 packets transmitted, 8 received, 90% packet loss, time 84619ms
rtt min/avg/max/mdev = 1.777/74.842/235.841/81.815 ms

But the module still accept AT commands and creates output. Using tcpdump I can see that there is still ARP and that ICMP requests are still send to the module:

$ sudo tcpdump -n -i eth0 host 192.168.131.150
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:59:03.446097 ARP, Request who-has 192.168.131.150 tell 192.168.131.146, length 28
22:59:03.530895 ARP, Reply 192.168.131.150 is-at 18:fe:34:9b:c6:85, length 46
22:59:03.530917 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 1, length 64
22:59:04.452917 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 2, length 64
22:59:05.460772 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 3, length 64
22:59:06.468832 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 4, length 64
22:59:07.476824 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 5, length 64
22:59:08.484839 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 6, length 64
22:59:09.492855 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 7, length 64
22:59:10.500857 IP 192.168.131.146 > 192.168.131.150: ICMP echo request, id 16356, seq 8, length 64

It seems like the module also can not ping a target on the network

AT+PING="192.168.131.1"
+timeout

After resetting the module the whole thing starts over again.

If I choose mode 3 (combined STA + SOFTAP) the problem does not occur:

AT+CWMODE=3

OK
AT+CIFSR
+CIFSR:APIP,"192.168.4.1"
+CIFSR:APMAC,"1a:fe:34:9b:c6:85"
+CIFSR:STAIP,"192.168.131.150"
+CIFSR:STAMAC,"18:fe:34:9b:c6:85"

OK

I could ping for more then 1 hour without any packetloss

[....]
64 bytes from 192.168.131.150: icmp_seq=5209 ttl=255 time=2.93 ms
64 bytes from 192.168.131.150: icmp_seq=5210 ttl=255 time=4.89 ms
64 bytes from 192.168.131.150: icmp_seq=5211 ttl=255 time=6.06 ms
^C
--- 192.168.131.150 ping statistics ---
5211 packets transmitted, 5211 received, 0% packet loss, time 5217795ms
rtt min/avg/max/mdev = 1.144/4.808/45.738/2.141 ms

But this can only be a workaround as I don't want each module to also span up an own network

I am watching this post as I too have the same problem but with 2, esp-12's whilst I don't have a problem with 2, esp-01's
I now realize why the esp-01's never loose a connection (months) I had these modules first and programmed them with mode 3 (combined STA + SOFTAP) not really knowing what I was doing, were as the esp-12s are on mode 1 Station so what impact will having them all on mode 3 because in reality I still don't know what I am doing hahahahh.

If you have STA+SOFTAP and you don't set any other parameter the module will open an unprotected (passwordless) WLAN with SSID called e.g. "ESP<something>". Mine also provides DHCP in this SSID and so anybody can connect to that WLAN, get an IP and can connect your module's services. There seems no possibility to forward packets between the STA SSID and the SOFTAP SSID but it is nevertheless a security issue. In my opinion you should at least configure the SOFTAP mode to use a known SSID and require a pasword for this network.

It would be very nice to have the STA-only mode working stable. If there is any information I can provide to help tracking that issue down, just drop a line.