Which file, for those of us not familiar with the code yet?
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
TashRouter: An AppleTalk Router
- Thread starter tashtari
- Start date
tashtari
PIC Whisperer
Okay, so if we want to make it so when BrRq datagrams are broadcast as LkUp datagrams, the datagram always uses the long header, the quick-and-dirty fix is to change this in port/localtalk/__init__.py:
to this:
Eagle-eyed observers may notice that I used
Python:
def multicast(self, zone_name, datagram):
if self.node == 0: return
log_datagram_multicast(zone_name, datagram, self)
self.send_frame(bytes((0xFF, self.node, 1)) + datagram.as_short_header_bytes())to this:
Python:
def multicast(self, zone_name, datagram):
if self.node == 0: return
log_datagram_multicast(zone_name, datagram, self)
self.send_frame(bytes((0xFF, self.node, self.LLAP_APPLETALK_LONG_HEADER)) + datagram.as_long_header_bytes())Eagle-eyed observers may notice that I used
1 where I should have used self.LLAP_APPLETALK_SHORT_HEADER, but we'll just sweep that under the rug...
Last edited:
RolandJuno
Active member
Thanks! I applied the patch to tashrouter/port/localtalk/__init__.py
#self.send_frame(bytes((0xFF, self.node, 1)) + datagram.as_short_header_bytes())
self.send_frame(bytes((0xFF, self.node, self.LLAP_APPLETALK_LONG_HEADER)) + datagram.as_long_header_bytes())and run it again. No change in the Mini VMac Chooser-- no ImageWriter appears. This time, I'm not seeing any replies of the ImageWriter II name of "Itchy & Scratchy" like I did before in the debug. I've attached the log. Let me know if there's anything else I can do to assist.
tashtari
PIC Whisperer
H*ck, I really hoped it was going to be that simple. As you say, the ImageWriter is now not responding at all to the NBP LkUp... hmm.
One more quick-and-dirty change that might make a difference. In service/name_information.py, line 111, change
destination_network=0x0000, to destination_network=entry.port.network, - I'm wondering if the destination network being zero is confusing the ImageWriter. Ordinarily this field is kind of moot as broadcasts typically use short headers anyway, but with the extended header, maybe it matters...
tashtari
PIC Whisperer
My first thought is that RTMP broadcasts are somehow not making it to the IIe, a minute is a reasonable timeframe for it to give up and think the router's gone away, but this...
...really confuses the issue. If one isn't getting RTMP broadcasts, the other shouldn't either. It's possible to test whether the router is sending RTMP broadcasts, look for a pair of lines that look like these in the debug output (they should come up every ten seconds):
Code:
out to 0.255 ttyAMA0 0 0.255 2.254 1 1 1
frame out ttyAMA0 255 254 type 02tashtari
PIC Whisperer
I'm interested! It'd be nice to get this setup documented.
tashtari
PIC Whisperer
I'm really hoping this was the problem, it's a much easier fix than going the stateful route described in the usenet post. However, if that's what it takes, that's what it takes, TashRouter isn't an embedded system and memory is plentiful. I guess the move is to change the name service so it keeps track of the LkUps it multicasts and add a special case for when it receives a LkUp-Reply directly that pretends that the (presumably) AppleTalk ImageWriter did the right thing...
RolandJuno
Active member
I've made the patch to tashrouter/service/name_information.py
destination_network=entry.port.network,
#destination_network=0x0000,
No change in Mini VMac Chooser, but there appears to be a checksum error now.
failed to parse long-header AppleTalk datagram from LocalTalk frame: invalid long DDP header, checksumThis is with the previous patch also applied. Log attached.
tashtari
PIC Whisperer
It can make a valid long-header DDP datagram but it gets the checksum wrong, that's adorable. Did Apple even test the bloody thing? I swear, I have had it up to here with Apple and the checksum algorithms they pull out of their asses, would it have killed them to use an industry standard CRC16? *angry noises*
If I could figure out how it's miscalculating the DDP checksum, I could have the Datagram class check for both the correct checksum and the ImageWriter's incorrect checksum, but I haven't been able to. Is there a dump of the ImageWriter AppleTalk card's firmware anywhere?
tashtari
PIC Whisperer
All right, ranting over. Just to prove that the datagram (minus the checksum) is valid, you can comment out the checksum check in datagram.py:
Python:
#if checksum != 0:
# calc_checksum = ddp_checksum(data[4:])
# if calc_checksum != checksum:
# raise ValueError('invalid long DDP header, checksum is 0x%04X but should be 0x%04X' % (checksum, calc_checksum))Here are a couple of captured traces from my setup using an unmodified tashrouter. The 'a2e.log' starts slightly before I boot the IIe, logon as user 'a2e' and mount A2BOOT and A2E shares. There's time for one or two directory listings of /a2e before it "loses" the server. The 'a2gs' log is similar with the //gs system. The session stays up without any problems.
Hopefully the underlying issue will jump out. Do let me know if you need anything else.
Hopefully the underlying issue will jump out. Do let me know if you need anything else.
The IWAT ROM is Apple part number 342-0034-B, but I'm not finding a dump in my archives. I have the board here and will image it a bit later today.
UPDATE: Here is the firmware from the IWLT board, complete with the developers who may be blamed for it
Last edited:
RolandJuno
Active member
Progress! I commented out the four lines for checking the checksum in datagram.py and the ImageWriter II shows in the Chooser under the TashTalk Zone in Mini VMac!
I started a print job using Illustrator 3 and it began to print. However, the print stalled about halfway through the job, eventually saying there was an AppleTalk error. I've included the debug output from tashrouter.
At this point, since we can show that it can indeed work, it may be better to seek the info in the IWII LT ROM as you suggest for what it's expecting.
Cheers!
Based on the symptoms you describe I believe you are now seeing the same session drop as I do when networking an Apple IIe across the tashrouter.
tashtari
PIC Whisperer
Well, the first thing that seems amiss is the raft of unanswered RTS frames starting at line 897 of a2e.log, that's never a good sign. I'm guessing from context that 2.16 is the IIe and 3.238 is netatalk... with that in mind, I'm wondering why the IIe is suddenly trying to talk to netatalk as though it were on the same network instead of using the router as it should... that's very strange and wrong.
Excellent, thanks! Now I just need to figure out how to disassemble it...Here is the firmware from the IWLT board, complete with the developers who may be blamed for it
Now this is really strange. This log has a bunch of unanswered RTS frames in it too, only this time, the ImageWriter seems to be trying to send frames to LocalTalk address 0, which is not a valid address. Things seem to be chugging merrily along, then Mini vMac starts sending unanswered SendStatus TReqs to the ImageWriter, meanwhile the ImageWriter is sending these RTSes into the void for some reason... it wants to say something, but why is it trying to send to address zero?
I don't know if they're exactly the same thing, but in both cases the Apple IIe and the ImageWriter seem to forget to talk to the router and it's not at all clear why. TashRouter is still sending out RTMP broadcasts every ten seconds, as it should, announcing its presence, so unless those broadcasts are repeatedly getting lost somehow (they shouldn't, the network is nowhere near busy enough for collisions to be that likely) the IIe and ImageWriter ought to know that a router is available on the network. In any case, they shouldn't be doing what they're doing in the absence of a router (sending to address zero in the ImageWriter's case and sending to the wrong address in the IIe's case).
This... is a real stumper, not gonna lie.
RolandJuno
Active member
Just an update on my progress of getting tashrouter to run on the same RaspberryPi as MacIPRpi. I figured out that Raspbian Buster also didn't have the "uml-utilities" installed which provides (among other things) the tunctl which is needed for the "tap2" device in @finkmac 's instructions.
Also, I used the ifup command, but not sure if that was needed (maybe it does this automatically on startup?) Providing it for completeness.
Afterwards, the Mini VMac machine was able to see the MacIPRpi share in the Chooser from netatalk running on the same machine as tashrouter!
One left hurdle is to figure out why Mini VMac doesn't see my HP LaserJet 4000 with a JetDirect card using EtherTalk.
sudo apt-get install uml-utilitiesAlso, I used the ifup command, but not sure if that was needed (maybe it does this automatically on startup?) Providing it for completeness.
sudo ifup br0
sudo ifup tap2Afterwards, the Mini VMac machine was able to see the MacIPRpi share in the Chooser from netatalk running on the same machine as tashrouter!
One left hurdle is to figure out why Mini VMac doesn't see my HP LaserJet 4000 with a JetDirect card using EtherTalk.
No worries! If you have the commands needed using IP, I can give those a try too.
tashtari
PIC Whisperer
By all means, another pair of eyes would be welcome.
RolandJuno
Active member
Strange, I've noticed that when I reboot the RPi, it's a 50/50 chance in the Mini VMac Chooser EtherTalk Zone that either the HP LaserJet 4000 showing up or the MacIPRpi netatalk suite of tools showing up, but not both.Just an update on my progress of getting tashrouter to run on the same RaspberryPi as MacIPRpi. I figured out that Raspbian Buster also didn't have the "uml-utilities" installed which provides (among other things) the tunctl which is needed for the "tap2" device in @finkmac 's instructions.
sudo apt-get install uml-utilities
Also, I used the ifup command, but not sure if that was needed (maybe it does this automatically on startup?) Providing it for completeness.
sudo ifup br0 sudo ifup tap2
Afterwards, the Mini VMac machine was able to see the MacIPRpi share in the Chooser from netatalk running on the same machine as tashrouter!
One left hurdle is to figure out why Mini VMac doesn't see my HP LaserJet 4000 with a JetDirect card using EtherTalk.
No worries! If you have the commands needed using IP, I can give those a try too.
I wonder if it has something too with the zone ranges? Also, shouldn't the MacIPRpi see the Mini VMac in the LToUDP Zone?
me@macippi:~ $ nbplkup
UTC:TimeLord 4.171:134
LocalTime:TimeLord 4.171:132
MacIPpi:AFPServer 4.171:129
172.16.2.1:IPGATEWAY 4.171:72
MacIPiRpi:netatalk 4.171:4
MacIPiRpi:Workstation 4.171:4
HP LaserJet 4000 Series:SNMP Agent 3.128:8
HP LaserJet 4000 Series:LaserWriter 3.128:157
HP LaserJet 4000 Series:HP LaserJet 3.128:158
HP LaserJet 4000 Series:HP Zoner Responder 3.128:154Or perhaps I don't having something configured correctly with the tun/tap/bridge?
br0: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST> mtu 1500
inet 192.168.1.193 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::886d:9dff:fe76:a70a prefixlen 64 scopeid 0x20<link>
ether 8a:6d:9d:76:a7:0a txqueuelen 1000 (Ethernet)
RX packets 13364 bytes 1663183 (1.5 MiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 8129 bytes 7665607 (7.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.193 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:6c:5b:81 txqueuelen 1000 (Ethernet)
RX packets 12540 bytes 1622992 (1.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10047 bytes 7494603 (7.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 506 bytes 48296 (47.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 506 bytes 48296 (47.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 8a:6d:9d:76:a7:0a txqueuelen 1000 (Ethernet)
RX packets 860 bytes 54249 (52.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9806 bytes 2457248 (2.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 586
inet 172.16.2.1 netmask 255.255.255.0 destination 172.16.2.1
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 48 (48.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Let me know if a eavesdropping dump (LToUDP and TashTalk) of Apple Internet Router handling an ImageWriter would help. Just would need some assistance in how to capture it.
