This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Simultaneous LE and BR/EDR to Same Device Capable: false

Hoping someone can help. 

I am using an nRF52840 MDK USB dongle running nrf firmware in wireshark / nrf sniffer. I am attempting to sniff the bluetooth messages from my pool controller, so that i can then add the commands to an espcontroller (then add it into my home automation).

I am able so see and select the nrf sniffer for Bluetooth LE interface in the list in wireshark, then once selected, I can see the bluetooth pool controller in the list of devices in Wireshark.

I am able to see constantly updating SCAN_RSP, SCAN_SEQ and ADV_IND records in the list, while my iphone is NOT connected to the pool controller, but then once I connect to the bluetooth controller from my iPhone, the messages stop and I get a final message ADV_EXT_IND [malformed Packet]. Once i disconnect my phone from the pool controller, the messages start coming through again.

If i open one of the messages, I can see a value stating Simultaneous LE and BR/EDR to Same Device Capable (Host): false, and another stating Simultaneous LE and BR/EDR to Same Device Capable (Controller): false so i suspect i cannot connect multiple bluetooth devices to the controller. 

Is there a way to get around this to sniff the messages as i click buttons?

thanks in advance for your assistance

Parents
  • Hello,

    Please make sure you have selected your device in the dropdown menu here:

    This will make the sniffer track the connection between your peripheral device and phone. It will only listed for data on the advertisment channels otherwise.

    Best regards,

    Vidar

  • thanks for the prompt response. Can i just clarify one point.

    Currently, when I am attempting to sniff the pool controller, within the 'Device' dropdown, I am selecting the mac address of the pool controller, which produces constant resulting lines. However, when i attempt to connect to the pool controller from my phone, I get the message stating ADV_EXT_IND [malformed Packet]. and within the message, the value Simultaneous LE and BR/EDR to Same Device Capable (Host): false, and no other records are captured until i disconnect the connection from my phone

    What you are asking me to do is to NOT select the specific pool controller from the dropdown, connect using my phone, run the commands I want to sniff, then once I am done, Stop capturing results, and go through and review those results. If this is the case, I have attempted this, and I still get the ADV_EXT_IND [malformed Packet] error and no further messages are captured until i disconnect my phone

  • Hello,

    mikkaa said:
    Currently, when I am attempting to sniff the pool controller, within the 'Device' dropdown, I am selecting the mac address of the pool controller, which produces constant resulting lines. However, when i attempt to connect to the pool controller from my phone, I get the message stating ADV_EXT_IND [malformed Packet]

    This is actually what I meant you should do. You have to select the pool controller from the dropdown menu before you initiate the connection. Otherwise, the sniffer will just to listen to traffic on the adv. channels, and not attempt to follow the connection on the data channels after the central has sent the connect request (CONNECT_IND).

    Malformed packet means the packet was not received correctly by the sniffer (invalid checksum), so you can't really trust the payload to be correct. It may even be displaying the wrong packet type.

    You will almost always get some malformed packets in a sniffer trace due to noise from other devices operating on the same frequencies, but it sounds like you are getting this malformed packet every time you try to establish the connection, which is not normal. Would you mind uploading the full sniffer trace here?

    Here is an example of what it should look like when the sniffer is tracking a connecting between a peripheral and an iPhone:

    Complete trace:

    example.pcapng

  • Thank you for continuing to assist. I have attached the extract you were after (i hope).

    I connected to the pool controller from my phone at row 14

    disconnected at row 21

    connected at row 28

    disconnected after some time at row 28

    pool_sniffer.pcapng

  • Thanks for sharing the capture. It clearly shows that the sniffer is struggling to receive packets, which again reduces the probability of being able to capture the connect request. There are several missing packets in addition to those that are displayed as malformed.

    Please try the following to see if it improves the packet reception:

    1. Reduce the distance between the phone, sniffer and pool controller.

    2. Connect the dongle to another USB port in case it may be related to USB noise. This is not a common problem, but worth a try. Some USB hubs produce more noise than others.

    3. If possible, move your test setup to a different location that may potentially be less noisy.

  • Thank you again for your assistance. I sat the bluetooth connector (plugged into a different port in my laptop) within 20cm from the pool controller and was able to capture messages (thank you). I have attached them here for your perusal.

    Connection was made at 5854 and disconnection at 10280. I am pretty sure I sent around 6 commands from the phone/app,

    1. medium pump speed
    2. low pump speed
    3. high pump speed
    4. Auto controller
    5. Manual controller
    6. Disconnect

    Can i just ask, I assume the protocol ATT is communication between the phone (app) and the pool controller. Should I be looking at the Send Write Command and within that the Handle and Value as the message attributes. AND should i be able to find the Service and UUID?

     pool_sniffer_2.pcapng

    Thanks for all your assistance again, this has been very educational.

Reply
  • Thank you again for your assistance. I sat the bluetooth connector (plugged into a different port in my laptop) within 20cm from the pool controller and was able to capture messages (thank you). I have attached them here for your perusal.

    Connection was made at 5854 and disconnection at 10280. I am pretty sure I sent around 6 commands from the phone/app,

    1. medium pump speed
    2. low pump speed
    3. high pump speed
    4. Auto controller
    5. Manual controller
    6. Disconnect

    Can i just ask, I assume the protocol ATT is communication between the phone (app) and the pool controller. Should I be looking at the Send Write Command and within that the Handle and Value as the message attributes. AND should i be able to find the Service and UUID?

     pool_sniffer_2.pcapng

    Thanks for all your assistance again, this has been very educational.

Children
  • It's hard to say what caused the poor reception earlier, maybe it was just the range, but I am glad to hear that you are able to follow the connection now.

    mikkaa said:
    Can i just ask, I assume the protocol ATT is communication between the phone (app) and the pool controller. Should I be looking at the Send Write Command and within that the Handle and Value as the message attributes. AND should i be able to find the Service and UUID?

    Yes, you can see from the write request what the iPhone is sending to the pool controller. However, to know which characteristics it's writing to, you need to know how the attribute table is laid out on the server. This is not possible to tell with this sniffer trace alone because the iPhone did not perform a service discovery at the beginning of this connection, but rather relied on previously cached attribute handle values from the pool controller's GATT server.

    Value written to attribute handle 0x20 (unknown characteristic):

    Example of an attribute table (layout is found through the service discovery procedure):

    You can clear the cache on the iPhone by toggling Bluetooth enable in Settings->Bluetooth (note: toggling Bluetooth enable from the access control center will not have the same effect), and therefore force the phone to perform a new discovery on the next connection. If you then sniff the connection you should be able to see which UUIDs the attribute handles belong to.

    A more visual approach to finding out which characteristics the attribute handles are assigned to is to use the the Bluetooth Low energy app in nRF connect for desktop and connect it to your pool controller. There you can send write and read request to the various characteristics and the log view will show what handles it used.

  • That information is exceptional. Thank you very much for your help, and I will try out the nRF Connect desktop app to get the values. Thanks again for all your help.

Related