Incorrect feature parsing of --ll-feature-set results?

[jsmif]

I don't know how to get more verbose data out of bluing, but when I do a manual request for features to a given BD_ADDR, I see the following in btmon:

> HCI Event: LE Meta Event (0x3e) plen 12                                                                                                                                                                            #760 [hci0] 2023-05-05 21:06:52.178861
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 64
        Features: 0x1d 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Extended Reject Indication
          Peripheral-initiated Features Exchange
          LE Ping

When I do the same request using bluing, I see this:

LE LL Features:
    LE Encryption: True
    Connection Parameters Request Procedure: False
    Extended Reject Indication: False
    Slave-initiated Features Exchange: False
    LE Ping: False

I.e. note how things like LE Ping are listed as false in bluing, but are true in the raw hcitool-based connection + feature data. Are you sure you're parsing the feature response correctly? (I also checked a pcap that was saved with Sniffle, and it also confirms the OTA packets had a feature set of 0x000...1d, so LE Ping is set to true.)

[jsmif]

OK, this seems to be because I requested the data from two different machines, which sent two different LL_FEATURE_REQ values (and thus the target replied with different LL_FEATURE_RSP).