Translations need for Basilisk 1.0, please help out.

@LiveForIt

I'm sorry to hear of your disappoiuntment with Roadshow.

In any case, it's what we've got and while it may be old,
it has proven to be quite bulletproof.

I also apologize for not having been able to test your
new Basilisk builds yet - been just *swamped* with real
life. :/

In any case, I wanted to check to see if you knew about
the "VLink" SANA driver set and whether that might be an
easy fix for Basilisk networking...

http://aminet.net/package/comm/tcp/vlink

It worked fantastically well providing networking with the
old Shapeshifter. I also "talked" with Olaf and he said it
should also work with Roadshow.

Basically, it allows you to just open the VLink driver
as though you're taking over a SANA ethernet interface
and the mirrored driver then routes the packets into the
TCP/IP stack on the Amiga side.

Please let us know if you think this might at least be a
passable networking fix for Basilisk.

Thanks!!

PJS

@pjs

Not at all I don’t know how to talk to vlink, need the source or some working example, same problem I have with SanaII and Roadshow, I have no clue way its not work, can’t debug roadshow, or understand way its do not working, its a black box.

@LiveForIt

Sorry, I'm not a coder, so I can't directly help...

But wasn't there old code in Basilisk or from Shapeshifter
which just called a SANA driver?

Thanks,

PJS

@LiveForIt

I reported the matter to Olaf. Claims that AROS's TCP stack relies on older sources than Roadshow as it uses AmiTCP V3, while Roadshow is an extension of AmiTCP V4.

Besides, Olaf has developed an example of using the SANA II, which works seamlessly with the Roadshow AmigaOS 4 and 68k.

https://github.com/obarthel/amiga-sana-ii-tftpclient

@mufa

Sorry, I haven't been around on this site for a long time

Some context on what I mentioned with regard to what Roadshow does, and how that tftp client code fits into the picture.

First thing, both AmiTCP V3 and Roadshow are using old TCP/IP stacks, with AmiTCP V3 using the older one, which goes back to the late 1980'ies. Roadshow's a bit younger, being derived from 4.4BSD-Lite2 (1995). That explains in part why Roadshow does things differently. But it also explains why there are limitations as to what the code can do. NetBSD is closest to the state of 4.4BSD-Lite2, yet porting features such as path MTU discovery from old NetBSD to the codebase which Roadshow uses has proven really hard. Not much wiggle room

Roadshow implements the AmiTCP V4 API, as did Miami, for example, but neither of these Amiga TCP/IP stacks use or share code of AmiTCP: They share code with the 4.4BSD-Lite2 release, directly (Roadshow) or indirectly (Miami is likely based upon NetBSD).

@LiveForIt: What exactly are you missing in Roadshow which AROS TCP (which is built upon AmiTCP V3) is delivering?

Roadshow requires that every client which uses it is a Process. How and why that would create trouble on AmigaOS4 threads I cannot tell. If libcurl is not working for you, it's possible that the POSIX interfaces it expects to work may not be supported by the AmigaOS architecture. For example, you can use POSIX signals to abort pending DNS queries and even Unix syscalls such as connect(), but this is not a robust approach on the Amiga. The Roadshow implementation of the socket networking API plays within the limitations imposed upon by the Amiga operating system.

I stumbled upon such issues with the wget port which ships with Roadshow which would use POSIX signals to implement timeouts for DNS queries, for example, and the workarounds I tried to find didn't exactly produce the same behaviour you'd get on a POSIX system. That's a side-effect of how the AmiTCP design integrated the libresolv functionality.

Oddly, some of the code I've seen which uses POSIX signals in order to implement timeouts for network operations makes assumptions about the socket networking API which hold on Linux but not on BSD Unix. For example, the connect() function has its own separate timeout which follows from how it was implemented, and that will take effect before a POSIX signal triggered by a longer alarm() timeout can. This is the kind of stuff you don't expect and will have to spend hours reading the old TCP/IP stack source code over

The SANA-II tftp client available at https://github.com/obarthel/amiga-sana-ii-tftpclient is an example of how SANA-II compliant network device drivers may be used in practice. The example builds both for AmigaOS 2.x/3.x and AmigaOS4 and I tested it in both environments. LiveForIt mentioned having difficulties making SANA-II work, so maybe that example could be helpful. The example pretty much covers what a TCP/IP stack would do when doing, juggling IP and ARP datagrams using asynchronous I/O. Which even for a "simple" protocol such as tftp is surprisingly complex. Careful please: this shows how you could approach this task without using an existing TCP/IP stack, just by going to the lowest available networking layer attainable on the Amiga. Don't try to use this tftp client if you already have a TCP/IP stack or Envoy running at the same time.

@olsen

@LiveForIt: What exactly are you missing in Roadshow which AROS TCP (which is built upon AmiTCP V3) is delivering?

Being able to see what TCP/IP stack is doing when I send some packages, and maybe understand way I don’t get any packages from Roadshow. At that was problem I had, it looked like communication did not go anywhere. From my point of view.

Something like Wireshark for Amiga might helped.

Quote:

I have no idea what is going on inside of POSIX sockets, I know roadshow is picky about having to open the interface per thread or something like that, but that cannot possibly work, I know about socket sharing, but that is below the POSIX api, so not easily accessible. I got lot crashes and count really do anything. Of course is also issues with errno because designed for isolated thread like forks(), but do not work well in Amiga landscape.

posix select() also behaves strangely, I had to make a work around in mplayer, when streaming you get error message about select() being broken on AmigaOS

Quote:

That might help, I never really owned a Amiga1200 or A4000, I owed a Amiga500 back in the day, I don’t really know how any of this should work on classic Amiga when its working regarding Basilisk II, so I’m really working blind.

For example do I need vlink? Well the TCP/IP package be send to roadshow and my program when I open a ethernet device, or will it only be send to roadshow only, does it work the same on all ethernet drivers? Or is different depending on driver used?

@LiveForIt

> @LiveForIt: What exactly are you missing in Roadshow which AROS TCP (which is built upon AmiTCP V3) is delivering?
>
> Being able to see what TCP/IP stack is doing when I send some packages, and > maybe understand way I don’t get any packages from Roadshow. At that was problem I had, it looked like communication did not go anywhere. From my point of view.
>
> Something like Wireshark for Amiga might helped.

Roadshow ships with tcpdump, which directly hooks into its builtin BPF interface. That should get you somewhere

At the very least, you could capture the packets, have tcpdump write them to a file (using the "-w" option) and feed these files into Wireshark.

> I have no idea what is going on inside of POSIX sockets, I know roadshow is picky about having open the interface per thread or something like that, but that cannot possibly work, I know about socket sharing, but that is below the POSIX api, so not easily accessible. I got lot crashes and count really do anything. Of course is also issues with errno because designed for isolated thread like forks(), but do not work well in Amiga landscape.

The AmiTCP API does not permit socket library bases to be shared (but doesn't indicate so), and Roadshow follows this practice by default. I tried to keep the behaviour of the API in line with how AmiTCP would approach this, but there is a caveat in that the library base sharing is unpredictable with AmiTCP. This is why Roadshow blocks sharing by default and will return an error. With AmiTCP you may not even get an error, your code might just hang indefinitely.

However, you can enable library base sharing through the SocketBaseTags() SBTC_CAN_SHARE_LIBRARY_BASES option, like so:

error = SocketBaseTags(
SBTM_SETVAL(SBTC_CAN_SHARE_LIBRARY_BASES), TRUE,
TAG_END);

Make sure to check if SocketBaseTags() returns an error code instead of 0. If there's an error code, it means that you can't enable or use library base sharing.

> posix select() also behaves strangely, I had to make a work around in mplayer, when streaming you get error message about select() being broken on AmigaOS

WaitSelect() comes with its share of peculiar features and it does not necessarily perform exactly like select() does. For example, Exec signals are checked during the syscalls behind the bsdsocket.library functions, and if your application so happens to use the same default signals (e.g. SIGBREAKB_CTRL_C) then there will be side-effects.

Due to how the TCP/IP kernel code handles time in, for example, the code which backs the select() syscall, you do not have as fine-grained an interval length as you would with timer.device on the Amiga. More recent versions of Roadshow support the more fine-grained microsecond intervals, though. But out of the box, Roadshow versions older than two years do not.

> For example do I need vlink? Well the TCP/IP package be send to roadshow and my program when I open a ethernet device, or will it only be send to roadshow only, does it work the same on all ethernet drivers? Or is different depending on driver used?

I haven't used vlink.device, so I would not know whether it would make it easier for you to add networking support to Basilisk.

If you went the other way through the use of a SANA-II network device, then the tftp client example should at least introduce you to the basics, namely how to open the device, initialize it, check for errors (and how to make sure that you have the right type of hardware!), and then how to receive and send Ethernet frames. Not all Amiga network device drivers support shared access to the same device, which is where things are bound to get tricky... Sending frames is easy enough, but receiving the frames intended for your emulated Mac is harder (it involves a filter function which not all Amiga device drivers support, and some do not support it completely/correctly). Documentation for SANA-II is available on the Amiga Developer CD 1.1 and beyond.

Whether BSD raw sockets can be a viable substitute remains to be seen. Both AmiTCP V3 and Roadshow support these, but I've never used them.

@pjs

vlink does not work, tried it now..

Some good news:

Tried to port ether_amiga.cpp to OS4 again, this time with some knowledge about libraries.

I assumed that 68K program will pass in 680x0 routines for copy from and to, I have recently working on some libraries , so I applied the knowledge I had about PPC stubs, and now it looks like I can send and receive packages.

Some not so good news:

But now have I crash somewhere else. I’m thinking maybe MacOS does not like large package sizes, or something else is bad in the emulation, or maybe its something strange in my MacOS installation.

Anyhow I expect the old MacOS internet software to be quite outdated by now, I expect we might have better more up to date Internet software on the AmigaOS side

@mufa

Looks interesting, but I think maybe its overkill.

@olsen

You bring up many interesting subjects, but think its best to focus on Basilisk and Sana II, or what topic was originally intended for translations.