1) Any packet with a payload will start with a L2CAP-S (Start) segment. All 0-length packets (ie link maintenance and acks) will come as L2CAP-C (continuation) as a 0 length continuation has no affect.
2) It looks like the FCS Error may have only occured at the sniffer (of course, the sniffer might receive different data than the peer device depending on rf conditions). This error packet is successfully ACK'd in the next packet (see below for ack scheme)
3) Every connection event should start with the Master transmitting. If the master has no data/signalling to transmit, it will transmit an empty packet to give the slave a chance to respond. If the slave has nothing to send, it will respond to the master with an empty packet (unless slave latency is enabled, then the slave is allowed to skip this connection event if it has nothing to send).
4) Lots of timing dependencies can result in this happening. Inaccurate timer, long connection interval, etc.
5) Yes. The ACK scheme is based on the NESN (next expected sequence number) and SN (sequence number) fields. So:
Frame 3461: Master sends empty packet to start the connection event, NESN=1 SN =1
Frame 3462: Slave sends data packet NESN = 0 SN = 1 (The NESN = 0 here means that the packet in frame 3461 has been ACK'd and the slave expects the next packet from the master to have SN = 1. Also note that the MD flag "more data" is set here, this basically lets the master know that the slave has more data and the master should give the slave another chance to transmit during this connection event if possible.
Frame 3463: Master sends empty packet to give slave a chance to tx again, NESN=0,SN=0 (NESN =0 Acks the packet from frame 3462)
Frame 3464: Slave sends data packet NESN = 1, SN = 0 (NESN = 1 Acks frame 3463 packet. Note MD is 0 here meaning the master doesn't need to extend the connection event)
Hope this helps. Reading the core spec or Robin Heydon's book would answer all of these questions too.
-Tyler
