Re: Port to TMS320C6713

Hello Bernhard,

On Fri, 2005-04-29 at 18:06, Bernhard 'Gustl' Bauer wrote:
> Hi,
> 
> '#define ETH_PAD_SIZE 2' did the trick. I had to add ETH_PAD_SIZE to 
> cs8900if.c.

Is this a patch useful for others? Pls. post or email to the list.

Thanks,

Leon.

Re: Port to TMS320C6713

Hello Leon,

Leon Woestenberg wrote:

> Hello Bernhard,
> 
> 
> On Fri, 2005-04-29 at 18:06, Bernhard 'Gustl' Bauer wrote:
> 
>>Hi,
>>
>>'#define ETH_PAD_SIZE 2' did the trick. I had to add ETH_PAD_SIZE to 
>>cs8900if.c.
> 
> 
> Is this a patch useful for others? Pls. post or email to the list.

It could be usefull, if it works correct. I still have some Problems 
with duplicate echo replys. And I have not everthing tested. If all is 
ok for me I post to list. But I used the source file from rev. 0.7.1 so 
I would be gratefull to have a newer revision for CS8900 myself.

Gustl

Re: BootP

    I wound up trying to implementing BootP myself, and I've run into a 
problem.  I can make a BootP request, and I get a reply, but I haven't 
been able to actually receive the reply.  I'm using the recv() call to 
retrieve the BootP packet, but recv() never returns.  Looking through 
the debug output it looks as if the BootP packet is being recognized as 
a DHCP packet and sent somewhere else.  Does anyone have any idea how I 
might be able to deal with this?

--Bill

Bill Lawson wrote:

> Hi Everybody,
>    Has anyone had any experience using BootP with lwIP?  For 
> compatibility purposes I need to be able to use BootP for dynamic host 
> configuration.  I don't need to transfer a boot file, I simply need to 
> obtain an IP/Subnet/Gateway.  I already have DHCP working on the 
> system in question, but I need to be able to use BootP as well if DHCP 
> is unavailable.
>    Is there BootP functionality built into lwIP, and I just haven't 
> seen it?  If not, does anyone know where I can find a lwIP compatible 
> implementation?  It seems like there should be no need to implement 
> this from scratch.
>
> Thanks for the info,
> Bill Lawson 

raw socket

Hi everybody,

It is possible to create a raw socket at data link level in iwIP?
because I must create a program for send and receive ethernet packet
without TCP & UDP encapsulation.

In my no rt program I use the PF_PACKET  to by pass the TCP/IP stack,
In lwIP don't exist this socket domain or similar?

thanks
   Nicol <at> 

Re: raw socket

On Wed, 2005-05-04 at 15:02 +0200, Qeltaras wrote:
> Hi everybody,
> 
> It is possible to create a raw socket at data link level in iwIP?
> because I must create a program for send and receive ethernet packet
> without TCP & UDP encapsulation.
> 
> In my no rt program I use the PF_PACKET  to by pass the TCP/IP stack,
> In lwIP don't exist this socket domain or similar?

No, I don't think it does.  It shouldn't be too much work to implement
it however, and if you do manage this, I'm sure a patch would be well
received.

Kieran

raw api recv callback - procedure to (temporarily) refuse data?

Hi all,

I am using LWIP 1.1.0 - which appears to be performing very well indeed -
using the RAW API.

What is the correct manner to return from the recv_callback when the data
may not be processed immediately?
I have experimented with several combinations of return code/whether to call
tcp_recvd with zero and/or free the pbuf - but with no luck yet?

My receive callback is summarised as follows :-

// recv callback which places incoming data into rx queue
static err_t btcp_recv_cb(void *arg, struct tcp_pcb *tpcb, struct pbuf *p,
err_t err)
{
   btcp_t *h = (btcp_t *)arg;
   struct pbuf *q;
   int q_write_tot = 0;
   ASSERT(h != NULL);
   ASSERT(tpcb == h->pcb);
   if(p == NULL)
   {
      // closed connection?
      . . .
   }
   else
   {
      h->poll_retries = 0; // <- reset poll timer, due to rx activity

RE: raw api recv callback - procedure to (temporarily)refuse data?

All,

I'm stuck. I'm nearly done with a single threaded version of slip. I
will add it to contrib when I complete it.

The problem stems most likely from my lack of understanding of pbufs.

The follow2ing is the code that executes when a complete packet is
received:

	p = pbuf_alloc(PBUF_RAW, recved, PBUF_POOL);
	if (p != NULL)
	{
		memcpy(p->payload, SlipBuff, recved);
		p->len = recved;
		LWIP_DEBUGF(SLIP_DEBUG, ("slipif: Got packet\n"));
		recved = 0;
		return p;
	}

SlipBuff has the data,
Recved has the length.

Small packets are handled correctly. However larger packets (around 300
bytes) the TCP checksum fails. The following is the portion of tcp_input
that fails.

  /* Verify TCP checksum. */
  if (inet_chksum_pseudo(p, (struct ip_addr *)&(iphdr->src),
      (struct ip_addr *)&(iphdr->dest),

Re: raw api recv callback - procedure to (temporarily)refuse data?

On Mon, May 09, 2005 at 10:29:08PM -0500, Karl Kobel wrote:
> I'm stuck. I'm nearly done with a single threaded version of slip. I
> will add it to contrib when I complete it.

If you might be interested, I've attached my changes to slipif that modify
slipif_input() and create a replacement for slipif_loop(), slipif_loop_iter(),
to run a single iteration instead of creating a thread and looping forever.
To allow the caller to sleep for a bit if there appears to be no traffic,
slipif_loop_iter() returns 1 if it read data, else 0.

The code is unfortunately fairly ugly, but perhaps it'll be of some use?

Thanks for lwip!
--

-- 
Chris Frost  |  <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
   Email chris@... with the subject "retrieve pgp key"
   or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>

--- lwip-1.1.0/src/netif/slipif.c	Mon Feb 23 02:15:06 2004
+++ school/rks/trunk/kudos/lib/net/netif/slipif.c	Sat Apr 30 14:10:44 2005
 <at>  <at>  -51,6 +51,8  <at>  <at> 

 #define MAX_SIZE     1500

+#define SLIP_FROST_DEBUG 0
+
 /**

RE: raw api recv callback - procedure to(temporarily)refuse data?

When you allocated a pbuf using PBUF_POOL, you are actually allocating a
chain og buffers linked together. The length of each is p->len(and then
p->next->len and so on). The total length is p->tot_len

memcpy(p->payload, SlipBuff, recved); 

The above line will fail if recved > p->len. You might do something like
this:

struct pbuf *make_pbuf (BYTE *packet, int packet_len)
{
    struct pbuf *p, *q;
    int left = packet_len;

    p = pbuf_alloc(PBUF_TRANSPORT, left, PBUF_POOL);
    if (!p) return NULL;

    q = p;

    while (left > 0)
    {
        int chunk_size = min (left, q->len);
        memcpy (q->payload, packet, chunk_size);

        packet += chunk_size;
        left -= chunk_size;
        q = q->next;
    }
    return p;
}    

Lwip Port to st10f269

Hi,

I learn at this time the port on the Infineon C16x by Leon Woestenberg 
to adapt it to the ST10F269 & CS8900A.

If somebody made the port of lwip to the phyCORE-167/ST10F269 Version 
HS/E, i'll be happy to have your help and maybe your source files...

Thanks,

Cedric