Nikolas Karakotas wrote:
I'm facing an issue on-site where there is quite a lot of traffic.
Sometimes I can see from the log that we have a TCP re-transmission
and we once the packet is re transmitted the data we receive is
impartial. As a result our modbus driver responds with and error.
I can
Amena El Homsi wrote:
For the outgoing packets, in low_level_output() function, We copy the
headers from the pbuf RAM to the frame memory and we inform the HW of
the address of the frame to be sent. Then HWMAC will send the frame
over the air and after it is successfully sent and the ACK is
Amena El Homsi wrote:
I am trying to send ping request using Lwip.
The ICMP header and ping data is in my system frame memory referenced
by a PBUF_ROM 'p' (p->payload points to the ICMP hdr in the frame memory.
Is this correct? How long is the contents of this buffer stable?
PBUF_ROM means
Markus Pischinger wrote:
what does the "cachehit" in tcp stats refer to?
It just means that the input pcb (active or listening) was the first in
the list. Not too interesting...
I got some "proterr" aswell but as far as i've seen they occur when i
get a packet while not having an active
Giuseppe Modugno wrote:
The prototype for SSI callbacks is:
[..]
I don't see any reference to query string parameters. So how to select
the right action?
Sorry for the confusion. This is a mix of resource optimization, missing
documentation and maybe missing framework functions.
The idea
antonio wrote:
I am using Lwip-2.0.3 and running a basic HTTPS MbedTLS application to
request MyIP. When I connect the application to a server running on my PC,
it works fine, but when I try to connect to a remote server "api.ipify.org"
I quickly run out of heap bcz LWIP is consumes much memory.
Itzik Levi wrote:
What I can do is work on an executable which dynamically loads lwip's
stack(I can make it a shared object).
Will that be good enough?
Ehrm, no, sorry. What I want is something that I can reproduce it
without 3rd party code that I can't check. In other words if I check
Itzik Levi wrote:
I'll recap the setup:
1. Non blocking sockets.
2. poll(thread 1).
OK, poll is pretty new. There might be problems of course, as it's new
code and also select has change a bit due to adding poll support.
1. read/write in 2 different threads, but not in parallel, mutex
Itzik Levi wrote:
After debugging a bit further, it seems that the data corruption I'm
having, is an old tcp segment, that was already received being sent
again(??).
[..]
Dumps are here:https://ufile.io/gbwit
What kind of "dumps" are these, and what do you expect me to do with them?
Anyway,
Olivier Desenfans wrote:
Regarding the TX side of things,
Keep in mind that most TX functions allocate PBUF_RAM pbufs, which are
allocated via mem_malloc(). To move this into pools, you'll need some
extra work.
Also, are you *sure* constructing packets in uncached memory is faster
than
Itzik Levi wrote:
Now I cant even reach the corruption issue(not sure if solved or not),
as I constantly getting another assert after a while : "Assertion
"sock->fd_used != 0" failed at line 344 in lwip/src/api/sockets.c.".
Could you add a description of the call stack or what your
Dirk Ziegelmeier wrote:
Try SO_BINDTODEVICE socket option
A better description for this short answer is: having 2 netifs on the
same subnet was not supported until we implemented SO_BINDTODEVICE. It
might now work, but there might be pitfalls we haven't thought
of/haven't tested yet.
Shinod AK wrote:
Where can I find source code of SNMP agent for lwip stack ? Please help.
Ehrm, I'm not sure I understand that question. Where have you looked?
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
Raivis wrote:
3. ST implementation of LwIP is faulty. I'm using LwIP version which
comes with CubeMX. I've noticed it is version 2.0.0 instead of 2.0.3.
I don't think it is. Comparing it to our original 2.0.0 sources, they
seem to have changed only compiler warnings this time.
ST *eth
Joel Cunningham wrote:
I've updated the remaining comments to mention the same priority on
git master
Hmm, thinking about this, shouldn't we instead change the killing scheme
to not kill active connections? It's been like it is for long, but given
this bug report, I think the way the
Could you please stop quoting over 80kb per mail? Thanks.
simeon.trifo...@amk-drives.bg wrote:
I also set the IP address and mask to 0 when I detect link down.
Ehrm, why do you do that? When DHCP is enabled, DHCP has control over
the IP addresses. If you mess with them manually while DHCP is
Adrian Figueroa wrote:
I have implemented a simple TCP server on lwIP 1.4.1 running on
chibiOS (a realtime OS) with the netconn api on an STM32F746.
It goes like this:
[..]
My TCP client (it is a Matlab PC) connects, sends some data, and
disconnects. The TCP server also closes the
Alex Simanovsky wrote:
I decided to try and use mempools. Copy pasted the code for lwipopts.h
and lwippools from the wiki.
Everything compiles fine but when running I get an assertion of "no
pool is that big"
Can anyone shed some light on what's going on and what exactly the
error means?
simeon.trifo...@amk-drives.bg wrote:
Can't move over header in packet
Have you changed the default setting of
LWIP_ICMP_ECHO_CHECK_INPUT_PBUF_LEN? That code is there to check your case.
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
Flavio Gobber wrote:
I need to implement a server which need to receive message large more
than the length of 1400 bytes.
What I see if the recv function return only a length of 1464 bytes, I
can repeat the the recv function before to parse the message, but how
can understand that the message
Ajay Garg wrote:
We are using lwip-1.4.1 with FreeRTOS on Atmel-Studio-7, on Windows.
During the call to netconn_connect, the resultant err_t code being
returned is ERR_ABRT.
[..]
I have googled, and I see a lot of people have this issue.
Great. This means the remote host did not respond to
gussabina wrote:
even when 2 TCP segments are received
in the ethernet interface (as observed in wireshark), the stack passes only
one packet with double size
In this case the application fails as it's not what would expect
I would not have expected this (normally, you'd get one recv
Adrian Figueroa wrote:
There is a list of chained DMA transmit descriptors, as they seem to be called.
There is always four of them, this is hard coded.
My version of the STM32F4xx HAL driver leaves this as a define to the
application... But you're limited by DMA-capable RAM, of course.
Adrian Figueroa wrote:
I can see some errors in low_level_output() in ethernetif.c.
This fails:
if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET)
{
errval = ERR_USE;
goto error;
}
I don't know the F7 driver, but my F4 driver seems to have
Ran Shalit wrote:
I have issue on using lwip (1.3.1)
You'll probably have more issues with that old version. As you might
imagine, there were some bugs fixes since then ;-)
Is there a simple way to fix it (without upgrading to newer version) ?
Yes. Well, simple depends on the definition.
antonio wrote:
I have an application that requires including dhcp.h, however, since the
DHCP state messages are in prot/dhcp.h
I got a compile error..
" error: 'DHCP_STATE_BOUND' undeclared (first use in this function)
if (new_state == DHCP_STATE_BOUND) {"
when I included
Nathan Hartman wrote:
When building lwIP-1.4.1
Honestly, I stopped paying attention here. 1.4.1 is nearly five years
old. Please do test the new version instead of cross-reading the sources ;-)
Have you found 'ip_addr_isany_val()'?
Simon
___
Paul Plankton wrote:
My problem: I'm running on an embedded system where I can't waste too
much time with handling network data.
This and the statement about handling "1460 bytes during one interrupt
call" is somewhat disturbing. Are you sure you don't violate lwIP's
threading requirements?
David Lockyer wrote:
Okay, thank you for the suggestion. Just to be clear are you
suggesting modifying lwip_select() to allocate select_cb from a pool &
free prior to return?
Via a define, like Joel wrote, yes. This might need a new memp pool
though...
We don't have an abstraction for your
Raphael Zulliger wrote:
I'd like to stress again that both, the mentioned Ubuntu and a Windows
10 system respect different MTUs for IPv4 and IPv6
That was clear from the first mail. Maybe it got clear from my mail,
that I wanted to know what are the downsides of our behaviour.
I failed to
Raphael Zulliger wrote:
What do you think? Have I found a bug and shall I open a bug report or
am I wrong?
I'm not really sure. After all, the MTU is what a network can send.
Having a different MTU for IPv4 and IPv6 doesn't make much sense to me?
Simon
Steinberg Michael wrote:
Hello,
Here's a bit more context to my problem. When I call tcp_close in reaction to being handed a NULL
pbuf ptr in the receive-callback, this is what happens inside file "tcp.c": Eventually
tcp_close_shutdown is called with the tcp_pcb in state CLOSE_WAIT. The "Not
Markus Pischinger wrote:
/LWIP_ASSERT("tcp_input: pcb->next != pcb (before cache)", pcb->next
!= pcb);
/
Normally, this is a strong indication that you are violating lwIP's
threading requirements. Read http://www.nongnu.org/lwip/2_0_x/pitfalls.html
Simon
Bill Auerbach wrote:
I can debug some, yes, but I’m no expert on this part of lwIP or TCP.
So I need help in what information is best to gather. I can pause
when the sending stops and get to these variables. Would output from
LWIP_DEBUG_ONs (whichever ones are pertinent) show you anything
Tony wrote:
The aim is to only allow n open TCP connection at a time, and reject
all further connection requests. This worked reasonably well in 1.3.2,
but now fails in 2.0.2.
[..]
HOWEVER: this n+1 connection terminates the very 1st connection (takes
over the 1st PCB?).
Although it's
nrichard wrote:
I have been able to get these all running
at the same time using the HEAP? method by setting both MEM_LIBC_MALLOC and
MEMP_MEM_MALLOC to 1. However it is not consistent. Sometimes the system
tells me "memp_malloc: out of memory in pool PBUF_POOL" even though I'm
using the HEAP
David Belyea wrote:
I am trying to create an LWIP TCP client using the raw API. I have an
echo server example, but I'm looking for a simple client example to
look at. Anyone have a simple TCP client I can see as an example.
Have a look at the SMTP client (src/apps/smtp).
Cheers,
Simon
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
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?
rom:* lwip-users <lwip-users-bounces+noam=silrd@nongnu.org> on
behalf of goldsi...@gmx.de <goldsi...@gmx.de>
*Sent:* Thursday, July 6, 2017 9:48 PM
*To:* Mailing list for lwIP users
*Subject:* Re: [lwip-users] how to set the link up
Noam Weissman wrote:
> THANKS for pointing thi
Noam Weissman wrote:
THANKS for pointing this out !!!.
I am using the code I sent for several years and was not aware of that :-(
I must say now I'm a little bit shocked. You already pointed out lwIP
has threading requirements on this list more than once. And still you've
got it wrong. What
Yubin Ruan wrote:
But I don't know how to get started
because the lack of document of lwip's API.
Now now, where have you looked? You seem to have missed the doc folder,
the "homepage" link from savannah, the wiki, and the example code?
Or are all those not enough? In that case, *please*
Noam Weissman wrote:
Cannot ?...[..] From working with LwIP for the last 6+ years I think
that unless Marvel made changes in
LwIP core you should not have any problems porting.
There *are* situations where you just can't upgrade without much effort
because the vendor has linked *closed
Simeon Trifonov wrote:
Probably you will ask now what kind of bug I mean. I don't remember,
but I will try to find out. Probably my fix is not the best and you
can offer me another one.
If the bug was not being able to use PBUF_REF/PBUF_ROM for input (since
pbuf_header does not work in
Xun Chen wrote:
Maybe I should track down the return from pbuf_alloc to confirm that I
indeed have a valid buffer
Yes, that would indeed be a *very* good idea!
Given the question in the subject: you'll just have to try again.
Unfortunately, there's currently no way of registering a callback
twork interface PPP code.
//
//*****
#include "third_party/lwip-1.4.1/src/netif/ppp/auth.c"
#include "third_party/lwip-1.4.1/src/netif/ppp/chap.c"
#include "third_party/lwip-1.4.
shruthi wrote:
Is it possible to change the TCP MSS dynamically in run-time before
connecting to a TCP server? I came across the link -
https://lists.gnu.org/archive/html/lwip-devel/2004-01/msg3.html. Has
this been implemented?
Wow, that link is really old. And no, it hasn't been
Hi Kiran,
posts like this, which basically say "I seem to have some arbitrary
problem, I use 10 other libraries and lwIP, please help me!" normally
don't get much attention here. Everyone reading and writing here does
this without getting paid for it (and your mail + address suggests you
use
billium wrote:
No this did not make much difference, but I had forgot the TI
lwiplib.c file has loads of includes, that was pulling in 1.4.1 files in!
How could it pull in 1.4.1 files? You should remove those files and fix
your include paths so this can't happen. That's not a TI problem but a
Jan Menzel wrote:
At the end, the buffer size required for encrypting/decrypting
transmitted/received data is something, that depends on your setup and
on configuration options commonly available. So, if you carefully
control and debug your setup you probably can run with less memory.
Werner Motz wrote:
Unfortunatelly I still have link errors and I cannot find a docu in the wiki
about it.
Link
DROP1264
ERR 1264
Search for "LINK_STATS_INC(link.drop);" in your project. That stats are
netif driver specific, we cannot help you there. It could just be
Werner Motz wrote:
Really (and not meant in an offensive way!), I'm with Dirk thinking you need
someone teaching you lessons on embedded programming. Or you need to pay
someone programming your devices if this is about devices you want to
sell...
---> Serious?
Yes! I can put bricks on bricks
Noam Weissman wrote:
First of all the code is still in development and secondly you need
lots of RAM.
That "lots of RAM" is a limitation of TLS, not a limitation of mbed TLS
or how lwIP uses it.
That code is still not finished though. And I have to come up with
RAM/ROM numbers once it is
Marco Jakobs wrote:
The memory issue is serious. A customer was asking for VJ compression
support, tried this today and BOOM, 3kB of RAM missing.
Yes, but have you actually tested 2.0.x to see it increased?
That's not fun, that's my daily business.
You're not the only one there ;-)
Just
Werner Motz wrote:
---> passing tcp_active_pcbs is not necessary because as u already
mentioned, I could call it everywhere. I just tried to give a parameter to
the callback function.
The usage of tcpip_callback should be OK.
---> Obviously it is not good / right to call macros and functions
Simeon Trifonov wrote:
My function low_level_output() sometimes tries to send data
bigger than MSS.
First of all you're mixing up things: the low_level_output() function
must *always* be prepared to handle packets larger than MSS: MSS limits
TCP data while your netif has to send MTU + ETH
Werner Motz wrote:
In my freertos task (outside lwip) I do following:
[..]
tcpip_callback_with_block(WTF, tcp_active_pcbs, 0);
Why on earth would you pass 'tcp_active_pcbs'? Wherever you got that
from: tell them this is wrong and they should stop spreading such
horrible code
Sylvain Rochet wrote:
I checked if the issue was still there is the current master/2.0 branch,
you are right, this bug was fixed in commit fb07a28c99 ("fixed bug
#36388 (PPP: checksum-only in last pbuf leads to pbuf with zero
length)") *FIVE* years ago.
:-))
Thanks, for jumping in, Sylvain!
gussabina wrote:
The problem was there was not default value for DEFAULT_UDP_RECVMBOX_SIZE in
the options, so I had to add an extra line.
Just in case someone else goes though the same problem, they need to add
last line in lwipopts.h file;
Ehrm, no, that line does *not* have to be added.
gussabina wrote:
I'm using the Atmel port for ATSAM4E which comes from ASF (Atmel Software
Framework) integrated with FreeRTOS.
In that case, have you asked Atmel? Tell them the lwIP guys said it's
not an lwIP bug ;-)
If it is, I'll pay you a beer next time I see you :-)
Simon
Werner Motz wrote:
tcpip_callback(tcp_write(pcb,ucrecBuff,supersize,TCP_WRITE_FLAG_COPY),NULL);
tcpip_callback(tcp_output(pcb), NULL);
Ouch! tcpip_callback() takes a void pointer as first argument. You are
*first* calling tcp_write with the parameters supplied, then passing the
return
gussabina wrote:
Ok. But TCP sockets works fine...
Honestly, that doesn't mean anything :-) There can well be other bugs
and TCP just happens to work...
Where do you have your lwIP port from? Who set up your interrupts and
thread configuration?
Actually, in below code I'm using select()
gussabina wrote:
Is the recvmbox supposed to be created by bind() function?
It's supposed to be allocated in socket() (that function fails if mbox
allocation fails) and removed in close() only. That's what makes me
think your port's mbox alloc/dealloc/check functions don't work correctly...
Noam Weissman wrote:
I have a simple link task that checks the PHY for link, reads it. If
link is up it starts the DHCP task and wait for address.
If link is down the DHCP task is put into an idle state and waits for
link to come back…
[..]
When board is reset, link is established and at
shruthi:
Can the rate of packet generation of the stack be controlled?
No. TCP will always send as much as it may. This is only limited by the
sender window, congestion control and available memory. You'd have to
limit that on your own (or reduce your processor's speed :-)
Simon
Mike Rosing wrote:
The SNTP seems to initialize ok, but the routine sntp_process() is never called.
Have you checked (e.g. using wireshark) that SNTP requests are sent and
responses are received? If not, sntp_process() won't get called either.
If the response is received, check "lwip_stats"
Patrick Klos wrote:
(I think if LWIP_ASSERT was enabled, the code generated by the macro
expansion would be enough to stop the warning, at least for 'prev'?)
Exactly. And honestly, I'm not sure if it makes sense to enable
"-Wnull-dereference" with asserts disabled. You enable half of the
I can't comment on the suggested protocols, but...
pupkin wrote:
I need to send large quantities of data reliably from a Zynq-based device to
a PC.
Although the name does not match: if you plan to implement a reliable
protocol over UDP, you could try and make it implement the new (git
markus.for...@gmx.ch wrote:
Hello Simon
> Try this:
> http://lmgtfy.com/?q=winpcap+developer%27s+pack
Thank you, I did find it. ;-)
I've also updated the readme.txt file by now, thanks for the hint!
Simon
___
lwip-users mailing list
shruthi wrote:
Any idea what the problem might be?
No, sorry.
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
fin wrote:
Hello, I use LwIP port for stm32f207 (IAR compiler), when working more than
24 hours, netconn_recv function returns error ERR_MEM.
Obviously, you have a netbuf leak somewhere. I haven't heard of this
being a bug and 1.4.0 is rather old, so I assume it's a bug in your
wrote shruthi:
In this case,
1. Is the support available for Unix?
Why wouldn't it? lwIP is just a library and using it on Unix is just a
port. If you want to see how it's done, get the latest git master's src
and contrib repositories and build the unix example port with "mbedtls"
next to
Jan Menzel wrote:
Can you tell me more what improvements you're implementing and how this
will effect the interface to mbedtls?
No improvements really. I have added an indirection layer to the tcp
callback API that allows to plug in layers between the application (e.g.
HTTP server) and TCP.
Noam Weissman wrote:
As far as I know 1.41 was the stable version used for a long time before 2.xx
That's correct. Nevertheless, it's so old by now that I wouldn't suggest
anyone to upgrade to it. Upgrading to version 2 is *strongly* suggested
as it includes many more bugfixes and new
Mohamed Hnezli wrote:
I am using lwip ontop of FreeRTOS to send data to a server. I am
trying to maximize the data flow. I've tuned several paramerters in
"lwipopts.h" but I am always receiving an ACK after emitting only two
packets.
That's just TCP. The window size does not have any
Ben Sedrine Mohamed khalil wrote:
my question is how do integrate LwIP HTTP On Aurix TC234 Board with
Erika OS.
If you have lwIP already running, it's just adding a call to
httpd_init() and adding the appropriate source files (just keep adding
missing files until it links).
If the question
Axel Lin wrote:
It's easy to get below debug message:
tcp_slowtmr: max SYN retries reached
I tried increase TCP_SYNMAXRTX but it seems does not help.
Hmm, we have changed something around there in 2.0.2, could you check
how 2.0.1 behaves?
Simon
Joel Cunningham wrote:
Given the list of limitations, should the current mDNS support only be
used for querying?
apps/mdns/mdns is a responder, I don't think it can be used for querying :-)
Host name querying is included in core/dns.c, but I don't think we have
support for service querying.
Mohamed Hnezli wrote:
when reloading a tab in chrome or adding new one the server crashs. Note
that the server runs well with firefox.
Any help please ?
Last time I tested those two browsers, chrome used more simultaneous
connections to my server than firefox. That explains the difference.
This is totally off-topic to this thread... :-)
Stephen Cowell wrote:
Sorry... I was under the impression that the subject line determined the
thread.
A thread is defined by the email's headers (readable by programs), not
the subject (human readable).
I'm using Thunderbird and I don't see
Noam Weissman wrote:
Any ideas ?
No, sorry. I'm sure I could find this when debugging myself, but I keep
getting lost in your descriptions and I haven't yet seen one thing that
springs to mind to say "this is it"...
Simon
___
lwip-users mailing
Noam,
that sounds a bit too complicatied...
My first thought is: you call select and it returns that there is data
to read, but that does not mean there is enough data to read for TLS, so
EWOULDBLOCK is not an error at all in this case.
Simon
___
Noam Weissman wrote:
I am not ignoring the fact that it may be the driver or definitions
but I am simply asking
for leads...
That's what I thought I gave in the last mail. OTOH, for getting the
errno set by recvfrom, you don't have to be an lwIP developer...
Simon
pekez wrote:
Well, yeah I didn't mean I fixed the fragmentation problem, I just
avoided it. :) Maybe I will try to set MTU to 1500 just to see what is
happening.
I meant to say 1500 *is* the MTU. MTU means what can be transferred on
the medium *without* the medium's headers (ethernet
massimiliano cialdi wrote:
is it possible to rinitialize lwip safely? how?
No. This has been asked before. We don't support this as it's not
required for the default use case of an embedded system.
Have you tried searching the list for how others did this?
Simon
Noam Weissman wrote:
Same problem with either 1.41 or 2.01 tested on both
Up to now, EWOULDBLOCK is based on netconn callback events. I'm in the
progress of changing this to be a result of a "tryget" operation on the
recvmbox. If there should be a bug in the event callback handling, this
Noam Weissman wrote:
lwip_recvfrom is called.
Inside this function there is a do <> while loop that is supposed to collect
the fragments into the 16K buffer
and after getting it all return to the SSL for decryption etc...
for some reason it always returns with EWOULDBLOCK error !
Which
pekez wrote:
I have not real clue what is going on.
Me neither.
You seem to have a debugger, why don't you try to find out? ;-)
(I.e. see where/why it hangs to try to give us more information or even
be able to fix it yourself)
Cheers,
Simon
___
I did have mbedTLS running against our httpd (no sockets) but the
resource usage was rather high.
I'd imagine the problem could be lwIP's memory configurations here, too.
Simon
Jan Menzel wrote:
Hi Noam!
I've designed a system with almost the same setup which works well
since a few
François Thierry wrote:
I checked all the parameters which seems relevant for me (see below)
but now I've got no idea why lwip could not allocate 1092 bytes on a pbuf.
[..]
- #define PBUF_POOL_SIZE 256
- #define PBUF_POOL_BUFSIZE 1700
- #define TCP_MSS 1460
- #define TCP_SND_BUF 8192
- #define
Oops, didn't see that before pushing the 'send' button :-)
Sylvain Rochet wrote:
The RX thread (if any) should have a higher priority than the TCPIP thread,
That's probably true. Having it the other way round doesn't actually
break it I guess, but you should have a strong cause to do so
Coming back to the 2nd mail of this thread:
Vass Szabolcs:
The problem is that my project is very large and complex so I wouldn't
like to exchange my lwip libraries.
So here's a problem in lwIP (or the handling of lwIP rather) and you
don't want to use a fixed version...
In my project I
Joan,
the return type is related to the type of struct lwip_sock's 'err' member.
reading the comment /** last error that occurred on this socket (in
fact, all our errnos fit into an u8_t) */
makes it clear this is just a size improvement which holds for our error
definitions but might not
bernard wrote:
Hi,
Because I need to implement the poll(struct pollfd *fds, nfds_t nfds,
int timeout) routine between bsd socket and device fd etc. I have to
set the callback to my event callback, then notify upper layer for
different kind of fd poll/select. For example:
conn->callback =
nrichard wrote:
As Patrick suggested, it was indeed the community length. I'm still not sure
why it cuts the length down to 1 since my community length define was the
default/unchanged. So instead I called the set_community() function in my
SNMP initialization and just set it to public there,
Freddie Chopin wrote:
I know that and in both cases the PCB stays active. But in case nr 1 it
quickly goes into TIME_WAIT state while in case nr 2 it says in
FIN_WAIT_1 forever...
Oh, I didn't see that in your last mails, sorry. That sounds odd, yes. I
haven't seen that before and I have no
Freddie Chopin wrote:
But what difference in reception does it make - in both cases
(with/without delay) the netconns are closed and deleted anyway.
What you might be mising is that the netconn can be deleted with the pcb
being still alive?
Simon
Freddie Chopin wrote:
Would any additions to the netconn API be accepted
Yes.
or maybe the plan
is really to add a function or two to sockets to allow netconn-like
interface (with no copying) and then netconn would be deprecated?
That's the longterm plan only...
[..] It works only if I
Sandra Gilge (ADATIS) wrote:
there is following line in cc.h:
extern u8_t memp_memory_PBUF_POOL_base[] __attribute__ ((aligned (32)));
I checked the address of memp_memory_PBUF_POOL_base it is 32byte aligned
That might not be enough. With this, you only have ensured the PBUF_POOL
memory
Freddie Chopin wrote:
[..]
Is there any other way than direct messing
with the tcp_pcb to set SOF_REUSEADDR in the so_options field? Maybe
I'm doing something wrong here (except force-closing the client
connections (; )?
In "specialities" like this one, the netconn API is (unfortunately)
401 - 500 of 1087 matches
Mail list logo
