Hi Bernhard,
Bernhard Ager wrote:
Oh, interesting to see that. Especially as I have also written a few
extensions for the BitTorrent analyzer, among them the above mentioned
Azureus Messaging Protocol (AZMP) and the LibTorrent Extension
Protocol.
I was not aware of that - I stopped following the SVN when 1.4 was
released. Also, by that time, I had pretty much finished the extensions.
It's been only a couple of fixes since then and my 1.4 patch still works
fine on the most recent SVN trunk. I should have released it back then
but somehow I kept forgetting, and only when I met Robin in Oakland last
month I remembered.
My flavour of the enhanced parser analyzes the extension
negotiation protocol (I remember that being a bit hairy) before
deciding if AZMP or plain BitTorrent is used.
I had planned to implement the negotiation protocol as well, but since I
never encountered it in my traces I postponed that project 
Main differences between the analyzers as far as I can tell from a
short peek into your code (forgive me if I mistook a thing or two):
- AZMP is parsed generically, e.g., I don't handle AZ_PEER_EXCHANGE in
a special way. When handling those messages explicitely, then this
should be unified with LTEP anyway.
- Well, LTEP and arbitraty message parsing integrated.
- We use different methods for determining the transparent switch to
the AZMP protocol. I can happily claim mine works correct for all
examined connections---that includes a few TB of traffic
- I deliberately decided against changing the event signatures by
adding an explicit PDU len field, though this is definitely the
cleaner solution, and in case of padding it is the only way to
communicate the correct PDU length. I have never seen a
non-encrypted BT connection using padding in the wild, though.
- Your analyzer handles a few non-standard message types that mine
does only cover by the bittorrent_peer_unknown event (with no loss
of information though).
I have tailored the analyzer to my needs, and all the changes are a
result of that, especially the PDU-len field and explicit recognition of
certain extended message types (makes post-processing much easier for
me). As you are the main developer for this analyzer and I but a mere
tinkerer, I suggest you take whatever is useful from my patch and
integrate it with your work. There is one actual bugfix in this patch
for BitTorrentTracker.cc, that clears up an endiannes SNAFU when
converting the peer list sent by the tracker to Bro host/port tuples.
However, this is only interesting when using the extended
bt-tracker-plist.bro policy that will also print the complete peer list
to the log file (again something I need that others probably won't find
usefull).
I've been testing my analyzer now on several TB of (live) BitTorrent
traffic and it appears to run stable. For SSH subversion users all of
this is available from
svn+ssh://svn.icir.org/bro/branches/bager/bittorrent-enhancements but
there appears to be no public access to this branch currently. Martin:
If you are interested in the patch but don't have access, drop me a
mail, then I'll send it to you.
For now, I am content with what I have and need to focus on other
things, but I would like to continue work on the BT analyzer when I have
more time (couple of weeks from now). I'll let you know when that
happens and if you are still working on BT/Bro then, I'd be delighted to
cooperate.
greetz Martin