ESP8266 Community Forum

- Thu Sep 28, 2017 9:02 am #70405 @tele_player: I tried mobile wireless on Sprint, VZW, and AT&T and all 3 failed with the current test code (packet size 1468). That's odd because it worked for you on AT&T. I have also attached clean packet traces (in zip file). In both cases I browsed to /inline first to confirm connection, and then "/". It's very clear when you compare the traces that over wifi the larger packet follows but not over mobile. I think in IP rules there are legal times to drop a packet - like when packet sizes break some boundary - so maybe that's what is happening but it sure seems like a solution may lie in the ESP stack somewhere... Please let me know what you think.

packets.zip

You do not have the required permissions to view the files attached to this post.

- Thu Sep 28, 2017 10:35 am #70416 I'm inclined to agree. If you google 'esp8266 MTU MSS' you'll find some discussions of bugs in how 8266 handles this stuff.

- Thu Sep 28, 2017 3:08 pm #70423 @tele_player: You seem to be very knowledgeable in this space. Does this get reported somehow? Or can I track down the errant code and try to correct it? Wondering where to go from here.

- Thu Sep 28, 2017 6:13 pm #70430 There's a sub-forum here for esp8266 Arduino bug reports, but this one might be tricky to replicate. If I'm reading the traces correctly, deeper digging into the lwip code is needed, to determine why the full HTTP reply is (apparently) not being sent. It's possible there are additional debug features that can be enabled, I haven't looked that deep.