public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] U-Boot not responding back to ARP requests?
@ 2004-09-27  0:44 Robin Getz
  2004-09-27  5:08 ` Robert Schwebel
  2004-09-27  6:58 ` Wolfgang Denk
  0 siblings, 2 replies; 6+ messages in thread
From: Robin Getz @ 2004-09-27  0:44 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [U-Boot-Users] U-Boot not responding back to ARP requests?
@ 2004-09-27 12:57 VanBaren, Gerald
  0 siblings, 0 replies; 6+ messages in thread
From: VanBaren, Gerald @ 2004-09-27 12:57 UTC (permalink / raw)
  To: u-boot

> -----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.
******************************************

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [U-Boot-Users] U-Boot not responding back to ARP requests?
@ 2004-09-26 20:29 Robin Getz
  2004-09-26 22:47 ` Wolfgang Denk
  0 siblings, 1 reply; 6+ messages in thread
From: Robin Getz @ 2004-09-26 20:29 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-09-27 12:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-27  0:44 [U-Boot-Users] U-Boot not responding back to ARP requests? Robin Getz
2004-09-27  5:08 ` Robert Schwebel
2004-09-27  6:58 ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2004-09-27 12:57 VanBaren, Gerald
2004-09-26 20:29 Robin Getz
2004-09-26 22:47 ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox