[lwip-users] file upload
Heike Lepke
I run the lwip rawAPI under OSEK. A GPRS-modem is connected via ppp and
tcp to the web. On the platform I run a little HTTP-server. All o.k.
I try now to implement a file-upload to the server with a usual upload
form like this:
<form action="receive" enctype="multipart/form-data" method="post">
select file: <br>
<input type="file" name="datafile" >
<input type="submit" value="Send">
<input type="reset">
</form>
I receive the first packet, trough tcp and to my http server, e.g.
POST /receive HTTP/1.1..Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, application/x-icq,
*/*..Referer: http://80.187.82.178/upload..Accept-Language:
de..Content-Type: multipart/form-data;
boundary=---------------------------7d72fd1d206c6..UA-CPU:
x86..Accept-Encoding: gzip, deflate..User-Agent: Mozilla/4.0
(compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)..Host:
80.187.82.178..Content-Length: 1586..Connection:
Keep-Alive..Cache-Control: no-cache..X-NovINet: v1.2
all o.k.
then I receive my data packets, see the added etherreal file (packets
4,5). But they are not forwarded to my http server. They get lost in the
ppp-task.
Anybody knows why???
Thanks
Heike
Kieran Mansley
> then I receive my data packets, see the added etherreal file (packets
> 4,5). But they are not forwarded to my http server. They get lost in the
> ppp-task.
>
> Anybody knows why???
Hmm. Could you send a copy of your lwipopts.h?
ethereal thinks a lot of the packets in the capture have bad TCP
checksums, but ethereal often gets things like that wrong and some of
the ones that get through fine are also marked like this, so I don't
believe it.
You could try turning on debugging print statements in lwIP to try and
trace what is happening to the received packets that go missing.
Kieran
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Heike Lepke
I added my debug info for one upload.
Can it be the problem, that my tcp-connection is closed after I send the
HTTP/1.1 200 OK answer to the client (line 152 in ppp_debug.txt)?
Heike
my lwipopts are...
rest is like in opts.h:
####################################################################################
#ifndef __LWIPOPTS_H__
#define __LWIPOPTS_H__
#define MEM_SIZE 32768
#define MEMP_NUM_PBUF 32
/*Maximum Send Buffer Space*/
#define TCP_SND_BUF 32768
#define TCP_WND 32768
/*Maximum retransmissions*/
#define TCP_MAXRTX 12
/*Maximum retransmissions of SYN frames.*/
#define TCP_SYNMAXRTX 6
/*Maximum Segment Size*/
#define TCP_MSS 1500
#define PBUF_POOL_BUFSIZE 1536
#define MEMP_NUM_RAW_PCB 4
#define MEMP_NUM_UDP_PCB 4
#define MEMP_NUM_TCP_PCB 5
#define MEMP_NUM_TCP_PCB_LISTEN 8
#define MEMP_NUM_NETBUF 2
#define PBUF_LINK_HLEN 16
#define ARP_TABLE_SIZE 2
#define ARP_QUEUEING 0
#define TCP_QUEUE_OOSEQ 0
#define LWIP_STATS_DISPLAY 1
#define RAW_STATS 1
#define PPP_SUPPORT 1
#define MD5_SUPPORT 1
#define CHAP_SUPPORT 1
####################################################################################
Kieran Mansley schrieb:
Kieran Mansley
> Hi Kieran,
>
> I added my debug info for one upload.
> Can it be the problem, that my tcp-connection is closed after I send the
> HTTP/1.1 200 OK answer to the client (line 152 in ppp_debug.txt)?
The TCP connection is only closed in one direction - from the server to
the client - which shouldn't stop the client being able to complete its
file upload. It just says that the server has no more data to send the
client.
Could you get debug output like this at the same time as getting an
ethereal capture? It is much easier to navigate if both have the same
sequence numbers etc. which means getting them at the same time.
Kieran Mansley
> new debug files...
Had a look at those and everything seems fine. The packets are getting
passed through and acknowledged by the TCP stack, so they are processed
correctly. It must be a problem relating to passing the data between
the stack and your application. You should look at this in more detail
(e.g. the receive callback to your application) and trace what happens
to the packets that should be passed up.
Just a thought - are you calling tcp_recved() after receiving the first
block of data?
Heike Lepke
I have set tcp_recv(pcb, http_recv);
and in the http_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p,
err_t err)
-function I call tcp_recved(pcb, p->tot_len); to the passed tcp_pcb *pcb
The first data block reaches the http_recv, the data-packets not.
I see that for the packet which is mixed with the http-upload request
and the data the p->len is set just to the length of the http-upload
request in tcp_input(struct pbuf *p, struct netif *inp), the real
data-len is ignored. But it seems that the data is inside the received
p-payload, after the p->len. If an another data packets comes I don't
get it. Do I have the chance to call an another tcp-function to get the
missing data-packets?
Thanks
Heike
Kieran Mansley schrieb:
Kieran Mansley
> Hi Kieran,
>
> I have set tcp_recv(pcb, http_recv);
> and in the http_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p,
> err_t err)
> -function I call tcp_recved(pcb, p->tot_len); to the passed tcp_pcb *pcb
OK.
> I see that for the packet which is mixed with the http-upload request
> and the data the p->len is set just to the length of the http-upload
> request in tcp_input(struct pbuf *p, struct netif *inp), the real
> data-len is ignored. But it seems that the data is inside the received
> p-payload, after the p->len. If an another data packets comes I don't
> get it. Do I have the chance to call an another tcp-function to get the
> missing data-packets?
I'm afraid I don't understand what the problem is you're describing
here. Can you illustrate with the code you think is at fault?
Heike Lepke
err_t
http_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err)
{
int i;
struct http_state *hs;
T_CHAR *pc_rq;
hs = reinterpret_cast<http_state*>(arg);
hs->file = hs->mem;
if(err == ERR_OK && p != NULL)
{
/* Inform TCP that we have taken the data. */
tcp_recved(pcb, p->tot_len);
/* Send the data to the http-Server. */
hs->left =
reinterpret_cast<http_state*>(arg)->myServer->HandleRequest(static_cast<T_CHAR*>(p->payload),p->len,hs->file,BUFFER_SIZE);
...
###############################################################################################################################
In this function I get the pbuf p, with the p->len e.g. 600, but the
real length of the data is 1400, whereby the data after the first 600
bytes is the part of the file to upload.
The upload-file I can see in the p->payload+600 following.
Heike
Kieran Mansley schrieb:
Kieran Mansley
>
> err_t
> http_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err)
> {
> int i;
> struct http_state *hs;
> T_CHAR *pc_rq;
> hs = reinterpret_cast<http_state*>(arg);
> hs->file = hs->mem;
>
> if(err == ERR_OK && p != NULL)
> {
>
> /* Inform TCP that we have taken the data. */
> tcp_recved(pcb, p->tot_len);
> /* Send the data to the http-Server. */
> hs->left =
> reinterpret_cast<http_state*>(arg)->myServer->HandleRequest(static_cast<T_CHAR*>(p->payload),p->len,hs->file,BUFFER_SIZE);
> ...
> ###############################################################################################################################
>
> In this function I get the pbuf p, with the p->len e.g. 600, but the
> real length of the data is 1400, whereby the data after the first 600
> bytes is the part of the file to upload.
> The upload-file I can see in the p->payload+600 following.
Ahh, could it be that this pbuf is part of a pbuf chain? p->len tells
you the length of each individual pbuf, p->tot_len (for the first one in
the chain) tells you the total length of all the pbufs in the chain. p-
>next lets you access the next pbuf in the chain.
Also, you should only be calling tcp_recved() after you have finished
accessing the data - i.e. copied it to your own memory or have no
further use for it. If you don't, it's possible that the stack will
overwrite the packet data with a new packet. Putting it at the end of
your http_recv() function should probably be sufficient.
Heike Lepke
the p->tot_len is the same as the p->len and p->next is NULL...
even if I call tcp_recved(pcb, p->tot_len); after I worked on my data.
Heike
Kieran Mansley schrieb: