lwIP - A Lightweight TCP/IP stack - Patches: patch #8994, dhcp: add support for vendor...
You are not allowed to post comments on this tracker with your current authentication level.
patch #8994: dhcp: add support for vendor specific options 43 and 60
Submitter: | Jan Breuer <jan_breuer> | ||
Submitted: | Sat 07 May 2016 09:56:23 AM UTC | ||
Category: | DHCP | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | goldsimon | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Tue 25 Apr 2017 06:21:20 PM UTC, comment #11: |
Simon Goldschmidt <goldsimon> |
Tue 25 Apr 2017 03:53:57 PM UTC, comment #10: It seems to be nice and universal solution for all issues like this. I'm working on another project now, so I can't test it soon. |
Jan Breuer <jan_breuer> |
Tue 25 Apr 2017 02:15:30 PM UTC, comment #9: Jan, I've attached file #40502 to task #14270. Would you mind checking if this does what you need? |
Simon Goldschmidt <goldsimon> |
Fri 12 Aug 2016 06:29:38 PM UTC, comment #8: Coming back on this:
|
Simon Goldschmidt <goldsimon> |
Tue 24 May 2016 10:48:34 AM UTC, comment #7:
|
Jan Breuer <jan_breuer> |
Tue 24 May 2016 10:33:31 AM UTC, comment #6:
|
Simon Goldschmidt <goldsimon> |
Tue 24 May 2016 09:42:27 AM UTC, comment #5: Yes, there is no retry and it will be lost.
|
Jan Breuer <jan_breuer> |
Mon 23 May 2016 08:25:18 PM UTC, comment #4: What happens if mem_calloc fails when parsing the server's response? There's no retry handling, so the information is lost. We should find a better way to handle the case where the response bytes are split among multiple pbufs. Maybe we can just pass the RX pbuf, start offset and length?
|
Simon Goldschmidt <goldsimon> |
Mon 23 May 2016 10:48:27 AM UTC, comment #3: Something like
|
Jan Breuer <jan_breuer> |
Mon 23 May 2016 08:07:51 AM UTC, comment #2: The patch looks OK, but the lwIP API design should provide functions (or function-like macros) to access struct members. Applications should not access struct members directly. Although this cannot really be checked in C (unless you hide the actual struct definition, which produces bad code), could you add such a function or macro for the new struct dhcp member? |
Simon Goldschmidt <goldsimon> |
Sat 07 May 2016 10:12:18 AM UTC, comment #1: File #37096 is the correct patch. I forget to add some changes in previous one. |
Jan Breuer <jan_breuer> |
Sat 07 May 2016 09:56:23 AM UTC, original submission:
Add feature LWIP_DHCP_VENDOR_SPECIFIC
|
Jan Breuer <jan_breuer> |
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 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-04-25 | goldsimon | Status | None | Done | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2016-05-23 | jan_breuer | Attached File | - | Added 0002-dhcp-vendor-specific-identifier-getter-setter.patch, #37235 | |
2016-05-07 | jan_breuer | Attached File | - | Added 0001-dhcp-add-support-for-vendor-specific-options-43-and-.patch, #37096 | |
2016-05-07 | jan_breuer | Attached File | - | Added 0001-dhcp-add-support-for-vendor-specific-options-43-and-.patch, #37095 |
Powered by Savane 3.13-d3ae.
Corresponding source code
In that case... I've just pushed it. Thanks for the fast response!
-> Done (although in a different way than origiginally proposed here)