IPTables is a firewall. It could certainly cause the problems. It could well be blocking things before your other firewalls get to see them.
As for WiFi it would have a different address from any wired interface, typically permissions on the firewalls would be different for each.
The other problem is that IPTables has different settings for “Current” config and after a reboot config. so you can change settings here and now and they will be forgotten after a reboot. Or, you can change settings that become effective after a reboot. I think you have used the non-persistent version and then rebooted, defaulting back to standard.
Issue your commands again and don’t reboot the Pi. Does it then work?
By the way, has anyone, time/opportunity to check what appears in a Wireshark capture (with host set to the computer running the IDE) when choosing “Run remotely…” ?
Done. Same problem/message
Input and Output?
Yes
And this is what appears in Wireshark when I run the test program sending ‘Hello’ over UDP then TCP from the Mac to the receiving test program on the raspberry, using port 44553 (the Mac is 192.168.1.7 and the raspberry is 192.168.1.191):
Nothing appears in Wireshark when I launch ‘run remotely…’
That list is cutoff. You can copy and paste the text rather than take a picture?
Then do:
sudo iptables -F
If you run the following:
sudo iptables -L -nv
It should look like this, if iptables is disabled:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
If it doesn’t look like that then try:
iptables -F
iptables -L -nv
Which should look like the above.
Results of -L after executing the two commands updating the policy :
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all – anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all – anywhere anywhere
ACCEPT all – anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all – anywhere anywhere
ACCEPT all – anywhere anywhere
ACCEPT all – anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
ACCEPT tcp – anywhere 172.17.0.2 tcp dpt:9000
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all – anywhere anywhere
RETURN all – anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all – anywhere anywhere
RETURN all – anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all – anywhere anywhere
Results of iptables -L -nv
Chain INPUT (policy ACCEPT 2627 packets, 2693K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 1869 packets, 266K bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION-STAGE-1 (0 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION-STAGE-2 (0 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-USER (0 references)
pkts bytes target prot opt in out source destination
===
And on the Mac:
and now try the remote debugger. Open the stub, with it running go to the mac and attempt to start a session. Make sure the ip address and port matches what the stub says.
Both the Mac and Pi should have a shared network, or there should be some sort of router that can route the traffic from one network to the other.
This is exactly what I did and the same message. And no message from LittleSnitch saying that I try to connect to 192.168.1.191 (the raspberry)
I will try tomorrow with a wired connection, maybe Xojo has a problem initializing the connection. It’s past midnight here :). Thanks for helping until this point. I come back with results of that test.
Same here. It sounds like you have the wrong IP for the Pi. ifconfig should list the connected ip addresses.
good night.
Hi. So I did the following:
1/ Use a wired ethernet connection from the Mac (it is named ‘en0’) to the closest router (needed some convincing to overcome the WAF limitations 
)
2/ Switch off wifi on the Mac, and test we have a working network connection
3/ Start Xojo and check the configuration defined for remote debugging
4/ run remotely …
5/ The raspberry is ‘off’ but I see in Wireshark an outgoing request from the Mac attempting to reach 192.168.1.191 (the IP address of the raspberry), the request failed since nobody was answering and I got a message from Xojo ‘failed to connect properly’ Remember that yesterday the Mac did NOT attempt any connection to that address when doing ‘run remotely…’ (hence my conclusion that the problem was on the mac side) and the message was not the same.
6/ abort the run and quit xojo
7/ start the raspberry, it is connected to the network via wifi
In case you ask, both the Mac and the raspberry are on the same 192.168.1.xxx
8/ start xojo and attempt a ‘run remotely’
9/ Working 
10/ quit xojo
11/ re-enable wifi on the Mac
12/ start Xojo, make sure run remotely uses the IP address of the ethernet adapter, run remotely: Working
12/ quit xojo
13/ Disconnect the ethernet cable
14/ reboot the mac and the raspberry
15/ now, we are using only wifi, since the ethernet cable is disconnected and Wifi is enabled
16/ start Xojo, make sure run remotely uses the IP address of the wifi adapter, run remotely: Working
My conclusions:
a/ the IP address given in the remote debug config for the raspberry is correct
b/ the connection between the Mac and the remote debug stub work
c/ maybe macos saves something about en0 (the adapteur for ethernet connection) as soon as it is used once. The ethernet connection was never used on the Mac.
d/ Xojo (at least my version) has a problem to launch a remote debugging session when it only has a wifi connection available and the ethernet connection was never used.
Voilà …
Thanks a lot to all the people helping me yesterday. Special thanks to Ian Kennedy who patiently helped me checking the Firewall config on the raspberry and TimStreater who gave me the hint about using an ethernet connection.
Extra!
You’re very welcome.
I just installed Xojo 2024 4.1, and the problem is back. I connected the Ethernet adapter as I did yesterday. In ‘Remote run setup’, I kept the IP of the Wifi adapter. So, the ethernet adapter is connected but not used for remote debugging. Working. Shutdown Xojo, disconnect Ethernet and start again. And everything still works. So, maybe, at the end, it is an issue with Xojo remote debugging.
Created issue xojoinc/xojo#78085
I find the Remote Debug UI confusing - you must take several steps to get it to work, and the UI lets you easily pick a configuration that won’t work…
Xojo / Settings / Debugging
UI/UX Problem A: having a machine selected here in step 2 does NOT actually select that machine for remote debugging. You must also do Step 3:
Xojo / Project / Run Remotely menu
3. Here, you must select the machine you want to remote debug to:
UI/UX Problem B: Until you do this step, hitting the keyboard shortcut (Command Option R) will try to remote debug on whatever machine was last selected, which may be incorrect.
UI/UX Problem C: on this menu, you can also choose any of the remote machines, even ones that are on a different network. In other words, it’s quite easy to have a mismatch between the Network Interface selected in Step 1 and the Remote Debug Host selected in Step 3. Xojo does nothing to help you avoid this problem.
A million Seven year sago, I suggested a feature request to make this better:
https://tracker.xojo.com/xojoinc/xojo/-/issues/46893
You have to allow this for remote debugging across networks connected by routers. It’s very helpful for instance if you’re debugging over a VPN and Xojo was just fast enough to do that 15 years ago.
That’s a good point - it’s not always possible to know which network interface can reach which address range.
Why it matters: if misconfigured, and you try to run remotely, the IDE Locks up for 60 (120?) seconds beach balling.
It would be nice if the IDE did some discovery for you (sending a UDP packet or something in the background) so that you wouldn’t have that minute+ long timeout on failure.
