WSL: Problem to connect to REST API of Frappeframework/ERPNext

Peer · October 3, 2024, 6:23pm

Finally I kind of solved a longstanding problem with connecting to the REST API of Frappeframework/ERPNext instances via Python3 code.

Problem: I simply couldn’t connect. Tried every solution in the book (documentation). I find the documentation lacking, so I tried many, many, many, many, many permutations of parameters. Nothing worked.
Not even frappe-client.
But I could easily and perfectly get the expected responses using a browser, sending GET requests to the relevant instance in the LAN.

Yesterday I found the reason:
I was working on the connection code in Ubuntu hosted in WSL (Windows Subsystem for Linux) on a current Windows 11 Laptop.
The WSL on the Windows host doesn’t let the connections from my python code on Ubuntu inside WSL through to ports other than 80 (http) and 443 (https) – maybe more – of machines in the LAN, but the LAN instance(s) were on port 8000 and 8080. These were blocked somewhere between my code and the instance on the LAN.

Once I suspected a network problem (this took me a far too long time, because the network works fine for many things, so it was kind of out of my debugging range), a quick check with nc (netcat) confirmed the problem literally in a minute.

The confirmation test was easy: I just ran the code on the Windows host instead of on the Ubuntu from inside the WSL => It directly and immediately worked.
Ah, and the browser was not in WSL but on the Windows host. Once you understand the problem, it makes sense that it worked from the browser.

Maybe (probably) there is a network or firewall setting for the WSL (v2) VM or the Windows host itself. I didn’t find it for now (hints welcome), but wasn’t essential in my current projects, because I can switch to development on another host or even the Windows host.

This thing annoyed me for months, though, and hindered my progress in implementation work and building of implementation tools. I had many other aspects of framework and implementation to work on, so it wasn’t a killer, but I finally I really got enough of it and pushed far enough through the barrier to get past it.

So, be advised that Linux und WSL is not like a bare metal host with Linux.
There are additional network quirks you should suspect if something unexpectedly does not work involving a network connection.

Best, good luck, and have fun building useful stuff!

avc · October 4, 2024, 1:46am

Hi @Peer:

You are not alone WSL2 works slightly different than WSL1, first time I faced this I’ve finally switch from WSL2 to WSL1 but … check this:

github.com/microsoft/WSL

Server running in WSL can only be accessed on version 1, version 2 blocks most of the port

opened 10:52AM - 17 Dec 21 UTC

closed 11:28PM - 22 Dec 21 UTC

maifeeulasad

bydesign

### Version Microsoft Windows [Version 10.0.19044.1415] ### WSL Version - [X]… WSL 2 - [X] WSL 1 ### Kernel Version 5.10.60.1 ### Distro Version Ubuntu-20.04 + Ubuntu-18.04 ### Other Software Docker Desktop 4.3.1 (72247) ### Repro Steps - Create an empty Django project - Copy it inside WSL instance folder, mounted under network - Try to access from a browser in Windows, from outside the WSL distro instance ### Expected Behavior Should be able to access it. But in `WSL2` it can't access, but in `WSL1` it can access these ports. ### Actual Behavior Needed to downgrade to `WSL1`, to access those ports. But some ports were working. This was kind of creepy. And I created another react project, which was able to call those APIs on the backend. So my server is up running. So WSL2 is blocking some ports, when it is being accessed outside WSL VM. ### Diagnostic Logs _No response_

Peer · October 5, 2024, 4:05pm

Thank you very much @avc for this link. It got me thinking in several ways.

Only, the problem they describe is the other way round – at least at first glance.

My script trying to connect to the ERPNext REST API is sitting inside the WSL.
The ERPNext instance is in the LAN.
So I’m trying to get out of, not into the WSL.

But looking closer, I’m not sure yet where exactly the access is blocked.
As the VM having the ERPNext instance I’m trying to connect to is sitting on an AD Server, it might well be a similar situation.
That thingy is managed by an external entity. So my information is limited ATM.
I guess I’ll find out in time.
So far I have my workarounds.

One thing I didn’t mention above which I found out I don’t remember how (probably a faint memory of an RFC I read many years ago, popping up in my mind), being rather strange:
If I put a dot at the end (right side) of the LAN’s host’s name, it does work.
Spelled out (with privatized host name / it’s a one-word hostname without dots, which otherwise works correctly in the LAN):

If I try to connect to:

http://erphost:8000/api/resource/doctype

it won’t work. But connecting to (note the additional “.” dot at the end of hostname):

http://erphost.:8000/api/resource/doctype

does work!

So it might well be linked to some kind of DNS (mis-?)configuration somewhere in the “traceroute”.

So, network configurations need knowledge and close attention in their own right, as they can be rather tricky and unexpected at times.
Lots of RFCs to have a minimum of an idea of…