Which file, for those of us not familiar with the code yet?Commenting out lines 152 to 154 should force all packets from TashRouter to "long" form.
Which file, for those of us not familiar with the code yet?Commenting out lines 152 to 154 should force all packets from TashRouter to "long" form.
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())
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())
1
where I should have used self.LLAP_APPLETALK_SHORT_HEADER
, but we'll just sweep that under the rug...Not quite - this will force all unicast datagrams to use the long header, but it won't affect the broadcast datagrams that are sent when the name service converts a BrRq to a LkUp. See above for code that will do that.Commenting out lines 152 to 154 should force all packets from TashRouter to "long" form.
Thanks! I applied the patch to tashrouter/port/localtalk/__init__.pyOkay, 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:
#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())
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.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.
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...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...For almost a minute, everything works fine. Then it spontaneously drops the session.
...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):If I change nothing else and connect a //gs to the tashtalk 9-pin port everything works properly and stays connected.
out to 0.255 ttyAMA0 0 0.255 2.254 1 1 1
frame out ttyAMA0 255 254 type 02
I'm interested! It'd be nice to get this setup documented.On the subject of a netatalk appliance, I have been testing integrating TashRouter into A2SERVER, mainly for its LToUDP routing. My preferred solution is to avoid the network bridges and macvtap method since they seem to all have their quirks depending on the system. I instead created a tap interface called 'tap0', setup the appropriate lines in atalkd.conf and the TashRouter startup program, and let them route that way. So far there are no issues other than an extra "virtual" network hop over the tap interface. One could even setup a tap enabled emulator like MAME on the machine and ...aham..... tap into the network. I will post this configuration later tonight if anyone is interested.
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...I'm wondering if the destination network being zero is confusing the ImageWriter.
I've made the patch to tashrouter/service/name_information.pyOne more quick-and-dirty change that might make a difference. In service/name_information.py, line 111, changedestination_network=0x0000,
todestination_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...
destination_network=entry.port.network,
#destination_network=0x0000,
failed to parse long-header AppleTalk datagram from LocalTalk frame: invalid long DDP header, checksum
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*No change in Mini VMac Chooser, but there appears to be a checksum error now.
#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))
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.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?
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!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:
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.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!
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.Hopefully the underlying issue will jump out.
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've included the debug output from tashrouter.
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).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.
sudo apt-get install uml-utilities
sudo ifup br0
sudo ifup tap2
No worries! If you have the commands needed using IP, I can give those a try too.this is my bad, technically bridge-utils is deprecated. There's newer incantations to do the same with the "ip" command.
By all means, another pair of eyes would be welcome.I'm going to try to rope Geoff Body into this discussion. I have a feeling he knows right off the bat what's going on.
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.
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:154
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 0
Let 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.By all means, another pair of eyes would be welcome.