Apple II, Development, IIgs, Networking, Retro, Update, Vintage

More BETA testing the Uthernet II

July 4, 2018

Since my last post, I have learned a lot about how Marinetti works, how the Uthernet II card works, and I have gotten a chance to work with some very awesome people. Glenn Jones of A2RetroSystems.com has allowed me to be a part of the 2018 BETA testing for a new batch run of Uthernet II ethernet cards for Apple II computers. Since I am doing most of my testing on my ROM01 IIgs, I have been using the Marinetti suite for most of my testing. Marinetti was written by Richard Bennett and is currently maintained by Andrew Roughan. Marinetti is a TCP/IP stack for the GS/OS operating system. This is required for activating the connection from the Uthernet II to your network and using any programs that use TCP/IP for communications. A suite of really superb programs for doing that very thing is written and offered by Ewen Wannop, aka Speccie. Speccie has written GS/OS applications that support Telnet, FTP, POP/SMTP email, some basic HTTP and even USENET! Ewen, Andrew and Glenn are truly great people and I have enjoyed learning about the hardware and software used during this BETA test very much. A big thank you to each of you.

For each of the applications that I was going to use to test the UII card, I started by simply installing the latest version of the software and checking to see if they worked, using the following criteria:

  1. Does it connect to a local IP device?
  2. Does it connect to an IP device on the Internet?
  3. Can I send data?
  4. Can I receive data?
  5. Is the connection reliable?
  6. Does the connection perform at an acceptable level?
  7. Does it change my computer’s performance level?
  8. Does it disconnect?
  9. Can it connect again without a reboot?
  10. Do I see any errors?

I started off my installing Marinetti 3.0b1 and was quickly informed by Glenn that there was a newer 3.0b8 on his site that could be downloaded and installed. I did just that, following the instructions in the included Quick Start guide. While downloading that package, I read that Ewen Wannop was the programmer who wrote the Uthernet II link layer for Marinetti so I decided to go to his site, speccie.uk and see if there was a newer version of the LL – there was. I downloaded that too and copied it into place.

To get connected to my home network, my basement lab was using a D-Link Wireless-N Dual-Band MediaBridge (DAP-1513) to bridge ethernet to my WiFi router, which is upstairs connected to the cable modem. The bridge did not like something about the Uthernet II/Marinetti stack and even though it would link up and show a link light and activity, it would not pass communication at layer 2 or 3 for any reason. I spoke with Glenn via the Slack group and let him know of the issues that I was having. He informed me that he and others have used the UII card with other WiFi bridges with no issues and that this configuration should work. I reset the bridge, reconfigured it, and still no working connection. After fighting that issue for a while, I plugged the ethernet cable from the UII card directly into my iMac for some simplified testing. I was then able to give Marinetti a static IP and my iMac a static IP and they were able to communicate as expected. I could ping, I could telnet, it was working! I had been having intermittent issues with the D-Link WiFi bridge prior to this and I was planning on running some ethernet between the basement lab and the router upstairs anyhow, this gave me a real need to do that job sooner than I had planned. As soon as the weather cooperated, I would have to make that happen. In the meantime, I ran a 25 ft patch cable up the stairway and plugged into the router directly. This proved that my bridge was the issue as it connected right up and received a DHCP address as expected – no issues, no delays. I am sure that the bridge is the issue, but I believe that another bridge would work with no problems. MY bridge is the issue. As I said, I had been fighting intermittent issues before this.

With a proper connection to the network established, I started with some basic testing. Can I connect with Marinetti? Yes. Can I ping the Uthernet II card? Yes. Do I get a proper reply? Yes. Can I ping it 1000 times in a row without a dropped packet? Yes. Is the reply as fast as it should be? Yes. Does my computer suffer or lag while I am pinging it? No. Does it disconnect? Yes. Can it connect again without a reboot? Yes. Do I see any errors? No.

Everything looked good so far.

Once the basic testing of the card and Marinetti were complete, I proceeded to install and use the list of programs that I had decided to test. Here is the list I used:

  1. Spectrum Telnet – for connecting to BBSes that I frequent
  2. SNAP Usenet – For reading/posting to Usenet newsgroups
  3. SAFE2 FTP – FTP Client
  4. Telnet 65 – another Apple II telnet app that does not use Marinetti, but has it’s own TCP stack and LL

Going through my list of test criteria, I immediately noticed something off about the apps that used Marinetti, they were all sending and receiving extremely slow for an ethernet connected application. I reported this to the Slack group and was informed that the current release of Marinetti had some debug code enabled, which was slowing everything down. Also, at this time I was informed that a known bug in Marinetti would not allow packets larger than 536 bytes to be sent to the device. Strange. A normal packet size for 10/100 ethernet is 1500 bytes. It is also common for a few bytes to be shaved off of that size for encapsulation/extra header info, etc. but not 66% of the size! That is too much for something normal to be taking up. Glenn said that he was hoping someone would take on fixing that bug. I would love to be that someone, but I lack the assembly language programming knowledge to do so. I wouldn’t even know where to begin. I started asking around on the forums to see if anyone would be willing to take on this challenge. This is where I was introduced to Andrew Roughan. Andrew has been maintaining and managing the Marinetti project for some time now. He informed me that the bug was well known and that he and Ewen Wannop were never really ever able to get it resolved. I then contacted Ewen and asked if he could explain to me what was going on and he informed me that the last time he worked on it, he had confirmed that his link layer was passing an MTU parameter to Marinetti, but that Marinetti was not including that option in the TCP handshake. He was not sure if this had been resolved since his work in 2015. I decided to see for myself. I setup an ethernet hub and connected my UII card, my iMac and the uplink patch cable. I then started up a packet capture using Wireshark to visualize the handshake packet by packet.

Now, let’s get into a brief description of TCP handshake and how that is supposed to work:

From Technopedia.com:

A three-way handshake is primarily used to create a TCP socket connection. It works when:

  • A client node sends a SYN data packet over an IP network to a server on the same or an external network. The objective of this packet is to ask/infer if the server is open for new connections.
  • The target server must have open ports that can accept and initiate new connections. When the server receives the SYN packet from the client node, it responds and returns a confirmation receipt – the ACK packet or SYN/ACK packet.
  • The client node receives the SYN/ACK from the server and responds with an ACK packet.

Upon completion of this process, the connection is created and the host and server can communicate.

Included in the initial SYN packet, there are a set of ‘TCP OPTIONS’ that can be set. One of which is called Maximum Segment Size or MSS. This is the MTU setting that your software is supposed to give to the network device that it is connected to, in order to let it know the maximum packet size that you can receive. The responding SYN/ACK packet should have the DF (Don’t fragment) bit set and the packet size set at the MSS number that you sent in the first packet, as well as an MSS setting of it’s own. If the packets arrive without a ‘fragmentation needed’ error, then that is the correct MSS for communicating to you from that device. If the device receives an error saying ‘Fragmentation needed’, there is likely a device (router or switch or?) in between the two of you that cannot handle that large of an MSS setting, in which case the responding device lowers the MSS and tries again. Once the original device receives this SYN/ACK reply without fragmentation, it replies back with an ACK packet using the DF bit and the MSS that it received in the SYN/ACK and everyone is running at maximum packet size without fragmentation.

This is the way that a proper TCP three-way handshake should go. However, in my packet captures, I verified that Ewen’s discovery was indeed correct – there was no MSS option set in the original SYN packet from Marinetti. You can see that the responding SYN/ACK packet does have the MSS option set coming back to Marinetti, but the original package does not. For comparison, I captured the same handshake from my Raspberry Pi to see the setting working properly:

 

I spoke to Ewen and Andrew and shared my pcaps with the both of them. They then started talking to each other about how to go about resolving this issue. As of this time (20180704) it is still not resolved. I would have to use Marinetti as-is for the time being. I tried to use it for FTP file transfers with SAFE2. I was able to connect to ASIMOV. So that was working. It would transfer smaller files OK, 2k, 6k, 200k. Then I tried a larger file, a 2MB disk image – it would transfer the first 30-50% of the file and then it would pause indefinitely. I tried the same test 5 times and it finally transferred the 2MB file. After this, I tried SNAP and connected to Usenet and had similar results. It would work very slowly for a bit, but eventually, it would hang, waiting for a response from the server.

In the meantime, I decided to test the telnet65 client, which does not use Marinetti, to see how much faster it would be with these issues resolved. While being a very basic, ProDos app and not running within the GUI of GS/OS, telnet65 worked very well! It is somewhat limited in features, but that is the appeal of an application like this. It is designed to be light and fast and stable. Somewhat of the KISS principal. With telnet65, I could see that the Uthernet II card was much much faster than the TCPSER/RPi connection I was using prior to having the card.

About a week later, Andrew emailed me a new version of Marinetti, 3.0b9, which has the debug code disabled. He told me that there was not any code changes or bug fixes in this version, but it should run faster without the debug code enabled. This made a huge difference as I was previously not able to use the entire suite of apps without any timeout issues at all. Marinetti was now working significantly faster than my TCPSER serial connection, and almost as fast as a modern ethernet connection should work! As soon as I verified that it worked, I let Andrew know that everything was as expected and he released Marinetti 3.0b9 to the world via A2RetroSystems.com 

With Marinetti now working well enough to use reliably, I proceeded to retest the applications in my list.

SAFE2 FTP now passed all tests with flying colors! There were no issues at all connecting or transferring files of any size. I could disconnect and reconnect without any issues at all. This was great and will really be useful when installing programs to my CFFA3000 CF card without having to remove the card from the computer.

Next I tried the SNAP Usenet application. It certainly connected and downloaded the list of messages much faster, however, it would still not mark any messages as read. I started up another email dialog with Speccie and through some troubleshooting and screenshot swapping, we discovered that if you have the following parameters set, it will mark the messages as read:

 

‘Mark Last Read’ needed to be checked and ‘List new messages first’ could not be checked.

Regardless of the ‘Mark Last Read’ setting, if you checked the box to ‘List new messages first’ it would not mark messages as read. Also, it would always download the entire list of messages, even if some were marked read by using the other setting. After a couple of very quick code updates from Speccie, he had all of this sorted out and the latest version of SNAP (released when Ewen is back from his holiday, I think), the program now marks messages as read no matter which order you list them in. It works exactly as expected.

Using SNAP to read my daily Usenet groups works so well that I have made it part of my daily morning routine. It is honestly just as easy as using a modern computer and since I am already logging onto BBSes with Spectrum every morning, there is no downside to popping over to SNAP and reading the Usenet posts before logging off of my retro machine and joining the real world for another day.

Finally, I retested using Spectrum Telnet for connecting to the BBSes. This time around, what a difference! That 3.0b9 release really helped a ton! The BBS communication is now significantly faster than the TCPSER/RPi connection ever was. On some of the BBSes, I get a strange repeated character when I enter a command, but I get that same thing using telnet on any modern machine to connect to these BBSes. On Dura-Europas, (telnet: dura-bbs.net:6359) I get no such issue. It works absolutely as well on direct telnet in Spectrum as it does using TCPSER/RPi. And it is even faster! Skip, the Dura BBS sysop is running an accelerator board in his IIe for hosting that BBS and he has that system tuned like a formula-one race car! Fast, efficient and fun!

All in all, this has been really fun to test the card and learn how it works. I learned quite a bit about how the TCP protocol works and was able to help a few great programmers improve their software at the same time. Next, I will be transferring my Uthernet II card to my non-enhanced IIe for some more testing.

Until next time, same bat-time, same bat channel!

You Might Also Like

2 Comments

  • Reply Andrew July 5, 2018 at 8:31 am

    Roughan

    • Reply Jeff Ramsey July 5, 2018 at 9:15 am

      Apologies Andrew. I will edit and correct that right away.

    Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.