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 ?

Submitted by:  S. Ali Tokmen <alitokmen>
Submitted on:  Wed 04 Jul 2007 03:53:25 PM UTC  
 
Category: IPv4Severity: 3 - Normal
Item Group: Feature RequestStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: None

(Jump to the original submission 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>
Project 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>
Project 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>
Project 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>
Project 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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by blackfin (Posted a comment)
  • -unavailable- added by fbernon (Posted a comment)
  • -unavailable- added by alitokmen (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 05 Jul 2007 08:47:06 AM UTCfbernonStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1