On Sun, Dec 12, 2010 at 6:30 PM, shogun wrote:
> I have one more question about what is safe to run in different execution
> context for lwip (interrupt/thread). I did add an OS to my application and
> now moved some things around so data is only sent and received in the tcp/ip
> thread context.
question before. For the TCP/IP standard, the FIN is a
> good solution. But the RST is a shotcut solution in certain environment.
>
>
>
>
>
> On Wed, Dec 8, 2010 at 10:53 PM, Jeff Barber wrote:
>>
>> On Tue, Dec 7, 2010 at 10:23 PM, runjin wrote:
>> > I fou
On Tue, Dec 7, 2010 at 10:23 PM, runjin wrote:
> I found that closesocket sends a FIN packet,
> How to send RST ?
AFAIK, there is no way to send RST using the socket or netconn APIs.
But then this is not something that is normally available to
applications in other OSes like Linux or Windows eith
Why don't you just imitate what the boot loader would do? Find the
symbol that indicates the beginning of BSS and the symbol that
indicates the end, find the difference and clear. Then only do that
when your wakeup has decided there's something to do. Linker-dependent
but usually these symbols ar
n I
> find the time):
> - lwIP 1.4.0 provides ready-to-use functions for timers, so there's no need
> to implement that yourself
> - you used the type mch_ip_add, which is not defined anywhere - later, this
> type is implicitly casted struct ip_addr
>
> Other than tha
Done. New page on the wiki at http://lwip.wikia.com/wiki/Porting_For_Bare_Metal
On Thu, Nov 4, 2010 at 3:50 PM, Kieran Mansley wrote:
>
> On 4 Nov 2010, at 17:55, Jeff Barber wrote:
>
>> I went through this learning curve last year and did essentially the
>> same thing
I went through this learning curve last year and did essentially the
same thing (for a very different board environment). The basic steps
are:
1. Create a cc.h for your port. This is straight-forward and involves
choosing types for u8, u16, u32, etc. as well as setting endianness
2. Create a sy
On Thu, Oct 14, 2010 at 7:56 AM, Jeff Barber wrote:
> - You're giving a Content-length header but the length is incorrect:
> your length says 19, but the actual length appears to be 27 (could it
> be you're using %x instead of %d?).
Hmm... Strike that one: hexadecimal 1
It appears that the browser is waiting about 1.35 seconds before
closing the connection after each request. I don't see any indication
that the lwIP side is doing anything wrong with respect to the TCP
session. Just a guess but any of several things might be confusing the
browser:
- You're giving
>From what I know of HTTP and lwIP, I think you will have to build this
in to your "web application". Like any other web application, you
probably need to establish some notion of a session. Since the same
HTTP TCP connection does not ordinarily persist throughout the life of
the session, that's
The Ethernet FCS is only 4 bytes, so dropping an additional 4 bytes
(beyond the FCS) may well cause problems.
Jeff
On Fri, Oct 8, 2010 at 12:38 AM, Simon Goldschmidt wrote:
>
> Joe Dupre wrote:
>
>> My MAC does not drop the 8 byte FCS, leaving it in the DMA buffer for my
>> EMAC driver to deal
On Mon, Sep 20, 2010 at 10:07 AM, farid mahini wrote:
> I am trying to enable KeepAlive/Idle feature, but I do not see a hit on
> tcp_tmr, tcp_slowtmr, tcp_fasttmr on an established connection! I am using
> lwIP 1.3 with FreeRTOS. I do not see the KeepAlive variables being accessed
> anywhere els
On Thu, Sep 2, 2010 at 2:43 PM, Timmy Brolin wrote:
> Jeff Barber wrote:
>>> For Tx it is pretty straightforward, I'll just write a
>>> low_level_output() function which will be called from the lwip thread.
>>> But how do I clean up the buffer descriptors when t
On Mon, Aug 30, 2010 at 3:52 PM, Timmy Brolin wrote:
> I am wondering if anyone could give me a pointer or two on the most
> appropriate way to implement a Ethernet driver.
> First of all, the MAC we are going to use it pretty standard. It uses
> DMA transfers and linked buffer descriptors just l
I'd like to see someone more authoritative (like Simon or Kieran?)
weigh in on this but I'm pretty sure that the advice you cited is just
plain wrong.
It's true that data may be delivered to your receive callback in a
chain of pbufs (something your code is not currently handling); I
believe this c
On Wed, Aug 11, 2010 at 10:02 AM, shogun wrote:
[snip]
> From reading the documentation, rawapi.txt “The tcp_listen() function
> returns a new connection identifier, and the one passed as an argument to
> the function will be deallocated. The reason for this behavior is that less
> memory is need
On Thu, Aug 5, 2010 at 9:22 AM, Friedrich Schick
wrote:
> I am writing a driver for lwip 1.4RC1. The fec (freescale fec) is able to
> use dma in tx and rx direction. The tx side is easy to implement but now it
> comes to the rx side. How do I implement dma on the rx side? My target
> platform is u
On Wed, May 26, 2010 at 2:36 PM, Kieran Mansley wrote:
> On 26 May 2010, at 14:58, Jeff Barber wrote:
>
>> Not an lwip problem per se (at least I don't think so), but I'm hoping
>> some TCP expert here can suggest a reason why this is happening:
>
> The usual r
Not an lwip problem per se (at least I don't think so), but I'm hoping
some TCP expert here can suggest a reason why this is happening:
I have a linux process (169.254.254.1) connecting to an lwIP v1.3.2
native api server (169.254.254.11 port 10). The client closes the
socket before exiting which
On Fri, Apr 30, 2010 at 12:09 PM, Kieran Mansley wrote:
> On Fri, 2010-04-30 at 11:54 -0400, Jeff Barber wrote:
>> Looking at the 29361 bugtracker entry, it appears that zero-copy
>> transmit is only an issue if there is IP fragmentation. Is that
>> correct? If so, then is
Hmm... I seem to have not been paying attention when this discussion
went by. Now wondering what (if anything) I need to do. I am using
zero-copy on both transmit and receive, and relying on the ability to
increase the pbuf reference count to keep the pbuf from being freed
while it's being transm
I'm guessing that the "packed" attributes on tcp_hdr are making the
compiler believe that (seg->tcphdr + 1) *might* fall on a non-u32_t
boundary (which is quite likely a realistic possibility). Not sure
why you're seeing this and no one else with gcc is. Maybe it has to
do with the particular ver
On Fri, Mar 5, 2010 at 11:44 AM, Kieran Mansley wrote:
> I think his point is that we're assuming that %x exists on his platform
> by hardcoding %02x in the code, whereas on his platform he needs to use
> something other than %x to get a hex output.
I suppose I could buy that. It would seem tha
I can see a need for the Xnn_F stuff in a few cases (for example, with
scanf so that it knows the integer size to store, or when printing
something that might be longer than some machines' standard integer
length such as u32_t on a 16-bit machine). However IMO it's really
ugly and shouldn't be used
In order to create a connection to your lwip device, the client must
be able to translate the host-name to an IP address. Traditionally,
this has meant teaching the local DNS server that the name "lwip"
translates to IP address X.X.X.X. The DHCP host-name option provided
by the lwip device can fa
This sounds a lot like a Spanning Tree Protocol (STP) effect.
However, that doesn't exactly match your description of the topology
so I'm not sure.
I have an lwIP device on a remote network segment and each time it's
rebooted (and hence, loses and regains link), it's inaccessible for a
fixed perio
On Mon, Mar 1, 2010 at 4:45 AM, Kieran Mansley wrote:
> On Sun, 2010-02-28 at 13:16 +0100, Martin Velek wrote:
>> I am running a lwip 1.3.2 with FreeRTOS. I am using own
>> malloc/free/calloc/realloc memory management. What should I setup in
>> the lwipopts.h if I would like use only malloc/free.
In this particular case, the function definition in the header file:
static void *mem_realloc(void *mem, mem_size_t size)
{
LWIP_UNUSED_ARG(size);
return mem;
}
could simply be replaced with the near-equivalent (which already
appears a few lines further on under a different combinati
There is a version of mem_realloc in mem.h that is marked 'static' but
not 'static inline'. This version is activated only with certain
lwipopts settings. Any source file that includes mem.h gets a new
version of the code compiled within it. If the source file doesn't
reference mem_realloc, that
On Fri, Nov 13, 2009 at 9:54 AM, goldsi...@gmx.de wrote:
> JM wrote:
>> Also, I looked in the rawapi.txt file and found this, which further
>> confuses me:
>>
>> The tcp_connect() function returns immediately; it does not wait for
>> the connection to be properly setup. Instead, it will call the
(Assuming I'm following the code correctly...)
You will get the connected callback only if successful. If the connection
fails, you will get the error callback instead with one of two error codes:
If the connection is rejected with a RST (I think that would mean that the
system is there but no ser
This isn't a case of *IP fragmentation* so there won't be any IP
reassembly. It's just that the TCP data is being sent in two
messages. This is perfectly valid TCP behavior.
Strictly speaking, there's nothing in TCP that prevents the client
from sending you the entire request in 1-byte pieces if
Please ignore this message. It's the one I originally posted
Thursday. It seems to have been stuck somewhere in gnu.org's mail
system for a couple of days.
On Thu, Oct 22, 2009 at 8:19 AM, Jeff Barber wrote:
> I have an lwip-based FTP server built on a nearly stock 1.3.1 lwIP.
rocks! One reason lwIP is slow in processing received packets
here is because I never bothered to figure out how to enable the NIC's
hardware checksum verification. Performance is not really very
important for my application. Robustness is far more important.]
On Thu, Oct 22, 2009 at 1
(Apologies if you see this twice; I didn't see it show up in the list
archives so am trying again without the attachment)
I have an lwip-based FTP server built on a nearly stock 1.3.1 lwIP.
When I do a GET on a large file (resulting in a high-speed
unidirectional transfer), I'm seeing about every
On Mon, Aug 10, 2009 at 1:41 PM, Chris Strahm wrote:
>>> Maybe recursion?
>>> Where is close_conn being called from here?
>
> It comes from my send_data() routine.
> Once all of the data to send has been written to tcp_write(),
> then close_conn gets called, and send_data() returns.
Don't know exa
On Mon, Aug 10, 2009 at 12:58 PM, Chris Strahm wrote:
>> Having set these to null, http_sent() with arg==NULL should also not
>> appear. Could it be that
>> you changed close_conn() to not reset these callbacks??
>
> Well here's what comes out. close_conn is called,
> then 2 more http_sent() ca
That's not true for the BSD socket API. Connect(2) has always worked
with UDP sockets as well. See, for example
"http://www.manpages.info/freebsd/connect.2.html"; which includes this
text:
If [the socket descriptor] is of type SOCK_DGRAM, this call
specifies the peer with which the sock
On Wed, Jul 1, 2009 at 9:17 AM, Lou Cypher wrote:
>> I'm not sure why the timer handling functions would be raising
>> interrupts.
>
> Well, interrupt won't come from tcp_fasttmr(), but from the caller.
> It's quite usual having hardware timers, with an automatic reload, that
> interrupt processing
On Wed, May 27, 2009 at 9:47 AM, John Kennedy
wrote:
> I’m using Lwip with sockets on MicroBlaze. I have an MTU of 1500. I want
> to maximize the Ethernet TX/RX data rates (bits/sec) in my embedded system.
> Memory is not an issue (512Mbytes avail).
>
> How does one determine the values for:
>
>
here is no comment or anything else I can find that indicates that it
>>even needs to be set. Hence my original question.
>>
>>-Original Message-
>>From: Jeff Barber [mailto:jeffba...@gmail.com]
>>Sent: Monday, May 18, 2009 2:24 PM
>>To: Mailing list for lwI
(I'm still a newbie with lwIP and am still working on a driver so I
have no direct experience yet but...)
There are two different state bits that are orthogonal: NETIF_FLAG_UP
and NETIF_FLAG_LINK_UP. It appears to me that these are intended to
reflect, respectively, whether the device driver is "
On Mon, May 11, 2009 at 2:06 AM, Simon Goldschmidt wrote:
>
>> Im able to run the simhost application on my Ubuntu 8.04 system. while
>> trying to debug the code, im not able to location the code that sets the
>> MAC address for the tap0 device.
>> Can anyone help me as in which file to look for t
s 0 for the tap0 device. But it keeps on increasing for the
> loopback address. Is this a normal response or is it indicating another
> problem(Im not that strong with networking concept)
>
> Regards,
> Deepak Gopalakrishnan
>
>
>
>
> Jeff Barber
&g
The MAC address you're seeing is being created by the kernel tap
interface each time you bring simhost up. If this is your machine
before you run simhost (use a fixed width font for best results):
--
| Linux host |
| |
| eth0 [|- (Your exist
I'm planning to port lwIP into a new system. I want to use the raw
API with no OS. I will need to write a new ethernet NIC driver and I
just want to make sure I completely understand the driver model (I
find the documentation available on this subject rather confusing). I
would appreciate it if
46 matches
Mail list logo
