the flags to true to redo the connect. Note,
this is just for testing not for any other purpose. Once I can see SYN packet
then I know I can start implementing properly...
......
Inderjit Singh Senior Embedded Engi
delay_ms is used throughout our bare metal implementation I can guarantee it's
not blocking.
tcp_cb_called is called to the registered callback function yes. And sure, main
loop as you suggest is functional as well yes.
However I fail see why LWIP layer marks SYN_SENT state in pcb but I cannot s
OK. i'll try that.
..
Inderjit Singh Senior Embedded Engineer, MSc
Evidente ES East AB
Warfvinges väg 34 SE-112 51 Stockholm Sweden
Mobile: +46 (0)70 912 42 69
E-mail: inderjit.si...@eviden
Yeah, the procedure is exactly as you descript with address setting, netifadd,
etc...
IP4_ADDR(&ip, 192, 168, 100, 250);
IP4_ADDR(&netmask, 255, 255, 255, 0);
IP4_ADDR(&gateway, 192, 168, 100, 1);
if (NULL == netif_add(&dev_netif, &ip, &netmask, &gateway, NULL,
ethernetif_init, ethernet_input)) {
get_data(ctx->recv_buf, ctx->recv_buf);
}
DBG_I("TCP RESPONSE: status:%03d. data_size: %d bytes. err: %d.",
ctx->status, ctx->recv_size, err);
}
return ERR_OK;
}
Tanks in advance,
Inderjit
/*****
So,
I have updated reception code (from the contrib examples httpd_raw) and still
the behaviour is the same (code at bottom).
I did a quick and ugly test by calling tcp_ack_now and tcp_output at the end of
the function and then the behaviour dramatically improved as ACKs are being
sent back an