Altirra + DragonCard + Contiki WebServer = No connectivity...

[PeBe]

Hello.

 

Has anyone perhaps managed the above connection, i.e., from a local computer, successful connection to the http server (from Contiki) on the Altirra emulator?

 

Is this even possible?

Will running Altirra (with the above configuration) under Linux work at all?

Does the system need to be specially prepared somehow?

 

I would appreciate any information on the above questions

 

 

[phaeron]

Yes, it is possible, though it takes some setup:

The main issue is that Altirra's Dragon Cart emulation is NATed, due to limitations of sockets. This means you cannot externally connect directly to the emulated server because the emulated network isn't publicly accessible, since it's not a real network. This is the same as if you tried to connect to a machine on your home network from the outside without opening a forwarding port on the router. The emulator does provide for one forwarding port in the DragonCart config:

 

 

As with a standard NAT network setup, the emulation network must not have the same network address as the actual network.

 

With regard to Linux, I can't say whether this works with WINE as I haven't tested it, though it should be pretty standard sockets networking. The listening socket from the emulator with netstat if it is set up correctly. You will need to ensure that the host firewall allows incoming connections on that port if connecting from another computer.

 

Ironically, one advantage of working on Linux is that it is easier to set up VXLAN tunneling to actually put the emulation on a different IP address on the host network. This removes the need for port forwarding and a separate network address as there is no NAT. Recommendations for setting up the VXLAN tunnel are in the help file, though YMMV whether they work on your version of Linux (the instructions are years old at this point). However, I don't actually recommend using VXLAN tunneling because of the amount of random traffic on modern networks -- it is easy for the Contiki network stack to get overloaded with the amount of random broadcast traffic sent by modern computers, unless you filter the traffic going to the VXLAN tunnel.

 

[PeBe]

Hey @phaeron

 

Thanks for the rather detailed answer.
 

I tried to set everything up according to your instructions, however, I still have no connection.

Netstat under Wine shows nothing to indicate listening on port 80.

From the Linux console it is also silent  Despite open port 80 in the firewall.

 

I get the impression that something is wrong at the Wine level and unfortunately, my knowledge doesn't go that far anymore

 

Shame. Because I would have played more in-depth with Contiki, because it's a cool package.

 

Edited May 27, 2023 by PeBe

[phaeron]

Oh, I might know what's going on. IIRC, on Linux binding to a port below 1024 requires special permissions, so Altirra is probably getting an error trying to bind to port 80.

 

Try setting the emulator to forward port 8000 or another similar port instead of 80, and see if it shows up as a TCP listening port on netstat. It won't work this way because HTTPD isn't listening on port 8000 on the emulation side, but if that does show up in netstat then either you can run Altirra with the needed capabilities (root or cap equivalent needed to bind <1024), or reconfigure HTTPD in the emulation to use port 8000.

 

[PeBe]

I recompiled httpd with port 8080, redirected port 8080 and it took off.

 

Brilliant  

 

Edited May 27, 2023 by PeBe
translate

[PeBe]

Interesting, because netstat (under wine) does not show listening on port 8080, but from under the console it does.

 

Of course, it was launched from the level of a regular user.

Earlier I found a tip on the WINEHQ site about sending/receiving raw IP packets from under Wine.

 

 

sudo dpkg-reconfigure wine-staging-amd64 wine-staging wine-staging-i386.

 

It is not (according to WINEHQ's indications) the safest solution, as it allows too much.

I also don't know how much applying it improved the whole thing.

 

In any case, it works.

 

Edited May 27, 2023 by PeBe

[PeBe]

And I was already jumping for joy, and here such an unusual occurrence.

 

In Contiki, the number of simultaneous connections can be set during compilation. By default it is set to 8, but for the http server it has 4 connections set.

The problem is that, once I connect to the server, i.e. it downloads the files: index.htm, contiki.gif, background.gif; reopening the page, is no longer possible, ie.

The server sends index.htm, then returns the error "tcp: found no unused connections." and nothing else.

After exiting httpd and restarting, you can open the site again, under the same conditions.

 

Why did I mention the number of simultaneous connections? When it translates into the number of files sent from the server. 4 connections = 4 files sent. I will change to 8 simultaneous connections, I will get 8 files sent.

 

It looks as if Contiki is not closing connections in the emulated environment, or something somewhere along the way is unresolved. I can't explain it.

On live hardware (see Pinocchio server) everything works - it's exactly the same httpd compilation. And this is (to me) strongly puzzling.

 

Any idea what could be wrong? DragonCart support from Altirra? Only, I don't see (in the code) any link "closing socket<->DragonCard device".

 

@phaeron Is it like this at your place too?

 

 

Edited May 28, 2023 by PeBe
translate

[phaeron]

I can reproduce this, it's an issue with the emulator's network traffic. In order to translate the network connection the emulator needs an entire TCP stack to interpret the packets being sent from the DragonCart. Unfortunately there seems to be an issue where if the close is initiated from the native side, the native socket is closed but a FIN packet never gets sent back to the emulation side because the emulator drops the NAT connection too early. This causes connections to get stuck in the Contiki TCP stack. This wasn't a problem for outgoing connections because in that case the emulation side initiates the close and closes its connection entry itself. I have some ideas on fixing this but it will require rewriting some of the code to allow for the socket to properly linger in FIN_WAIT_1 state.

 

[PeBe]

In that case, I'm left waiting for an update
 

Thank you for taking the time to troubleshoot, especially since I realize that using DragonCart in an emulator is a niche solution.