Not working with DD-WRT Entware python3

[MatthewLundberg]

I'm trying to run the example program status.py. Within eternalegypt.LB2120.login(), self.websession.get() is called for index.html. This fails to return the proper text, and printing response.history shows that it is in a redirection loop. It's bouncing between
http://192.168.5.1/index.html and http://192.168.5.1/sess_cd_tmp?op=%2Findex%2Ehtml&oq= until the redirection limit is reached.

The responses from http://192.168.5.1/index.html send the cookie sessionId=unknown; path=/. The responses from http://192.168.5.1/sess_cd_tmp?op=%2Findex%2Ehtml&oq= send a cookie that looks like what we need (e.g. sessionId=00000005-Zni5gIGKv6EVmh99NmH2gYjnyMFDxZb; path=/).

Changing the CookieJar creation to specify unsafe=False in the example program (status.py) fixes that particular problem, in that the redirection chain is as expected, the text is returned, and the token is retrieved. However, then the post to Forms/config fails with a 400 error. (I tried changing the unsafe setting due to the lack of DNS for the device IP. It seems that this is why the setting is for unsafe=True, and that we need it here.) The text of the page is The request was invalid. which is what you get if you go to the login page in a browser, clear your cookies, then click the login button.

Let me know if there's anything I can do to help debug this situation. I'm not a web expert by any means.

The setup:

LB1120:
Firmware version: M18Q2_v12.09.163431
App Version: NTG9X07C_12.09.05.27
Web App Version: LBHDATA_03.03.103.165
Bootloader Version: Bootloader Ver: v1.0.0
Hardware Version: 08

DD-WRT:
Asus RT-AC68U
DD-WRT v3.0-r38507 std (01/29/19)
Linux 4.4.172 #4532 SMP Tue Jan 29 08:58:00 CET 2019 armv7l

Python:
Installed with Entware opkg
Python 3.7.1 (default, Dec 23 2018, 08:36:24)
eternalegypt installed with pip3

[amelchio]

I think this could be due to the issue fixed by aio-libs/aiohttp#3576.

[MatthewLundberg]

It sure looks related. I duplicated the problem on a Linux machine running Fedora 27 also, but don't have the details. I will check out the aio* software versions on both of these tonight.

[MatthewLundberg]

This is indeed the problem. I patched the file locally, and the example file now runs. I see that the fix is not released.

I'm not familiar enough with github to know how to mark the aiohttp#3576 as the cause of this problem, but I see that the aio code has not yet been released.

[amelchio]

You could add a "thumbs up" to aio-libs/aiohttp#3576 and maybe add a comment that the PR fixes your issue. That might help to get it integrated a bit faster.