[U-Boot-Users] U-Boot not responding back to ARP requests?

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Robin Getz]

All:

I was doing some debugging of some networking issues I am seeing, and saw
something that I thought was strange. I am seeing the following:

If I set things up as U-Boot = 192.168.0.3 and cross over cable to U-boot 
on 192.168.0.2

 From U-boot, if I ping 192.168.0.2

The ethereal dump is something like:

U-Boot Broadcasts -> Who has 192.168.0.2? Tell 192.168.0.3
Server Reply      -> I do (192.168.0.3 is at aa.bb.cc.dd.ff.gg)
U-boot IMCP       -> ping request
Server IMCP       -> ping reply

And now U-boot stops, and goes back to the command prompt. (like it should)

Now the Server starts asking:

Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
It does that three times (once a second) every time that it sees a packet.

My question is - shouldn't U-Boot respond? I don't see it in the code (I 
see the rarp handler, but not a arp handler).

My problem is that I have many U-boot boards on the same network, and the 
network is being flooded with ARP traffic, as the routers try to figure out 
the U-Boot MAC<->IP associations.

Thanks
-Robin

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Wolfgang Denk]

Dear Robin,

in message <6.1.1.1.0.20040926124409.01e178d0@wheresmymailserver.com> you wrote:
> 
> I was doing some debugging of some networking issues I am seeing, and saw
> something that I thought was strange. I am seeing the following:

It's normal.

> And now U-boot stops, and goes back to the command prompt. (like it should)

At  this   point,   please   remember   that   U-Boot   is   strictly
single-tasking, and that it usually uses polled device drivers only.

> Now the Server starts asking:
> 
> Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
> Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
> Server Broadcasts -> who has 192.168.0.3? Tell 192.168.0.2
> It does that three times (once a second) every time that it sees a packet.

Why does your server do that? It just TALKED with 192.168.0.2, so  it
should  really  be able to remember which MAC address it used to send
the ICMP replies to.

> My question is - shouldn't U-Boot respond? I don't see it in the code (I 
> see the rarp handler, but not a arp handler).

Why should U-Boot respond? It has completed it's  network  task,  and
shut down the network driver. It does not even attemot to receive any
packets from the network any more.

> My problem is that I have many U-boot boards on the same network, and the 
> network is being flooded with ARP traffic, as the routers try to figure out 
> the U-Boot MAC<->IP associations.

For U-Boot this is a S.E.P. (Somebody Else's  Problem).  U-Boot  does
not care about this (and there is no reason why it should).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Where there's no emotion, there's no motive for violence.
	-- Spock, "Dagger of the Mind", stardate 2715.1

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Robin Getz]

Wolfgang Denk wrote:
>Why does your server do that? It just TALKED with 192.168.0.2, so  it 
>should  really  be able to remember which MAC address it used to send the 
>ICMP replies to.

The server is a stock 2.6.4 kernel (SuSe 9.1) - so I think that the issue 
might be wide spread. I will ask on the LKML why it does this.

>Why should U-Boot respond? It has completed it's  network  task,  and shut 
>down the network driver. It does not even attempt to receive any packets 
>from the network any more.

OK - this is more of a development issue than anything I guess - most 
people will not be having U-boot sit on their network for days on end, like 
I do now. I would be interested in understanding based on the lists usage - 
how many people use u-boot to load a kernel, vs just use it to run a 
standalone application as shown in the examples directory.

>For U-Boot this is a S.E.P. (Somebody Else's  Problem).

Yeah - my problem as soon as the network admin figures out what is going 
on, and tells me I can't have U-boot plugged into the network. :( There is 
so much ARP/RARP traffic that the subnet performance is about 1/10 of what 
it should be. So far the only person complaining was me, and now I will stop.

>U-Boot  does not care about this (and there is no reason why it should).

I agree (almost) - it is a development issue that is only a problem during 
bring up and testing of U-boot. There is no reason to change production 
level code to fix a development issue.

Thanks
-Robin

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Robert Schwebel]

Hi Robin, 

On Sun, Sep 26, 2004 at 05:44:02PM -0700, Robin Getz wrote:
> Yeah - my problem as soon as the network admin figures out what is going 
> on, and tells me I can't have U-boot plugged into the network. :( There is 
> so much ARP/RARP traffic that the subnet performance is about 1/10 of what 
> it should be. So far the only person complaining was me, and now I will 
> stop.

Just put your development network behind a machine with two network
cards; it is not the best idea to mix a lab net with the IT network
anyway. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] U-Boot not responding back to ARP requests?

[Wolfgang Denk]

In message <6.1.1.1.0.20040926172119.01e24fc0@wheresmymailserver.com> you wrote:
> 
> Yeah - my problem as soon as the network admin figures out what is going 
> on, and tells me I can't have U-boot plugged into the network. :( There is 
> so much ARP/RARP traffic that the subnet performance is about 1/10 of what 
> it should be. So far the only person complaining was me, and now I will stop.

I cannot believe this. How many boards do  you  have  connected,  how
often  o  they  boot,  and how much ARP traffic do you really have on
your net?

Yes, there may be some  ARP  traffic,  but  it  should  nbever  be  a
noticable network load.

> I agree (almost) - it is a development issue that is only a problem during 
> bring up and testing of U-boot. There is no reason to change production 
> level code to fix a development issue.

Ummm... no. We are focussed on development.  If  U-Boot  causes  real
problems  in  a development environment we have to address this, too.
But ARP? I cannot imagine that this is a real problem.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
       - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

[U-Boot-Users] U-Boot not responding back to ARP requests?

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Robert
> Schwebel
> Sent: Monday, September 27, 2004 1:09 AM
> To: Robin Getz
> Cc: u-Boot-Users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] U-Boot not responding back to ARP
> requests?
>
>
> Hi Robin,
>
> On Sun, Sep 26, 2004 at 05:44:02PM -0700, Robin Getz wrote:
> > Yeah - my problem as soon as the network admin figures out
> what is going
> > on, and tells me I can't have U-boot plugged into the
> network. :( There is
> > so much ARP/RARP traffic that the subnet performance is
> about 1/10 of what
> > it should be. So far the only person complaining was me,
> and now I will
> > stop.
>
> Just put your development network behind a machine with two network
> cards; it is not the best idea to mix a lab net with the IT network
> anyway.
>
> Robert
> --

Another option is to put a cheap firewall/router between your development LAN and the Co. LAN, at least until you have the bulk of the bugs out.  This keeps you from polluting the Co. LAN and keeps the Co. LAN from causing seemingly random misbehavior while you are working the bugs out.  Note that the heavier traffic of the Co. LAN (especially broadcast if you have Microsoft/Novel protocols running around on the Co. LAN) can be a Good Thing[tm] for flushing out some remaining ethernet bugs on your development target.  Don't ask me how I know ;-).

You can set the FW/R to have a "DMZ" machine... set the DMZ IP address to be your development target, then any packets sent to the FW/R's IP address will get forwarded to your development target's IP address.

The _best_ configuration (IMHO) is to have the FW/R and two cards in a PC, one connected to each LAN.  This gives a lot of flexibility without having to unplug/reconfigure your LANs.

Just as a piece of trivia: the LinkSys BEFSR81v3 and BEFSR41v3 (version 3 only, version 2 was OK) FW/Rs had a problem where they would respond to _every_ ARP request on the net with an ARP reply.  That made our co-workers really unhappy with the network performance which, in turn, made the IT department very unhappy.  We ended up with in an edict from the top that v3s were _not_ to be plugged into the network.  LinkSys fixed the BEFSR41v3 (4 port) FW/Rs pretty quickly, but it took them nearly a year to fix the less popular 8 port BEFSR81v3 FW/Rs.  Of course, we had been buying the 8 port version.  We were _not_ pleased.

gvb

******************************************
The following messages are brought to you by the Lawyers' League of IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************