Fix endianness of options field in CHANNEL_DEF

[JiajunW]

No description provided.

[JiajunW]

The options field should be little-endian.

The example packet is recorded in MS-RDPBCGR section 4.1.3:

03 00 00 00 -> TS_UD_CS_NET::channelCount = 3
72 64 70 64 72 00 00 00 -> CHANNEL_DEF::name = "rdpdr"
00 00 80 80 -> CHANNEL_DEF::options = 0x80800000
0x80800000
= 0x80000000 | 0x00800000
= CHANNEL_OPTION_INITIALIZED | CHANNEL_OPTION_COMPRESS_RDP
63 6c 69 70 72 64 72 00 -> CHANNEL_DEF::name = "cliprdr"
00 00 a0 c0 -> CHANNEL_DEF::options = 0xc0a00000
0xc0a00000
= 0x80000000 |
 0x40000000 |
 0x00800000 |
 0x00200000
= CHANNEL_OPTION_INITIALIZED |
 CHANNEL_OPTION_ENCRYPT_RDP |
 CHANNEL_OPTION_COMPRESS_RDP |
 CHANNEL_OPTION_SHOW_PROTOCOL
72 64 70 73 6e 64 00 00 -> CHANNEL_DEF::name = "rdpsnd"
00 00 00 c0 -> CHANNEL_DEF::options = 0xc0000000
0xc0000000
= 0x80000000 | 0x40000000
= CHANNEL_OPTION_INITIALIZED |
 CHANNEL_OPTION_ENCRYPT_RDP

[CendioOssman]

Hmm... Odd. The code has been like this for ages an things have worked fine. Have you seen any practical issues?

We would need to re-test these channels to make sure such a change doesn't break anything.

[JiajunW]

I haven't see any issues right now. I just analyze the network trace and found the endianness is incorrect.

[CendioOssman]

Alright, great.

I'm afraid I don't have time to test this right now. But I'll leave this PR open and hopefully someone can verify things and we can merge it.

[ThomasAdam]

Hi @JiajunW,

This change makes sense to me given the packet capture is indicating a change in endianness. Have you been able to test this sufficiently that you've not seen any negative impact?

[JiajunW]

No I have not done a thorough testing. But I have not seen anything broken by this change.