tasklwIP - A Lightweight TCP/IP stack - Tasks: task #1551, Make ARP more independent of...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #1551: Make ARP more independent of interface hardware type

Submitter:  Leon Woestenberg <likewise>
Submitted:  -
   
 
Category:  ARP Should Start On:  Fri 18 Oct 2002 12:00:00 AM UTC
Should be Finished on:  Fri 18 Oct 2002 12:00:00 AM UTC Priority:  1 - Later
Status:  Cancelled Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Closed Planned Release:  None
Effort:  50.00

Jump to the original submission

Thu 26 Feb 2015 07:42:49 PM UTC, comment #14: 

If anyone really needs this, please open a bug for it and I'll help implementing it. However, we'd need specific knowledge of what's wrong with the current implementation.

Simon Goldschmidt <goldsimon>
Group administrator
Mon 18 Jun 2007 07:56:23 PM UTC, comment #13: 

Setting this as 'postponed' and 'later' since we don't have the need and the info to do it.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 09 May 2007 01:17:11 PM UTC, comment #12: 


>What about DHCP in this case?


And SNMP, too. I would make it function pointers in struct netif which would be filled on creating the netif. The downside would be that the function calls wouldn't be hardcoded any more, which would reduce the performance a little...

Simon Goldschmidt <goldsimon>
Group administrator
Wed 09 May 2007 12:36:36 PM UTC, comment #11: 


>>It seems to me that we can reuse etharp.c with some modifications.
>
>
>As far as I can see it, what can be reused is
>- finding an arp entry
>- the calling structure (netif->input calls arp_output which calls netif->linkoutput)
>

And packet buffering (when sending to an unresolved IP address)

>But since the arp table (and maybe some functions as entrypoints), I think it would be best to create another ARP module and link it instead of etharp.
>
>>A specific arp.c module for each interface where entry points are set in the netif structure.
>
>
>If used simultaneously, I think this would be the best solution as I don't see much code can be reused. (If we make it clear etharp.c is only for ethernet, we can also have some speedup by defining hwaddr_len to always be 6.)
>


What about DHCP in this case ?

>>I work on it when I have time.
>
>
>Take your time, I don't see this as a pressing issue as long as >nobody uses it (aside from you :)


Unfortunately, you are right.

Nicolas Pinault <nicolasp>
Wed 09 May 2007 09:32:12 AM UTC, comment #10: 


>It seems to me that we can reuse etharp.c with some modifications.


As far as I can see it, what can be reused is
- finding an arp entry
- the calling structure (netif->input calls arp_output which calls netif->linkoutput)

But since the arp table (and maybe some functions as entrypoints), I think it would be best to create another ARP module and link it instead of etharp.

>A specific arp.c module for each interface where entry points are set in the netif structure.


If used simultaneously, I think this would be the best solution as I don't see much code can be reused. (If we make it clear etharp.c is only for ethernet, we can also have some speedup by defining hwaddr_len to always be 6.)

>I work on it when I have time.


Take your time, I don't see this as a pressing issue as long as nobody uses it (aside from you :)

Simon Goldschmidt <goldsimon>
Group administrator
Wed 09 May 2007 08:27:30 AM UTC, comment #9: 

Unfortunately I don't have much time to spend on this topic.
I work on it when I have time.
It seems to me that we can reuse etharp.c with some modifications.
Globaly, I can see to roads :
- A universal arp.c module working together with a specific arpif.c module for each interface.
- A specific arp.c module for each interface where entry points are set in the netif structure.


Nicolas Pinault <nicolasp>
Fri 04 May 2007 07:45:29 PM UTC, comment #8: 

I've had another look at ARP for IEEE1394 and it seems to me it is completely different from ARP for IEE802.3. Maybe this is the reason our file is named etharp? :-)

I don't think we can re-use much...

Simon Goldschmidt <goldsimon>
Group administrator
Thu 19 Apr 2007 11:36:46 AM UTC, comment #7: 

I'm new to lwip and I have to admit that I have hard time trying to understand lwip architecture.
I may be able to answer your question later when my knowledge will be better.

Nicolas Pinault <nicolasp>
Thu 19 Apr 2007 08:06:16 AM UTC, comment #6: 

I've had a quick look at RFC2734. Ignoring the fact the etharp is used from dhcp.c (and maybe netif.c and tcpip.c, but that's a define), do you need any modifications in the rest of the stack (aside from a new module like 1394arp.c and a configurable NETIF_MAX_HWADDR_LEN)?

I'd imagine (if the code in etharp.c cannot be somehow reused) to create a module 1394.c, make NETIF_MAX_HWADDR_LEN comfigurable (and maybe change dhcp). Since etharp is otherwise only used from ethernetif.c, that should be enough. Or am I wrong?

Simon Goldschmidt <goldsimon>
Group administrator
Wed 18 Apr 2007 07:32:02 PM UTC, comment #5: 

I've forgotten to say that I may have to use IP over USB. Of course, I will have the same problem as with Firewire.

Nicolas Pinault <nicolasp>
Wed 18 Apr 2007 07:30:10 PM UTC, comment #4: 

My comment is : It is necessary to do it to make lwip more portable.
I'm currently porting lwip on a system using IEEE1394 (FireWire) as physical media. There is a standart specifying how to transport IP packets on this media : IP over Ieee1394 (RFC2734)
As FireWire does not work like ethernet, ARP is done differently on  a FireWire network.
This leads me to create a bad hack to make it work with lwip.

Nicolas Pinault <nicolasp>
Mon 05 Mar 2007 09:16:02 AM UTC, comment #3: 

I'd regard this as relatively low priority, unless someone has a particular need or desire to change it.

Kieran Mansley <kieranm>
Group Member
Fri 02 Mar 2007 06:14:04 PM UTC, comment #2: 

Can someone comment on this? Does it make sense to make ARP independent of ethernet?

Personally, I also thought ARP was only for ethernet (802.3), so I think this is not needed, is it?

Simon Goldschmidt <goldsimon>
Group administrator
Mon 25 Nov 2002 10:06:44 AM UTC, comment #1: 

But isn't ARP specifically related to IP and 802.3 ?
how should it work with ATM and PPP?

Jani Monoses <jani>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nicolasp (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-26 goldsimon StatusPostponed Cancelled
        Open/ClosedOpen Closed
    2007-06-18 goldsimon Priority3 - Low 1 - Later
        StatusNone Postponed
    2007-03-05 kieranm Priority5 - Normal 3 - Low
    2007-03-02 goldsimon Percent CompleteNone 0%
        Carbon-Copy- Added -email is unavailable-
    2002-11-25 jani start_date1034978400
        end_date1034978400

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code