Hi Ben,<br><br>I have just tested this with the Ping and Dhcp commands. <br><br>Ping <serverip>: With Promiscuous mode enabled, the <serverip> is shown alive. When promiscuous mode is disabled, the <serverip> is shown to be not alive.
<br><br>Dhcp: With Promiscuous mode enabled, the device gets an IP address . When
promiscuous mode is disabled, it keeps broadcasting the Bootp packets, but is perhaps not able to receive the Bootp reply packets sent by the server.<br><br>The same Mac address works fine in case of Linux and Nucleus, so i think the Mac address should not be a problem.
<br><br>Regards,<br>Upakul Barkakaty<br><br><div class="gmail_quote">On Dec 27, 2007 9:00 PM, Ben Warren <<a href="mailto:bwarren@qstreams.com">bwarren@qstreams.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Upakul,<br><div><div></div><div class="Wj3C7c"><br>Upakul Barkakaty wrote:<br>> Hi all,<br>><br>> I am using an ethernet driver, working in Polling mode, ARM<br>> architecture. It works fine in Promiscuous mode. However, when the
<br>> promiscuous mode is disabled, then the network operations are not<br>> functional. Does the Uboot network stack have any limitation, or is it<br>> a bug in the ethernet driver itself? Please share your inputs.
<br>><br></div></div>Your description is a bit vague... I don't know what type of traffic<br>you're dealing with, what commands you're using etc. Enabling<br>promiscuous mode essentially bypasses any hardware MAC address matching
<br>that your controller does and thus lets everything in. Since that<br>works, the driver is probably fine, and I suspect that you haven't<br>properly configured a valid unicast MAC address.<br><br>regards,<br><font color="#888888">
Ben<br></font></blockquote></div>