[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] GPL Licensing issues

[Robin Getz]

The files in the examples directory - since everything needs to be linked 
to u-boot to work, and u-boot is released under the GPL, does that mean 
that custom user applications are also under the GPL - or do you use 
Linus's relationship of kernel/application separation?

Either is OK - I was just going to be talking to some people and wanted to 
make sure they understood things about how to keep their secret sauce to 
them selves.

I assume that if it does use U-Boot functions, then the application is a 
derivative work, and should be covered under the GPL (must make available 
source, per the GPL). If the application does not use any U-boot functions, 
it would not be classified a derivative work - because it could be stand 
alone program, and burned into flash without U-boot to load it.

I thought I would get the contributors/maintainers aspects before I started 
spreading nasty rumors and untruths - so can someone clarify things for me?

-Robin

[U-Boot-Users] GPL Licensing issues

[Marc Leeman]

> The files in the examples directory - since everything needs to be linked
> to u-boot to work, and u-boot is released under the GPL, does that mean
> that custom user applications are also under the GPL - or do you use
> Linus's relationship of kernel/application separation?

Didn't linux say that linking involves using the GPL. I remember a
discussion about this very topic a couple of months ago on the lkml
(about the nvidia modules).

As far as I am concerned, including GPL header files makes your
application GPL (since you implicitly verbatim copy code).

This being said, I have problems convincing collegues who are
convinced that they write a piece of 'original' code and don't want to
make it public...

-- 
ash nazg durbatul?k, ash nazg gimbatul,
ash nazg thrakatul?k agh burzum-ishi krimpatul

[U-Boot-Users] GPL Licensing issues

[Wolfgang Denk]

In message <1f729c4804092623274a63a453@mail.gmail.com> you wrote:
>
> As far as I am concerned, including GPL header files makes your
> application GPL (since you implicitly verbatim copy code).

Header files contain interfaces, not code.

Code is in source files per definition :-)

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
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot-Users] GPL Licensing issues

[Marc Leeman]

> Header files contain interfaces, not code.
> Code is in source files per definition :-)

In an ideal world with decent programmers, they are :)

In a something less than ideal world where ppl are bent on *cough*
optimising *cough* the code for reasons they only know, code can be
found anywhere...

Don't get me wrong, I fully agree with you, but in an environment
where engineers with an exclusive FPGA and hardware background write C
'firmware', one tends to see all kinds of code organisations :-/

As such, making the difference between *.c and *.h might not be the
best solution. But this is the OS vs FS software discussion again in
which I am not yet fully decided (I think)...

-- 
ash nazg durbatul?k, ash nazg gimbatul,
ash nazg thrakatul?k agh burzum-ishi krimpatul

[U-Boot-Users] GPL Licensing issues

[Marius Groeger]

On Mon, 27 Sep 2004, Marc Leeman wrote:

> Don't get me wrong, I fully agree with you, but in an environment
> where engineers with an exclusive FPGA and hardware background write C
> 'firmware', one tends to see all kinds of code organisations :-/

I'm not much of an EE, but I think it's too easy to always put the 
blame on those folks. I'm pretty sure there were some fine CS people 
involved in <asm/uaccess.h>... ;-)

Regards,
Marius

-- 
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com

[U-Boot-Users] GPL Licensing issues

[Marc Leeman]

> I'm not much of an EE, but I think it's too easy to always put the
> blame on those folks. I'm pretty sure there were some fine CS people
> involved in <asm/uaccess.h>... ;-)

<off topic>
Nah, 

I am just taking a personal example and try to generalise it, has
nothing to do with CS vs EE (Our software group wants to implement a
feature in the controlling software to show graphically and in real
time the loads of all the processes of the processors on the boards;
says enough).

Some ppl are just excellent FPGA coders, and are convinced they
exhibit the same skills after writing 200 lines of C code: resulting
in a lot of and long #defines and a lot of 'simple' functions on *.h
files.

Happy debugging :-/
</off topic>

-- 
ash nazg durbatul?k, ash nazg gimbatul,
ash nazg thrakatul?k agh burzum-ishi krimpatul

[U-Boot-Users] GPL Licensing issues

[Doug Kehn]

--- Wolfgang Denk <wd@denx.de> wrote:

> 
> Header files contain interfaces, not code.
> 
> Code is in source files per definition :-)
> 

Could this distinction become blurred as 'inline'
functions appear in header files?

Regards.
...doug


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

[U-Boot-Users] GPL Licensing issues

[Wolfgang Denk]

In message <20040927124041.76928.qmail@web51908.mail.yahoo.com> you wrote:
> 
> > Code is in source files per definition :-)
> 
> Could this distinction become blurred as 'inline'
> functions appear in header files?

It could. But it should not. At least such ehaders should not be used
to  define  interfaces  which  are  expected  to   be   exported   to
applications.

Let's bring it to a point: U-Boot is GPLed, and this is a Good Thing (TM).

There are cases where propriatary code needs  to  be  used  (for  one
reason  or  another,  not all of them being good reasons), and U-Boot
facilitates this by means of standalone applications.

This is the intention. From  what  I  know,  standalone  applications
don't  need  to  include  any headers or link against any files which
might give reason do  even  remotely  consider  this  as  creating  a
"derived work".

I will add an appropriate comment to the  COPYING  file  (similar  to
what  Linus  uses for the Linux kernel) to make this absolutely clear
to everybody. [Checked in right now.] If anybody asks, just point him
to the COPYING file.

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
Life. Don't talk to me about life.      - Marvin the Paranoid Android

[U-Boot-Users] GPL Licensing issues

[Wolfgang Denk]

In message <6.1.1.1.0.20040926174406.01e1d130@wheresmymailserver.com> you wrote:
> The files in the examples directory - since everything needs to be linked 
> to u-boot to work, and u-boot is released under the GPL, does that mean 
> that custom user applications are also under the GPL - or do you use 
> Linus's relationship of kernel/application separation?

Standalone applications only use exported U-Boot  services.  They  do
not  have  to  be linked against any U-Boot code. So ther eis no need
for  standalone  applications  to  be  GPLed  -  exactly   like   the
kernel/application separation in Linux.

> Either is OK - I was just going to be talking to some people and wanted to 
> make sure they understood things about how to keep their secret sauce to 
> them selves.

See http://www.denx.de/twiki/bin/view/UBootdoc/Presentation for some
materrial I prepared for soem U-Boot presentations myself; it covers
this topic in
http://www.denx.de/twiki/bin/view/UBootdoc/StandalonePrograms

> I assume that if it does use U-Boot functions, then the application is a 
> derivative work, and should be covered under the GPL (must make available 

But standalone applications doe not use U-Boot functions by  linking,
only through the exported interface. Just like Linux system calls.

> source, per the GPL). If the application does not use any U-boot functions, 
> it would not be classified a derivative work - because it could be stand 
> alone program, and burned into flash without U-boot to load it.

No. You can burn it into flash, but you still need U-boot to run it -
like you need  a  Linux  kernel  to  run  a  proprietary  application
program.


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
I am an atheist, thank God!

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