Can't open VDE2 ctl socket on Android/Termux

[puddles123fluffy]

Hello all,

After building the MicroVAX 3900 simulator with VDE2 support on Android/Termux attempting to at xq0 vde:switch0 gives these errors:

Eth: wlan0: SIOCETHTOOL(ETHTOOL_GLINK) ioctl failed: Permission denied
Eth: pcap_findalldevs warning: wlan0: SIOCETHTOOL(ETHTOOL_GLINK) ioctl failed: Permission denied
Eth: wlan0: SIOCETHTOOL(ETHTOOL_GLINK) ioctl failed: Permission denied
Eth: pcap_findalldevs warning: wlan0: SIOCETHTOOL(ETHTOOL_GLINK) ioctl failed: Permission denied
%SIM-ERROR: Eth: open error - Permission denied

I also tried connecting to a test socket created by socat, that failed the same way. I was able to use socat to connect to the ctl socket created by vde_switch, so it seems the problem is with Open SIMH.

Thank you!

[markpizz]

What is the output of the "SHOW ETHERNET" command on the simulator you are running?

[markpizz]

Also. Please provide the output of the "SHOW VERSION" command.

[puddles123fluffy]

Hello,

Here is the output of:

SHOW ETHERNET:

Eth: wlan0: SIOCETHTOOL(ETHTOOL_GLINK) ioctl failed: Permission denied
Eth: pcap_findalldevs warning: wlan0: SIOCETHTOOL(ETHTOOL_GLINK) ioctl failed: Permission denied
ETH devices:
 eth0   vde:device{:switch-port-number}      (Integrated VDE support)
 eth1   nat:{optional-nat-parameters}        (Integrated NAT (SLiRP) support)
 eth2   udp:sourceport:remotehost:remoteport (Integrated UDP bridge support)

and
SHOW VERSION:

MicroVAX 3900 simulator Open SIMH V4.1-0 Current
    Simulator Framework Capabilities:
        64b data
        64b addresses
        Threaded Ethernet Packet transports:PCAP:VDE:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        RAW disk and CD/DVD ROM support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 12
    Host Platform:
        Compiler: GCC Clang 21.1.8
        Simulator Compiled as C (Release Build) on Apr 20 2026 at 20:46:39
        Build Tool: CMake (Unix Makefiles)
        Memory Access: Little Endian
        Memory Pointer Size: 64 bits
        Large File (>2GB) support
        SDL Video support: No Video Support
        No RegEx support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 1ms
        Ethernet packet info: libpcap version 1.10.5 (with TPACKET_V3)
        OS: Linux localhost 6.1.93-android14-11 #1 SMP PREEMPT Fri Mar 21 02:07:05 UTC 2025 aarch64 Android
        Processor Name: Cortex-A55
        tar tool: tar (GNU tar) 1.35
        curl tool: curl 8.19.0 (aarch64-unknown-linux-android) libcurl/8.19.0 OpenSSL/3.6.2 zlib/1.3.2 libssh2/1.11.1 nghttp2/1.68.1 ngtcp2/1.22.1 nghttp3/1.15.0
        git commit id: 7994e0a7+uncommitted-changes
        git commit time: 2026-01-08 13:05:22+01:00

[markpizz]

I don't really have anything good to help you, but it would be interesting to know what phone, tablet or other box you're running under?

Also, please say if you've rooted the device to get there.

If you've capable of running as root, the pcap and vde might work, otherwise, I'd be surprised if you can get anywhere with either.

Without root, maybe udp transport might work, but I'd think that the internal firewall would probably get in the way of arbitrary incoming udp traffic. If you can do udp bidirectionally, maybe another system on the LAN could be configured with a useful bridge (translating UDP frames to ethernet...).

Otherwise Android isn't going to be an general purpose as running on a Raspberry Pi, Other Linux, Mac, or Windows system.

I would guess that, when using NAT you could make outbound connections from a simulator to the LAN or beyond, but I'd again think that the Android firewall wouldn't let incoming traffic to reach a simulator...

[puddles123fluffy]

Hello,

I don't have root on my phone.
The SLiRP works fine, I can even do XDMCP to a NetBSD/vax from other hosts on my Wi-Fi. That requires 2 ports, one forwarded in through SIMH's NAT and it works.
Now I'd like to have multiple instances of SIMH networked together, which requires VDE2.

I did some more debugging with socat. I captured and replayed the message SIMH sends to VDE and VDE responded correctly, same as it did for other VDE clients. It seems that there is a logic error in sim_ether.c.

Thank you.

[markpizz]

I did some more debugging with socat. I captured and replayed the message SIMH sends to VDE and VDE responded correctly, same as it did for other VDE clients. It seems that there is a logic error in sim_ether.c.

It would seem that for VDE to deliver raw frames to your WiFi LAN, something in VDE beyond the simh simulator (deep within the VDE functionality) would have to be sending raw ethernet frames. I'll be surprised that would be possible, but since you're convinced, please propose a VDE related fix.

[puddles123fluffy]

Hello,

I'm very sorry if I've bothered you, but I must clarify:

VDE has its own SLiRP plugin. That part is working fine. The goal is not raw frames, but IP through NAT (VDE's SLiRP) and between simulators (within VDE).

SIMH is creating the VDE "port" socket, opening the VDE control socket, telling VDE where the "port" socket is, then suddenly giving up. Looking at sim_ether.c, it seems the VDE logic is falling through into the code for opening a real ethernet adapter, which fails and causes the whole thing to give up.

Sorry again for the bother, but I am not familiar with SIMH's code.

[markpizz]

No bother at all. I've never personally used the VDE code. VDE was the first non pcap network methodology added to sim_ether a very long time ago (2011). I don't know anything about the VDE plumbing, I was under the impression that to get some of the more complicated VDE behaviors (or maybe even the basics) there would have to be some sort of background process to coordinate things.

I'll be glad to be wrong. If you can get VDE working in a useful way, like I said, please propose a fix.

[puddles123fluffy]

Hello,

I was wrong, it was not a "logic error", it was an incorrect function call to vde_open().

Replacing the pointer to the VDE options struct &voa with NULL got it to connect.

According to this man page, the options struct is deprecated, replaced by a new vde:// URL scheme. A permanent fix would pass the whole string, including "vde:" to vde_open and completely remove the voa struct.

Thank you again for your work maintaining SIMH. I will leave the issue open since I can not write the fix myself at this time.

[markpizz]

If you make the adjustment you describe, what functionality can you achieve?

1. multiple simh simulators (with an OS that has an IP stack) that can talk to:
   • Systems on your LAN?
   • To/From The host system?
   • Another simulator running concurrently in the same host system?
2. Can multiple simulators speak to each other using protocols other than IP?

Will you provide examples of vde: settings which are useful to achieve the above?

[puddles123fluffy]

Yes, here are the settings:

In vax.ini for each simulated VAX, I have attach xq0 vde:/data/data/com.termux/files/usr/tmp/switch0.
Before starting the simulators, I start the virtual switch with vde_switch -s /data/data/com.termux/files/usr/tmp/switch0.
Next, I start the NAT "router" using vde_plug /data/data/com.termux/files/usr/tmp/switch0 slirp:///verbose.
Now, any number of SIMH instances could be started and connected to the switch.

I have not yet tested DECnet, since I don't have much VMS experience.

After a fix, the setting could instead be attach xq0 vde://path/to/switch[virt. eth. port no.], as mentioned in the man pages linked above.

Potentially, all the networking in SIMH could be done through libvdeplug, which supports attaching to tap devices, SLiRP, ssh, vxlan, etc. This might have performance implications. A simpler suggestion is to bring the syntax of the other networking options in line with VDE, changing nat: to slirp://, etc., but keeping the current implementations.

Thank you again.

[markpizz]

First you say: In vax.ini for each simulated VAX, I have attach xq0 vde:/data/data/com.termux/files/usr/tmp/switch0.

Then you say: Now, any number of SIMH instances could be started and connected to the switch.

Can each of the SIMH instances use precisely the same attach string or would there need to something which designates each connecting to a different "port" port on the vde switch?

[puddles123fluffy]

Hello,

Sorry fot the late reply.

Yes, the same string can be used. vde_switch will automatically assign sequential ethernet port numbers if one is not specified. In fact, I had to remove the ability to specify the port for my temporary fix. If there ends up being a permanent fix, then the port would be specified in square brackets according to the vde:// url scheme from the manual above.

I have since tested DECnet as well. It works as expected, I can SET HOST from one node to another, but of course I could not access a DECnet host outside of the virtual ethernet. vde_plug has a TAP module as I mentioned above, so I expect it would be possible to interface with real hardware if I had root on my phone, which I don't.

Thank you.