Wireshark AppleTalk dissector improvements.

[NJRoadfan]

Had some spare time last week and decided to contribute some improvements to Wireshark. A few of these were gripes because I use Wireshark ALOT when working on Netatalk.

-The AFP dissector now properly decodes the ProDOS information block. This one was annoying because Wireshark kept throwing exceptions due to treating this block as an offset for a UTF8 filename. Its been fixed and now when you packet monitor traffic from your Apple II, it properly decodes it.

-Support for MacIP packet dissection has been added. Decoding the packets is easy since they are IPv4 packets with a DDP header, so they get passed off to the IPv4 dissector. I did go a step further and add support for the ATP IP address configuration packets, which the draft IETF paper called "MacIP Gateway Protocol". Way fancier sounding than it really is. If anything it was planned for more and development stopped when it reached the "it works, ship what we have and worry about the rest later" stage. Well, later never came!

I hope to make further improvements if/when I have time. I know @robin-fo has some additions that were worked one (I've seen ADSP decoding and LToUDP support). Don't be afraid to submit a PR. The folks at Wireshark are pretty chill!

 

[wthww]

This is awesome, thanks for your contribution @NJRoadfan!

 

[thecloud]

I hope to make further improvements if/when I have time. I know @robin-fo has some additions that were worked one (I've seen ADSP decoding and LToUDP support). Don't be afraid to submit a PR. The folks at Wireshark are pretty chill!

AURP packet dissection support has also been done; there is a plugin at https://github.com/bytex64/aurp-dissector which worked well for us this past March. As long as Wireshark is accepting PRs then maybe he can contribute this one as well.

 

[slipperygrey]

we have two hurdles to overcome to get bytex64's AURP dissector into Wireshark proper:

it needs to be rewritten from Lua to C, as per the Wireshark Developer's Guide (unless we can make an argument that it absolutely has to be in Lua)

bytex64 needs to apply a GPL-2.0-or-later compatible license blurb to his code, if he or someone else is to use it as basis for an MR submission to Wireshark

while I appreciate the tongue-in-cheek tone of the current blurb, the GPL licenses forbid any kind of explicit obstacle to commercial use (and I doubt he wants a thousand emails everyday from everyone who uses Wireshark at work :-D )

 

[slipperygrey]

FWIW, the author has given his permission to create derived work from his plugin and distribute under another license

Chip (@bytex64@awesome.garden)

@dmark@hachyderm.io @theirongiant@hachyderm.io @_the_cloud@mastodon.social If someone has commercial need of an AURP dissector, I weep for the both of us. 😆 I’m quite happy to let someone else rewrite it in C. I have neither the time nor the desire to do it myself. I wouldn’t even consider that...

awesome.garden

to his point, this is all based on an open standard, but still!

 

[NJRoadfan]

I'd need some actual AURP packet traffic to test any sort of dissector.

Meanwhile, I've looked at DDP-IP aka Kinetics IP used by the Columbia AppleTalk Package and supported by the Fastpath and Gatorbox. Its very similar to LToUDP in that its straight LLAP wrapped with a UDP header. It dedicates the various AppleTalk services to IP sockets (RTMP to socket 201, NBP to 202, etc.) Instead of broadcasts, it leans on the IP side of things for addressing (ex: the node number is derived from the last octet of the IP) so no LLAP enquery packets are needed. The assigned IP socket thing seems kind of pointless (the packets still have full DDP headers indicating socket and DDP type), but I can see it being easier to implement listening on the server end of things.

 

[cheesestraws]

(ex: the node number is derived from the last octet of the IP)

ahhh fun with classful addressing. Also, ew.

 

[thecloud]

I'd need some actual AURP packet traffic to test any sort of dissector.

I should try to systematically gather a corpus of packets for testing, but here's some for Routing Information Update, Routing Information Acknowledgement, Routing Information Request, Routing Information Response, and Zone Information Response.