<div dir="ltr">I figured out that my driver was not sending a zero length packet after receiving the RNDIS Initialize message.  This fixed the problem above, and now I am on to debugging the next issue.<div><br></div><div>Thanks</div><div>Trampas</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2025 at 9:50 AM Trampas Stern <<a href="mailto:trampas@gmail.com">trampas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I am trying to do USB RNDIS enumeration and having issues.  I have googled and read everything I can find and keep running into issues.   I get the enumeration working and it will work for days on my PC, then at some point it will not work.   I switch hubs, ports and it might work again for days, then stop. <br><br>I have been using Saleae logic analyzer as well as USB protocol analyzer (Total Phase Beagle device) and have been unable to figure out the issues.   <br><br>My initial thoughts were that Microsoft was doing some predictive analysis on device timing.  That is, I noticed that if the USB request from the host came in too quickly it would cause issues.   I figured that based on the packet NAKs that Microsoft might dynamically change request timing to compensate for slower devices.  I figure this would maximize the bus bandwidth utilization by not sending packets that most likely would be NAK'd.  I am not sure if this is true or not, but sounded reasonable?   I since changed my device to be all interrupt driven for fastest response.  This addressed some issues, but not all of my problems. <div><br></div><div>Now I seem to have hit another issue.  The host sends an RNDIS Initialize message, after which I setup device's USB peripheral to send the RESPONSE_AVAILABLE message, however the host never seems to poll for the RESPONSE_AVAILABLE  and then timeout on the RNDIS Initialize message.   <br><br>I have previously seen this behavior and found that if I delayed setting up the RESPONSE_AVAILABLE message it would sometimes work.  Specifically, I would send the REPONSE_AVAILABLE using main loop verses right away in the interrupt handler and it would work most of the time.  This did not make any sense as that as I understand it the host has to poll for the RESPONSE_AVAILABLE so the timing of configuring peripheral to send message should not matter, since it is all host driven system.  As I understand it the host does an interrupt polling messages to the RNDIS command end point to request the RESPONSE_AVAILABLE.  I am not seeing and polling message from host (Windows) on the RNDIS interrupt end point.  I do see EP0 polling, but not ones on the RNDIS command endpoint. </div><div><br>I was wondering if anyone had experience with USB and  possibly could offer some advice, education, or help.  I do have all kinds of data captures and logs etc.. </div><div><br></div><div>Thanks! </div><div>Trampas</div><div><br></div></div>
</blockquote></div>