IPv6 multicast starts with 33:33 and ends with the last 32 bits of the unicast address. The neighbor solicitation multicast IP is ff02::1:ff followed by the last 24 bits of the unicast address. So let's say you're looking for fe80::2216:d8ff:fe78:a737. The multicast IP would then be ff02::1:ff78:a737 and the MAC address would be 33:33:ff:78:a7:37.
You can see an example of it here: http://www.cloudshark.org/captures/3dca5db8cee9
*Edit: Also look at Keith Barker's video here: http://www.youtube.com/watch?v=O1JMdjnn0ao He covers this starting at about 3:30 into the video.
This is a very niche product, but Cloudshark. If you're unfamiliar, Cloudshark is basically Wireshark re-implemented as a web application. It's one of those products that only does one thing, but it does it very, very well. They also offer free hosted accounts.
Already covered it. Quoting myself.
> IIRC there is an opposite "who's out there?" broadcast a client can do, but that's not asking for any SSID in particular.
> The only time your computer will broadcast the SSID of a network its looking for is if the network is Ad-Hoc mode (rarely used) or has a "hidden" SSID.
If you don't believe me, have a look at this: http://www.cloudshark.org/captures/3832a10a2ca1
That's a capture from just now of my Galaxy S4 running Android 4.4.2 (CM11) looking for networks in a random office building I happen to be in. As you can see, it doesn't list any SSIDs, it's just looking for who all's out there. When looking at the whole dump rather than just filtering traffic involving my device there's a flood of beacon frames as well, allowing the device to have a fairly complete idea of what's out there without having to transmit at all. For power consumption reasons that is the preferred way to do it for auto-connections, though obviously if the user specifically has the wifi control panel open as I did for these captures it's safe to assume they want to connect and would prefer faster over lower power.
I stand by my statement, unless you're using hidden SSID networks due to your network admin being stupid or misinformed, your computer is not broadcasting any SSIDs.
Would you be willing to upload the .pcap to http://www.cloudshark.org/ ? If it contains sensitive info then no worries, just thinking it might help to take a look at everything going on.
I'm not sure I'm following your train of thought on how fast transmission works though. I'm pulling this quote from http://en.wikipedia.org/wiki/Fast_retransmit ...
>The fast retransmit enhancement works as follows: if a TCP sender receives a specified number of acknowledgements which is usually set to three duplicate acknowledgements with the same acknowledge number (that is, a total of four acknowledgements with the same acknowledgement number), the sender can be reasonably confident that the segment with the next higher sequence number was dropped, and will not arrive out of order. The sender will then retransmit the packet that was presumed dropped before waiting for its timeout.
Could be a lot of things.
Is the source a machine within your local network?
Is the destination a local or remote DNS resolver?
What OS is the source machine running?
Would you mind posting the portion of the data capture for both the source and destination addresses on CloudShark and linking it here?