as far as I know (I'm not part of the community) there is no public documentation about the bf2142 protocol.
a micro example is in my bf2fp tool (fake players) where I show how to build a connect packet compatible with both bf2 and bf2142 and any of their versions.
in fact one of the problems I have seen during the writing of my fake players tool for the battlefield series (bf1942fp and bf2fp) is that the fields of the protocol change a lot between the game versions (note, I talk just about "versions" like 1.0 and 1.1 and only about the "connect" packet so the rest can be even worst) and I reached that result only using some work-arounds.
as far as I know no compression or encryption is used in the packets.
the data in them is stored using bitstreams, so for example instead of occupying 8 or 32 bits for a number they use a smaller fixed bit size needed for each element.
the result is the saving of space in the packet but lack of "readability", in fact if you try to sniff some packets you will see almost no plain text strings due to the lost of the constant 8 bit padding.
bf2_sniff intercepts just the function which puts these elements in the packets and shows their exact size in bit and their content.
for example take the following connect packet sent by the client to the server in bf2:
Code:
==================================================================
packet size 000005c1
_________________________________________________________________4
00000001
_________________________________________________________________8
00000001
________________________________________________________________32
00001002
________________________________________________________________32
110b9500
_________________________________________________________________1
00000001
________________________________________________________________32
00000000
_______________________________dump____________________________256
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
_______________________________dump____________________________256
6d 6f 64 73 2f 62 66 32 00 00 00 00 00 00 00 00 mods/bf2........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
(for the moment ignore the "packet size" value because is not realistic in the "SEND" column, while it's good for the "RECV" one).
reading this dump you can see that the first element in the packet is a number of 4 bits of value 1, the second has a size of 8 bits and a value of 1, the third a 32bit size and a value of 0x1002 (fixed value, the demo should use 0xf005) followed by another 32 bit number containing the version of the client 0x110b9500 ("1.1.2965.0") and so on.
the "dump" fields are referred to the strings contained in the packet, the first contains the password for joining the server (empty) and the second the mod in use.
now if you watch the source code of my bf2fp.c you will notice the same values and sizes:
Code:
b = write_bits(1, 4, buff, b);
b = write_bits(par1, 8, buff, b);
b = write_bits(par2, 32, buff, b);
b = write_bits(ver, 32, buff, b);
b = write_bits(1, 1, buff, b);
b = write_bits(0, 32, buff, b);
b = write_bstr(pass, 32, buff, b);
b = write_bstr(mod, 32, buff, b);
anyway keep in mind that bf2_sniff is experimental so some fields in its output could be mixed or chaotic, it was mainly a proof-of-concept I wrote for curiosity