ESP8266 Community Forum

- Wed Sep 27, 2017 5:10 pm #70378 @tele_player: I think I have stumbled on the area of the problem and it seems to be MTU size related. I modified the html size and found that when "size" as presented in the html header is 1458 it works, but it fails at 1468. I am assuming that at some point around 1460 the stack will need to break up the data into multiple packets which does not appear to be happening. I can PM you my outside address if you would be willing to hit my environment. That will help determine if it's mobile carrier related or connected to my firewall settings in some way. Your help is appreciated! EDIT: Can't find a way to send a PM(!) Please hit my esp with here:
testmyesp (dot) dynalias (dot) com : 8099

- Wed Sep 27, 2017 7:11 pm #70379 (Edit: this is about the code posted above)

That code works here, on WiFi and mobile.

But if your ESP is responding differently between WIFi and mobile, you should see a difference in the packet trace, other than just not seeing the data go out.

There is a bug somewhere, but it's still not clear if it is ESP or Verizon.

- Wed Sep 27, 2017 7:33 pm #70381

@tele_player: I think I have stumbled on the area of the problem and it seems to be MTU size related. I modified the html size and found that when "size" as presented in the html header is 1458 it works, but it fails at 1468. I am assuming that at some point around 1460 the stack will need to break up the data into multiple packets which does not appear to be happening. I can PM you my outside address if you would be willing to hit my environment. That will help determine if it's mobile carrier related or connected to my firewall settings in some way. Your help is appreciated! EDIT: Can't find a way to send a PM(!) Please hit my esp with here:
testmyesp (dot) dynalias (dot) com : 8099

It seems to work from here, using both WiFi via Comcast, and mobile via AT&T. Looks different on Safari, Chrome, Firefox... but it's getting here.

- Thu Sep 28, 2017 4:59 am #70392 @tele_player: This is very helpful. It seems that I can rule out my environment since its works for you over AT&T. Today at work I will try a few different carriers and see how they each do. It seems unlikely that VZW has a strict defect - I would conclude that, more likely, there are some assumptions being made between the ESP stack and the VZW stack that don't match up - therefore it may be correctable at the ESP end. Do you agree?

I note that when I do the ping (pre-fragmentation) test to determine optimal packet size using my environment as the target, over mobile data I have to drop down to the low 1300s to get a solid reply, whereas over broadband it's in the 1400s. I'd be interested in what you see on your end. I'll leave the ping enabled for now in case you are able to try that.

Regarding the packets: I have been studying the traces - I'm not sure what I'm looking for - I see all 3 packets apparently contiguous following the html header packet when it works, but only the header packet when it fails. Yesterday I was taking packets from my laptop test host - not from inside the network. It may have missed what the ESP tried to send. If you can help me decipher what is happening, I'll re-run the test using this test code and I'll take all data to/from the ESP. I would think that might at least surface some clues, if not expose the problem itself.

Again, many thanks. This appears to be progress!