[U-Boot-Users] Issue with Ethernet operation in non-promiscuous mode.
Hi all,
I am using an ethernet driver, working in Polling mode, ARM architecture. It works fine in Promiscuous mode. However, when the promiscuous mode is disabled, then the network operations are not functional. Does the Uboot network stack have any limitation, or is it a bug in the ethernet driver itself? Please share your inputs.
Hi Upakul,
Upakul Barkakaty wrote:
Hi all,
I am using an ethernet driver, working in Polling mode, ARM architecture. It works fine in Promiscuous mode. However, when the promiscuous mode is disabled, then the network operations are not functional. Does the Uboot network stack have any limitation, or is it a bug in the ethernet driver itself? Please share your inputs.
Your description is a bit vague... I don't know what type of traffic you're dealing with, what commands you're using etc. Enabling promiscuous mode essentially bypasses any hardware MAC address matching that your controller does and thus lets everything in. Since that works, the driver is probably fine, and I suspect that you haven't properly configured a valid unicast MAC address.
regards, Ben
Hi Ben,
I have just tested this with the Ping and Dhcp commands.
Ping <serverip>: With Promiscuous mode enabled, the <serverip> is shown alive. When promiscuous mode is disabled, the <serverip> is shown to be not alive.
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.
The same Mac address works fine in case of Linux and Nucleus, so i think the Mac address should not be a problem.
Regards, Upakul Barkakaty
On Dec 27, 2007 9:00 PM, Ben Warren bwarren@qstreams.com wrote:
Hi Upakul,
Upakul Barkakaty wrote:
Hi all,
I am using an ethernet driver, working in Polling mode, ARM architecture. It works fine in Promiscuous mode. However, when the promiscuous mode is disabled, then the network operations are not functional. Does the Uboot network stack have any limitation, or is it a bug in the ethernet driver itself? Please share your inputs.
Your description is a bit vague... I don't know what type of traffic you're dealing with, what commands you're using etc. Enabling promiscuous mode essentially bypasses any hardware MAC address matching that your controller does and thus lets everything in. Since that works, the driver is probably fine, and I suspect that you haven't properly configured a valid unicast MAC address.
regards, Ben
Hi Upakul,
Please don't top-post.
Upakul Barkakaty wrote:
Hi Ben,
I have just tested this with the Ping and Dhcp commands.
Ping <serverip>: With Promiscuous mode enabled, the <serverip> is shown alive. When promiscuous mode is disabled, the <serverip> is shown to be not alive.
I think you need to run Wireshark (Ethereal) to find out what's going on. In particular, is the SA of the ARP and ICMP requests what you expect, and what is the DA of the responses.
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.
The same Mac address works fine in case of Linux and Nucleus, so i think the Mac address should not be a problem.
Yeah, but the OS may program the MAC address (I can't keep up with the MAC address programming controversy in ARM Linux, and don't know enough about Nucleus). Just run Wireshark. It should shed lots of light.
Regards, Upakul Barkakaty
regards, Ben
participants (2)
-
Ben Warren -
Upakul Barkakaty