Strange error with cookies (to the same domain) accesed through the same router

[Lisandro]

I'm having this strange problem, and I would like to know if it is a web2py bug or is something that I'm missing.

My web2py app is accesed through a domain, and in the model file, I connect to the db and to the session like this:

db = DAL('postgres:.....', migrate=False, lazy_tables=True)
session.connect(request, response, db=db, masterapp='myapp')

It's a bit difficult to explain the problem, so here are the steps to reproduce it:

1. From a mobile device using Chrome or Firefox, open this website http://nachoesbo.com (this will ejecute the /default/index).
   
   
2. Browse the web nachoesbo.com for a few seconds.
   
   
3. Try to access the same web through Chrome or Firefox in a desktop pc using the same internet connection.
   In this point, the browser will stay "connecting" to domain, and it will hang until timeout.
   This situation will stay this way until you close the mobile browser (or after a few minutes).
   
   

I'm really pulling my hair off with this. 

I'm experiencing the same problem with all of my web2py applications.

The same problem occurs using a different router and a different ISP.

I've checked the cookies and there is nothing odd. I don't store anything in the cookie, it's just the default behaviour. 

What could I be missing?

[Anthony]

I'm not sure what the actual problem is, but what leads you to believe it has anything to do with cookies?

[Lisandro]

Anthony, my first thought was about the cookies session, but I was wrong. 

I've just tried disabling cookies in all of my browsers (mobile and desktop), but the problem remains.

I've been doing some more tests, and I think the problem isn't web2py related, but more network related.

Some points that I should mention:

• The problem is the same with all the websites I have running in my server
• The problem is reproducible using any router or ISP.
• All of my websites are served through domains, and all the domains are pointed to the same server, with a unique IP address.

I think the problem may be related to a missconfiguration of the server provider (I'm using Linode).

I've just contacted them with the problem, I will be back here when I receive their answer.

[Lisandro]

Hi there, 

I'm back just to inform that we haven't found the cause of the problem yet, but we've been doing a lot of tests (with Linode support guys, and with a couple of nginx professionals hired in upwork). The problem still remains, but we have concluded that it's not related to web2py or sessions. Also, the problem is not related to nginx webserver configuration. And also the problem is not related to firewall or network configuration.

A really weird problem in deed. The problem is only reproducible with ISPs from Argentina (so far). Using the same internet connection, two or more desktops can browse our domains (all pointed to the same IP address). However, when a mobile browser uses that same internet connection to access any of our domains, then the desktops hang "connection", and they hang until timeout. But mobile keeps browsing without any problem.

With all the tests we run we have concluded that, in those cases, the request never even reaches the server, so the problem has something to do with the network between the customer and our server. Really weird.

Well, I just wanted to tell you, and let clear that web2py isn't the cause of the problem. I hope to find it soon!

Sorry to bother.

Thanks for your time.

Regards, Lisandro.

[Massimo Di Pierro]

Thanks for letting us know. Keep us posted if you find the problem since it may affect others.

[c...@cemeren.com]

Really weird. I have reproduced the problem from Turkey too. I am no network expert but they would better check security / firewall software running at any tier if applicable. Good luck.

[Lisandro]

I've solved the problem! And it feels really nice :)

As I previously said, web2py hadn't anything to do with this issue, but I still wanted to come back here and post the solution: the problem was a misconfiguration in /etc/sysctl.conf regarding tcp. The following configuration parameters where set to 1 (true) but I had to set them to 0 (false):

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_window_scaling = 0

net.ipv4.tcp_tw_recycle = 0

net.ipv4.tcp_tw_reuse = 0

I'm not a network expert, so I don't have a full understanding about that parameters. 

This was the post that lead me to the solution:

http://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet

Thanks for your time!

Regards, 

Lisandro.