Should uaenet.device work in AmiBerry 7 (Preview) on MacOS

[marjue12255]

Hello

I would like to get my emulated Amiga online but many progs do not work with the internal bsdsocket.library. So i decided to give the uaenet.device a chance together with RoadShow TCP. But when I start the uaenet via AddNetInterface always the same error is coming up:
uaenet.device Unit 0 could not be opened.

The device is loaded in the VM. The version command says that there ist version 1.2 of uaenet.device. Is uaenet.device functional in AmiBerry 7 (Preview)? If not I could stop wasting time in that :-)

Greetings
Marcus

[midwan]

I haven't really used it, so I'm not entirely sure.
I think it requires WinPCAP on WinUAE, which of course does not exist on other platforms.
Probably the best approach would be to find something that works on WinUAE, and test the exact same scenario on Amiberry. The code is identical in the relevant file (sana2.cpp), but maybe something else around it is missing.

[midwan]

I'm adding SLIRP support in a new commit, which might help. From what I see in the code, that seems to be used when enabling uaenet.device.

Don't have the time to test the results here for now, just making sure the build works.

[marjue12255]

Thanx for the reply. I will have an eye on it.

[giantclambake]

Just tested this, using the demo version of RoadShow TCP ...amiberry master, amd64 debian Bookworm ; ClassicWB v28 was the guest OS...

The Roadshow ManageNetInterface command successfully detected the uaenet.device, and added the required files into Devs:
After editing DEVS:NetInterfaces/uaenet and providing 'sensible' IP/netmask/default route (to gel with my host LAN setup), the command AddNetInterface uaenet completed successfully....read: attached the tcp/ip stack, to the uaenet.device

However, no packets are detected by wireshark, running on the host -- in the emulation, guest apps like aweb, amirc, etc, complain about no hostname resolution -- in the CLI, you can't even ping yourself 8)

Scarily, it reminds me of the 1990's (dialup ISP days in AU), when you'd have a NIC fail, stop the machine, replace NIC and restart, and everything would look normal, but the machine couldn't 'talk' (it could ping itself tho')...cause? One or another switch hanging on to a stale MAC cache entry...used to drive me nuts...

If WinUAE is citing the need for winpcap, doesn't that infer we need replace those functions, with those available from linux libpcap and friends?...as in, if you look at what WinPCAP facilitates, it's not hard to understand why WinUAE uses it for uaenet.device

...I mean, bsdsocket_lib is unto itself a packet filter, and apps get to use that...but if you have to emulate an ethernet device, you have to match the packets to that network interface's criteria...including mac_addr (synthetic)

At a glance, it seems pcap.h is very similar between linux pcap and winpcap ... still looks like a bit of work ;)