from:"Amit Ashara"

Re: [lwip-users] Using BOOTP with lwIP

2017-08-10 Thread Amit Ashara

Thansk Simon. That did the trick.

Just an information to anyone looking for it, I put the following define in
my project lwipopts.h

#define LWIP_IP_ACCEPT_UDP_PORT(dst_port) ((dst_port) == PP_NTOHS(68))

#define LWIP_DHCP   0   // default is 0


On Wed, Aug 9, 2017 at 2:30 PM, goldsi...@gmx.de <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
>
>> I am trying to get BOOTP working with lwIP 1.4.1 stack. [..]However the
>> call back function for udp does not get invoked. After debugging the same,
>> the issue seems to be in ip.c file.
>>
>
> Of course that doesn't work out of the box. DHCP has a workaround, which
> is disabled for LWIP_DHCP==0. However, by defining LWIP_IP_ACCEPT_UDP_PORT
> correctly, you can get the same behaviour for your own application.
>
> Simon
>
> ___
> 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

[lwip-users] Using BOOTP with lwIP

2017-08-09 Thread Amit Ashara

Hello All,

I am trying to get BOOTP working with lwIP 1.4.1 stack. I am able to
configure the device in STATIC IP address mode and send the BOOTP packet
and have the BOOTP server send the BOOTP response. However the call back
function for udp does not get invoked. After debugging the same, the issue
seems to be in ip.c file. In the function ip_input

  if ((netif_is_up(netif)) && (!ip_addr_isany(&(netif->ip_addr {
/* unicast to this interface address? */
if (ip_addr_cmp(_iphdr_dest, &(netif->ip_addr)) ||
/* or broadcast on this interface network address? */
ip_addr_isbroadcast(_iphdr_dest, netif)) {
  LWIP_DEBUGF(IP_DEBUG, ("ip_input: packet accepted on interface
%c%c\n",
  netif->name[0], netif->name[1]));
  /* break out of for loop */
  break;
}
#if LWIP_AUTOIP
/* connections to link-local addresses must persist after changing
   the netif's address (RFC3927 ch. 1.9) */
if ((netif->autoip != NULL) &&
ip_addr_cmp(_iphdr_dest, &(netif->autoip->llipaddr))) {
  LWIP_DEBUGF(IP_DEBUG, ("ip_input: LLA packet accepted on
interface %c%c\n",
  netif->name[0], netif->name[1]));
  /* break out of for loop */
  break;
}
#endif /* LWIP_AUTOIP */

the check seems to fail at ip_addr_isany causing the netif pointer to be
NULL and hence later in the code the udp stack call is not occuring. Since
BOOTP requires the client to send the BOOTP request packet with IP address
0.0.0.0 the server responds to the IP address 0.0.0.0 which causes the
check to fail. Is there some way I can bypass the same to get the BOOTP
response to the application layer.

Furthermore: the same logic exists on lwip 2.0.2 so my assumption would be
that it would not be possible with 2.0.2. I do understand that DHCP has
superseded BOOTP, but legacy network still relies on the same.

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

Re: [lwip-users] Example of changes needed to switch from 1.4.1 to 2.0.1

2017-05-23 Thread Amit Ashara

Hello Simon,

Yes, it works fine, but yes, I agree it should not have been done this way

Amit

On Tue, May 23, 2017 at 3:26 PM, goldsi...@gmx.de <goldsi...@gmx.de> wrote:

> Wow, this is so horrible! I really don't know why people come up with this
> idea of including C files in other C files.
>
> Funny enough, it seems to work on the lwIP sources without problems, does
> it?
>
> Keep in mind though that this is *not* how the sources were intended to
> use and I'm not prepared to fix naming clashes (if there should be any in
> the future when including C files in C files).
>
> I'd strongly suggest to fix the build process here!
>
> Simon
>
>
> Amit Ashara wrote:
>
> Hello Billy,
>
> Try the following two files.
>
> Regards
> Amit
>
> On Fri, May 19, 2017 at 4:30 PM, billium <bill...@bucknall.me.uk> wrote:
>
>> Thanks Simon
>>
>> This is what I mean, this is tivaware/utils/lwiplib.c
>>
>> //**
>> ***
>> //
>> // lwiplib.c - lwIP TCP/IP Library Abstraction Layer.
>> //
>> // Copyright (c) 2008-2017 Texas Instruments Incorporated.  All rights
>> reserved.
>> // Software License Agreement
>> //
>> // Texas Instruments (TI) is supplying this software for use solely and
>> // exclusively on TI's microcontroller products. The software is owned by
>> // TI and/or its suppliers, and is protected under applicable copyright
>> // laws. You may not combine this software with "viral" open-source
>> // software in order to form a larger program.
>> //
>> // THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
>> // NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
>> // NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> // A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
>> // CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
>> // DAMAGES, FOR ANY REASON WHATSOEVER.
>> //
>> // This is part of revision 2.1.4.178 of the Tiva Utility Library.
>> //
>> //**
>> ***
>>
>> //**
>> ***
>> //
>> // Ensure that the lwIP compile time options are included first.
>> //
>> //**
>> ***
>> #include 
>> #include 
>> #include "utils/lwiplib.h"
>>
>> //**
>> ***
>> //
>> // Ensure that ICMP checksum offloading is enabled; otherwise the TM4C129
>> // driver will not operate correctly.
>> //
>> //**
>> ***
>> #ifndef LWIP_OFFLOAD_ICMP_CHKSUM
>> #define LWIP_OFFLOAD_ICMP_CHKSUM 1
>> #endif
>>
>> //**
>> ***
>> //
>> // Include lwIP high-level API code.
>> //
>> //**
>> ***
>> #include "third_party/lwip-1.4.1/src/api/api_lib.c"
>> #include "third_party/lwip-1.4.1/src/api/api_msg.c"
>> #include "third_party/lwip-1.4.1/src/api/err.c"
>> #include "third_party/lwip-1.4.1/src/api/netbuf.c"
>> #include "third_party/lwip-1.4.1/src/api/netdb.c"
>> #include "third_party/lwip-1.4.1/src/api/netifapi.c"
>> #include "third_party/lwip-1.4.1/src/api/sockets.c"
>> #include "third_party/lwip-1.4.1/src/api/tcpip.c"
>>
>> //**
>> ***
>> //
>> // Include the core lwIP TCP/IP stack code.
>> //
>> //**
>> ***
>> #include "third_party/lwip-1.4.1/src/core/def.c"
>> #include "third_party/lwip-1.4.1/src/core/dhcp.c"
>> #include "third_party/lwip-1.4.1/src/core/dns.c"
>> #include "third_party/lwip-1.4.1/src/core/init.c"
>> #include "third_party/lwip-1.4.1/src/core/mem.c"
>> #include "third_party/lwip-1.4.1/src/core/memp.c"
>> #include "third_party/lwip-1.4.1/src/core/netif.c"
>> #include "third_party/lwip-1.4.1/src/core/pbuf.c"
>> #include "third_party/lwip-1.4.1/src/core/raw.c"
>>

Re: [lwip-users] Example of changes needed to switch from 1.4.1 to 2.0.1

2017-05-23 Thread Amit Ashara

Hello Billy,

Try the following two files.

Regards
Amit

On Fri, May 19, 2017 at 4:30 PM, billium  wrote:

> Thanks Simon
>
> This is what I mean, this is tivaware/utils/lwiplib.c
>
> //**
> ***
> //
> // lwiplib.c - lwIP TCP/IP Library Abstraction Layer.
> //
> // Copyright (c) 2008-2017 Texas Instruments Incorporated.  All rights
> reserved.
> // Software License Agreement
> //
> // Texas Instruments (TI) is supplying this software for use solely and
> // exclusively on TI's microcontroller products. The software is owned by
> // TI and/or its suppliers, and is protected under applicable copyright
> // laws. You may not combine this software with "viral" open-source
> // software in order to form a larger program.
> //
> // THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
> // NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
> // NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> // A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
> // CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
> // DAMAGES, FOR ANY REASON WHATSOEVER.
> //
> // This is part of revision 2.1.4.178 of the Tiva Utility Library.
> //
> //**
> ***
>
> //**
> ***
> //
> // Ensure that the lwIP compile time options are included first.
> //
> //**
> ***
> #include 
> #include 
> #include "utils/lwiplib.h"
>
> //**
> ***
> //
> // Ensure that ICMP checksum offloading is enabled; otherwise the TM4C129
> // driver will not operate correctly.
> //
> //**
> ***
> #ifndef LWIP_OFFLOAD_ICMP_CHKSUM
> #define LWIP_OFFLOAD_ICMP_CHKSUM 1
> #endif
>
> //**
> ***
> //
> // Include lwIP high-level API code.
> //
> //**
> ***
> #include "third_party/lwip-1.4.1/src/api/api_lib.c"
> #include "third_party/lwip-1.4.1/src/api/api_msg.c"
> #include "third_party/lwip-1.4.1/src/api/err.c"
> #include "third_party/lwip-1.4.1/src/api/netbuf.c"
> #include "third_party/lwip-1.4.1/src/api/netdb.c"
> #include "third_party/lwip-1.4.1/src/api/netifapi.c"
> #include "third_party/lwip-1.4.1/src/api/sockets.c"
> #include "third_party/lwip-1.4.1/src/api/tcpip.c"
>
> //**
> ***
> //
> // Include the core lwIP TCP/IP stack code.
> //
> //**
> ***
> #include "third_party/lwip-1.4.1/src/core/def.c"
> #include "third_party/lwip-1.4.1/src/core/dhcp.c"
> #include "third_party/lwip-1.4.1/src/core/dns.c"
> #include "third_party/lwip-1.4.1/src/core/init.c"
> #include "third_party/lwip-1.4.1/src/core/mem.c"
> #include "third_party/lwip-1.4.1/src/core/memp.c"
> #include "third_party/lwip-1.4.1/src/core/netif.c"
> #include "third_party/lwip-1.4.1/src/core/pbuf.c"
> #include "third_party/lwip-1.4.1/src/core/raw.c"
> #include "third_party/lwip-1.4.1/src/core/stats.c"
> #include "third_party/lwip-1.4.1/src/core/sys.c"
> #include "third_party/lwip-1.4.1/src/core/tcp.c"
> #include "third_party/lwip-1.4.1/src/core/tcp_in.c"
> #include "third_party/lwip-1.4.1/src/core/tcp_out.c"
> #include "third_party/lwip-1.4.1/src/core/timers.c"
> #include "third_party/lwip-1.4.1/src/core/udp.c"
>
> //**
> ***
> //
> // Include the IPV4 code.
> //
> //**
> ***
> #include "third_party/lwip-1.4.1/src/core/ipv4/autoip.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/icmp.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/igmp.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/inet.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/inet_chksum.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/ip.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/ip_addr.c"
> #include "third_party/lwip-1.4.1/src/core/ipv4/ip_frag.c"
>
> //**
> ***
> //
> // Include the IPV6 code.
> // Note:  Code is experimental and not ready for use.
> // References are included for completeness.
> //
> //**
> ***
> #if 0
> #include "third_party/lwip-1.4.1/src/core/ipv6/icmp6.c"
> #include "third_party/lwip-1.4.1/src/core/ipv6/inet6.c"
> #include "third_party/lwip-1.4.1/src/core/ipv6/ip6.c"
> #include

Re: [lwip-users] Example of changes needed to switch from 1.4.1 to 2.0.1

2017-05-15 Thread Amit Ashara

Hello Billy,

Please look at the following two threads

https://lists.nongnu.org/archive/html/lwip-users/2016-11/msg00161.html
https://lists.nongnu.org/archive/html/lwip-users/2016-11/msg00160.html

On Sat, May 13, 2017 at 6:41 PM, billium <bill...@bucknall.me.uk> wrote:

> Hello Amit
>
> Yes I am using the enet_lwip example that uses Tivaware.
>
> Billy
>
>
>
> On 13/05/17 14:01, Amit Ashara wrote:
>
> Hello Billy,
>
> Are you using TivaWare?
>
> Amit
>
> On Fri, May 12, 2017 at 3:03 PM, billium <bill...@bucknall.me.uk> wrote:
>
>> I tried to change an example from a Texas Instruments TM4C1294 example.
>>
>> I had the typedef problems in cc.h
>> followed your switch from tcp_impl.h to tcp_priv.h
>>
>> Not using snmp.
>>
>> I replaced timers.h with timeouts.h
>>
>> But now I am stuck because api_msg.h is moved to priv and other changes
>> mean there are compile errors with api_msg.
>>
>> Any help gratefully received.
>>
>> (I am referring to a thread started on 3 March by Mikael Eiman)
>>
>> Billy
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
>
> ___
> lwip-users mailing 
> listlwip-users@nongnu.orghttps://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 mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Example of changes needed to switch from 1.4.1 to 2.0.1

2017-05-13 Thread Amit Ashara

Hello Billy,

Are you using TivaWare?

Amit

On Fri, May 12, 2017 at 3:03 PM, billium  wrote:

> I tried to change an example from a Texas Instruments TM4C1294 example.
>
> I had the typedef problems in cc.h
> followed your switch from tcp_impl.h to tcp_priv.h
>
> Not using snmp.
>
> I replaced timers.h with timeouts.h
>
> But now I am stuck because api_msg.h is moved to priv and other changes
> mean there are compile errors with api_msg.
>
> Any help gratefully received.
>
> (I am referring to a thread started on 3 March by Mikael Eiman)
>
> Billy
>
> ___
> 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

Re: [lwip-users] Issue in err.c for lwIP 2.0.0

2016-12-01 Thread Amit Ashara

Thanks Dirk. I added the same to the lwipopts.h and it works.

Regards
Amit

On Thu, Dec 1, 2016 at 1:57 AM, Dirk Ziegelmeier <d...@ziegelmeier.net>
wrote:

> No, the solution is in errno.h:
>
> Choose one of:
>
> - #define LWIP_PROVIDE_ERRNO 1
> - #define LWIP_ERRNO_INCLUDE "path/my_header_file_containing_errno.h"
>
> HTH
> Dirk
>
>
>
> On Wed, Nov 30, 2016 at 7:45 PM, Amit Ashara <ashara.a...@gmail.com>
> wrote:
>
>> Hello All,
>>
>> When integrating FreeRTOS with lwIP 2.0.0 the following gives an error
>> for missing defines.
>>
>> #if !NO_SYS
>> /** Table to quickly map an lwIP error (err_t) to a socket error
>>   * by using -err as an index */
>> static const int err_to_errno_table[] = {
>>   0, /* ERR_OK  0  No error, everything OK. */
>>   ENOMEM,/* ERR_MEM-1  Out of memory error. */
>>   ENOBUFS,   /* ERR_BUF-2  Buffer error.*/
>>   EWOULDBLOCK,   /* ERR_TIMEOUT-3  Timeout  */
>>   EHOSTUNREACH,  /* ERR_RTE-4  Routing problem. */
>>   EINPROGRESS,   /* ERR_INPROGRESS -5  Operation in progress*/
>>   EINVAL,/* ERR_VAL-6  Illegal value.   */
>>   EWOULDBLOCK,   /* ERR_WOULDBLOCK -7  Operation would block.   */
>>   EADDRINUSE,/* ERR_USE-8  Address in use.  */
>>   EALREADY,  /* ERR_ALREADY-9  Already connecting.  */
>>   EISCONN,   /* ERR_ISCONN -10 Conn already established.*/
>>   ENOTCONN,  /* ERR_CONN   -11 Not connected.   */
>>   -1,/* ERR_IF -12 Low-level netif error*/
>>   ECONNABORTED,  /* ERR_ABRT   -13 Connection aborted.  */
>>   ECONNRESET,/* ERR_RST-14 Connection reset.*/
>>   ENOTCONN,  /* ERR_CLSD   -15 Connection closed.   */
>>   EIO/* ERR_ARG-16 Illegal argument.*/
>> };
>> #endif /* !NO_SYS */
>>
>> #if !NO_SYS
>> int
>> err_to_errno(err_t err)
>> {
>>   if ((err > 0) || (-err >= (err_t)LWIP_ARRAYSIZE(err_to_errno_table))) {
>> return EIO;
>>   }
>>   return err_to_errno_table[-err];
>> }
>> #endif /* !NO_SYS */
>>
>> The assumption is that if NO_SYS is 0, or an RTOS is used, the socket
>> model will be used. However when not using the socket model this is not
>> true. Instead the following should be done (in my opinion)
>>
>> #if !NO_SYS
>> #if LWIP_SOCKET
>> /** Table to quickly map an lwIP error (err_t) to a socket error
>>   * by using -err as an index */
>> static const int err_to_errno_table[] = {
>>   0, /* ERR_OK  0  No error, everything OK. */
>>   ENOMEM,/* ERR_MEM-1  Out of memory error. */
>>   ENOBUFS,   /* ERR_BUF-2  Buffer error.*/
>>   EWOULDBLOCK,   /* ERR_TIMEOUT-3  Timeout  */
>>   EHOSTUNREACH,  /* ERR_RTE-4  Routing problem. */
>>   EINPROGRESS,   /* ERR_INPROGRESS -5  Operation in progress*/
>>   EINVAL,/* ERR_VAL-6  Illegal value.   */
>>   EWOULDBLOCK,   /* ERR_WOULDBLOCK -7  Operation would block.   */
>>   EADDRINUSE,/* ERR_USE-8  Address in use.  */
>>   EALREADY,  /* ERR_ALREADY-9  Already connecting.  */
>>   EISCONN,   /* ERR_ISCONN -10 Conn already established.*/
>>   ENOTCONN,  /* ERR_CONN   -11 Not connected.   */
>>   -1,/* ERR_IF -12 Low-level netif error*/
>>   ECONNABORTED,  /* ERR_ABRT   -13 Connection aborted.  */
>>   ECONNRESET,/* ERR_RST-14 Connection reset.*/
>>   ENOTCONN,  /* ERR_CLSD   -15 Connection closed.   */
>>   EIO/* ERR_ARG-16 Illegal argument.*/
>> };
>> #endif /* LWIP_SOCKET */
>> #endif /* !NO_SYS */
>>
>> #if !NO_SYS
>> #if LWIP_SOCKET
>> int
>> err_to_errno(err_t err)
>> {
>>   if ((err > 0) || (-err >= (err_t)LWIP_ARRAYSIZE(err_to_errno_table))) {
>> return EIO;
>>   }
>>   return err_to_errno_table[-err];
>> }
>> #endif /* LWIP_SOCKET */
>> #endif /* !NO_SYS */
>>
>> Regards
>> Amit Ashara
>>
>> ___
>> 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
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Issue in err.c for lwIP 2.0.0

2016-11-30 Thread Amit Ashara

Hello All,

When integrating FreeRTOS with lwIP 2.0.0 the following gives an error for
missing defines.

#if !NO_SYS
/** Table to quickly map an lwIP error (err_t) to a socket error
  * by using -err as an index */
static const int err_to_errno_table[] = {
  0, /* ERR_OK  0  No error, everything OK. */
  ENOMEM,/* ERR_MEM-1  Out of memory error. */
  ENOBUFS,   /* ERR_BUF-2  Buffer error.*/
  EWOULDBLOCK,   /* ERR_TIMEOUT-3  Timeout  */
  EHOSTUNREACH,  /* ERR_RTE-4  Routing problem. */
  EINPROGRESS,   /* ERR_INPROGRESS -5  Operation in progress*/
  EINVAL,/* ERR_VAL-6  Illegal value.   */
  EWOULDBLOCK,   /* ERR_WOULDBLOCK -7  Operation would block.   */
  EADDRINUSE,/* ERR_USE-8  Address in use.  */
  EALREADY,  /* ERR_ALREADY-9  Already connecting.  */
  EISCONN,   /* ERR_ISCONN -10 Conn already established.*/
  ENOTCONN,  /* ERR_CONN   -11 Not connected.   */
  -1,/* ERR_IF -12 Low-level netif error*/
  ECONNABORTED,  /* ERR_ABRT   -13 Connection aborted.  */
  ECONNRESET,/* ERR_RST-14 Connection reset.*/
  ENOTCONN,  /* ERR_CLSD   -15 Connection closed.   */
  EIO/* ERR_ARG-16 Illegal argument.*/
};
#endif /* !NO_SYS */

#if !NO_SYS
int
err_to_errno(err_t err)
{
  if ((err > 0) || (-err >= (err_t)LWIP_ARRAYSIZE(err_to_errno_table))) {
return EIO;
  }
  return err_to_errno_table[-err];
}
#endif /* !NO_SYS */

The assumption is that if NO_SYS is 0, or an RTOS is used, the socket model
will be used. However when not using the socket model this is not true.
Instead the following should be done (in my opinion)

#if !NO_SYS
#if LWIP_SOCKET
/** Table to quickly map an lwIP error (err_t) to a socket error
  * by using -err as an index */
static const int err_to_errno_table[] = {
  0, /* ERR_OK  0  No error, everything OK. */
  ENOMEM,/* ERR_MEM-1  Out of memory error. */
  ENOBUFS,   /* ERR_BUF-2  Buffer error.*/
  EWOULDBLOCK,   /* ERR_TIMEOUT-3  Timeout  */
  EHOSTUNREACH,  /* ERR_RTE-4  Routing problem. */
  EINPROGRESS,   /* ERR_INPROGRESS -5  Operation in progress*/
  EINVAL,/* ERR_VAL-6  Illegal value.   */
  EWOULDBLOCK,   /* ERR_WOULDBLOCK -7  Operation would block.   */
  EADDRINUSE,/* ERR_USE-8  Address in use.  */
  EALREADY,  /* ERR_ALREADY-9  Already connecting.  */
  EISCONN,   /* ERR_ISCONN -10 Conn already established.*/
  ENOTCONN,  /* ERR_CONN   -11 Not connected.   */
  -1,/* ERR_IF -12 Low-level netif error*/
  ECONNABORTED,  /* ERR_ABRT   -13 Connection aborted.  */
  ECONNRESET,/* ERR_RST-14 Connection reset.*/
  ENOTCONN,  /* ERR_CLSD   -15 Connection closed.   */
  EIO/* ERR_ARG-16 Illegal argument.*/
};
#endif /* LWIP_SOCKET */
#endif /* !NO_SYS */

#if !NO_SYS
#if LWIP_SOCKET
int
err_to_errno(err_t err)
{
  if ((err > 0) || (-err >= (err_t)LWIP_ARRAYSIZE(err_to_errno_table))) {
return EIO;
  }
  return err_to_errno_table[-err];
}
#endif /* LWIP_SOCKET */
#endif /* !NO_SYS */

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

Re: [lwip-users] Issue in arch.h for lwIP 2.0.0

2016-11-30 Thread Amit Ashara

Hello Freddie

That helped too. I added the include in the arch/cc.h for the device port.

Regards
Amit

On Wed, Nov 30, 2016 at 3:14 AM, Freddie Chopin 
wrote:

> On Wed, 2016-11-30 at 07:45 +0100, Dirk Ziegelmeier wrote:
> > I added it, thanks for reporting!
>
> It was behaving the same way in the git version prior to 2.0.0 and I
> guess the "standard" approach to that was to include  in your
> arch/cc.h file. I think that such issue was reported to the mailing
> list in the past and that was the suggested approach.
>
> Anyway - having stdlib.h included in lwip/arch.h is also a good option.
>
> Regards,
> FCh
>
> ___
> 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

Re: [lwip-users] Issue in arch.h for lwIP 2.0.0

2016-11-30 Thread Amit Ashara

Hello Simon 

We are using 1.4.1 and we get a lot of queries  on when we will migrate to 2.0.0

The other being to correct the LLDP stack as was being discussed in the Another 
thread.

Regards
Amit Ashara

> On Nov 30, 2016, at 6:58 AM, Simon Goldschmidt <goldsi...@gmx.de> wrote:
> 
> Amit Ashara wrote:
>>  Is there going to be an incremental release of lwIP
> 
> Yes. 2.0.1 will be coming as soon as we'll need it (i.e. as soon as there are 
> enough
> bugs fixed from 2.0.0 to justify releasing it).
> The time from 1.4.1 to 2.0.0 was way too long. This mainly was because the 
> integration
> of IPv6 brought big changes and mainly due to lack of manpower, we just 
> needed that long.
> 
>> or should I make the same changes as Dirk and use lwIP-2,0.0
> 
> The preferred way is *always* to use vanilla lwIP and make local 
> modifications outside
> our source tree. You can of course go with git master, where the change is 
> integrated.
> That probably depends on what you do at TI, which I don't know ;-)
> 
> 
> Simon
> 
> ___
> 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

Re: [lwip-users] Issue in arch.h for lwIP 2.0.0

2016-11-30 Thread Amit Ashara

So what is the final solution. Adding the stdlib.h in arch/cc.h or as what
Dirk has made changes?

Is there going to be an incremental release of lwIP or should I make the
same changes as Dirk and use lwIP-2,0.0

~Amit

On Wed, Nov 30, 2016 at 4:34 AM, Dirk Ziegelmeier 
wrote:

> Since it was already included in several lwIP .c/.h files, I simply
> decided to move it to a central place: arch.h.
>
> So my change should not break anything or make lwIP less portable as it
> was before.
>
> Dirk
>
> On Wed, Nov 30, 2016 at 11:07 AM, Simon Goldschmidt 
> wrote:
>
>> Freddie Chopin wrote:
>> > It was behaving the same way in the git version prior to 2.0.0 and I
>> > guess the "standard" approach to that was to include  in your
>> > arch/cc.h file. I think that such issue was reported to the mailing
>> > list in the past and that was the suggested approach.
>>
>> It was like that some years ago, but sicne by now, most embedded compilers
>> support these standard files, we decided to use them and to let people
>> missing
>> them emulate them...
>>
>>
>> Simon
>>
>> ___
>> 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
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Issue in arch.h for lwIP 2.0.0

2016-11-29 Thread Amit Ashara

Hello All,

I am using the ARM Compiler from Code Composer Studio and while updating
lwIP from 1.4.1 to 2.0.0, I ran into a compilation issue. I get an error
for size_t being undefined. Tracing the issue I was able to go past the
issue by adding stdlib to arch.h

#if !LWIP_NO_STDINT_H
#include 
#include 
typedef uint8_t   u8_t;
typedef int8_ts8_t;
typedef uint16_t  u16_t;
typedef int16_t   s16_t;
typedef uint32_t  u32_t;
typedef int32_t   s32_t;
typedef uintptr_t mem_ptr_t;
#endif

"D:/ti/TivaWare_C_Series-2.1.3.156/third_party/lwip-2.0.0/src/include/lwip/def.h",
line 124: error #20: identifier "size_t" is undefined

Can any of the lwIP developers confirm if this is expected issue?

As a side note: after making the change lwIP 2.0.0 works great with TM4C
devices.

Thanks and Regards
Amit Ashara
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-11-15 Thread Amit Ashara

Hello Simon,

Thanks for the list of to-do items. How do I open a patch tracker?

1. As for the heap allocation, it is being released after the packet is
transmitted.
2. Should I remove the opt.h and stats.h defines being integrated in the
lldp.c file?
3. The protocol values are required for LLDP and I checked the other file
for protocol definition and it was kept in ethernetif.h and hence I
followed the same structure. Where do you suggest I move the same?

On Mon, Nov 14, 2016 at 2:52 AM, Simon Goldschmidt <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
> > [..] The function that the receive performs is highly varied based on
> the context of the TLV.
>
> That's also true for transmission. E.g. going back to the profinet case,
> there are numerous other
> things to send. You'd need to find a way to make sending configurable to
> make it useful for
> the non-standard-IT case...
>
> Other than that:
> - please diff against newer sources (git master, 2.0.0)
> - indentation = 2 spaces, not 4
> - no need to change opt.h/stats.h, such deep integration is neither wanted
> nor needed for 3rd party protocols
> - don't use heap allocation just to fill in a TLV: this is for embedded
> systems, right?
> - separate protocol definitions from external interface of the component
> (not everything in one header)
> - keep private functions "static" in the C file
> - etc...?
>
> And last but not least, I have to repeate myself: if you want this to be
> integrated into core lwIP,
> open a patch tracker entry for it on savannah and put the sources there.
>
> Simon
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-11-11 Thread Amit Ashara

Hello All

Did anyone have a look at the lldp code base?

Regards
Amit Ashara

On Sat, Nov 5, 2016 at 12:57 AM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello All,
>
> The Manifest has been updated now and the new package is available for
> download.
>
> http://www.ti.com/lit/zip/spmc023
>
> Regards
> Amit Ashara
>
> On Wed, Nov 2, 2016 at 1:08 PM, Amit Ashara <ashara.a...@gmail.com> wrote:
>
>> Hello Simon,
>>
>> The issue was with the License Option that we had used. The same is being
>> now under correction and I would upload a new package with the correct
>> License file.
>>
>> Regards
>> Amit Ashara
>>
>> On Wed, Nov 2, 2016 at 11:02 AM, Amit Ashara <ashara.a...@gmail.com>
>> wrote:
>>
>>> Hello Simon
>>>
>>> Thanks for the quick feedback. I am clarifying the same with the Legal
>>> team.
>>>
>>> Regards
>>> Amit Ashara
>>>
>>>
>>> On Wed, Nov 2, 2016 at 10:39 AM, Simon Goldschmidt <goldsi...@gmx.de>
>>> wrote:
>>>
>>>> Amit Ashara wrote:
>>>> > The LLDP package is now online at the following link
>>>> > http://www.ti.com/lit/zip/spmc023
>>>> > There is a short ReadMe on integrating the LLDP into the LwIP and the
>>>> application layer. I hope it is useful for others.
>>>>
>>>> Excerpt from the docx in the zip:
>>>>
>>>> "any redistribution and use of the source code, including any resulting
>>>> derivative works, are licensed by TI for use only with TI Devices"
>>>>
>>>> Being like that, I can't even have a look at the sources... :-(
>>>> Interestingly, the source code files have a different license included
>>>> ;-)
>>>>
>>>>
>>>> Simon
>>>>
>>>> ___
>>>> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-11-04 Thread Amit Ashara

Hello All,

The Manifest has been updated now and the new package is available for
download.

http://www.ti.com/lit/zip/spmc023

Regards
Amit Ashara

On Wed, Nov 2, 2016 at 1:08 PM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Simon,
>
> The issue was with the License Option that we had used. The same is being
> now under correction and I would upload a new package with the correct
> License file.
>
> Regards
> Amit Ashara
>
> On Wed, Nov 2, 2016 at 11:02 AM, Amit Ashara <ashara.a...@gmail.com>
> wrote:
>
>> Hello Simon
>>
>> Thanks for the quick feedback. I am clarifying the same with the Legal
>> team.
>>
>> Regards
>> Amit Ashara
>>
>>
>> On Wed, Nov 2, 2016 at 10:39 AM, Simon Goldschmidt <goldsi...@gmx.de>
>> wrote:
>>
>>> Amit Ashara wrote:
>>> > The LLDP package is now online at the following link
>>> > http://www.ti.com/lit/zip/spmc023
>>> > There is a short ReadMe on integrating the LLDP into the LwIP and the
>>> application layer. I hope it is useful for others.
>>>
>>> Excerpt from the docx in the zip:
>>>
>>> "any redistribution and use of the source code, including any resulting
>>> derivative works, are licensed by TI for use only with TI Devices"
>>>
>>> Being like that, I can't even have a look at the sources... :-(
>>> Interestingly, the source code files have a different license included
>>> ;-)
>>>
>>>
>>> Simon
>>>
>>> ___
>>> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-11-02 Thread Amit Ashara

Hello Simon,

The issue was with the License Option that we had used. The same is being
now under correction and I would upload a new package with the correct
License file.

Regards
Amit Ashara

On Wed, Nov 2, 2016 at 11:02 AM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Simon
>
> Thanks for the quick feedback. I am clarifying the same with the Legal
> team.
>
> Regards
> Amit Ashara
>
>
> On Wed, Nov 2, 2016 at 10:39 AM, Simon Goldschmidt <goldsi...@gmx.de>
> wrote:
>
>> Amit Ashara wrote:
>> > The LLDP package is now online at the following link
>> > http://www.ti.com/lit/zip/spmc023
>> > There is a short ReadMe on integrating the LLDP into the LwIP and the
>> application layer. I hope it is useful for others.
>>
>> Excerpt from the docx in the zip:
>>
>> "any redistribution and use of the source code, including any resulting
>> derivative works, are licensed by TI for use only with TI Devices"
>>
>> Being like that, I can't even have a look at the sources... :-(
>> Interestingly, the source code files have a different license included ;-)
>>
>>
>> Simon
>>
>> ___
>> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-11-02 Thread Amit Ashara

Hello Simon

Thanks for the quick feedback. I am clarifying the same with the Legal team.

Regards
Amit Ashara

On Wed, Nov 2, 2016 at 10:39 AM, Simon Goldschmidt <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
> > The LLDP package is now online at the following link
> > http://www.ti.com/lit/zip/spmc023
> > There is a short ReadMe on integrating the LLDP into the LwIP and the
> application layer. I hope it is useful for others.
>
> Excerpt from the docx in the zip:
>
> "any redistribution and use of the source code, including any resulting
> derivative works, are licensed by TI for use only with TI Devices"
>
> Being like that, I can't even have a look at the sources... :-(
> Interestingly, the source code files have a different license included ;-)
>
>
> Simon
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-11-02 Thread Amit Ashara

Hello All

The LLDP package is now online at the following link

http://www.ti.com/lit/zip/spmc023

There is a short ReadMe on integrating the LLDP into the LwIP and the
application layer. I hope it is useful for others.

Regards
Amit Ashara

On Mon, Oct 24, 2016 at 9:29 AM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Sergio
>
> I run a windows system and Unix does not allow to run Git. I would
> definitely put in the ReadMe document.
>
> I will try to see if I can run Git on Windows system, but then which Git
> branch do I need to pull in and what permissions I need to have. The one
> listed on savannah does not seem to work on TI's windows system, so need to
> double check.
>
> Regards
> Amit
>
> On Mon, Oct 24, 2016 at 7:54 AM, Sergio R. Caprile <scapr...@gmail.com>
> wrote:
>
>> If you run a un*x flavor, you can have a fresh 1.4.1 tree and your
>> modified tree, and run a simple 'diff -pu -r fresh mod >lldp.patch'
>> standing at the parent for both trees.
>> A readme will be nice in case the developers decide not to include it as
>> built-in and there is 'user installation' needed for interested parties.
>> Your chances of it being considered for inclusion might improve if you
>> patch against git head instead of 1.4.1
>>
>>
>> ___
>> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-10-24 Thread Amit Ashara

Hello Sergio

I run a windows system and Unix does not allow to run Git. I would
definitely put in the ReadMe document.

I will try to see if I can run Git on Windows system, but then which Git
branch do I need to pull in and what permissions I need to have. The one
listed on savannah does not seem to work on TI's windows system, so need to
double check.

Regards
Amit

On Mon, Oct 24, 2016 at 7:54 AM, Sergio R. Caprile 
wrote:

> If you run a un*x flavor, you can have a fresh 1.4.1 tree and your
> modified tree, and run a simple 'diff -pu -r fresh mod >lldp.patch'
> standing at the parent for both trees.
> A readme will be nice in case the developers decide not to include it as
> built-in and there is 'user installation' needed for interested parties.
> Your chances of it being considered for inclusion might improve if you
> patch against git head instead of 1.4.1
>
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for 1.4.1

2016-10-23 Thread Amit Ashara

Hello Dirk

I would be uploading it on TI's web page as I have not used Git. Hope that
it is OK

Regards
Amit

On Sun, Oct 23, 2016 at 12:35 PM, Dirk Ziegelmeier <d...@ziegelmeier.net>
wrote:

> Just post it as a patch at savannah, we'll see what to do then. Hope this
> is OK for you.
>
> Dirk
>
> On Sat, Oct 22, 2016 at 3:56 AM, Amit Ashara <ashara.a...@gmail.com>
> wrote:
>
>> Hello All
>>
>> The LLDP base implementation for lwIP 1.4.1 is ready and will be released
>> on or before Oct 28, 2016. I wanted to check back with the user group if
>> some form of ReadMe document on integrating it an application is required.
>> Or should we keep it on hold for review by lwIP developers.
>>
>> Looking forward to some response
>>
>> Regards
>> Amit Ashara
>>
>> ___
>> 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
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] LLDP Implementation for 1.4.1

2016-10-21 Thread Amit Ashara

Hello All

The LLDP base implementation for lwIP 1.4.1 is ready and will be released
on or before Oct 28, 2016. I wanted to check back with the user group if
some form of ReadMe document on integrating it an application is required.
Or should we keep it on hold for review by lwIP developers.

Looking forward to some response

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

Re: [lwip-users] LLDP Implementation for lwIP

2016-09-07 Thread Amit Ashara

Hello All,

How do I release the source code and the license file? I have never used
git earlier.

Regards
Amit

On Tue, Aug 23, 2016 at 7:01 AM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Dirk
>
> I am using 1.4.1 version of the lwIP. Maybe once I get all the copyright
> and licensing in place, I can share the lldp files for review and latter
> merge them with lwIP if everyone else agrees
>
> Regards
> Amit
>
> On Tue, Aug 23, 2016 at 5:46 AM, Dirk Ziegelmeier <d...@ziegelmeier.net>
> wrote:
>
>> Hi Amit,
>>
>> you can now use ethernet_output() in lwIP git head to send your packets.
>> There is also an LWIP_HOOK_UNKNOWN_ETH_PROTOCOL now to receive ethernet
>> protocols that are unknown to lwIP.
>>
>> Dirk
>>
>> --
>> Dirk Ziegelmeier * d...@ziegelmeier.net * http://www.ziegelmeier.net
>>
>> On Fri, Aug 19, 2016 at 4:28 PM, Amit Ashara <ashara.a...@gmail.com>
>> wrote:
>>
>>> Hello Simon
>>>
>>> The lwIP license would not be touched. The only change will be that the
>>> lldp.c and lldp.h files may have copyright information w.r.t the
>>> organization I work for (*and I am clarifying with the legal team).
>>>
>>> Regards
>>> Amit
>>>
>>> On Fri, Aug 19, 2016 at 9:11 AM, Simon Goldschmidt <goldsi...@gmx.de>
>>> wrote:
>>>
>>>> Amit Ashara wrote:
>>>> > I wanted to however check before I do that is that is there a
>>>> contributor license
>>>> > agreement/contributors agreement for lwIP that I need to be aware of?
>>>>
>>>> lwIP's license is available nearly everywhere (website, sources, etc.).
>>>>
>>>> What I don't get is: where would the lwIP license be touched if you
>>>> write an LLDP stack?
>>>>
>>>>
>>>> Simon
>>>>
>>>> ___
>>>> 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
>>>
>>
>>
>> ___
>> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-19 Thread Amit Ashara

Hello Simon

OK, I will set it up on git. I wanted to however check before I do that is
that is there a contributor license agreement/contributors agreement for
lwIP that I need to be aware of?

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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-18 Thread Amit Ashara

Hello All,

I have the updated files for lldp transmit function. How do I put it up for
review?

Regards
Amit

On Wed, Aug 17, 2016 at 9:38 AM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Simon
>
> I have reduced the function call as lldp_raw(struct netif *netif);
>
> Since the packet needs to be constructed based on options, the functions
> called by lldp_raw would be static. After constructing the packet lldp_raw
> callsnetif->linkoutput(netif, p); The pbuf p is allocated in the function
> lldp_raw.
>
> Regards
> Amit
>
> On Wed, Aug 17, 2016 at 9:15 AM, Amit Ashara <ashara.a...@gmail.com>
> wrote:
>
>> Hello Simon
>>
>> I can make the change for lldp_raw to be netif compliant and using
>> internal functions in the lldp.c to construct the packet.
>>
>> Will it be OK in that case (along with the single port requirement)
>>
>> Regards
>> Amit
>>
>> On Wed, Aug 17, 2016 at 9:12 AM, Simon Goldschmidt <goldsi...@gmx.de>
>> wrote:
>>
>>> Amit Ashara wrote:
>>> > I call the LLDP transmit function lldp_raw(struct netif *netif, const
>>> struct eth_addr *ethsrc_addr)
>>> > with the MAC address of the port. So if there are multiple ports each
>>> with its MAC address, then
>>> > that can be resolved by the 2nd argument of the function.
>>>
>>> That's not netif-portable. A netif driver has to implement
>>> netif_linkoutput_fn(struct netif *netif, struct pbuf *p)
>>> and there's no source MAC address passed. You can check the pbuf of
>>> course, but that's not acceptable
>>> for all TX packets.
>>>
>>> > Also if we put the use restriction of a single port, wouldn't that
>>> work also?
>>>
>>> You can do that but you would limit the use of such a protocol
>>> implementation.
>>>
>>> Simon
>>>
>>> ___
>>> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-17 Thread Amit Ashara

Hello Simon

I have reduced the function call as lldp_raw(struct netif *netif);

Since the packet needs to be constructed based on options, the functions
called by lldp_raw would be static. After constructing the packet lldp_raw
callsnetif->linkoutput(netif, p); The pbuf p is allocated in the function
lldp_raw.

Regards
Amit

On Wed, Aug 17, 2016 at 9:15 AM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Simon
>
> I can make the change for lldp_raw to be netif compliant and using
> internal functions in the lldp.c to construct the packet.
>
> Will it be OK in that case (along with the single port requirement)
>
> Regards
> Amit
>
> On Wed, Aug 17, 2016 at 9:12 AM, Simon Goldschmidt <goldsi...@gmx.de>
> wrote:
>
>> Amit Ashara wrote:
>> > I call the LLDP transmit function lldp_raw(struct netif *netif, const
>> struct eth_addr *ethsrc_addr)
>> > with the MAC address of the port. So if there are multiple ports each
>> with its MAC address, then
>> > that can be resolved by the 2nd argument of the function.
>>
>> That's not netif-portable. A netif driver has to implement
>> netif_linkoutput_fn(struct netif *netif, struct pbuf *p)
>> and there's no source MAC address passed. You can check the pbuf of
>> course, but that's not acceptable
>> for all TX packets.
>>
>> > Also if we put the use restriction of a single port, wouldn't that work
>> also?
>>
>> You can do that but you would limit the use of such a protocol
>> implementation.
>>
>> Simon
>>
>> ___
>> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-17 Thread Amit Ashara

Hello Simon

I can make the change for lldp_raw to be netif compliant and using internal
functions in the lldp.c to construct the packet.

Will it be OK in that case (along with the single port requirement)

Regards
Amit

On Wed, Aug 17, 2016 at 9:12 AM, Simon Goldschmidt <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
> > I call the LLDP transmit function lldp_raw(struct netif *netif, const
> struct eth_addr *ethsrc_addr)
> > with the MAC address of the port. So if there are multiple ports each
> with its MAC address, then
> > that can be resolved by the 2nd argument of the function.
>
> That's not netif-portable. A netif driver has to implement
> netif_linkoutput_fn(struct netif *netif, struct pbuf *p)
> and there's no source MAC address passed. You can check the pbuf of
> course, but that's not acceptable
> for all TX packets.
>
> > Also if we put the use restriction of a single port, wouldn't that work
> also?
>
> You can do that but you would limit the use of such a protocol
> implementation.
>
> Simon
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-17 Thread Amit Ashara

Thanks Sergio. I am also awaiting Simon's inputs as well

Regards
Amit

On Wed, Aug 17, 2016 at 8:41 AM, Sergio R. Caprile 
wrote:

> I would #define fixed fields in the lldp.h equivalent and #ifndef #define
> the user modifiable values in a lldpopts.h file. However, I'm just as a
> user as you are; Simon is THE man here ;^)
>
>
>
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-12 Thread Amit Ashara

Hello Simon,

I call the LLDP transmit function lldp_raw(struct netif *netif, const
struct eth_addr *ethsrc_addr) with the MAC address of the port. So if there
are multiple ports each with its MAC address, then that can be resolved by
the 2nd argument of the function.

Also if we put the use restriction of a single port, wouldn't that work
also?

Regards,
Amit

On Fri, Aug 12, 2016 at 3:01 PM, goldsimon <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
>
> > LLDP can use the same MAC address as being used by lwIP. It is not
> mandated
> > that they be different.
>
> No, but if you have more than one port, it's typical to have one MAC per
> port. This helps to tell which port of a switch a device is connected to,
> for example (e.g. used in profinet for simple device replacement).
>
> For a single port device, the MAC address used for lldp can obviously be
> the same lwip uses.
>
> I was just saying lwip does not very well support multi port devices.
>
> Simon
>
> Gesendet mit AquaMail für Android
> http://www.aqua-mail.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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-12 Thread Amit Ashara

Hello Sergio, Simon,

I finally got the LLDP basic frame to work. I am able to send the LLDP
frame out of my device and see the same correctly on the wire-shark.

However, do be able to make a proper source code out of it, I would need
advise. The fields of the LLDP are static and not expected to change
dynamically. Also it is up to the user to decide what is required in the
fields and some of the field size may be configured at compile time. How do
I do this within the framework of lwIP

As an example, following is the "hack-patch" code.

#if !LWIP_AUTOIP
static
#endif /* LWIP_AUTOIP */
err_t
lldp_raw(struct netif *netif, const struct eth_addr *ethsrc_addr)
{
#if 1
  struct pbuf *p;
  err_t result = ERR_OK;
  struct eth_hdr *ethhdr;
  struct lldp_hdr *lldptlv;

  LWIP_ASSERT("netif != NULL", netif != NULL);

  /* allocate a pbuf for the outgoing ARP request packet */
  p = pbuf_alloc(PBUF_RAW, SIZEOF_LLDP_PACKET, PBUF_RAM);
  /* could allocate a pbuf for an ARP request? */
  if (p == NULL) {
LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_LEVEL_SERIOUS,
  ("etharp_raw: could not allocate pbuf for ARP request.\n"));
ETHARP_STATS_INC(etharp.memerr);
return ERR_MEM;
  }
  LWIP_ASSERT("check that first pbuf can hold struct etharp_hdr",
  (p->len >= SIZEOF_LLDP_PACKET));

  ethhdr = (struct eth_hdr *)p->payload;
  lldptlv = (struct lldp_hdr *)((u8_t*)ethhdr + SIZEOF_ETH_HDR);
  LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE, ("etharp_raw: sending raw
ARP packet.\n"));

  lldptlv->chassisid.tlvtype= 0x02;
  lldptlv->chassisid.tlvlen = 0x07;
  lldptlv->chassisid.tlvsubtype = 0x04;
  ETHADDR16_COPY(>chassisid.tlvvalue,ethsrc_addr);

  lldptlv->portid.tlvtype  = 0x04;
  lldptlv->portid.tlvlen   = 0x07;
  lldptlv->portid.tlvsubtype = 0x03;
  ETHADDR16_COPY(>portid.tlvvalue,ethsrc_addr);

  lldptlv->ttl.tlvtype  = 0x06;
  lldptlv->ttl.tlvlen   = 0x07;
  lldptlv->ttl.tlvsubtype = 0x00;
  lldptlv->ttl.tlvvalue[0] = 0x10;
  lldptlv->ttl.tlvvalue[1] = 0x00;
  lldptlv->ttl.tlvvalue[2] = 0x00;
  lldptlv->ttl.tlvvalue[3] = 0x00;
  lldptlv->ttl.tlvvalue[4] = 0x00;
  lldptlv->ttl.tlvvalue[5] = 0x00;


  LWIP_ASSERT("netif->hwaddr_len must be the same as ETHARP_HWADDR_LEN
for etharp!",
  (netif->hwaddr_len == ETHARP_HWADDR_LEN));
  /* Write the Ethernet MAC-Addresses */
  ETHADDR16_COPY(>dest, );
  ETHADDR16_COPY(>src, ethsrc_addr);
  ethhdr->type = PP_HTONS(ETHTYPE_LLDP);

  /* send ARP query */
  result = netif->linkoutput(netif, p);
  //ETHARP_STATS_INC(etharp.xmit);
  /* free ARP query packet */
  pbuf_free(p);
  p = NULL;
  /* could not allocate pbuf for ARP request */

  return result;
#endif
}


Regards
Amit

On Thu, Aug 4, 2016 at 1:07 PM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Sergio
>
> LLDP is a multicast information only packet. It has the be sent at fixed
> time intervals. The second approach to have a separate driver and calling
> it in a timer function seems to be the approach. Again the receive packet
> is easy to process. The transmit needs to be thought and inserted . Let me
> run some experiments and run into issues rather than sending emails on
> phantom issues.
>
> Regards
> Amit Ashara
>
> On Aug 4, 2016, at 9:31 AM, Sergio R. Caprile <scapr...@gmail.com> wrote:
>
> >> psNetif->linkoutput = tivaif_transmit;
> >
> >> If i check the tivaif_transmit function, "tivaif_transmit(struct
> >> netif *psNetif, struct pbuf *p)" it maps the pbuf to the MAC
> >> controller for transmission. It is this buffer that needs to be
> >> modified for LLDP frame.
> >
> > Not exactly. You need to allocate a pbuf, fill it with your data, give
> > it to tivaif_transmit(), and free it when it is done. Unless there is
> > some retransmission mechanism inside LLDP (which I don't know), then it
> > is done when the controller has it in its memory. Unless it is a
> > zero-copy driver (looks so, DMA perhaps?), in which "the controller
> > memory and the pbuf memory is the same space", so you need to know when
> > it has been transmitted to free it. I have no expertise in this area,
> > but there is this:
> > http://lwip.wikia.com/wiki/Writing_a_device_driver#Notes_
> on_Zero-Copy_Network_interface_drivers
> >
> >> However the call stack is always from TCP or DHCP (even when ARP is
> >> called which is a link layer packet).
> >
> > That is because you said you just needed the output phase ;^)
> > The stack is answ

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-04 Thread Amit Ashara

Hello Sergio

LLDP is a multicast information only packet. It has the be sent at fixed time 
intervals. The second approach to have a separate driver and calling it in a 
timer function seems to be the approach. Again the receive packet is easy to 
process. The transmit needs to be thought and inserted . Let me run some 
experiments and run into issues rather than sending emails on phantom issues.

Regards
Amit Ashara

On Aug 4, 2016, at 9:31 AM, Sergio R. Caprile <scapr...@gmail.com> wrote:

>> psNetif->linkoutput = tivaif_transmit;
> 
>> If i check the tivaif_transmit function, "tivaif_transmit(struct
>> netif *psNetif, struct pbuf *p)" it maps the pbuf to the MAC
>> controller for transmission. It is this buffer that needs to be
>> modified for LLDP frame.
> 
> Not exactly. You need to allocate a pbuf, fill it with your data, give
> it to tivaif_transmit(), and free it when it is done. Unless there is
> some retransmission mechanism inside LLDP (which I don't know), then it
> is done when the controller has it in its memory. Unless it is a
> zero-copy driver (looks so, DMA perhaps?), in which "the controller
> memory and the pbuf memory is the same space", so you need to know when
> it has been transmitted to free it. I have no expertise in this area,
> but there is this:
> http://lwip.wikia.com/wiki/Writing_a_device_driver#Notes_on_Zero-Copy_Network_interface_drivers
> 
>> However the call stack is always from TCP or DHCP (even when ARP is
>> called which is a link layer packet).
> 
> That is because you said you just needed the output phase ;^)
> The stack is answering because it is receiving the datagrams.
> Now you need to check your input to see why. You can go two paths, and I
> suggest you take both, not necessarily in this order.
> 
> (1) Go back to my first mail, where I've shown you code that explains this
> 
> (2) Read this:
>http://lwip.wikia.com/wiki/Writing_a_device_driver
> 
> ARP is link layer but is part of the IP suite, so the stack supports ARP
> and the link level driver has been configured to deliver ARP to lwIP
> input function.
> 
> 
> 
> ___
> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-03 Thread Amit Ashara

Hello Sergio,

I am using bare metal as well without OS and lwIP 1.4.1. So I don't see
most of the functions being mentioned. Looks like I would need to bring
2.0.0.RC2 (quite some work). in my case I am using the drivers from TM4C. I
checked and

  psNetif->output = etharp_output;

So what you are suggesting that I modify the etharp_output to process the
LLDP transmit packet?

Regards
Amit

On Wed, Aug 3, 2016 at 3:18 PM, Sergio R. Caprile 
wrote:

> I sent my response before you answered to Simon, so I couldn't know your
> problem was in the output path without violating causality. I think some
> states penalize that... ;^)
>
> When the stack needs to send a frame, it will call netif->output. That
> pointer is usually setup at the init function for the netif driver (see
> ethernetif_init()). My driver sets up etharp_output() for that, and I
> followed the guidelines in the wiki link I sent you, I suggest you follow
> that. I'm using bare metal, not an OS, and I don't remember if there is a
> constraint for this (it is for input stage).
>
> Anyway, that will eventually call netif->linkoutput() which is what you
> probably want to use. Remember you are using bare Ethernet over your driver
> in your port; you are not (yet) using lwIP.
>
>
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-03 Thread Amit Ashara

Hello Simon,

LLDP can use the same MAC address as being used by lwIP. It is not mandated
that they be different.

Regards
Amit

On Wed, Aug 3, 2016 at 3:08 PM, goldsi...@gmx.de <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
>
>> http://lwip.wikia.com/wiki/LwIP_Developers_Manual
>>
>
> Oh, right. You see, I don't really follow the wiki... Wikia has way too
> much advertising.
>
> This implementation is only for a single port device [..]
>> So it is not clear where do I insert the LLDP frame?
>>
>
> That's what I said. A device having one netif (i.e. the device's MAC
> address having one IP address) that connects to a network via multiple
> ports (which, in the LLDP case, each must have their own port MAC address),
> doesn't fit the lwIP netif model.
>
> You need to insert the LLDP TX frames to your driver independent of lwIP
> (although it could be done by adding some kind of destination port to a
> pbuf or something like that). And you'll have to extract the source port
> from incoming pbufs, which is also not covered by lwIP.
>
> I'm open for suggestions on integrating multi-port support to lwIP as long
> as it doesn't have negative side-effects on the standard single-port case.
>
>
>
> Simon
>
> ___
> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-03 Thread Amit Ashara

Hello Sergio,

As I mentioned earlier, the receive part is not the problem (based on the
inputs from Simon and going through the lwIP files. It is the transmit path
for which the call stack is not clear. Tracing it seems to always bring me
to the DHCP or TCP call function.

Regards
Amit

On Wed, Aug 3, 2016 at 2:46 PM, Amit Ashara <ashara.a...@gmail.com> wrote:

> Hello Simon
>
> I was referring to the following link
>
> http://lwip.wikia.com/wiki/LwIP_Developers_Manual
>
> This implementation is only for a single port device, which connects to a
> switch/router. While the receive part is clear, it is the transmit path
> that is not clear.
>
> In the current implementation netif->linkoutput is already mapped to a
> function which calls the EMAC driver. I checked the call stack and the
> transmit call comes from the DHCP during IP address acquisition. So it is
> not clear where do I insert the LLDP frame?
>
> Regards
> Amit
>
>
> On Wed, Aug 3, 2016 at 2:07 PM, goldsi...@gmx.de <goldsi...@gmx.de> wrote:
>
>> Amit Ashara wrote:
>>
>>> I would like to develop the Link Layer LLDP stack within lwIP framework.
>>>
>>
>> Cool!
>>
>> However the developer's manual link is empty.
>>>
>>
>> I have absolutely *no* idea what this means.
>>
>> Any suggestions where to start?
>>>
>>
>> Implementing LLDP is a bit tricky if you have more than one port, as lwIP
>> sees this as one 'netif' having a single IP address only (but the ports
>> have a MAC address each, used for LLDP at least).
>>
>> That being said, you'll have to send and receive LLDP packets on every
>> Ethernet port. If you have only one port, send via "netif->linkoutput" and
>> intercept before calling "ethernet_input()". If you have more than one
>> port, it gets more tricky and doesn't really fit the lwIP netif concept:-(
>>
>> Then, grab lwIP 2.0.0 (RC2 is the current one) and use the MIB-compiler
>> from "contrib/apps/LwipMibCompiler" to implement the LLDP mib(s?) and feed
>> the results of rx parsing into that mib.
>>
>> I'd be interested in taking a look at the code once it's done!
>>
>>
>> Simon
>>
>> ___
>> 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

Re: [lwip-users] LLDP Implementation for lwIP

2016-08-03 Thread Amit Ashara

Hello Simon

I was referring to the following link

http://lwip.wikia.com/wiki/LwIP_Developers_Manual

This implementation is only for a single port device, which connects to a
switch/router. While the receive part is clear, it is the transmit path
that is not clear.

In the current implementation netif->linkoutput is already mapped to a
function which calls the EMAC driver. I checked the call stack and the
transmit call comes from the DHCP during IP address acquisition. So it is
not clear where do I insert the LLDP frame?

Regards
Amit


On Wed, Aug 3, 2016 at 2:07 PM, goldsi...@gmx.de <goldsi...@gmx.de> wrote:

> Amit Ashara wrote:
>
>> I would like to develop the Link Layer LLDP stack within lwIP framework.
>>
>
> Cool!
>
> However the developer's manual link is empty.
>>
>
> I have absolutely *no* idea what this means.
>
> Any suggestions where to start?
>>
>
> Implementing LLDP is a bit tricky if you have more than one port, as lwIP
> sees this as one 'netif' having a single IP address only (but the ports
> have a MAC address each, used for LLDP at least).
>
> That being said, you'll have to send and receive LLDP packets on every
> Ethernet port. If you have only one port, send via "netif->linkoutput" and
> intercept before calling "ethernet_input()". If you have more than one
> port, it gets more tricky and doesn't really fit the lwIP netif concept:-(
>
> Then, grab lwIP 2.0.0 (RC2 is the current one) and use the MIB-compiler
> from "contrib/apps/LwipMibCompiler" to implement the LLDP mib(s?) and feed
> the results of rx parsing into that mib.
>
> I'd be interested in taking a look at the code once it's done!
>
>
> Simon
>
> ___
> 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

[lwip-users] LLDP Implementation for lwIP

2016-08-03 Thread Amit Ashara

Hello lwIP developers,

I would like to develop the Link Layer LLDP stack within lwIP framework.
However the developer's manual link is empty. Any suggestions where to
start?

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

Re: [lwip-users] Raw lwIP server write issue

2015-11-07 Thread Amit Ashara

Thanks Uwe.

On Fri, Nov 6, 2015 at 5:17 PM, Valery Ushakov <u...@stderr.spb.ru> wrote:

> Amit Ashara <ashara.a...@gmail.com> wrote:
>
> > Do you mean that instead of using pcb I should have another tcp_pcb e,g,
> > newpcb that is assigned from the pcb in the call back.
> >
> > struct tcp_pcb *newpcb;
> >
> > static err_t echo_accept(void *arg, struct tcp_pcb *pcb, err_t err)
> >
> > {
> >   LWIP_UNUSED_ARG(arg);
> >   LWIP_UNUSED_ARG(err);
> >
> >   newpcb = pcb;
>
> Exactly.
>
>
> > On Thu, Nov 5, 2015 at 11:28 AM, Valery Ushakov <u...@stderr.spb.ru>
> wrote:
> >
> >> Amit Ashara <ashara.a...@gmail.com> wrote:
> >>
> >> > When a connection is established between the server and the client,
> >> > I can use the tcp_write on the client side to send data in my
> >> > application code.  However the same on the server side is not
> >> > possible.  The pcb that has been used for the server only contains
> >> > the server's address and server's port but not the client's address
> >> > and client's port.  In the receive call back on the server side, I
> >> > can send the data to the client but not outside of the call back.
> >>
> >> You are using wrong pcb.  On the server you start with a listening
> >> pcb.  When your accept callback is called, it's passed a *new* pcb,
> >> that represents the established connection.  You should use that pcb
> >> for tcp_write.  Writing from receive callback works because in the
> >> receive callback the pcb argument is that connection pcb, not the
> >> original listening pcb.
> >>
> >> -uwe
>
> -uwe
>
>
> ___
> 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

Re: [lwip-users] Raw lwIP server write issue

2015-11-05 Thread Amit Ashara

Hello Uwe,

I have the call back for accept set as follows.

In the main application, I call echo_accept.

server_tpcb = tcp_new();
ui32Err = tcp_bind(server_tpcb, (ip_addr_t
*)_ui32IPAddress, NODE_TCP_SERVER_PORT);
UARTprintf("\n%d",ui32Err);
server_tpcb = tcp_listen(server_tpcb);
tcp_accept(server_tpcb, echo_accept);

which is as follows.

static err_t echo_accept(void *arg, struct tcp_pcb *pcb, err_t err)

{
  LWIP_UNUSED_ARG(arg);
  LWIP_UNUSED_ARG(err);

  tcp_setprio(pcb, TCP_PRIO_MIN);
  tcp_arg(pcb, NULL);
  tcp_recv(pcb, echo_recv);
  tcp_err(pcb, echo_err);
  tcp_poll(pcb, NULL, 0);
  return ERR_OK;
}

Do you mean that instead of using pcb I should have another tcp_pcb e,g,
newpcb that is assigned from the pcb in the call back.

struct tcp_pcb *newpcb;

static err_t echo_accept(void *arg, struct tcp_pcb *pcb, err_t err)

{
  LWIP_UNUSED_ARG(arg);
  LWIP_UNUSED_ARG(err);

  newpcb = pcb;

  tcp_setprio(pcb, TCP_PRIO_MIN);
  tcp_arg(pcb, NULL);
  tcp_recv(pcb, echo_recv);
  tcp_err(pcb, echo_err);
  tcp_poll(pcb, NULL, 0);
  return ERR_OK;
}

Regards
Amit

On Thu, Nov 5, 2015 at 11:28 AM, Valery Ushakov <u...@stderr.spb.ru> wrote:

> Amit Ashara <ashara.a...@gmail.com> wrote:
>
> > When a connection is established between the server and the client,
> > I can use the tcp_write on the client side to send data in my
> > application code.  However the same on the server side is not
> > possible.  The pcb that has been used for the server only contains
> > the server's address and server's port but not the client's address
> > and client's port.  In the receive call back on the server side, I
> > can send the data to the client but not outside of the call back.
>
> You are using wrong pcb.  On the server you start with a listening
> pcb.  When your accept callback is called, it's passed a *new* pcb,
> that represents the established connection.  You should use that pcb
> for tcp_write.  Writing from receive callback works because in the
> receive callback the pcb argument is that connection pcb, not the
> original listening pcb.
>
> -uwe
>
>
> ___
> 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

[lwip-users] Raw lwIP server write issue

2015-11-05 Thread Amit Ashara

Hello All,

I am using Raw lwIP 1.4.1 on a microcontroller. Since the requirement is to
have acknowledged transfer between two devices, I created a server and
client model. However I ran into an issue.

When a connection is established between the server and the client, I can
use the tcp_write on the client side to send data in my application code.
However the same on the server side is not possible. The pcb that has been
used for the server only contains the server's address and server's port
but not the client's address and client's port. In the receive call back on
the server side, I can send the data to the client but not outside of the
call back.

Since I know that at any point only one client can communicate with a
server, so

1. Is the server client model in TCP/IP the correct choice, or is there
some other model like a peer-2-peer that I should be using
2. If the server client model is correct, then how do I do a tcp_write
outside the scope of a call back.

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

38 matches

Mail list logo