Hello everyone,
(I'm working with lwip 1.4.0.)
I have a question regarding netif_add.
netif_add( ) has the following prototype.
struct netif *netif_add(struct netif *netif, ip_addr_t *ipaddr, ip_addr_t
*netmask,
ip_addr_t *gw, void *state, netif_init_fn init, netif_input_fn input)
My networ
Hello everyone,
The file src/include/lwip/arch.h defines several error codes,
some of which are used in DNS-related operations: the ENSR*
error codes such as ENSRNOTFOUND.
sys_arch.txt states:
[cc.h] must either include a system-local which defines
the standard *nix error codes, or it shoul
Kieran Mansley wrote:
> Mason wrote:
>
>> struct netif *netif_add(struct netif *netif, ip_addr_t *ipaddr, ip_addr_t
>> *netmask,
>> ip_addr_t *gw, void *state, netif_init_fn init, netif_input_fn input)
>>
>> My network interface is supposed to be
Hello,
I'm trying to port lwip 1.4.0 to STMicro's OS21/OS+ operating system.
I've coded the required sys_arch.c
I'm now working on the Ethernet interface code.
On my platform, reads (rx) and writes (tx) are asynchronous.
Here's how the driver works for reads:
I register a packet-handling func
Mason wrote:
> I'm trying to port lwip 1.4.0 to STMicro's OS21/OS+ operating system.
>
> I've coded the required sys_arch.c
>
> I'm now working on the Ethernet interface code.
>
> On my platform, reads (rx) and writes (tx) are asynchronous.
>
>
Hello,
I've been trying to port lwip 1.4.0 to OS21/OS+ for several
weeks. I am very stuck on the aspect of buffer management,
because what lwip expects seems incompatible with the way
things work on this platform.
Here's a short description:
At init, I specify how many RX buffers and TX buffers
e
by making as few modifications inside lwip as possible.
I'll have to balance performance vs portability, I guess.
Maybe copying every outgoing packet is not such a big deal
after all? ;-)
Regards,
Mason
> Mason wrote:
>> Hello,
>>
>> I've been trying to port lwip
Simon wrote:
> Mason wrote:
>
>> I've defined a new struct packet_info_t which stores a pbuf
>> (for lwip) and an OS descriptor.
>>
>> typedef struct { struct pbuf_custom pbuf; ethernet_async_t desc; }
>> packet_info_t;
>
> Where's the act
Hello,
I've ported lwip 1.4.0 to an ST7105 dev set-top box
(450 MHz SH-4 core, Fast Ethernet port).
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00209329.pdf
The STB is connected directly to my PC (no switch or router).
I've written code on the STB to rec
Simon Goldschmidt wrote:
> Mason wrote:
>
>> I send 58,400,000 bytes from the PC to the STB.
>> This takes 14.25 seconds, i.e. an average of 33 Mbit/s
>>
>> I was expecting to reach 80+ Mbit/s, so I captured the conversation
>> with Wireshark, and I notice
Bill Auerbach wrote:
> Mason wrote:
>
>> I was expecting to reach 80+ Mbit/s, so I captured the conversation
>> with Wireshark, and I noticed that the sender is being throttled
>> because the receiver (the STB running lwip) is not sending ACKs
>> fast enough.
>
Kieran Mansley wrote:
> On Tue, 2011-10-11 at 16:50 +0200, Mason wrote:
>>
>> So the hardware + driver is indeed able to handle the load.
>>
>> I must be doing something wrong in my driver when I pass
>> data to lwip.
>
> In this UDP test did you use lwI
Kieran Mansley wrote:
> Mason wrote:
>
>> In the UDP test, any frame larger than 1500 bytes was
>> not passed to lwip. The bogus ACK was sent directly
>> from the RX context instead.
>
> OK, I'm not at all surprised that there is a big difference between the
Bill Auerbach wrote:
> That 7.4% for memcpy is a direct hit on throughput. You're seeing a
> breakdown of total CPU time. How much of that 7+% for memcpy comes out of
> the total time used by lwIP? I think you'll find that to be a much larger
> hit and a large contributor to lower bandwidth.
B
Simon wrote:
> Mason wrote:
>
>> IMHO, the elephant in the room is task-switching, as correctly
>> pointed out by Kieran.
In my previous tests, I ran all three network-related threads
(RxTask, tcpip_thread, rxapp) at the same priority (MIN+4)
while other threads ran at th
Simon wrote:
> Mason wrote:
>
>> Perhaps I could keep the RxTask, and enable LWIP_TCPIP_CORE_LOCKING_INPUT
>> which would take tcpip_thread out of the equation? Thus, LOCK_TCPIP_CORE
>> would be called from task context, which is fine.
>
> I guess that would also
Simon wrote:
> Mason wrote:
>
>> I tried using the Netconn API because I thought it didn't
>> force a memcpy (is that correct?), but I can't get it to work.
>
> Yes, that's correct. From your example, I guess you're running out of
> netbufs: i
Simon Goldschmidt wrote:
> Amir Shalem wrote:
>
>> 3. missing ENSRNOTFOUND
>> lwip/src/api/netdb.c:203: error: ‘ENSRNOTFOUND’ undeclared
>
> I think I remember this being reported on one of the lists.
http://lists.gnu.org/archive/html/lwip-users/2011-08/msg00013.html
> I guess there's an inclu
Mason wrote:
> Simon Goldschmidt wrote:
>
>> Amir Shalem wrote:
>>
>>> 3. missing ENSRNOTFOUND
>>> lwip/src/api/netdb.c:203: error: 'ENSRNOTFOUND' undeclared
>>
>> I think I remember this being reported on one of the lists.
>
> ht
Simon wrote:
> After looking at the code, the cleaner solution is to define
> MEM_LIBC_MALLOC to 1 and then define mem_malloc (etc.) to your
> own functions (see mem.h in the upper half).
I've started looking at the TX side, and I don't understand
your suggestion.
My driver manages TX buffers (w
Kieran Mansley wrote:
> I haven't yet decided, or given enough thought to, what features
> other than IPv6 should be included in the 1.5.0 release.
Support for zero-copy DMA drivers (RX and TX) with netconn API :-)
On RX, I used
CORE_LOCKING=1
CORE_LOCKING_INPUT=1
PBUF_REF custom pbuf with custo
Simon wrote:
> After looking at the code, the cleaner solution is to define
> MEM_LIBC_MALLOC to 1 and then define mem_malloc (etc.) to your
> own functions (see mem.h in the upper half).
I've started looking at the TX side, and I don't understand
your suggestion.
My driver manages TX buffers (w
(Please don't top-post.)
Vincent Cui wrote:
> I just wonder to know that the release code for IPv6 could be ported
> to LWIP 1.3.2, anyone care this?
I may be wrong, but I think that 1.3 may be configured to support
EITHER v4 OR v6 (both at the same time is not supported).
I don't think anyone
Simon wrote:
> That's interesting. Since I know of at least one Ethernet/IP stack being
> ported to linux, do you know whether/how linux allows changing the VLAN
> header per socket?
SO_PRIORITY (and setsockopt) might be useful?
The following document might also be relevant.
https://trac.pjsip
Vincent,
Please do not top-post.
http://catb.org/jargon/html/T/top-post.html
Vincent wrote:
> When will you release new lwIP with stable IPv6 version?
Simon has already answered that question:
> I'm afraid you won't get IPv6 support from us before 1.5.0 unless you
> are willing to use a versi
Fernando C.V. wrote:
> I'm intending to port the libupnp library for its use on an ARM STM32
> processor. This library seems to rely on Berkeley sockets and under
> FreeRTOS as it asks for "netinet/in.h", "sys/socket.h", etc. header
> files, so I was thinking about creating replacements for these
N.Karakotas wrote:
> I'm using the makefsdata.pl perl script to create the html data. I
> was having a strange problem with .png files not showing up on the
> browser. After tracing the problem I noticed that the array data
> created by the perl script was missing 1 byte of data at the beginning
Hello Simon,
If I remember correctly, you plan on releasing a bug-fix
version of the 1.4 code-base in the next few weeks.
Is this still true? Do you have an approximate idea when
a 1.4.1 version would be available?
--
Regards.
___
lwip-users mailing
Hello,
According to sys_arch.txt
sys_prot_t sys_arch_protect(void)
This optional function does a "fast" critical region protection and returns
the previous protection level. This function is only called during very short
critical regions. An embedded system which supports ISR-based drive
Simon wrote:
> Mason wrote:
>
>> I'm using OS21 (STMicro) and I've decided to use a mutex.
>>
>> Is it correct that, in my case, I can ignore the sys_prot_t arguments?
>
> Yes, mapping sys_arch_protect/unprotect to mutex_lock/unlock is correct.
And wh
Simon Goldschmidt wrote:
> Mason wrote:
>
>> If I remember correctly, you plan on releasing a bug-fix
>> version of the 1.4 code-base in the next few weeks.
>>
>> Is this still true? Do you have an approximate idea when
>> a 1.4.1 version would be availabl
Simon Goldschmidt wrote:
> Mason wrote:
>
>> I also see that bug #25882 is targeted for 1.4.1, but the status is "Need
>> Info".
>> http://savannah.nongnu.org/bugs/index.php?25882
>
> That one is "in progress" but I guess we haven't re
Simon Goldschmidt wrote:
> Still, I think lwIP should be able to achieve the performance you want if:
> A) your netif driver correctly supports zero copy
A few months ago(*) we discussed zero-copy for DMA drivers,
and you wrote:
> For the RX side, using a *custom* PBUF_REF would be the best solu
Zayaz Volk wrote:
> Did somebody use a UDP on any hardware using NETCONN API (zero copy,
> multithreaded environment) ? What was your maximum throughput ? What
> is the characteristic of your system ?
I can max out a Fast Ethernet link on a 450-MHz SH-4 system with
lots of CPU cycles to spare.
-
Hello,
The documentation for sys_mbox_new states
> Creates an empty mailbox for maximum "size" elements. Elements stored
> in mailboxes are pointers. You have to define macros "_MBOX_SIZE"
> in your lwipopts.h, or ignore this parameter in your implementation
> and use a default size.
The relevan
Mason wrote:
> The documentation for sys_mbox_new states
>
>> Creates an empty mailbox for maximum "size" elements. Elements stored
>> in mailboxes are pointers. You have to define macros "_MBOX_SIZE"
>> in your lwipopts.h, or ignore this parameter
Mason wrote:
> Simon Goldschmidt wrote:
>
>> Still, I think lwIP should be able to achieve the performance you want if:
>> A) your netif driver correctly supports zero copy
>
> A few months ago(*) we discussed zero-copy for DMA drivers,
> and you wrote:
>
>&
(Weird, my client could not thread your message correctly,
because it didn't have a "References" header.)
Simon Goldschmidt wrote:
> Mason wrote:
>
>> The relevant macros are
>>
>> TCPIP_MBOX_SIZE
>
> The number of application tasks communicating
Simon Goldschmidt wrote:
> Sorry for not answering that post, I meant to, but somehow it slipped
> through...
I was afraid to bother you by asking too many questions ;-)
> Mason wrote:
>
>> I don't think it's possible to use mem_malloc as a packet
>> bu
Mason wrote:
> (Weird, my client could not thread your message correctly,
> because it didn't have a "References" header.)
>
> Simon Goldschmidt wrote:
>
>> Mason wrote:
>>
>>> The relevant macros are
>>>
>>> TCPIP_M
Hello,
Below is the makefile I use for building lwip as a static library.
I like it because it's short and easy to understand. (I used a few
gmake-specific extensions.)
CC = sh4gcc
AR = sh4ar
PORT_DIR = os21_port
CFLAGS += -Wall
CFLAGS += -mruntime=os21
CFLAGS += -I src/include -I src/include/i
Hello,
Can you explain why the pbuf struct and the payload buffer
need to be contiguous? What problems are solved by having
the struct and the buffer stored contiguously?
There is a pointer to a buffer in the struct, it is redundant
if the payload is at a known offset, right?
Simon once wrote to
Zayaz Volk wrote:
> On other hand, if UDP checksum is omitted and under certain
> conditions (long UDP datagram timeout, high communcation speed and as
> a result IP overlapping while still within a UDP datagram timeout) -
> one might expect to get a wrong, but "valid" datagram with IP
> fragment
Hello,
I've never used git. I haven't yet figured out how to check out
branches, such as the DEVEL-1_4_1 branch. What is the command?
--
Regards.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Mason wrote:
> I've never used git. I haven't yet figured out how to check out
> branches, such as the DEVEL-1_4_1 branch. What is the command?
The following seems to do the trick.
$ git clone -b DEVEL-1_4_1 git://git.sv.gnu.org/lwip.
Hello,
I ported lwip 1.4.0 to my platform, and the port builds
with no errors.
When I tried the 1.4.1 branch, the port fails to build:
src/core/init.c:269:4:
error: #error "lwip_sanity_check: WARNING: TCP_WND is larger than space
provided by PBUF_POOL_SIZE * (PBUF_POOL_BUFSIZE - protocol headers
Simon wrote:
> Mason wrote:
>
>> I ported lwip 1.4.0 to my platform, and the port builds
>> with no errors.
>>
>> When I tried the 1.4.1 branch, the port fails to build:
>>
>> src/core/init.c:269:4:
>> error: #error "lwip_sanity_check:
Chris Ponder wrote: [snip]
Chris,
Could you please make you e-mail client thread correctly?
--
Regards.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Chris Ponder wrote:
> What is it that you want the email client to do that it is not doing,
> or what is it doing that it shouldn't?
Your latest message (this one I am replying to) threads correctly,
as it provides a valid "References:" header field.
Your previous messages, on the other hand, di
Chris Ponder wrote:
> So is this one correct or not?
Nope, no References header.
It seems Microsoft could not care less about standards...
(I wish people didn't use their tools. Sigh.)
> -Original Message-----
> From: Mason
> Sent: 28 February 2012 12:54
> To: M
Hello,
Is it possible to configure lwip in such a way that the static
library I build exports the /real/ BSD socket API function names?
I.e. export foo instead of lwip_foo (for socket, connect, bind, etc)
I'm trying to port libcurl on top of lwip, and it expects an actual
BSD socket implementatio
Simon Goldschmidt wrote:
> Mason wrote:
>
>> Is it possible to configure lwip in such a way that the static
>> library I build exports the /real/ BSD socket API function names?
>> I.e. export foo instead of lwip_foo (for socket, connect, bind, etc)
>
> I don&#
Krzysztof Wesołowski wrote:
> I have encountered some HardFaults in rcurrent 1.4.0 version, file
> etharp.c code, line 416.
>
> code (stripped from asserts):
> static err_t
> etharp_send_ip(struct netif *netif, struct pbuf *p, struct eth_addr
> *src, struct eth_addr *dst)
> {
> struct eth_hdr *
Simon Goldschmidt wrote:
> Mason wrote:
>
>> However, this was a red herring, and I'm still stuck building
>> libcurl. I think the main problem is that the lwip header
>> naming might not be 100% POSIX compliant, and libcurl can't
>> find a lot of network r
Hello,
I'm trying to port libcurl on top of lwip.
http://en.wikipedia.org/wiki/CURL
http://en.wikipedia.org/wiki/LwIP
My main difficulty is the close function, because it is
defined both in libc.a, to deal with regular files, and
in lwip.a, to deal with sockets.
I suppose the simple solution wo
Kieran Mansley wrote:
> If you could arrange for lwIP to use a different range of socket IDs
> from the file descriptors used by libc then you could easily make a
> wrapper function that would call the appropriate function (libc close or
> lwip_close) based on the fd provided. This would then all
Gisle Vanem wrote:
> Mason wrote:
>
>> My main difficulty is the close function, because it is
>> defined both in libc.a, to deal with regular files, and
>> in lip.a, to deal with sockets.
>>
>> I suppose the simple solution would be to convince libcurl
&
Hello,
I'm using lwip 1.4.1
Below is the code I use to initialize the network stack.
static void do_lwip_init(void *arg)
{
struct netif *netif = malloc(sizeof *netif);
memset(netif, 0, sizeof *netif);
#if USE_DHCP
netif_add(netif, NULL, NULL, NULL, NULL, ethernetif_init, tcpip_input);
dh
Simon Goldschmidt wrote:
> Mason wrote:
>
>> 1) The correct function to use is netif_set_default, right?
>>
>> 2) If I use static addressing, I have to declare the
>> default route myself, using netif_set_default?
>>
>> 3) When using DHCP, does the DHCP
Hello,
I am porting libcurl on top of lwip on a POSIX platform.
(libcurl uses the BSD sockets API, and non-blocking sockets.)
Calling connect on a non-blocking socket is supposed to
return EINPROGRESS in errno, but in my port, errno is
not set.
Looking at sockets.c, the relevant code is:
#ifdef
Simon wrote:
> Personally, I think it's correct that we do not change 'errno' without
> explicitly enabling it: we don't want to mess with C library code that
> uses 'errno' by default.
I cannot stress how strongly I disagree on this point.
I will take the discussion to lwip-dev by filing a bu
Simon Goldschmidt wrote:
> Mason wrote:
>
>> Note that Google sends only 590-byte frames. How do I get lwip
>> to advertize larger MSS?
>>
>> NB: I have the following TCP-related definitions in my lwipopts.h
>>
>> #define TCP_MSS 1460
>> #defin
Simon Goldschmidt wrote:
> Mason wrote:
>
>> Note that Google sends only 590-byte frames. How do I get lwip
>> to advertize larger MSS?
>>
>> NB: I have the following TCP-related definitions in my lwipopts.h
>>
>> #define TCP_MSS 1460
>> #defin
Mason wrote:
> I don't understand the comment explaining why the MSS is clipped.
> Does this come from an RFC?
For my own records, relevant RFC is
http://tools.ietf.org/html/rfc879
___
lwip-users mailing list
lwip-users@nongn
Simon Goldschmidt wrote:
> "Define LWIP_COMPAT_MUTEX if the port has no mutexes and binary
> semaphores should be used instead". The only disadvantage of using
> binary semaphores (in this case, the sys_mutex_* functions are
> defined to their sys_sem_* substitute) is that you can get priority
> i
Bill Auerbach wrote:
> However, depending on the processor, at Gbps speeds, the packet interrupt
> overhead becomes significant over polling. This might be why some
> processors (e.g. the PowerPC PowerQUICC) have the option to interrupt after
> N number of packets or M microseconds since last pac
Hello,
On my platform, the hardware notifies the driver of link status
changes by calling a user-defined call-back function.
In this call-back, I pass the notification up to lwip.
Here's my rough code:
static int mac_link_callback(ethernet_device_t *dev, unsigned status)
{
if ((status & LINK_S
Marty wrote:
> Mason,
>
> In my phy interrupt, I use:
> err_t tmp = tcpip_callback_with_block( s_HandlePhyInterrupt, NULL, 0);
>
> That puts a callback to s_HandlePhyInterrupt into the tcpip thread.
> Then in s_HandlePhyInterrupt is all the phy status processi
Simon Goldschmidt wrote:
> Mason wrote:
>
>> If LWIP_TCPIP_CORE_LOCKING is 0, tcpip_netifapi looks
>> fairly similar to tcpip_callback_with_block.
>>
>> Does netifapi make sense when LWIP_TCPIP_CORE_LOCKING is 1,
>> in which case there is no message passing,
Hello,
Suppose a user can't use DHCP, and configures his network stack
manually. If he picks an address that is already in use, we might
want to report the problem back to him as soon as possible.
In netif_set_up, we send a "gratuitous ARP" packet. Windows sees
this packet, pops a message to warn
Bill Auerbach wrote:
> Mason wrote:
>
>> Maybe we could detect the problem there, and set the interface down?
>> Then the netif_status callback would be called, and the user could
>> decide to use a different address?
>>
>> What is the best strategy her
Mason wrote:
> Simon Goldschmidt wrote:
>
>> Mason wrote:
>>
>>> If LWIP_TCPIP_CORE_LOCKING is 0, tcpip_netifapi looks
>>> fairly similar to tcpip_callback_with_block.
>>>
>>> Does netifapi make sense when LWIP_TCPIP_CORE_LOCKING is 1,
>&g
Marty wrote:
> I want to add support to Simon's point: If the netif goes down, then
> someone has to know where to look to figure out why. It kinda moves the
> problem to another layer.
>
> I appreciate trying to protect users from themselves, but using a
> correct process for manual IP assignm
Simon wrote:
> Yep, AutoIP is something different from the usage scenario. However,
> from the technical point of view, it's very close to what you want. I
> wouldn't automatically switch off the local netif though: I think it
> should be up to the application to decide whether to set the netif
Simon Goldschmidt wrote:
> That's what I said: "where they are passed to DHCP", not "in dhcp.c"
> (i.e. add a call to your own function in etharp_arp_input() just
> after/before the call to dhcp_arp_reply() - in this function, check
> if the ARP response handles your IP address and react
> appropr
Sylvain Rochet wrote:
> Yep, GPL is viral and changes whole project license.
Can we do without the Microsoft propaganda?
--
Regards.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
76 matches
Mail list logo
