Send lwip-users mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nongnu.org/mailman/listinfo/lwip-users
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of lwip-users digest..."
Today's Topics:
1. Re: porting lwip to a mips system (Robert Goeffringmann)
2. Re: problem with netconn_accept (Clive Wilson)
3. Re: Contents of lwip-users Digest, Vol 42, Issue 7 (geckook Xu)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Feb 2007 18:34:36 +0100
From: "Robert Goeffringmann" <address@hidden>
Subject: Re: [lwip-users] porting lwip to a mips system
To: "Mailing list for lwIP users" <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
Sorry if I'm being stupid, but isn't the link header size always
2 x 6 bytes mac + 2 bytes ethertype?
In any case, changing it to 16 doesn't have any influence on this at all.
The code in pbuf.c behaves exactly the same as with PBUF_LINK_HLEN=14, due
to that alignment code and the size of the ethernet header is hardcoded in
etharp.c.
Regards,
Robert.
----- Original Message -----
From: "Taranowski, Thomas (SWCOE)" <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Wednesday, February 07, 2007 12:14 AM
Subject: RE: [lwip-users] porting lwip to a mips system
Out of curiosity, why did you define the PBUF_LINK_HLEN to be 14? If
you are using 802.3, it should typically be 16.
-----Original Message-----
From: address@hidden
[mailto:address@hidden
On Behalf Of Robert Goeffringmann
Sent: Tuesday, February 06, 2007 12:45 PM
To: address@hidden
Subject: [lwip-users] porting lwip to a mips system
Hello!
I am currently trying to get lwip to work on a PlayStation 2.
In this process, I've been facing some rather strange effects and I am
wondering if things are actually meant to work this way...
The first issue I ran into was the sys_arch_protect function.
My system works with multiple threads and implements the semaphore
functions
as well.
First I tried to implement sys_arch_protect by disabling interrupts.
This doesn't work because certain functions (e.g. pbuf_free in pbuf.c)
will
use sys_arch_protect (thereby disabling interrupts) and will then (while
interrupts are still disabled) call functions which use semaphores for
inter-thread protection (in this case, pbuf_free may call mem_free).
And well... obviously you can't wait for a semaphore if you've disabled
interrupts in order to prevent thread switching.
The way I understand it, pbuf_free could even be changed so that it
doesn't
need to disable interrupts if the pbuf it's being called on is a memory
buffer.
Or did I overlook a good reason why it works like this?
At some point I had the feeling that this situation occurs with other
functions as well, but so far I couldn't find any.
Anyways, if this can't be changed, I suppose it would be better to
mention
this behaviour in the sys_arch.txt. :)
Now as I implemented sys_arch_protect using a recursive mutex, it works.
The problem I am facing right now is the alignment of packets.
I've set MEM_ALIGNMENT to 4 in my lwipopts.h.
Now, if my netif driver receives a packet, it invokes pbuf_alloc,
receives a correctly aligned buffer, fills it with data and passes it to
lwip.
Works smoothly.
However, if an application sends tcp data (using the socket api, I
didn't
try anything else), all the packets that lwip sends to my netif driver
for
outputting are misaligned by 2 bytes. And looking at pbuf.c, this
actually
seems to be the intention...
I defined PBUF_LINK_HLEN as 14 bytes.
Now, when tcp_enqueue calls pbuf_alloc, pbuf_alloc first computes the
size
it needs for headers. In this case, that's:
20 (PBUF_TRANSPORT_HLEN) + 20 (PBUF_IP_HLEN) + 14 (PBUF_LINK_HLEN) = 54
bytes.
This is then rounded up to 56 bytes in order to match my MEM_ALIGNMENT
of 4
and pbuf->payload is set to that offset, so payload is correctly
aligned.
However, later these header sizes get substracted again and so the
pbuf's
payload
points to an address which is 2 bytes off from the necessary alignment
when
it's passed to netif->linkoutput.
This is especially annoying as I have to pass the data as doublewords of
4
bytes to the hardware's I/O port.
So basically, I have to read it from memory in units of 2 bytes, put it
together to make dwords and pass it to the HW port.
Even worse, though, if the pbuf is splitted, the splits occur in the
middle
of a dword, which makes it even more difficult.
Is this really the intention?
Thanks in advance :)
Robert.
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
------------------------------
Message: 2
Date: Thu, 08 Feb 2007 18:20:43 +0000
From: Clive Wilson <address@hidden>
Subject: Re: [lwip-users] problem with netconn_accept
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 12:42 08/02/2007, you wrote:
>On Thu, Feb 08, 2007 at 06:19:56AM -0500, shobhit saxena wrote:
> > hello everyone,
> > i am using arm e7t board with ecos cofig tool & my
> > target is to establish LWIP-TCP/IP over PPP & have communication
> > between a server and ARM kit(client).I am using the lwip_init()
> > function to establish PPP connection.I am using the following code for
> > establishing TCP/IP .
> > my problem is that the program is running fine till the line
> > "newconn=netconn_accept(conn);"
> > but its not accepting connection.Is there something wrong with my code?
>
>I haven't looked in detail but it sounds like the packets aren't
>getting through to lwIP. I'm afraid I don't know enough about the
>board you're using to suggest how to debug it though.
Might be an obvious question, but have you started up the network interface
over which you wish to pass data? You mentioned PPP, is it dial up or PPPoE
for example? You might be thinking that LwIP does this for you - it
doesn't. You need to establish the low level link you wish to use (e.g. if
dial up PPP, then start the modem connection) before trying to send any data.
Hope this helps,
CTW
------------------------------
Message: 3
Date: Fri, 9 Feb 2007 09:09:14 +0800
From: "geckook Xu" <address@hidden>
Subject: [lwip-users] Re: Contents of lwip-users Digest, Vol 42, Issue
7
To: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
I use api of socket.c .
When I create the 4th connect, the other connects will receive a lot
of I/O inturrupts(all the sockets are receiving data.), but can not
receive any data,so in my program,I will decide these connects are
idle and should be shutdown.
On 2/8/07, address@hidden <address@hidden> wrote:
> Send lwip-users mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lwip-users digest..."
>
>
> Today's Topics:
>
> 1. Re: curious large packets and transmit stuck (Andre Puschmann)
> 2. problem with netconn_accept (shobhit saxena)
> 3. I can only create 3 tcp/ip connects ? why? (geckook Xu)
> 4. Re: problem with netconn_accept (Kieran Mansley)
> 5. Re: I can only create 3 tcp/ip connects ? why? (Kieran Mansley)
> 6. client-server arch. using lwip (TEJ)
> 7. Just to inform : Internet Explorer 7.0 and LwIP Savannah web
> site problem (Fr?d?ric BERNON)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 07 Feb 2007 20:45:31 +0100
> From: Andre Puschmann <address@hidden>
> Subject: [lwip-users] Re: curious large packets and transmit stuck
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> hey thomas,
> we are using a freescale mpc5200 and its integrated fec.
> the os is a osek/vdx compliant one.
> the driver uses the bestcomm dma engine that is integrated in the mpc5200.
> i don't think that there is a problem at the basic functionality of the
> driver but indeed there is a point which i can't understand.
> if i count the times the fec_send()-method was called and the number of
> fec-tx-interrupts they differ from time to time, i mean i got less
> tx-interrupts, what properly shouldn't be the case.
> if i really loose some tx-interrupts maybe i loose rx-interrupts as well?!
> but how could that be?
>
>
> Regards,
>
> Andre
>
>
>
> Taranowski, Thomas (SWCOE) wrote:
> > I didn't see any details on what driver/hardware/os you're using, so I'm
> > making an educated guess...
> >
> > The problem you describe could potentially be a problem within the
> > driver. I could see a scenario where the driver fails to send/transmit
> > any data because, say, there are no transmit buffers available. In this
> > case the driver would fail to send, but be unable to notify that data
> > was sent, depending on the implementation of the low level driver/stack
> > interface. In this case, the stack could be caught in some undefined
> > state. The receipt of the ping triggers a transmit, and an interrupt,
> > and perhaps some other events, depending on the implementation, that
> > could cause operation to resume, but you'd probably see that some
> > packets were lost.
> >
> > I'd make sure that the driver send call never returns an error
> > condition. As a simple test, try increasing the size of the transmit
> > queue, or whatever you use, for the driver.
> >
> > You could also increase the size of the PBUF_POOL_BUFSIZE option, so
> > that the depth of the buffer chain sent to the driver is shorter. This
> > could result in fewer transmit buffers being used, depending on your
> > implementation of course.
> >
> > -Thomas
> >
> > -----Original Message-----
> > From: address@hidden|k %6l� u�(c)j
> > [mailto:address@hidden|k %6l� u�(c)j]
> > On Behalf Of Andre Puschmann
> > Sent: Sunday, February 04, 2007 12:06 PM
> > To: address@hidden
> > Subject: [lwip-users] Re: curious large packets and transmit stuck
> >
> > hey guys,
> > another thing that maybe brings a bit more light is the following. once
> > the stack is as slow i can burst the things up for another ~300 packets
> > with a single ping.
> > after that burst transmission is slow again. but i can do this "trick"
> > again and again.
> > i already checked the timer function but they are called frequently.
> > what can a single ping packet activate in the stack (or its helper
> > functions)??
> > any hints??
> >
> >
> > best regards,
> >
> > andre
> >
> >
> > Andre Puschmann wrote:
> >> hi kieran,
> >> here are my lwip opts.h and one trace using the netconn-api and
> > another
> >> one using the raw api ..
> >> if you have a look at the first trace (netconn) you can see that the
> >> packets slowly dropping out/in .. it seems that lwip "forgets" acks
> > the
> >> other end send. you can't see the large packets directly, i mean there
> >> is one large and another small one, but before the stuck all packets
> >> were 1000bytes long. so it seems that it has something to do with
> > that.
> >> if i use the raw api there are no "large" packets .. since as long as
> >> lwip has something to send it sends packet with max size (1456byte).
> > but
> >> nevertheless, after a while the whole system shows the same behavior.
> >>
> >> do you think it has something to do with my timer/semaphore/mbox
> >> implementation?
> >>
> >>
> >> many thanks
> >>
> >> andre
> >>
> >>
> >>
> >> 1: http://www.puschmann.net/public/dropping_packets_rawapi.cap
> >> 2: http://www.puschmann.net/public/large_and_small_packet.cap
> >> 3: http://www.puschmann.net/public/opt.h
> >>
> >>
> >> Kieran Mansley wrote:
> >>> On Tue, 2007-01-30 at 21:56 +0100, Andre Puschmann wrote:
> >>>> i am aware of this fact. the curious thing IMO is the correlation
> >>>> between the occurrences of this "larger packets" and the stuck of
> > the
> >>>> whole stack.
> >>> Sounds like you may either have a locking problem (the usual cause of
> >>> deadlock) or possibly a resource allocation issue. Is lwIP sending
> > or
> >>> receiving the large packet? Could you get a packet trace using
> >>> something like ethereal? Your lwipopts.h configuration might throw
> > some
> >>> light on the problem too.
> >>>
> >>> Kieran
> >
> >
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 8 Feb 2007 06:19:56 -0500
> From: "shobhit saxena" <address@hidden>
> Subject: [lwip-users] problem with netconn_accept
> To: address@hidden
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> hello everyone,
> i am using arm e7t board with ecos cofig tool & my
> target is to establish LWIP-TCP/IP over PPP & have communication
> between a server and ARM kit(client).I am using the lwip_init()
> function to establish PPP connection.I am using the following code for
> establishing TCP/IP .
> my problem is that the program is running fine till the line
> "newconn=netconn_accept(conn);"
> but its not accepting connection.Is there something wrong with my code?
> Is there any function to check the ip address that is being used?
>
>
> static void simple_prog(CYG_ADDRESS data)
> {
> cyg_io_handle_t handle1;
> cyg_io_lookup( "/dev/ser0", &handle1);
> lwip_init();
> printf("\nConnected PPP\n");
> struct netconn *conn, *newconn;
> err_t err;
> struct ip_addr *addr;
> unsigned short port;
> conn = netconn_new(NETCONN_TCP);
> cyg_thread_delay(50);
>
> int bind_result = netconn_bind(conn, NULL, 2506);
> //int bind_result = netconn_bind(conn,"192.168.0.4",2506);
> cyg_thread_delay(50);
> printf("\nBind to port 2506: [%d]", bind_result);
> int listen_result = netconn_listen(conn);
> cyg_thread_delay(50);
> printf("\nListening: [%d]\nPress any key to begin accepting.",
> listen_result);
> getchar();
> cyg_thread_delay(100);
> int netconn_peer_result;
> netconn_peer_result = netconn_peer(conn,NULL, NULL);
>
> printf("\nEntering while loop");
> while(1) {
> printf("\nInside while loop");
>
> // --FROM HERE THE PROBLEM STARTS--//
>
> newconn=netconn_accept(conn);
> cyg_thread_delay(50);
> printf("\nAccept: [%d]", newconn);
> if(newconn != NULL)
> {
> struct netbuf *buf;
> void *data;
> u16_t len;
> while((buf = netconn_recv(newconn)) != NULL)
> {
> do {
> netbuf_data(buf, &data, &len);
> err = netconn_write(newconn, data, len, NETCONN_COPY);
> if(err != ERR_OK) { }
> } while(netbuf_next(buf) >= 0);
> netbuf_delete(buf);
> }
> netconn_delete(newconn);
> }
> }
> }
>
>
>
> void cyg_user_start(void)
> {
> cyg_thread_create(4, simple_prog, (cyg_addrword_t) 0, "serial",
> (void *)stack[0], STACKSIZE, &thread[0], &thread_obj[0]);
> cyg_thread_resume(thread[0]);
> cyg_scheduler_start();
> }
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 8 Feb 2007 19:55:29 +0800
> From: "geckook Xu" <address@hidden>
> Subject: [lwip-users] I can only create 3 tcp/ip connects ? why?
> To: address@hidden
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> When I create the 4th connect, All the others connects will be quit,
> and the new connect are not avaliable.
>
> Are there some other setup?
>
> There are my lwipopts.h file.
> -------------- next part --------------
> /*
> * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
modification,
> * are permitted provided that the following conditions are met:
> *
> * 1. Redistributions of source code must retain the above copyright notice,
> * this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
notice,
> * this list of conditions and the following disclaimer in the
documentation
> * and/or other materials provided with the distribution.
> * 3. The name of the author may not be used to endorse or promote products
> * derived from this software without specific prior written permission.
> *
> * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED
> * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT
> * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT
> * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING
> * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY
> * OF SUCH DAMAGE.
> *
> * This file is part of the lwIP TCP/IP stack.
> *
> * Author: Adam Dunkels <address@hidden>
> *
> */
>
> #ifndef __LWIPOPTS_H__
> #define __LWIPOPTS_H__
>
> #if 1
> #define LWIP_DEBUG
> #define DBG_MIN_LEVEL 0
> #define DBG_TYPES_ON (DBG_ON | DBG_TRACE | DBG_STATE | DBG_FRESH |
DBG_HALT)
> #if 0
> #define TCP_DEBUG DBG_OFF
> #define TCP_QLEN_DEBUG DBG_OFF
> #define TCP_OUTPUT_DEBUG DBG_ON
> #define TCP_RTO_DEBUG DBG_ON
> #define TCP_FR_DEBUG DBG_ON
> #define TCP_CWND_DEBUG DBG_ON
> #define TCP_WND_DEBUG DBG_ON
> #endif
> #define TCP_RST_DEBUG DBG_ON
> #if 1
> #define LINK_STATS 1
> #define IP_STATS 1
> #define IPFRAG_STATS 1
> #define ICMP_STATS 1
> #define UDP_STATS 1
> #define TCP_STATS 1
> #define MEM_STATS 1
> #define MEMP_STATS 1
> #define PBUF_STATS 1
> #define SYS_STATS 1
> #define RAW_STATS 1
> #define LWIP_STATS_DISPLAY 1
> #endif
> #define MEM_DEBUG DBG_ON
> #define MEMP_DEBUG DBG_ON
> #if 0
> #define TCP_INPUT_DEBUG DBG_ON
> #define RAW_DEBUG DBG_OFF
> #define PBUF_DEBUG DBG_OFF
> #endif
> #endif
>
> //efine SO_REUSE 1
> #define NO_SYS 0
> #define LWIP_CALLBACK_API 1
> #define LWIP_DHCP 0
> #define SYS_LIGHTWEIGHT_PROT 1
>
> /* #define TCP_TMR_INTERVAL 250 */
> #define TCP_TMR_INTERVAL 250
>
> /* ---------- Memory options ---------- */
> /* MEM_ALIGNMENT: should be set to the alignment of the CPU for which
> lwIP is compiled. 4 byte alignment -> define MEM_ALIGNMENT to 4, 2
> byte alignment -> define MEM_ALIGNMENT to 2. */
> /* tried 4 byte alignment, but that seems to cause problems with pbuf
> * routines */
> #define MEM_ALIGNMENT 4
>
> /* MEM_SIZE: the size of the heap memory. If the application will send
> a lot of data that needs to be copied, this should be set high. */
> #define MEM_SIZE 1024*90
>
> /* The following four are used only with the sequential API and can be
> set to 0 if the application only will use the raw API. */
> /* MEMP_NUM_NETBUF: the number of struct netbufs. */
> #define MEMP_NUM_NETBUF 2
> /* MEMP_NUM_NETCONN: the number of struct netconns. */
> #define MEMP_NUM_NETCONN 4*2
> #define MEMP_NUM_TCP_PCB 5*10
> #define OS_MAX_QS 20*2 /* Max. number of queue control
blocks in your application */
> /* MEMP_NUM_APIMSG: the number of struct api_msg, used for
> communication between the TCP/IP stack and the sequential
> programs. */
> #define MEMP_NUM_API_MSG 16
> /* MEMP_NUM_TCPIPMSG: the number of struct tcpip_msg, which is used
> for sequential API communication and incoming packets. Used in
> src/api/tcpip.c. */
> #define MEMP_NUM_TCPIP_MSG 16*10
>
> #define MEMP_NUM_SYS_TIMEOUT 4+1
>
> #define PBUF_POOL_SIZE 16*16
> #define PBUF_POOL_BUFSIZE 128
> #define PBUF_LINK_HLEN 14
>
> #define TCP_MSS 1460
>
> /* TCP_SND_BUF should be less than or equal to MEMP_NUM_TCP_SEG *
> * TCP_MSS otherwise the system will not be able to allocate enough
> * tcp_segs to transmit all the data and will return ERR_MEM when
> * attempting to transmit large amounts of data. You want to guarantee
> * that there are more tcp_segs than there is memory. Each segment
> * is equal to TCP_MSS.
> */
> #define MEMP_NUM_TCP_SEG 255
>
> #define TCP_WND 2048
> #define TCP_SND_BUF (MEMP_NUM_TCP_SEG-1) * TCP_MSS
>
> #endif /* __LWIPOPTS_H__ */
>
> ------------------------------
>
> Message: 4
> Date: Thu, 8 Feb 2007 12:42:21 +0000
> From: Kieran Mansley <address@hidden>
> Subject: Re: [lwip-users] problem with netconn_accept
> To: Mailing list for lwIP users <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 08, 2007 at 06:19:56AM -0500, shobhit saxena wrote:
> > hello everyone,
> > i am using arm e7t board with ecos cofig tool & my
> > target is to establish LWIP-TCP/IP over PPP & have communication
> > between a server and ARM kit(client).I am using the lwip_init()
> > function to establish PPP connection.I am using the following code for
> > establishing TCP/IP .
> > my problem is that the program is running fine till the line
> > "newconn=netconn_accept(conn);"
> > but its not accepting connection.Is there something wrong with my code?
>
> I haven't looked in detail but it sounds like the packets aren't
> getting through to lwIP. I'm afraid I don't know enough about the
> board you're using to suggest how to debug it though.
>
> Good luck,
>
> Kieran
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 8 Feb 2007 12:44:54 +0000
> From: Kieran Mansley <address@hidden>
> Subject: Re: [lwip-users] I can only create 3 tcp/ip connects ? why?
> To: Mailing list for lwIP users <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 08, 2007 at 07:55:29PM +0800, geckook Xu wrote:
> > When I create the 4th connect, All the others connects will be quit,
> > and the new connect are not avaliable.
>
> Which API to lwIP are you using?
>
> Kieran
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 8 Feb 2007 13:12:27 +0000 (GMT)
> From: TEJ <address@hidden>
> Subject: [lwip-users] client-server arch. using lwip
> To: Mailing list for lwIP users <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> hi
> can i use the complete lwip for a client server acrh. even if my system is
having full fledged TCP/IP code and network driver.
> if yes then how to proceed with this design
> just give me some example...
> help needed very desparately
>
> Thank you in advance
>
>
> ---------------------------------
> Here's a new way to find what you're looking for - Yahoo! Answers
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://lists.gnu.org/pipermail/lwip-users/attachments/20070208/34b381c5/attachment.html
>
> ------------------------------
>
> Message: 7
> Date: Thu, 8 Feb 2007 15:41:57 +0100
> From: Fr?d?ric BERNON <address@hidden>
> Subject: [lwip-users] Just to inform : Internet Explorer 7.0 and LwIP
> Savannah web site problem
> To: "Mailing list for lwIP users" <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Skipped content of type multipart/related-------------- next part
--------------
> A non-text attachment was scrubbed...
> Name: =?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?=
> Type: text/x-vcard
> Size: 589 bytes
> Desc: =?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?=
> Url :
http://lists.gnu.org/pipermail/lwip-users/attachments/20070208/df64b3ae/iso-8859-1QFrE9dE9ric_BERNON2Evcf.vcf
>
> ------------------------------
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
> End of lwip-users Digest, Vol 42, Issue 7
> *****************************************
>
------------------------------
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
End of lwip-users Digest, Vol 42, Issue 9
*****************************************