lwIP - A Lightweight TCP/IP stack - Bugs: bug #26309, Implement SOF_BROADCAST
You are not allowed to post comments on this tracker with your current authentication level.
bug #26309: Implement SOF_BROADCAST
Submitter: | Frédéric Bernon <fbernon> | ||
Submitted: | Thu 23 Apr 2009 01:10:55 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Feature Request | Status: | Fixed |
Privacy: | Public | Assigned to: | fbernon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Jump to the original submission
Wed 29 Apr 2009 12:49:34 PM UTC, comment #21: |
Frédéric Bernon <fbernon> |
Sun 26 Apr 2009 05:59:32 PM UTC, comment #20: I do not really have a preference, but I also don't like to move away from the standard just to prevent breaking older applications running on lwIP.
|
Simon Goldschmidt <goldsimon> |
Sun 26 Apr 2009 05:52:35 PM UTC, comment #19: One option in opt.h will define the behavior of SO(F)_BROADCAST on recv operations we want. Two options (like I proposed) avoid to break any application.
|
Frédéric Bernon <fbernon> |
Sun 26 Apr 2009 05:33:24 PM UTC, comment #18: I must say I don't really favor adding too many options. Do we really need this option? Can't that be achieved by some flag for setsockopt like MS does it? That way we could prevent having yet another configuration option for this...
|
Simon Goldschmidt <goldsimon> |
Sun 26 Apr 2009 03:32:39 PM UTC, comment #17: yes, in my case, I prefer a LWIP_SO_BROADCAST_RECV opt.h option saying the scope of the SO(F)_BROADCAST flag.
|
Frédéric Bernon <fbernon> |
Sun 26 Apr 2009 02:51:24 PM UTC, comment #16:
|
Stephane Lesage <slesage> |
Sun 26 Apr 2009 12:37:41 PM UTC, comment #15: The best seems to get some opt.h options:
|
Frédéric Bernon <fbernon> |
Sun 26 Apr 2009 11:23:46 AM UTC, comment #14: On lwip-devel, Stéphane Lesage brought up this link:
|
Simon Goldschmidt <goldsimon> |
Fri 24 Apr 2009 12:31:31 PM UTC, comment #13: Stéphane, about your question :
|
Frédéric Bernon <fbernon> |
Fri 24 Apr 2009 10:10:47 AM UTC, comment #12: For send operations, changes are :
|
Frédéric Bernon <fbernon> |
Fri 24 Apr 2009 08:53:26 AM UTC, comment #11: I attach a patch for recv operations. It is based on raw_input & udp_input.
|
Frédéric Bernon <fbernon> |
Fri 24 Apr 2009 07:54:58 AM UTC, comment #10: I think SO_BROADCAST shouldn't affect TCP connections, so ip_input might not be the best.
|
Kieran Mansley <kieranm> |
Fri 24 Apr 2009 06:04:25 AM UTC, comment #9: I'd only favour ip_input because we can avoid having duplicate code and the filter is based on IPs, not ports (hence ip_input would be the correct filter level). |
Simon Goldschmidt <goldsimon> |
Thu 23 Apr 2009 07:46:27 PM UTC, comment #8: I think that the change in raw_input and in udp_input (sorry for the mistake in the previous post) is better, since inside ip_input, we don't manage pcbs, but we did in raw_input and in udp_input.
|
Frédéric Bernon <fbernon> |
Thu 23 Apr 2009 04:09:58 PM UTC, comment #7: ip_input vs (raw_sendto + udp_sendto_if), I will check where is the best place.
|
Frédéric Bernon <fbernon> |
Thu 23 Apr 2009 04:01:46 PM UTC, comment #6: I thought SOF_BROADCAST would say "don't accept broadcast data", not "don't queue received data for RX"? If so, those 2 features are not that similar to me. They both do RX filtering, but with different conditions.
|
Simon Goldschmidt <goldsimon> |
Thu 23 Apr 2009 03:00:40 PM UTC, comment #5: OK, it wasn't quite clear!
|
Kieran Mansley <kieranm> |
Thu 23 Apr 2009 02:52:56 PM UTC, comment #4: Implement SOF_BROADCAST is a "new" feature which will avoid some bugs.
|
Frédéric Bernon <fbernon> |
Thu 23 Apr 2009 02:43:36 PM UTC, comment #3: OK, I understand now: I didn't realise the traffic was coming from some other application and for some other device.
|
Kieran Mansley <kieranm> |
Thu 23 Apr 2009 02:32:51 PM UTC, comment #2: The problem is I received in my lwIP device's socket some broadcast traffic between another application (not mine) and another device (not mine).
|
Frédéric Bernon <fbernon> |
Thu 23 Apr 2009 01:35:33 PM UTC, comment #1: Can you explain how implementing SO_BROADCAST will solve the problem of the stack buffering data on RX?
|
Kieran Mansley <kieranm> |
Thu 23 Apr 2009 01:10:55 PM UTC, original submission:
I propose to implement SOF_BROADCAST option. I post that like a bug because without it, we could block the stack some cases. I explain:
|
Frédéric Bernon <fbernon> |
Depends on the following items: None found
Items that depend on this one: None found
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 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-05-01 | fbernon | Status | Ready For Test | Fixed | |
Open/Closed | Open | Closed | |||
2009-04-29 | kieranm | Status | Works For Me | Ready For Test | |
2009-04-29 | fbernon | Status | None | Works For Me | |
2009-04-24 | fbernon | Attached File | - | Added SOF_BROADCAST.txt, #18003 |
Powered by Savane 3.13-f8d8.
Corresponding source code
I have check in a first patch. Since this patch work on all API layers, I have name options IP_SOF_BROADCAST & IP_SOF_BROADCAST_RECV (since others IP_ levels options are prefixed like this).
These options are disabled as default values in opt.h. The default behavior is not change, so, it's compatible with previous releases.
IP_SOF_BROADCAST_RECV=1 requires IP_SOF_BROADCAST=1 (a check is done in init.c).
SO(F)_BROADCAST comments in ip.h & sockets.h tell to check these options.
Implement IP_RECEIVE_BROADCAST could be done as another task I think. The problem is to find something which is not too "windows-like".
If there is no comments, I will chose this task as done.