[lwip-users] compiling lwip using arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi

2024-01-23 Thread massimiliano cialdi via lwip-users

Hello,
I am trying to compile with gcc 13.2 (from 
arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi)
I have some warnings when compile dhcp.c, and I cannot understand why:

In function 'dhcp_option_byte',
   inlined from 'dhcp_discover' at 
ThirdParties/lwip/src/core/ipv4/dhcp.c:1053:25:
ThirdParties/lwip/src/core/ipv4/dhcp.c:1453:30: warning: writing 1 byte into a 
region of size 0 [-Wstringop-overflow=]
1453 |   options[options_out_len++] = value;
 |   ~~~^~~
In file included from ThirdParties/lwip/src/include/lwip/arch.h:48,
from src/config/lwipopts.h:445,
from ThirdParties/lwip/src/include/lwip/opt.h:51,
from ThirdParties/lwip/src/core/ipv4/dhcp.c:66:
ThirdParties/lwip/src/include/lwip/prot/dhcp.h: In function 'dhcp_discover':
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:26: note: at offset 68 into 
destination object 'options' of size 68
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |  ^~~
bsp/lwip/port/arch/cc.h:83:30: note: in definition of macro 'PACK_STRUCT_FIELD'
  83 | #define PACK_STRUCT_FIELD(x) x
 |  ^
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:3: note: in expansion of 
macro 'PACK_STRUCT_FLD_8'
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |   ^
In function 'dhcp_option_byte',
   inlined from 'dhcp_reboot.isra' at 
ThirdParties/lwip/src/core/ipv4/dhcp.c:1291:25:
ThirdParties/lwip/src/core/ipv4/dhcp.c:1453:30: warning: writing 1 byte into a 
region of size 0 [-Wstringop-overflow=]
1453 |   options[options_out_len++] = value;
 |   ~~~^~~
ThirdParties/lwip/src/include/lwip/prot/dhcp.h: In function 'dhcp_reboot.isra':
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:26: note: at offset 68 into 
destination object 'options' of size 68
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |  ^~~
bsp/lwip/port/arch/cc.h:83:30: note: in definition of macro 'PACK_STRUCT_FIELD'
  83 | #define PACK_STRUCT_FIELD(x) x
 |  ^
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:3: note: in expansion of 
macro 'PACK_STRUCT_FLD_8'
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |   ^
In function 'dhcp_option_byte',
   inlined from 'dhcp_select.isra' at 
ThirdParties/lwip/src/core/ipv4/dhcp.c:478:25:
ThirdParties/lwip/src/core/ipv4/dhcp.c:1453:30: warning: writing 1 byte into a 
region of size 0 [-Wstringop-overflow=]
1453 |   options[options_out_len++] = value;
 |   ~~~^~~
ThirdParties/lwip/src/include/lwip/prot/dhcp.h: In function 'dhcp_select.isra':
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:26: note: at offset 68 into 
destination object 'options' of size 68
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |  ^~~
bsp/lwip/port/arch/cc.h:83:30: note: in definition of macro 'PACK_STRUCT_FIELD'
  83 | #define PACK_STRUCT_FIELD(x) x
 |  ^
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:3: note: in expansion of 
macro 'PACK_STRUCT_FLD_8'
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |   ^
In function 'dhcp_option_byte',
   inlined from 'dhcp_renew' at ThirdParties/lwip/src/core/ipv4/dhcp.c:1179:25:
ThirdParties/lwip/src/core/ipv4/dhcp.c:1453:30: warning: writing 1 byte into a 
region of size 0 [-Wstringop-overflow=]
1453 |   options[options_out_len++] = value;
 |   ~~~^~~
ThirdParties/lwip/src/include/lwip/prot/dhcp.h: In function 'dhcp_renew':
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:26: note: at offset 68 into 
destination object 'options' of size 68
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |  ^~~
bsp/lwip/port/arch/cc.h:83:30: note: in definition of macro 'PACK_STRUCT_FIELD'
  83 | #define PACK_STRUCT_FIELD(x) x
 |  ^
ThirdParties/lwip/src/include/lwip/prot/dhcp.h:90:3: note: in expansion of 
macro 'PACK_STRUCT_FLD_8'
  90 |   PACK_STRUCT_FLD_8(u8_t options[DHCP_OPTIONS_LEN]);
 |   ^

Do you guys have any idea?

best regards

Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 7350230
<http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> 
[cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft>  
[cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] 
<https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com>  
[cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> 
<https://www.linkedin.com/company/

Re: [lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS

2022-06-22 Thread massimiliano cialdi via lwip-users

sorry,

my fault


best regards

Max

Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 7350230
<http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> 
[cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft>  
[cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] <https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com>  
[cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> 
<https://www.linkedin.com/company/powersoft>  [cid:YT_c74db1a3-a814-4e66-b04f-15ff9bd7940d.png] 
<https://www.youtube.com/user/powersoftaudio> <https://www.youtube.com/user/powersoftaudio>  
[cid:IG_b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/> 
<https://www.instagram.com/powersoft.audio/>  <http://www.powersoft-audio.com/en/>




On 21/06/22 20:56, goldsi...@gmx.de<mailto:goldsi...@gmx.de> wrote:
Am 21.06.2022 um 12:37 schrieb massimiliano cialdi via lwip-users:
hello,

the setsockopt(SO_RCVTIMEO) POSIX call contemplates the possibility of
imposing 0 as the 'timeout' parameter, and in that case that socket
becomes non-blocking (See, for example,
https://stackoverflow.com/questions/49706883/disable-socket-timeout-via-setsockopt).


Sorry, but stackoverflow is *not* a good source to cite when talking
about POSIX standard.

Instead, I prefer to search opengroup.com and on the 'setsockopt' page
google gives me
(https://pubs.opengroup.org/onlinepubs/95399/functions/setsockopt.html),
I find this in the description of SO_RCVTIMEO:

"The default for this option is zero, which indicates that a receive
operation shall not time out."

BTW, even the stackoverflow page you cited says: "If the timeout is set
to zero (the default) then the operation will never timeout".

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS

2022-06-21 Thread massimiliano cialdi via lwip-users

hello,

the setsockopt(SO_RCVTIMEO) POSIX call contemplates the possibility of imposing 
0 as the 'timeout' parameter, and in that case that socket becomes non-blocking 
(See, for example, 
https://stackoverflow.com/questions/49706883/disable-socket-timeout-via-setsockopt).

The socket API of lwip does not match this behavior. Or am I mistaken?
Would it be possible to impose the underlying netconn as nonblocking (using 
e.g. `netconn_set_nonblocking()`) when the timeout is 0? Am I oversimplifying?

best Regards

Max

Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 7350230
<http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> 
[cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft>  
[cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] <https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com>  
[cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> 
<https://www.linkedin.com/company/powersoft>  [cid:YT_c74db1a3-a814-4e66-b04f-15ff9bd7940d.png] 
<https://www.youtube.com/user/powersoftaudio> <https://www.youtube.com/user/powersoftaudio>  
[cid:IG_b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/> 
<https://www.instagram.com/powersoft.audio/>  <http://www.powersoft-audio.com/en/>




On 20/06/22 21:17, goldsi...@gmx.de<mailto:goldsi...@gmx.de> wrote:
Am 20.06.2022 um 11:22 schrieb massimiliano cialdi via lwip-users:
hello,

I am using lwip 2.1.3 and contrib 2.1.0.
in the ports/freertos/sys_arch.c file there is the sys_arch_mbox_fetch()
function, in which there is the timeout_ms parameter.
Given the name I expect the sys_arch_mbox_fetch() function to be
blocking for a maximum time corresponding to timeout_ms milliseconds.
I see this piece of code, though:

  if (!timeout_ms) {
/* wait infinite */
ret = xQueueReceive(mbox->mbx, &(*msg), portMAX_DELAY);
LWIP_ASSERT("mbox fetch failed", ret == pdTRUE);
  } else {

I wonder why I should wait infinitely if I set the timeout to 0 (so I
want it non-blocking)? is this a bug?

See the documentation of that parameter in sys.h:
@param timeout maximum time (in milliseconds) to wait for a message (0 =
wait forever)

It's a bit unfortunate, but it has been like that since forever (0 =
wait forever). The code uses sys_arch_mbox_tryfetch() when it does not
want to block at all.


In fact, it happens to me occasionally (I have yet to figure out the
conditions) that even though I have the timeout set to 0, re-read with
lwip_getsockopt(SO_RCVTIMEO), the task blocks indefinitely while waiting
for a message in the queue.

That would be odd. Please report a fix if you find one.

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] sys_arch_mbox_fetch() implementation for FreeRTOS

2022-06-20 Thread massimiliano cialdi via lwip-users

hello,

I am using lwip 2.1.3 and contrib 2.1.0.
in the ports/freertos/sys_arch.c file there is the sys_arch_mbox_fetch() 
function, in which there is the timeout_ms parameter.
Given the name I expect the sys_arch_mbox_fetch() function to be blocking for a 
maximum time corresponding to timeout_ms milliseconds.
I see this piece of code, though:

 if (!timeout_ms) {
   /* wait infinite */
   ret = xQueueReceive(mbox->mbx, &(*msg), portMAX_DELAY);
   LWIP_ASSERT("mbox fetch failed", ret == pdTRUE);
 } else {

I wonder why I should wait infinitely if I set the timeout to 0 (so I want it 
non-blocking)? is this a bug?


In fact, it happens to me occasionally (I have yet to figure out the 
conditions) that even though I have the timeout set to 0, re-read with 
lwip_getsockopt(SO_RCVTIMEO), the task blocks indefinitely while waiting for a 
message in the queue.


best regards

Max

Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 7350230
<http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> 
[cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft>  
[cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] <https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com>  
[cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> 
<https://www.linkedin.com/company/powersoft>  [cid:YT_c74db1a3-a814-4e66-b04f-15ff9bd7940d.png] 
<https://www.youtube.com/user/powersoftaudio> <https://www.youtube.com/user/powersoftaudio>  
[cid:IG_b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/> 
<https://www.instagram.com/powersoft.audio/>  <http://www.powersoft-audio.com/en/>



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] Listening PCBs updating address issue

2022-05-03 Thread massimiliano cialdi via lwip-users

Hello,

I have a similar problem (maybe the same?).

Not only with listening TCP sockets but also with already open TCP sockets. 
When the IP address changes the lwip stack has unexpected behavior. Sometimes 
no more data arrives, sometimes it arrives but the source address is wrong, 
sometimes it arrives whether the sender sends to the old or to the new address.

One of the scenarios in which this happens is the following: I have LWIP_DHCP, 
LWIP_AUTOIP, LWIP_DHCP_AUTOIP_COOP set to 1. My application starts but there is no DHCP 
server in the network, so it assigns itself an autoip address (169.254.x.x). Afterwards a 
DHCP server is connected to the network, and my application will receive a new address 
when it queries it. From that point on the lwip stack seems to "break".

I use lwip STABLE-2_1_3_RELEASE (commit 
6ca936f6b588cee702c638eee75c2436e6cf75de)

best regards

Max



On 29/04/22 15:18, Amena El Homsi wrote:
Hi,

When we call netif_remove(), tcp_netif_ip_addr_changed() is called. In this 
case old_addr is not null and new_addr is null, which means that 
tcp_netif_ip_addr_changed_pcblist() will be called to abort active and bound 
pcbs.
However, since new_addr is null, the listening pcbs are not updated and they 
are still listening to the old addr.
When we start a new DHCP session and we get an IP address, 
tcp_netif_ip_addr_changed() is called. However, since old_addr is NULL, the 
listening PCBs will not be updated.

We should have a way to update the listening PCBs ip address even when the 
old_addr is null. Am I right or wrong?

--

Amena El-Homsi
Computer & Communication Engineer
Dipl. Eng,  M.S.



___
lwip-users mailing list
lwip-users@nongnu.org<mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users


Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 7350230
<http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> 
[cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft>  
[cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] <https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com>  
[cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> 
<https://www.linkedin.com/company/powersoft>  [cid:YT_c74db1a3-a814-4e66-b04f-15ff9bd7940d.png] 
<https://www.youtube.com/user/powersoftaudio> <https://www.youtube.com/user/powersoftaudio>  
[cid:IG_b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/> 
<https://www.instagram.com/powersoft.audio/>  <http://www.powersoft-audio.com/en/>



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] mDNS behaviour on IP address change

2022-03-14 Thread Massimiliano Cialdi
I apologize for thinking too suddenly about a bug.
Actually it was enough to set LWIP_NETIF_EXT_STATUS_CALLBACK to have
the expected behavior.
I apologize again.

best regards
Max


On Mon, Mar 14, 2022 at 3:49 PM massimiliano cialdi via lwip-users
 wrote:
>
> continuing to read RFC 6762 at section 8.4
> (https://datatracker.ietf.org/doc/html/rfc6762#section-8.4) I find:
>
>
> At any time, if the rdata of any of a host's Multicast DNS records
> changes, the host MUST repeat the Announcing step described above to
> update neighboring caches.  For example, if any of a host's IP
> addresses change, it MUST re-announce those address records.
>
>
> This is exactly the case I was describing.
> I have tested both the 2.1.3 release of lwip and the current master. In
> both cases mDNS doesn't re-announce.
>
>
> I believe this can be considered a bug.
>
>
> best regards
>
> Max
>
>
>
> Massimiliano Cialdi
> FIRMWARE ENGINEERING PROFESSIONAL LEADER
>
> Powersoft S.p.A.
> Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
> OFFICE:+39 055 7350230
>
>
>
>
>
>
> On 14/03/22 11:02, massimiliano cialdi wrote:
> >
> > hello,
> >
> > In RFC 6762 I find (section 8):
> >
> >
> > "Whenever a Multicast DNS responder starts up, wakes up from sleep,
> > receives an indication of a network interface "Link Change" event, or
> > has any other reason to believe that its network connectivity may
> > have changed in some relevant way, it MUST perform the two startup
> > steps below: Probing (Section 8.1) and Announcing (Section 8.3)."
> >
> >
> > Does the IP change fall under one of the reasons for reannouncement?
> > In my opinion it should but I'm not sure. I mean, if I set
> > LWIP_DHCP_AUTOIP_COOP and assigned a link-local address, and then a
> > dhcp server is turned on, my IP address changes. I believe that this
> > should require sending a new announcement to inform of the newly
> > acquired IP.
> >
> > Lwip doesn't seem to act like that, but I don't know if it should.
> > What do you guys think?
> >
> >
> > best regards
> >
> > Max
> >
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users



-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] mDNS behaviour on IP address change

2022-03-14 Thread massimiliano cialdi via lwip-users

hello,

In RFC 6762 I find (section 8):


"Whenever a Multicast DNS responder starts up, wakes up from sleep,
receives an indication of a network interface "Link Change" event, or
has any other reason to believe that its network connectivity may
have changed in some relevant way, it MUST perform the two startup
steps below: Probing (Section 8.1) and Announcing (Section 8.3)."


Does the IP change fall under one of the reasons for reannouncement? In my 
opinion it should but I'm not sure. I mean, if I set LWIP_DHCP_AUTOIP_COOP and 
assigned a link-local address, and then a dhcp server is turned on, my IP 
address changes. I believe that this should require sending a new announcement 
to inform of the newly acquired IP.

Lwip doesn't seem to act like that, but I don't know if it should. What do you 
guys think?


best regards

Max

Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER

Powersoft S.p.A.
Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 7350230
<http://www.powersoft-audio.com/en/>[cid:PS_553e4174-d089-4113-aa68-7863aa6108ea.png]<http://www.powersoft-audio.com/en/> 
[cid:FB_c651e92c-f558-4470-9dc8-0cde2dc49cf4.png] <https://www.facebook.com/powersoft>  
[cid:Teams_6088ac53-fdc7-460a-97b3-533e03f1ad3d.png] <https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cia...@powersoft.com>  
[cid:IN_2180daad-e9b1-4c84-9ac3-d130a49ed1c3.png] <https://www.linkedin.com/company/powersoft> 
<https://www.linkedin.com/company/powersoft>  [cid:YT_c74db1a3-a814-4e66-b04f-15ff9bd7940d.png] 
<https://www.youtube.com/user/powersoftaudio> <https://www.youtube.com/user/powersoftaudio>  
[cid:IG_b8aafa87-2c84-4406-9c9e-91da1b7684d0.png] <https://www.instagram.com/powersoft.audio/> 
<https://www.instagram.com/powersoft.audio/>  <http://www.powersoft-audio.com/en/>



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] Missing autoip_remove_struct() fix in latest release (2.1.3)

2022-03-14 Thread massimiliano cialdi via lwip-users


it seems that such a commit was not cherry-picked in the last release.


Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER


Powersoft 
S.p.A.
Via E. Conti, 5 
- Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 
7350230
  








 
On 03/03/22 22:31, Erik Ekman wrote:
> Does adding commit 03998f5147f090d42bde1b2220b75129957e2348 on top of
> the release fix it for you?
>
> On Thu, 3 Mar 2022 at 15:24, Shawn Silverman  wrote:
>> It doesn't look like this fix made it into the latest release.
>> Ref: https://lists.nongnu.org/archive/html/lwip-users/2019-11/msg00063.html
>>
>> (Or maybe that was intentional? In any case, I just noticed this.)
>>



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] mDNS behaviour on IP address change

2022-03-14 Thread massimiliano cialdi via lwip-users


continuing to read RFC 6762 at section 8.4 
(https://datatracker.ietf.org/doc/html/rfc6762#section-8.4) I find:


At any time, if the rdata of any of a host's Multicast DNS records
changes, the host MUST repeat the Announcing step described above to
update neighboring caches.  For example, if any of a host's IP
addresses change, it MUST re-announce those address records.


This is exactly the case I was describing.
I have tested both the 2.1.3 release of lwip and the current master. In 
both cases mDNS doesn't re-announce.


I believe this can be considered a bug.


best regards

Max



Massimiliano Cialdi
FIRMWARE ENGINEERING PROFESSIONAL LEADER


Powersoft 
S.p.A.
Via E. Conti, 5 
- Scandicci (Fi) 50018 - Italy
OFFICE:+39 055 
7350230
  








 
On 14/03/22 11:02, massimiliano cialdi wrote:
>
> hello,
>
> In RFC 6762 I find (section 8):
>
>
> "Whenever a Multicast DNS responder starts up, wakes up from sleep,
> receives an indication of a network interface "Link Change" event, or
> has any other reason to believe that its network connectivity may
> have changed in some relevant way, it MUST perform the two startup
> steps below: Probing (Section 8.1) and Announcing (Section 8.3)."
>
>
> Does the IP change fall under one of the reasons for reannouncement? 
> In my opinion it should but I'm not sure. I mean, if I set 
> LWIP_DHCP_AUTOIP_COOP and assigned a link-local address, and then a 
> dhcp server is turned on, my IP address changes. I believe that this 
> should require sending a new announcement to inform of the newly 
> acquired IP.
>
> Lwip doesn't seem to act like that, but I don't know if it should. 
> What do you guys think?
>
>
> best regards
>
> Max
>



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] using LWIP_PBUF_CUSTOM_DATA together with socket api

2022-02-21 Thread Massimiliano Cialdi
On Sat, Feb 19, 2022 at 9:38 PM goldsi...@gmx.de  wrote:
> The easiest way probably might be to implement a socket read function
> that returns netbufs instead of the standard socket read function. But
> that's not implemented yet.
I finally decided to reimplement a read function, and it works!
Now I have the opposite problem: I need to timpestamp only some
special packages, not all of them. My desire is to be able to call a
function of mine that sets a flag in the metadata that is then used in
the function closest to the hw, that performs the actual sending,
activating or not the hw timestamping for that packet.

Unfortunately the sendto() function and all other functions that are
used to send and that directly or indirectly use pbuf do not use an
allocator like calloc that populates all allocated memory to 0.
How can I initialize my metadata flowing from the application to the
hw in all cases?

best regards
Max

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] using LWIP_PBUF_CUSTOM_DATA together with socket api

2022-02-19 Thread Massimiliano Cialdi
On Sat, Feb 19, 2022 at 10:02 PM goldsi...@gmx.de  wrote:
> Well, there's still an undone task in our tracker to convert the socket
> API to just be a "copying" wrapper around the netconn API.
> Unfortunately, it's not like that now and select is not available for
> netconns, yet.
Okay. Could you give me a suggestion on how I can implement an
equivalent `select` with in netconn. Keep in mind that I use FreeRTOS.

best regards
Max


-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] using LWIP_PBUF_CUSTOM_DATA together with socket api

2022-02-19 Thread Massimiliano Cialdi
On Sat, Feb 19, 2022 at 9:38 PM goldsi...@gmx.de  wrote:
> The easiest way probably might be to implement a socket read function
> that returns netbufs instead of the standard socket read function. But
> that's not implemented yet.
Alternatively I could replace the socket API of the project I'm
porting with the netconn API. The only issue is that such project also
makes use of the `select` API. How can I replace it or implement it
with the netconn API?

best regards
Max


--
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] using LWIP_PBUF_CUSTOM_DATA together with socket api

2022-02-19 Thread Massimiliano Cialdi
I'm trying to port a project to lwip. This project uses BSD sockets
calls, so first, I used lwip's socket APIs.
The project I'm trying to port has to deal with packet timestamping,
that's why I used LWIP_PBUF_CUSTOM_DATA as explained here
https://savannah.nongnu.org/bugs/?55078
This way I can "enrich" the pbuf structure with metadata fields of my own.

The question is: how do I retrieve my metadata using the socket API?
For example how do I get a read pbuf? Or how do I convert the socket
to a netconn?

best regards
Max

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] metadata into pbuf

2022-01-27 Thread Massimiliano Cialdi
Hi,

this sounds great!!

Is it possible to retrieve this metadata using the socket API?

best regards
Max

On Thu, Dec 16, 2021 at 9:09 PM Erik Ekman  wrote:

> Hi
>
> It should be possible by configuring LWIP_PBUF_CUSTOM_DATA to hold the
> extra data you need (added in https://savannah.nongnu.org/bugs/?55078)
>
> /Erik
>
> On Tue, 14 Dec 2021 at 21:49, Massimiliano Cialdi 
> wrote:
> >
> > hello,
> >
> > I have the packets time stamped with IEEE1588.
> > Is it possible to add metadata (into pbuf?) so that the timestamp
> > information can be transferred from the MAC device interrupt, inside
> > the lwip stack, to the application code?
> >
> > best regards
> > Max
> > --
> > Et nunc, auxilium solis, vincam!
> > Oppugnatio solaris!
> > VIS!
> >
> > Massimiliano Cialdi
> > cia...@gmail.com
> >
> > ___
> > lwip-users mailing list
> > lwip-users@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] how to use netif_find() correctly

2022-01-26 Thread Massimiliano Cialdi
hello

I must have the *netif given its name. I used the netif_find() function,
but got an assert:
"Function called without core lock".
Among netif functions there is no wrapper for netif_find().
What is the correct way to proceed?

should i write my own wrapper, in one of my files, copying from a netifapi
function? Or should I use the locks? And how should I do that?

best regards
Max

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] metadata into pbuf

2021-12-14 Thread Massimiliano Cialdi
hello,

I have the packets time stamped with IEEE1588.
Is it possible to add metadata (into pbuf?) so that the timestamp
information can be transferred from the MAC device interrupt, inside
the lwip stack, to the application code?

best regards
Max
-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] bind with link down

2020-04-03 Thread Massimiliano Cialdi
On Fri, Apr 3, 2020 at 12:55 PM goldsi...@gmx.de  wrote:
> > And, if I understand correctly, when the ip is static I don't even
> > need to set the link down when cable is unconnected.
> No, you should still set the link down if you can detect it. It's not
> required, but it might improve *some* things if that is known.
This proves once again my ignorance on these matters so...

> > Where could I find documents or books to increase my know-how on these 
> > topics?
...this question remains more valid than ever.

best regards
Max


-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

2020-04-03 Thread Massimiliano Cialdi
On Fri, Apr 3, 2020 at 1:28 AM Sylvain Rochet  wrote:
> netif_set_up() and netif_set_down() is a software switch telling the
> lwIP stack if you want the interface to be active or silent. If you
> don't need to disable an interface at runtime (with only one interface,
> you never need that!), you only have to call netif_set_up() once at
> init.
>
> netif_set_link_up() and netif_set_link_down() may be called when cable
> is plugged or unplugged. Calling netif_set_link_down() then
> netif_set_link_up() is optional and only meant to speed up DHCP recover,
> IPv6 discovery, or such. If you don't care about speeding up things on
> cable connection you only have to call netif_set_link_up() once at init.
I confess my lack of knowledge on these matters.
I didn't know that if I have just one interface, I never need to put it down.
And I wouldn't know after which events to put the interfaces up/down
in case I had more than one.
And, if I understand correctly, when the ip is static I don't even
need to set the link down when cable is unconnected.
Where could I find documents or books to increase my know-how on these topics?

best regards
Max

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

2020-04-02 Thread Massimiliano Cialdi
On Thu, Apr 2, 2020 at 11:25 PM Sylvain Rochet  wrote:
> "ip link set  up/down" is interface administrative state.
>
> Link state is whether the cable is plugged or unplugged, i.e. "ethtool"
> for linux equivalent.
This answer confuses me.

I tried: on linux the link state and the admin state *are* related to
each other.
with the cable connected both ip and ethtool report the states up
max@jarvis:~$ ip link show enx0050b6e9a99e && ethtool enx0050b6e9a99e | tail -n2
5: enx0050b6e9a99e:  mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:50:b6:e9:a9:9e brd ff:ff:ff:ff:ff:ff
Cannot get wake-on-lan settings: Operation not permitted
   drv probe link
Link detected: yes

and even with the cable disconnected they both say down:
max@jarvis:~$ ip link show enx0050b6e9a99e && ethtool enx0050b6e9a99e | tail -n2
5: enx0050b6e9a99e:  mtu 1500 qdisc
fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 00:50:b6:e9:a9:9e brd ff:ff:ff:ff:ff:ff
Cannot get wake-on-lan settings: Operation not permitted
   drv probe link
Link detected: no

but you said:
> "Admin state" is "netif_set_up()".
>
> > How should the admin state be affected by the link state?
> Not at all. Just call "netif_set_link_up()" or down when you found out a
> state change. Leave "netif_set_up()" as it is.
From this I understand that the links state and admin state are not
related. I may have (and you say so) links down but admin state up.
Tell me if I understand correctly.

So I find myself forced to ask you the question again: on linux how
can I have admin state up and link down?

the last thing: you say that "ip link set  up/down" is interface
administrative state.
But if I force down the "admin state" with the cable connected, both
ip and ethtool tell me the link is down. And once again, that seems
contrary to what you say (link and admin state are not related).

best regards
Max


-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

2020-04-02 Thread Massimiliano Cialdi
On Thu, Apr 2, 2020 at 8:33 PM goldsi...@gmx.de  wrote:
> "Admin state" is "netif_set_up()".
>
> > How should the admin state be affected by the link state?
> Not at all. Just call "netif_set_link_up()" or down when you found out a
> state change. Leave "netif_set_up()" as it is.
what's the linux equivalent of 'admin state'? Which command could be
used to change it? This might help me figure out what admin state is
and what admin state is for.
I only know
ip link set  up/down
This should be the equivalent of netif_set_link_up()/netif_set_link_down()

After which events should I call netif_set_up()/netif_set_down()?

I copied this pattern from the examples found in the ST SDKs (hoping
they'd know more about it than I do.):
https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Projects/STM32756G_EVAL/Applications/LwIP/LwIP_UDPTCP_Echo_Server_Netconn_RTOS

where I find comments that contradict what you're telling me
(https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Projects/STM32756G_EVAL/Applications/LwIP/LwIP_UDPTCP_Echo_Server_Netconn_RTOS/Src/app_ethernet.c#L153):
/* When the netif link is down this function must be called.*/
netif_set_down(netif);

and also the call netif_set_up() in the link_callback when the link is up:
https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Projects/STM32756G_EVAL/Applications/LwIP/LwIP_UDPTCP_Echo_Server_Netconn_RTOS/Src/app_ethernet.c#L144


best regards
Max

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] bind with link down

2020-03-31 Thread Massimiliano Cialdi
On Tue, Mar 31, 2020 at 10:11 PM Simon Goldschmidt  wrote:
> You're mixing link state with admin state here. That might work, but
> might not work in some situations.
It's not so clear to me.
Which pattern should I adopt to keep the link status under control?
What do you mean by 'admin state'?
How should the admin state be affected by the link state?


> > Then when the link goes down while
> > err = netconn_recv(conn, );
> > is waiting, it doesn't exit with an error. Is that correct?
> Correct or not depends on how you define it. There's currently no code
When you say "depends on how you define it.", what are you talking about?

> in lwIP to unblock on link loss. That could only work if you're bound to
> a netif. I'm not sure if what you think of works in other stacks.
What other stacks? Stacks other than lwip?

best regards
Max



-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] bind with link down

2020-03-31 Thread Massimiliano Cialdi
I have a process that polls the PHY to find out if the link is up or
down. It calls netif_set_link_up()/netif_set_link_down(). I also have
the link callback calling netif_set_up()/netif_set_down().

I wonder what happens if the functions:
  conn = netconn_new(NETCONN_UDP);
  netconn_bind(conn, IP_ADDR_ANY, 7);
are called when netif is still down. This happens because, for
example, the udpecho_thread() process starts before the netif is up.

Then when the link goes down while
   err = netconn_recv(conn, );
is waiting, it doesn't exit with an error. Is that correct?

best regards
Max
-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cia...@gmail.com

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] What happens to udp (and tcp) connections when changing ip address?

2017-07-12 Thread massimiliano cialdi

I use lwip 2.0.2 + FreeRTOS 9.0.0

I have a ask that implement udp server:

static void udpMan_Task(void)
{
struct netbuf *buf;
char *buffer;
err_t err;
client_desc_t client;

UdpConn = netconn_new(NETCONN_UDP);
LWIP_ASSERT("con != NULL", UdpConn != NULL);

int timeout_ms = DHCP_FINE_TIMER_MSECS; // this timeout has to be 
less than DHCP_FINE_TIMER_MSECS


while (1) {
err = netconn_bind(UdpConn, NULL, CONFIG_UDP_PBUS_PORT);
netconn_set_recvtimeout (UdpConn, timeout_ms);

while ((err == ERR_OK) || (err == ERR_TIMEOUT)) {
err = netconn_recv(UdpConn, );
if (err == ERR_OK) {
// compute received data
}

} // end receiving loop
vTaskDelay(1000);

} // end global loop
}


What happens when changing ip address with netifapi_netif_set_addr()? 
What actions should i do in the udp task?

How can I notice the change of IP?


best regards

Max



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] How to switch between DHCP and static IP assignment?

2017-07-11 Thread massimiliano cialdi

Hallo,

I wonder how to switch between DHCP and static IP. I found an old post, 
and I wonder How this switch can be done with lwip 2.0.2.


I simply call

netifapi_dhcp_release(netif);
netifapi_dhcp_stop(netif);

// set addresses in ipaddr, netmask, gw

netifapi_netif_set_addr(netif, , ,  );


At this point netif->ip_addr is populated with new address and link is 
up and netif is up (verified with debugger), but the equipment seems to 
drop all packet to new address and als to old address


best regards
Max


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] dhcp behaviour

2017-07-11 Thread massimiliano cialdi

Hallo,

I have some questions about dhcp behaviour:

- Do I have to call the functions dhcp_coarse_tmr() and 
dhcp_coarse_tmr() explicitly?
I have this doubt because I have seen that these functions are already 
being declared as

  timer callbacks in file timeout.c

- if my dhcp server has 10s as lease time, should I lower 
DHCP_COARSE_TIMER_SECS and DHCP_FINE_TIMER_MSECS? And what values?


Best regards
Max

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] how to set the link up

2017-07-10 Thread massimiliano cialdi

I wonder what the difference between link status and netif status is.

I mean, reading documentation:

- netif_set_link_up(struct netif *netif)

  This is the hardware link state; e.g. whether cable is plugged for wired
  Ethernet interface. This function must be called even if you don't know
  the current state. Having link up and link down events is optional but
  DHCP and IPv6 discover benefit well from those events.

- netif_set_up(struct netif *netif)

  This is the administrative (= software) state of the netif, when the
  netif is fully configured this function must be called.

butI can not figure out what conditions can lead to link up and netif down. 
In other words what I would do is set the flag up following the link up 
flag and vice versa. but in this scenario up flag and link up flag would 
be the same. Another question is about the sentence "This function [netif_set_link_up()] must be called even if you don't know the current state". Why?What happens if  I call netif_set_link_up()but the link is actually down (Unplugged cable)?


 
best regards

Max

On 09/07/2017 08:39, Noam Weissman wrote:


Hi Max,

I just read your comments. In my case I have two tasks… one that poll 
the link and one handling


the application DHCP. The link task changes the DHCP task state when 
link is established and therefore


they are independent and no deadlock happens.

The link call back is used to update parameters or do special 
operations at the application level.


I am for example call announce for my discovery protocol.

BR,

Noam.

*From:*lwip-users 
[mailto:lwip-users-bounces+noam=silrd@nongnu.org] *On Behalf Of 
*Krzysztof Wesolowski

*Sent:* Friday, July 07, 2017 8:22 PM
*To:* Mailing list for lwIP users
*Subject:* Re: [lwip-users] how to set the link up

One simplification would be to do those link monitoring operations on 
timer running on LwIP thread, it removes threading issues (ie. 
Modifying stack data, accessing PHY). Only dhcp/ip setup would need to 
come from external memory/queue.


On Fri, 7 Jul 2017, 18:52 massimiliano cialdi, 
<massimiliano.cia...@powersoft.it 
<mailto:massimiliano.cia...@powersoft.it>> wrote:


On 07/07/2017 18:04, Noam Weissman wrote:
>
> Speed, duplex, link etc... is low level handling and the TCP
stack is
> not aware of that.
>
>
> This is why you call the set_link_up/down in your task,
informing the
> stack !.
>
Yes, of course

> The MDIO interface between your micro and PHY has no relation with
> netif so why do you
>
> pass it as argument ?
>
because, in our implementation (NXP), netif->state is pointer to
structure containing information to interface with PHY.

> You several options to get the link state. You can connect the link
> led in the ETH connector
>
> to your micro and read it as a simple IO.
>
>
> If your PHY supports MII and it is connected as an MII you can
hook an
> interrupt to the link line.
>
We are compliant to RMII, except interrupt signal that is not
routed, so
we have to poll PHY.

> The third option is what I suggested to read the PHY basic register
> and check for the link bit.
>
Is what I do.

> Your link task should not only check if link is up or down but also
> know if it has changed !!. In your
>
> code is constantly calling the netifapi functions unless I missed
> something ?
>
Yes, I have further modified the task:

static void PhyStatus_Task( struct netif *netif )
{
 enum { link_up, link_down } linkstatus = link_down;
 phy_speed_t physpeed;
 phy_duplex_t phyduplex;
 bool link;
 status_t result;

 ETHSPDOFF();
 netifapi_netif_set_link_down(netif);
 while(1)
 {
 result = ethernetif_GetLinkStatus(netif, );
 if(result == kStatus_Success)
 {
 switch(linkstatus)
 {
 case link_down:
 if(true == link)
 {
 linkstatus = link_up;
 netifapi_netif_set_link_up(netif);
 }
 break;
 case link_up:
 if(false == link)
 {
 linkstatus = link_down;
 netifapi_netif_set_link_down(netif);
 ETHSPDOFF();
 }
 else
 {
 result = ethernetif_GetLinkSpeedDuplex(netif,
, );
 if(result == kStatus_Success)
 {
 ETHSPD(physpeed);
 }
 }
 break;
 

Re: [lwip-users] how to set the link up

2017-07-07 Thread massimiliano cialdi

On 07/07/2017 18:04, Noam Weissman wrote:


Speed, duplex, link etc... is low level handling and the TCP stack is 
not aware of that.



This is why you call the set_link_up/down in your task, informing the 
stack !.



Yes, of course

The MDIO interface between your micro and PHY has no relation with 
netif so why do you


pass it as argument ?

because, in our implementation (NXP), netif->state is pointer to 
structure containing information to interface with PHY.


You several options to get the link state. You can connect the link 
led in the ETH connector


to your micro and read it as a simple IO.


If your PHY supports MII and it is connected as an MII you can hook an 
interrupt to the link line.


We are compliant to RMII, except interrupt signal that is not routed, so 
we have to poll PHY.


The third option is what I suggested to read the PHY basic register 
and check for the link bit.



Is what I do.

Your link task should not only check if link is up or down but also 
know if it has changed !!. In your


code is constantly calling the netifapi functions unless I missed 
something ?



Yes, I have further modified the task:

static void PhyStatus_Task( struct netif *netif )
{
enum { link_up, link_down } linkstatus = link_down;
phy_speed_t physpeed;
phy_duplex_t phyduplex;
bool link;
status_t result;

ETHSPDOFF();
netifapi_netif_set_link_down(netif);
while(1)
{
result = ethernetif_GetLinkStatus(netif, );
if(result == kStatus_Success)
{
switch(linkstatus)
{
case link_down:
if(true == link)
{
linkstatus = link_up;
netifapi_netif_set_link_up(netif);
}
break;
case link_up:
if(false == link)
{
linkstatus = link_down;
netifapi_netif_set_link_down(netif);
ETHSPDOFF();
}
else
{
result = ethernetif_GetLinkSpeedDuplex(netif, 
, );

if(result == kStatus_Success)
{
ETHSPD(physpeed);
}
}
break;
}
}
vTaskDelay(100);
}
}


I have investigated the problems: netifapi_netif_set_link_up() is called 
and it cause call to link callback, in this function I call another 
function in netifapi (netifapi_dhcp_start()), so I have a deadlock.


best regards
Max

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] how to set the link up

2017-07-07 Thread massimiliano cialdi

I changed the task in this way but nothing changes:

static void PhyStatus_Task( struct netif *netif )
{
enum { link_up, link_down } linkstatus = link_down;
phy_speed_t physpeed;
phy_duplex_t phyduplex;
bool link;
status_t result;

while(1)
{
switch (linkstatus)
{
case link_down:
vTaskDelay(100);
ETHSPDOFF();
netifapi_netif_set_link_down(netif);
while(1)
{
result = ethernetif_GetLinkStatus(netif, );
if(result == kStatus_Success)
{
if(link == true)
{
break;
}
}
}

linkstatus = link_up;
break;
case link_up:
netifapi_netif_set_link_up(netif);
while(1)
{
vTaskDelay(100);
result = ethernetif_GetLinkStatus(netif, );
if(result == kStatus_Success)
{
if(link == false)
{
break;
}
else
{
result = ethernetif_GetLinkSpeedDuplex(netif, 
, );

if(result == kStatus_Success)
{
ETHSPD(physpeed);
}
}
}
else
break;
}
linkstatus = link_down;
break;
}
}
}

best regards
Max

On 07/07/2017 17:27, massimiliano cialdi wrote:
I have implement a task to check phy status (similar to what you do), 
and also I use netifapi_* functions:



static void PhyStatus_Task( struct netif *netif )
{
phy_speed_t physpeed;
phy_duplex_t phyduplex;
bool linkstatus;
status_t result;

ETHSPDOFF();

while(1)
{
result = ethernetif_GetLinkStatus(netif, );
if(result == kStatus_Success)
{
if(linkstatus == true)
{
result = ethernetif_GetLinkSpeedDuplex(netif, 
, );

if(result == kStatus_Success)
{
ETHSPD(physpeed);
}
netifapi_netif_set_link_up(netif);
}
else
{
ETHSPDOFF();
netifapi_netif_set_link_down(netif);
}

}
else
{
ETHSPDOFF();
netifapi_netif_set_link_down(netif);
}

vTaskDelay(100);
}
}

unfortunately I have a problem: when netif_set_link_up() is finally 
called always return immediately:



void
netif_set_link_up(struct netif *netif)
{
  if (!(netif->flags & NETIF_FLAG_LINK_UP)) {
netif->flags |= NETIF_FLAG_LINK_UP;

#if LWIP_DHCP
dhcp_network_changed(netif);
#endif /* LWIP_DHCP */

#if LWIP_AUTOIP
autoip_network_changed(netif);
#endif /* LWIP_AUTOIP */

if (netif->flags & NETIF_FLAG_UP) {
  netif_issue_reports(netif, 
NETIF_REPORT_TYPE_IPV4|NETIF_REPORT_TYPE_IPV6);

}
NETIF_LINK_CALLBACK(netif);
  }
}


first 'if' is always false, and I wonder why


best regads

Max


On 05/07/2017 19:21, Noam Weissman wrote:


Yes Sylvain 

I already changed the code according to your comments 


Thanks.




*From:* lwip-users <lwip-users-bounces+noam=silrd@nongnu.org> on 
behalf of Sylvain Rochet <grada...@gradator.net>

*Sent:* Wednesday, July 5, 2017 8:08 PM
*To:* Mailing list for lwIP users
*Subject:* Re: [lwip-users] how to set the link up
Hi,

On Wed, Jul 05, 2017 at 04:55:24PM +, Noam Weissman wrote:
>
> My DHCP task calls dhcp_start and wait for an IP. If there is a
> timeout the task will assign a static default IP. You can do something
> similar.

Erm, should I add that dhcp_start() is not thread safe ?

Sylvain







___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

2017-07-07 Thread massimiliano cialdi
I have implement a task to check phy status (similar to what you do), 
and also I use netifapi_* functions:



static void PhyStatus_Task( struct netif *netif )
{
phy_speed_t physpeed;
phy_duplex_t phyduplex;
bool linkstatus;
status_t result;

ETHSPDOFF();

while(1)
{
result = ethernetif_GetLinkStatus(netif, );
if(result == kStatus_Success)
{
if(linkstatus == true)
{
result = ethernetif_GetLinkSpeedDuplex(netif, 
, );

if(result == kStatus_Success)
{
ETHSPD(physpeed);
}
netifapi_netif_set_link_up(netif);
}
else
{
ETHSPDOFF();
netifapi_netif_set_link_down(netif);
}

}
else
{
ETHSPDOFF();
netifapi_netif_set_link_down(netif);
}

vTaskDelay(100);
}
}

unfortunately I have a problem: when netif_set_link_up() is finally 
called always return immediately:



void
netif_set_link_up(struct netif *netif)
{
  if (!(netif->flags & NETIF_FLAG_LINK_UP)) {
netif->flags |= NETIF_FLAG_LINK_UP;

#if LWIP_DHCP
dhcp_network_changed(netif);
#endif /* LWIP_DHCP */

#if LWIP_AUTOIP
autoip_network_changed(netif);
#endif /* LWIP_AUTOIP */

if (netif->flags & NETIF_FLAG_UP) {
  netif_issue_reports(netif, 
NETIF_REPORT_TYPE_IPV4|NETIF_REPORT_TYPE_IPV6);

}
NETIF_LINK_CALLBACK(netif);
  }
}


first 'if' is always false, and I wonder why


best regads

Max


On 05/07/2017 19:21, Noam Weissman wrote:


Yes Sylvain 

I already changed the code according to your comments 


Thanks.




*From:* lwip-users  on 
behalf of Sylvain Rochet 

*Sent:* Wednesday, July 5, 2017 8:08 PM
*To:* Mailing list for lwIP users
*Subject:* Re: [lwip-users] how to set the link up
Hi,

On Wed, Jul 05, 2017 at 04:55:24PM +, Noam Weissman wrote:
>
> My DHCP task calls dhcp_start and wait for an IP. If there is a
> timeout the task will assign a static default IP. You can do something
> similar.

Erm, should I add that dhcp_start() is not thread safe ?

Sylvain




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

2017-07-06 Thread massimiliano cialdi

sorry,

I was too inattentive and too fast to write my previously mail.


I still apologize


best regards

Max


Powersoft logo <http://www.powersoft.it>

*Massimiliano Cialdi |*Senior Firmware Engineer

*skype:*  mci.pws *| email:* massimiliano.cia...@powersoft.it 
<mailto:massimiliano.cia...@powersoft.it>


*HQ Italy:* Via E. Conti, 5 *|* 50018 Scandicci (FI) Italy

*direct phone:*  +39 055 0153429 *| Fax:*  +39 055 735 6235

*web site:* www.powersoft.it <http://www.powersoft.it>

Green Audio Power

On 06/07/2017 13:14, Dirk Ziegelmeier wrote:
Seriously, Max, if I send you a link to the lwIP docs, the I can at 
least expect you

​ READ AND try HARD to UNDERSTAND the docs.​
You really can answer that question by yourself.​

Read the page that I sent you, and several other pages in the docs, 
there are many questions answered in there (especially 
http://www.nongnu.org/lwip/2_0_x/pitfalls.html)


​



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

2017-07-06 Thread massimiliano cialdi
About thread safe, in all the examples I found the sequence of 
instructions is this:


tcpip_init(NULL, NULL);

netif_add(_netif0, _netif0_ipaddr, _netif0_netmask, 
_netif0_gw, NULL, ethernetif_init, tcpip_input);

netif_set_default(_netif0);
netif_set_up(_netif0);

I guess that netif_add()m call should be netifapi_netif_add() instead, 
because is called from a different task from tcpip_thread.



What about the other two calls?


best regadrs

Max


On 05/07/2017 19:08, Sylvain Rochet wrote:

Hi,

On Wed, Jul 05, 2017 at 04:55:24PM +, Noam Weissman wrote:

My DHCP task calls dhcp_start and wait for an IP. If there is a
timeout the task will assign a static default IP. You can do something
similar.

Erm, should I add that dhcp_start() is not thread safe ?

Sylvain




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] seting up ip address after initialization

2017-07-06 Thread massimiliano cialdi

I have to set the ip address after initialization.

I guess I have to pass 0.0.0.0 as ip address, netmask and gw to call to 
netif_add().


I wonder which api (thread safe?) to call to set the proper ip address 
at a later time.



best regards

Max



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] how to set the link up

2017-07-05 Thread massimiliano cialdi

  
  
So you have a task to manage link status an another to manage
  DHCP?
  
  I have to make possible to change ip address or switch between
  static and dynamic ip without reboot.
  I noticed that when the board has a DHCP assigned IP and the link
  goes down, the board do not change ip or switch in auto ip.
  
  So I'm going to setup a task to poll PHY link status (and speed,
  to switch on/off speed led), and another task to manage ip
  assignment. These task should be under application layer.
I do not know if it's a good idea.
  
  best regards
  Max
  


  
  

On 05/07/2017 16:40, Noam Weissman
  wrote:


  Hi Sylvian,

THANKS for pointing this out !!!. 

I am using the code I sent for several years and was not aware of that :-(

The base code was taken from ST example !!

I could not find netifapi_netif_set_link_up ... did you mean netifapi_netif_set_up ?





  


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] how to set the link up

2017-07-05 Thread massimiliano cialdi


On 05/07/2017 13:59, Noam Weissman wrote:

>From what I have seen the KSZ8081RNACA is an IEEE compliant PHY... that means 
that the driver is standard.

You need to read PHY_BSR register (1) and check bit 3 ... this is the link 
status. This is what I am doing in a task.
The reason for doing the above is that a PHY with RMII has no link interrupt 
and the simplest way is to read the
basic status register.
Yes, I know, but I wonder where, in the code, to poll that register. Do 
I need to provide a task as you do? And netif_set_link_up() has to be 
called only from this task?



Do you have a fully functional driver and initialize code that works for you ?

I have an implementation... Is the sample code provided by NXP in 
KSDK2.2 (our board is very similar to FRDM K64). They do some strange 
things, but they have provided a task that only deals with receiving the 
data from network. PHY polling is done in an high level (application) 
task that deal with UDP packets.


best regards
Max

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] how to set the link up

2017-07-05 Thread massimiliano cialdi
I haveKSZ8081RNACA as phy that has to be polled (interrupt signal is not 
routed)


In LWIP documentation I read:

- netif_set_link_up(struct netif *netif)

  This is the hardware link state; e.g. whether cable is plugged for wired
  Ethernet interface. This function must be called even if you don't know
  the current state. Having link up and link down events is optional but
  DHCP and IPv6 discover benefit well from those events.

- netif_set_up(struct netif *netif)

  This is the administrative (= software) state of the netif, when the
  netif is fully configured this function must be called.


So I understand that netif_set_link_up() has to be called from phy 
driver? and what about netif_set_up()?



best regads


--

Powersoft logo <http://www.powersoft.it>

*Massimiliano Cialdi |*Senior Firmware Engineer

*skype:*  mci.pws *| email:* massimiliano.cia...@powersoft.it 
<mailto:massimiliano.cia...@powersoft.it>


*HQ Italy:* Via E. Conti, 5 *|* 50018 Scandicci (FI) Italy

*direct phone:*  +39 055 0153429 *| Fax:*  +39 055 735 6235

*web site:* www.powersoft.it <http://www.powersoft.it>

Green Audio Power


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


Re: [lwip-users] lwip complex example

2017-07-05 Thread massimiliano cialdi
Ok but I wonder how to implement two sockets, because reading txt 
documentation provided it seems that only a subset of api are thread 
safe, and I use LWIP + FreeRTOS.


So I wonder if I can do this with two threads or I have to do with just one.

I have other doubts about initialization


best regards

Max

On 04/07/2017 17:53, Jan Menzel wrote:

Hi Max!
It's the nature of the stack that you may combine any examples you like
suppose you can provide sufficient resources. Running eg. http and sntp
is quite easy you just need more udp pcbs for sntp and/or tcp support
for http...




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] lwip complex example

2017-07-04 Thread massimiliano cialdi
I'm searching for more complex example of use lwip. For example 
something that allow me to switch between static ip and dhcp assigned ip 
without rebooting application. Or have UDP and TCP sockets opened at the 
same time.



best regards

Max

--

Powersoft logo <http://www.powersoft.it>

*Massimiliano Cialdi |*Senior Firmware Engineer

*skype:*  mci.pws *| email:* massimiliano.cia...@powersoft.it 
<mailto:massimiliano.cia...@powersoft.it>


*HQ Italy:* Via E. Conti, 5 *|* 50018 Scandicci (FI) Italy

*direct phone:*  +39 055 0153429 *| Fax:*  +39 055 735 6235

*web site:* www.powersoft.it <http://www.powersoft.it>

Green Audio Power


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users


[lwip-users] How to reinitialize lwip

2017-03-04 Thread massimiliano cialdi

is it possible to rinitialize lwip safely? how?


best regards


--

Powersoft logo <http://www.powersoft.it>

*Massimiliano Cialdi |*Senior Firmware Engineer

*skype:*  mci.pws *| email:* massimiliano.cia...@powersoft.it 
<mailto:massimiliano.cia...@powersoft.it>


*HQ Italy:* Via E. Conti, 5 *|* 50018 Scandicci (FI) Italy

*direct phone:*  +39 055 0153429 *| Fax:*  +39 055 735 6235

*web site:* www.powersoft.it <http://www.powersoft.it>

Green Audio Power

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users