[U-Boot-Users] Issue with Ethernet operation in non-promiscuous mode.

[U-Boot-Users] Issue with Ethernet operation in non-promiscuous mode.

[Upakul Barkakaty]

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.

-- 
Regards,
Upakul Barkakaty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071227/f511dd3f/attachment.htm 

[U-Boot-Users] Issue with Ethernet operation in non-promiscuous mode.

[Ben Warren]

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

[U-Boot-Users] Issue with Ethernet operation in non-promiscuous mode.

[Upakul Barkakaty]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071227/f984368f/attachment.htm 

[U-Boot-Users] Issue with Ethernet operation in non-promiscuous mode.

[Ben Warren]

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