Hi, @ArthurC
Thanks for your feedback. Please see below inline replies:
Why is NXP making the auto_fw_reload enabled(default)?
[Christine]: This parameter is used when firmware crashed if meet some unknown errors, and works as a reset strategy so that Wi-Fi can continue to work.
Is there known expected issue to NXP's product needed to re-init the FW?
[Christine]:If there is any known issue, we will fix it in the newer firmware and mentioned in our release note.
We didn't do any nmcli command to reconnect during iperf3 test. Why should we do this thing to break our test?
[Christine]:I can understand that this action from nmcli to do disconnect and reconnect is not your expected behavior, or not do it deliberately. But from given logs, it shows that this is from nmcli side. Sometimes some app will do some thing in the background or be effected by some thing else.
How do NXP make sure NXP's driver & FW is OK?
[Christine]: There might be some misunderstandings between us. We are not saying that NXP's driver & FW is totally OK without any issue. Just mentioned, the disconnected and reconnection issue is not from NXP's driver and FW side, and we concluded this from previous given logs. But we admit that the scan timeout 0x107 error is from NXP side, so we request you to test with our new release + our patch. And for the new release + patch, we did test locally, we didn't see this scan timeout 0x107 error.
Why the latest driver is more stable than previous one?
[Christine]: We always fix some issues reported by our internal test team or reported by some of our customer in the newer release. Or add some features in the new release. So in theory, newer release is more recommended to customer.
Why issue will not be occurred in 5G Hz Wi-Fi?
[Christine]: It should because BT is working in 2.4G Hz. But we need logs to show where we have to improve in 2.4G Hz.
Why issue is not occurred in bcm4356a2?
[Christine]: I can understand your situation and your concerns. With same test environment and same test steps, issue is not seen on other products. But to identify why it doesn't see on other products and why it only happens on our product, we need logs to compare. We suspect there is not same behavior from nmcli even you do same thing in front, but there might some thing else effect nmcli to have different behaviors.
Is this NXP's service quality?
[Christine]: I have to say sorry and apologize if my support is not satisfied you. But as mentioned several times, we need logs to find evidence to show it is our issue then we can do something from our side. I can also understand that there are so many things to improve on our products, but we have to improve them through comparing and logs. Also thank you so much for the long-term corporation on this case. If I am a customer using this product, this kind of using experience can also not make me satisfied, but please also understand our situation, without logs showing, we will stuck here.
So, please help on below request:
1. Are you still continuing the test or you have stopped the test with Q2-24 release + patch?
2.You mentioned our latest release is more stable than previous one, do you mean only the latest release? or with our patch? Did you also test without patch?
3.Can you please provide us logs based on Q2-24 release + patch? So that we can confirm:
a) Our patch worked or not?
b)Identify whether the disconnection and reconnection is because of nmcli's new activation.
Best regards,
Christine.
