buglwIP - A Lightweight TCP/IP stack - Bugs: bug #20346, IPv4 broadcasts ?

 
 

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

bug #20346: IPv4 broadcasts ?

Submitter:  S. Ali Tokmen <alitokmen>
Submitted:  Wed 04 Jul 2007 03:53:25 PM UTC
   
 
Category:  IPv4 Severity:  3 - Normal
Item Group:  Feature Request Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Fri 06 Jul 2007 06:53:58 AM UTC, comment #7: 

Hello Zhenwei,

As Frédéric mentioned in his reply, the issue is on Analog Devices' side:

- During initialization, lwIP calls the external low_level_init function. That function does the initialization of the Ethernet hardware, and is of course hardware specific.
- That function takes as argument a pointer to a struct netif, which describes the Ethernet device to lwIP.
- By default, netif's flags are all set to false. As a result, IP broadcast, which is a feature requiring that flag to be set, is disabled by default.
- In the code example in lwIP's source code, the NETIF_FLAG_BROADCAST flag is being set. On the other hand, for some reason, Analog Devices didn't set this flag in their Ethernet driver.

Analog Devices has been made aware of the issue, and they've told me this problem will be fixed in their IDE's next major release (VisualDSP++ 5.0). This release should be out in late summer 2007.

Regards;

S. Ali Tokmen
http://ali.tokmen.com/

S. Ali Tokmen <alitokmen>
Thu 05 Jul 2007 09:43:36 PM UTC, comment #6: 


>However I am just curious why this problem cannot be fixed in lwip code. Any particular reason?


Hi Zhenwei,

Perhaps something is not clear: the bug is not in lwIP, but in the BF537 port of Analog Device. In fact, this is not even a bug, since the netif init HAVE TO set (or not) NETIF_FLAG_BROADCAST flag if you want to receive broadcast packets (decide which flags to set is done in the port or by the "application"). In this port, it doesn't seems to be set (I don't know why).

I use broadcast protocols with lwIP without any problems since 1.1.1 with my target. Since Ali fix the problem with the NETIF_FLAG_BROADCAST flag, we have close it as invalid.

About bug #17200, I can't tell, it's pretty old...

Note that with current CVS HEAD, there is some new flags to decide to set or not (like NETIF_FLAG_ETHARP), and some new options.


Frédéric Bernon <fbernon>
Group Member
Thu 05 Jul 2007 08:20:05 PM UTC, comment #5: 

After evaluate the fix discussed in previous post, I think this bug can be fixed in different place, lwip code or ADI code. There is another Bug #17200 seems to address the same issue. But we confirmed that fix for bug #17200 did not fix the broadcast problem. The fix mentioned here does fix the problem. However I am just curious why this problem cannot be fixed in lwip code. Any particular reason?

Zhenwei Chu

Zhenwei Chu <blackfin>
Thu 05 Jul 2007 08:47:06 AM UTC, comment #4: 

Ok, seen with S. Ali Tokmen...

Frédéric Bernon <fbernon>
Group Member
Thu 05 Jul 2007 07:34:27 AM UTC, comment #3: 

Yes, you're right, if they don't set NETIF_FLAG_BROADCAST, so ip_addr_isbroadcast will return NULL. In this case, the loop in line 256 (CVS HEAD)...

"for (netif = netif_list; netif != NULL; netif = netif->next) {"

will reach the end and netif will be NULL, since the ip_addr_isbroadcast call will "failed".

So, yes, close it and set the "Status" to "Invalid"...

Thank

Frédéric Bernon <fbernon>
Group Member
Thu 05 Jul 2007 07:22:05 AM UTC, comment #2: 

Hello, Frédéric

I'm using lwIP Version 1.2.0, ported to the BF537 platform by Analog Devices.

I've taken a look at the CVS head, and apparently the portion of code I'm talking about moved to lines 315-316. So it still is there, and without my modification broadcast still doesn't work on my machine...

On the other hand, after a short analysis, I've seen that the NETIF_FLAG_BROADCAST flag has not been set by Analog Devices! So the bug is not on your side, but on theirs.

I guess I will now close this bug report.

Thank you for your help.

S. Ali Tokmen
http://ali.tokmen.com/

S. Ali Tokmen <alitokmen>
Wed 04 Jul 2007 09:45:14 PM UTC, comment #1: 

Hi Ali,

Can you tell me which lwIP release you use? I don't find exactly this code in CVS HEAD. Is it in ip_input in this block of code ?

  /* packet not for us? */
  if (netif == NULL) {
  ...
  }

Perhaps you could attach or paste a more important sample of the file?

In a general way, lwIP support IPv4 broadcast, I use them to send&recv packets for my own "discovery" protocol. So, perhaps something is broken since last changes?

Frédéric Bernon <fbernon>
Group Member
Wed 04 Jul 2007 03:53:25 PM UTC, original submission:  

In the current implementation, IPv4 ignores broadcast packets. This results in the non-usability of services depending on broadcast (for example, NetBIOS name lookup).

This is where broadcast packets are stopped:

    (./src/core/ipv4/ip.c, lines 285-286)

   
    pbuf_free(p);
    return ERR_OK;

I've "fixed" it the following way but I guess it will let go too many packets:

    (./src/core/ipv4/ip.c, lines 285-286)


    // For broadcast support
    if( IPH_PROTO(iphdr) != IP_PROTO_UDP &&
        IPH_PROTO(iphdr) != IP_PROTO_UDPLITE )
    {
        pbuf_free(p);
        return ERR_OK;
    }

Thank you

S. Ali Tokmen
http://ali.tokmen.com/

S. Ali Tokmen <alitokmen>

 

(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 blackfin (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by alitokmen (Submitted the item)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-07-05 fbernon StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code