ModTashtalk: lt0 driver for Linux

[NJRoadfan]

Looks like its the same problem I'm having. Printing works fine since PAP usually deals with small packet and its mostly outgoing to the host. Also, tcpdump is working for me, in that I can see the contents of the packets. It might not be 100% perfect information, but at least I can see when data is being sent.

@dougg3 don't worry about the kernel patch right now. Its a bit off topic for this thread anyway. The problem seems mostly cosmetic in that NBP lookups only show the contents of the first (or last, I can't remember) network listed in atalkd.conf.

As for getting it to work on the RPi400 (64-bit ARM). I had to change the device to "/dev/AMA0" in setup_and_run (see above) to reflect the use of the GPIO serial port and add the line "arm_64bit=0" to /boot/config.txt to compile the kernel module. I suspect it would have worked fine in 64bit mode, but apt isn't pulling the correct version of the kernel header files.

 

[twelvetone12]

My hunch is that something gets messed up when transmitting a stream of big packets, since aecho works perfectly but the packets are quite slow, afp on the other hand sends them almost back-to-back. But I'm not 100% sure where, I will need to make a tash-sniffer so I can either log packets on the mac (I'm using appletalk on the modem port and I need an adapter to use the printer port) or see if I can capture enough data with my logic analyzer to see where the hiccup is.

 

[tashtari]

The best bus analyzer in this case might actually be another TashTalk to just sit on the line and relay frames to the UART. I don't have any more TashTalk hat PCBs but I can send you programmed PICs if you need them - let me know.

 

[twelvetone12]

Yes that's my plan! Digikey just dropped a package yesterday with some PICs and I will make exactly that, when I have the next slot for this project. Unfortunately my RPi hat is still lost in German customs

 

[twelvetone12]

Soo.. I think I fixed it! It was the buffer that sometimes would not completely flush. I added that and well... I can transfer files from my pc! I forgot how slow it is with big files.

 

[tashtari]

Soo.. I think I fixed it! It was the buffer that sometimes would not completely flush. I added that and well... I can transfer files from my pc! I forgot how slow it is with big files.

Cool! Glad you figured it out, I'm always paranoid that there's an undiscovered bug left in TashTalk...

Unfortunately my RPi hat is still lost in German customs

The one I mailed you two months ago? Yuck, that's terrible...

 

[NJRoadfan]

...I'm not having much luck with the changes. Netbooting the IIgs still doesn't get past logging into the server, I get a ton of "truncating packet: 602 to 600" and the like. The Macintosh is still not receiving large packets either. The Tashtalk seems to be ok though as aecho pings to the Mac on LocalTalk keep on returning. Something is stalling somewhere.

 

[tashtari]

"truncating packet: 602 to 600"

This makes me think the CRC bytes are getting included in a calculation where they shouldn't. The payload of a LocalTalk packet is indeed 600 bytes but this limit does not include the two-byte CRC (which is technically part of the frame rather than the packet).

 

[NJRoadfan]

Looking at the source, that warning is being generated before the CRC is calculated and appended..... odd. These oversized packets appear to be coming from the network stack (via tt_transmit() ) and modtashtalk is flat out dropping them.

 

[NJRoadfan]

The best I can figure out is something is not honoring the MAX_MTU of 600 for LocalTalk devices in the kernel. I'm getting oversized packets coming into tt_send_frame() that are 601-605 bytes, maybe higher but that is the highest I saw in the debug messages.

 

[tashtari]

605 bytes could be including the destination, source, and LLAP type bytes along with the two CRC bytes... if it's more than 605, I don't know how to account for it.

 

[NJRoadfan]

Thing is, even if the kernel is sending the node IDs and type on every packet, the checksum calculation should be fail on the client side.... unless the Macintosh networking stack just ignores it. NEVERMIND: Those are part of the checksum calculation. So the max length of a packet should be 603, not 600. Still doesn't explain the packets I saw larger then that though.

 

[twelvetone12]

Mmh yes the CRC is not included in the MTU which is checked before and CRC added later. In theory you should not be able to send bigger packets with sendto() than 587 bytes from userspace, at least I could never manage to send bigger pkts. You should be able to increment the MTU, the tt driver does not really care and the buffers are oversized anyways.
For incoming packets not arriving that's different, I will have a look. On my PC I could transfer big files (which create 587 byte long afp packets) back and forth, but that was with the USB adapter and maybe the internal UART behaves differently. I will try on my Pi.

 

[twelvetone12]

The one I mailed you two months ago? Yuck, that's terrible...

Yeah German customs can be quite opaque, I should have had you send it to CH. No problem, I will build my own I got the trancievers for the USB2LT thing I want to build! But it will take some time.

 

[NJRoadfan]

Curious as to your configuration, particularly atalkd.conf. I'm running the netatalk-2.x branch release (not the official 2.2.10) and using the stock Pi400 Ethernet in combination with the TashTalk. Looking at the DDP handling code, the netatalk services should be limited to 587 byte packets. Somewhere along the line, bytes are being added, and they are entering the driver at tt_transmit() with more than that.

 

[NJRoadfan]

Reposting to the correct thread.

Alright...... I got it working after some choice edits to the driver. You saw it here first, an Apple IIgs booted directly off a RPi without a Localtalk-To-Ethernet Bridge:


Browsing the Web:


The mess on my livingroom floor. Look Ma, no boot floppy!:


Not pictured is the computer with a mess of terminal windows on it outputting log data. The IIgs screen looks like crap because I grabbed a spare unit and just hooked up the composite out to test.

 

[NJRoadfan]

Here is the edited driver file. I moved the oversized packet check (set to 603 vs. 600) to tt_transmit() and removed an extra tt_unlock_netif() in tt_send_frame(). One thing that I'm wondering about is if you need to append the packet size to an outgoing frame (@dougg3 does this in his driver). I'm not seeing any issues with transferred data though.

Also, I added a echo of a ton of null characters to the "setup_and_run" script directed to the serial port in order to hard reset the TashTalk. This likely should be moved to the driver itself.

 

[tashtari]

an Apple IIgs booted directly off a RPi without a Localtalk-To-Ethernet Bridge:

Nice work!

One thing that I'm wondering about is if you need to append the packet size to an outgoing frame

You shouldn't need to, TashTalk derives the frame size from the frame data - if the type is a control frame, it has no payload so it's five bytes in length; if the type is a data frame, the payload length is in the fourth and fifth bytes.

Regarding the flood of framing errors you're seeing from the IIgs that you posted about in the other thread... do you know if there's any data in the buffer before the framing error is flagged? I'm looking at all the ways the TashTalk code can get to flagging a framing error and they all seem like they'd either require the IIgs to do something it really shouldn't do or require TashTalk to be in a state that it looks like it's impossible to get to... weird. Maybe I'll have to get the IIgs hooked up and see if I can reproduce it.

 

[NJRoadfan]

I'll have to pull the logs and check. Honestly, I'd assume the IIgs is doing something it shouldn't based on my past experience with its AppleTalk stack! I thought it might be a weird bug in the ROM based AppleTalk stack used during netboot, but they were still coming up when booted to GS/OS with a complete stack running.

 

[NJRoadfan]

Here is a log excerpt:

Sep 17 20:28:58 a2server kernel: [ 2368.901122] (1) Tash read 2
Sep 17 20:28:58 a2server kernel: [ 2368.901129] (2) Tash start new frame
Sep 17 20:28:58 a2server kernel: [ 2368.901135] Tash frame error
Sep 17 20:28:58 a2server kernel: [ 2368.901141] (5) Done read, pending frame=0
Sep 17 20:28:58 a2server kernel: [ 2368.902370] (1) Tash read 7
Sep 17 20:28:58 a2server kernel: [ 2368.902381] (2) Tash start new frame
Sep 17 20:28:58 a2server kernel: [ 2368.902388] (3) Tash done frame, len=5
Sep 17 20:28:58 a2server kernel: [ 2368.902395] (4) Tash next frame, remaining=0
Sep 17 20:28:58 a2server kernel: [ 2368.902401] (5) Done read, pending frame=0
Sep 17 20:28:58 a2server kernel: [ 2368.902445] (1) Tash read 2
Sep 17 20:28:58 a2server kernel: [ 2368.902452] (2) Tash start new frame
Sep 17 20:28:58 a2server kernel: [ 2368.902457] Tash frame error
Sep 17 20:28:58 a2server kernel: [ 2368.902463] (5) Done read, pending frame=0
Sep 17 20:28:58 a2server kernel: [ 2368.905117] (1) Tash read 7
Sep 17 20:28:58 a2server kernel: [ 2368.905124] (2) Tash start new frame
Sep 17 20:28:58 a2server kernel: [ 2368.905130] (3) Tash done frame, len=5
Sep 17 20:28:58 a2server kernel: [ 2368.905136] (4) Tash next frame, remaining=0
Sep 17 20:28:58 a2server kernel: [ 2368.905142] (5) Done read, pending frame=0

Looks like invalid frames (2 bytes is too short?) every once in awhile. Parsing the logs, it only happens 9 times a second when connected to a Macintosh. With the IIgs its happening close to 100 times!