i can hear you mummy!

Work continues apace. Yesterday tap.device received and decoded its first packets, and I happily watched as AROSTCP issued write commands in response. This morning on the bus, the first packet was responded to. Some output:

[tap] [0] got a packet
[tap] [0] packet dump (42 bytes):
0x000000  ff ff ff ff ff ff be 21  7e 9b ce 97 08 06 00 01  
0x000010  08 00 06 04 00 01 be 21  7e 9b ce 97 c0 a8 1e 01  
0x000020  00 00 00 00 00 00 c0 a8  1e 02                    
[tap] [0] source address: be:21:7e:9b:ce:97
[tap] [0] dest address: ff:ff:ff:ff:ff:ff
[tap] [0] packet type: 0x0806
[tap] [0] broadcast packet
[tap] [0] found a request that wants this packet, sending it
[tap] [0] packet copied successfully
[tap] in begin_io
[tap] CMD_READ
[tap] [0] queued read request
[tap] in begin_io
[tap] CMD_WRITE
[tap] [0] queued write request
[tap] [0] waiting for write events
[tap] [0] ready to write
[tap] [0] buffer has 28 bytes
[tap] [0] packet dump (42 bytes):
0x000000  be 21 7e 9b ce 97 2e 2e  22 89 d7 0a 08 06 00 01  
0x000010  08 00 06 04 00 02 2e 2e  22 89 d7 0a c0 a8 1e 02  
0x000020  be 21 7e 9b ce 97 c0 a8  1e 01                    
[tap] [0] source address: 2e:2e:22:89:d7:0a
[tap] [0] dest address: be:21:7e:9b:ce:97
[tap] [0] packet type: 0x0806
[tap] [0] wrote 42 bytes

Thats the debug output from the driver as it receives an ARP who-has broadcast from Linux, and sends a reply. tcpdump was kind enough to show it:

08:02:42.663596 arp who-has 192.168.30.2 tell 192.168.30.1
08:02:42.675941 arp reply 192.168.30.2 is-at 2e:2e:22:89:d7:0a (oui Unknown)

So we’re extremely close. I’ve got a bug at the moment that is only really allowing one packet to be sent by AROS before it gets stuck somewhere deep in the kernel and consumes all of my CPU. Its to do with trying to disable write events when I’ve got no more packets to send - there’s no point having UnixIO wake me up every second to tell me I can write if I have nothing to write. It seems to be causing some kind of interesting race condition inside the kernel’s signal stuff. I’m not sure yet if its a bug or a limitation of UnixIO, but I’m sure its possible to fix, so my next step is to print unixio_class.c and study it for a while.