[lwip-users] Transferring data from pbuf chain to app buffer.

[mitchj]

Good afternoon LWIP users,

I could use a little help here, I'm attempting to take data from a pbuf
chaing and transfer it to an app buffer. What I'm doing is adding data to a
pbuf as I receive it, my app is aware of that object and will read off bytes
into its own buffer. I'm doing this to be compatible with other software. So
the function will receive a void* and length that are allocated outside of
the scope of this class (this is in CPP) and will need to copy up to the
length of the app buffer. I then need to remove that amount of bytes from
the front of the pbuf chain so that when the app does another "read" it gets
the correct data in the chain. My attempt at this is below, however, it
appears I'm chopping data off of the end and not the front. I'm not quite
sure what approach is best for this, so any input on how I might do this, or
an alternate method would be great. Thanks!

uint32 cx_TEthernetParams::RetrieveDataAndRX(void* pvBuff, uint32
uiNumBytes)
{
  uint32 rx_bytes = 0;
  if((mxDataSet.in_pb != NULL) && (mxDataSet.in_pb->tot_len > 0))
  {
  rx_bytes = pbuf_copy_partial(mxDataSet.in_pb, pvBuff, uiNumBytes, 0);
  if(rx_bytes <= mxDataSet.in_pb->tot_len)
  {
pbuf_realloc(mxDataSet.in_pb, mxDataSet.in_pb->tot_len - rx_bytes);
  }else
  {
pbuf_free(mxDataSet.in_pb);
  }
//}
  }
  return rx_bytes;
}



--
View this message in context: 
http://lwip.100.n7.nabble.com/Transferring-data-from-pbuf-chain-to-app-buffer-tp30205.html
Sent from the lwip-users mailing list archive at Nabble.com.

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

Re: [lwip-users] ARP message stops TCP?

[Mike Rosing]

After some online digging it looks like I will have problems to work on eventually - for the moment things are working.  The call backs are inside the interrupt level, the calls to the library are in the main loop.  I don't know what the priority levels are for the interrupts, or if this system allows nesting, so I suspect I'll see weird problems eventually.Thank you for the warning - when the time comes to rewrite (which always happens!) that will be on top of the list.MikeOn July 20, 2017 at 2:52 PM "goldsi...@gmx.de"  wrote:Mike Rosing wrote:I do think the call backs are inside the interruptEhrm, unless everything in lwIP runs on that interrupt level and *not*in main loop (or a thread), that's OK. If not, sooner or later, you'llget a problem!, but the total time is 10's of microseconds and the system responsetime is milliseconds, so it should not be an issue.This doesn't depend on the callback run time vs. system response time.If it just happens that lwIP is processing timers while your callbackfires, you'll have a problem.In the end, just don't try to use a library in a way that it wasn'tmeant to!Simon___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

Re: [lwip-users] ARP message stops TCP?

[goldsi...@gmx.de]

Mike Rosing wrote:

I do think the call backs are inside the interrupt


Ehrm, unless everything in lwIP runs on that interrupt level and *not* 
in main loop (or a thread), that's OK. If not, sooner or later, you'll 
get a problem!


, but the total time is 10's of microseconds and the system response 
time is milliseconds, so it should not be an issue.


This doesn't depend on the callback run time vs. system response time. 
If it just happens that lwIP is processing timers while your callback 
fires, you'll have a problem.
In the end, just don't try to use a library in a way that it wasn't 
meant to!


Simon

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

Re: [lwip-users] ARP message stops TCP?

[Mike Rosing]

Thank you - I have not seen that page.  I will check into that.I did change the delay time between messages from minutes to seconds, and then the system works fine.  I have also tried a completely different approach using UDP only, and LwIP works fine, Linux fails to receive what LwIP sends.  So I think the problems I have are not on the LwIP side.  I do think the call backs are inside the interrupt, but the total time is 10's of microseconds and the system response time is milliseconds, so it should not be an issue.  But it is easy enough to measure and double check.At this point I think LwiP is pretty solid.  Now that I understand how it works it is more robust than the rest of my system!MikeOn July 20, 2017 at 2:07 PM "goldsi...@gmx.de"  wrote:Mike Rosing wrote:I have a strange problem where raw API LwIP (2.0.2) seems to work most of the time but appears to randomly stop.  So I put wireshark up and looked at the messages between LwIP and the server it was talking to.  From the description of your program, it sounds like your problem could well be that you're violating lwIP's threading requirements. Have you read the documentation on how lwIP must be used (e.g. http://www.nongnu.org/lwip/2_0_x/pitfalls.html)?  Simon ___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

Re: [lwip-users] netconn API reliability issue

[goldsi...@gmx.de]

newbie wrote:

In simple tests, I tried to exchange data betwenn server. transmission
succeeded only for 17 sequential exchanges then I get error from
netconn_recv.


My simple answer would be that the remote side closes the connection.
Seriously, without any more info, how could one help here? You'll at 
least have to try to match lwIP's behaviour with what's going on (on the 
cable), e.g. by using wireshark.


Simon

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

Re: [lwip-users] Fwd: problems in pppos

[parwath . r]

Hi,
  thanks, i will try with lwip never version.

thanks
parwath

On 2017-07-20 02:25, Sylvain Rochet wrote:

Hi,

On Thu, Jul 20, 2017 at 02:11:41AM -0700, parwat...@yashaswinies.com 
wrote:


Hello all,
   I am new to lwip 1.4.0  stack. i am trying ppp over serial port for 
small
ppp connect test, but its getting strucked in networking phase here i 
have

attached log also please suggest us to move forward.


PPP stack in lwIP 1.4.0 is awfully old, lwIP 1.4.0 itself was released 
6

years ago (which is already quite a lot) but this is worse for the PPP
stack. Please switch to lwIP 2.0 first.

Sylvain

___
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] Fwd: problems in pppos

[Sylvain Rochet]

Hi,

On Thu, Jul 20, 2017 at 02:11:41AM -0700, parwat...@yashaswinies.com wrote:
> 
> Hello all,
>I am new to lwip 1.4.0  stack. i am trying ppp over serial port for small
> ppp connect test, but its getting strucked in networking phase here i have
> attached log also please suggest us to move forward.

PPP stack in lwIP 1.4.0 is awfully old, lwIP 1.4.0 itself was released 6 
years ago (which is already quite a lot) but this is worse for the PPP 
stack. Please switch to lwIP 2.0 first.

Sylvain


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

[lwip-users] Fwd: problems in pppos

[parwath . r]

Hello all,
   I am new to lwip 1.4.0  stack. i am trying ppp over serial port for 
small ppp connect test, but its getting strucked in networking phase 
here i have attached log also please suggest us to move forward.




thanks
parwathppp phase changed[0]: phase=0

13Executing ATD*99***1#
151
CONNECT

netif: setting default interface ''

ppp_connect[0]: holdoff=0

ppp phase changed[0]: phase=1

pppos_connect: unit 0: connecting

ppp_start[0]

pppos_send_config[0]: out_accm=FF FF FF FF

ppp_send_config[0]

pppos_recv_config[0]: in_accm=FF FF FF FF

ppp_recv_config[0]

ppp: auth protocols:
 PAP=1

pbuf_alloc(length=24)

pbuf_alloc: allocated pbuf 0x2032976c

pbuf_alloc(length=24) == 0x2032976c

sentc0 21 01 01 00 14 02 06 00 00 00 00 05 06 68 06 4d 17 07 02 08 02 

pbuf_alloc(length=0)

pbuf_alloc: allocated pbuf 0x20329610

pbuf_alloc(length=0) == 0x20329610

pbuf_free(0x20329610)

pbuf_free: deallocating 0x20329610

pppos_write[0]: len=24

pbuf_free(0x2032976c)

pbuf_free: deallocating 0x2032976c

sys_timeout: 0x2120 msecs=2000 handler=(fsm_timeout) arg=0x2032e408

ppp_start[0]: finished

pppos_input[0]: got 92 bytes

pbuf_alloc(length=0)

pbuf_alloc: allocated pbuf 0x2032976c

pbuf_alloc(length=0) == 0x2032976c

rcvdc0 21 01 01 00 14 02 06 00 00 00 00 05 06 7b 2d f7 6d 07 02 08 02 

pbuf_header: old 0x2032977c new 0x2032977e (-2)

pbuf_alloc(length=256)

pbuf_alloc: allocated pbuf 0x20329610

pbuf_alloc(length=256) == 0x20329610

pbuf_free(0x20329610)

pbuf_free: deallocating 0x20329610

pbuf_alloc(length=24)

pbuf_alloc: allocated pbuf 0x20329610

pbuf_alloc(length=24) == 0x20329610

sentc0 21 02 01 00 14 02 06 00 00 00 00 05 06 7b 2d f7 6d 07 02 08 02 

pbuf_alloc(length=0)

pbuf_alloc: allocated pbuf 0x203294b4

pbuf_alloc(length=0) == 0x203294b4

pbuf_free(0x203294b4)

pbuf_free: deallocating 0x203294b4

pppos_write[0]: len=24

pbuf_free(0x20329610)

pbuf_free: deallocating 0x20329610

pbuf_free(0x2032976c)

pbuf_free: deallocating 0x2032976c

pbuf_alloc(length=0)

pbuf_alloc: allocated pbuf 0x2032976c

pbuf_alloc(length=0) == 0x2032976c

rcvdc0 21 02 01 00 14 02 06 00 00 00 00 05 06 68 06 4d 17 07 02 08 02 

pbuf_header: old 0x2032977c new 0x2032977e (-2)

netif_set_mtu[0]: mtu=1500

pppos_send_config[0]: out_accm=0 0 0 0

ppp_send_config[0]

pppos_recv_config[0]: in_accm=0 0 0 0

ppp_recv_config[0]

ppp phase changed[0]: phase=5

ppp phase changed[0]: phase=7

pbuf_alloc(length=20)

pbuf_alloc: allocated pbuf 0x20329610

pbuf_alloc(length=20) == 0x20329610

sent80 21 01 01 00 10 02 06 00 2d 0f 01 03 06 00 00 00 00 

pbuf_alloc(length=0)

pbuf_alloc: allocated pbuf 0x203294b4

pbuf_alloc(length=0) == 0x203294b4

pbuf_free(0x203294b4)

pbuf_free: deallocating 0x203294b4

pppos_write[0]: len=20

pbuf_free(0x20329610)

pbuf_free: deallocating 0x20329610

sys_timeout: 0x2120 msecs=2000 handler=(fsm_timeout) arg=0x2032f5c8

pbuf_free(0x2032976c)

pbuf_free: deallocating 0x2032976c



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