Hey folks,
I'm trying to complete a port of LWIP 1.3.0 raw api. I've used sockets on
several earlier versions of LWIP in the past, and usually I've hacked away
at my current installation to upgrade to the latest. Haven't had any problems.
This time I decided to start from scratch, just to clean
One more bit of data I just noticed...
If I turn off ARP_QUEUEING, then etharp_query() hits the error message
at the bottom of the function...
Ethernet destination address unknown, queueing disabled, packet ...dropped.
Ed
Ed Sutter wrote:
Hey folks,
I'm trying to complete a port of LWIP 1.3.0
);
/* free the pbuf */
pbuf_free(p);
}
}
So, if anyone who knows this stack really well could verify that my thinking
is correct, that sure would be helpful!
Thanks!
Ed
Ed Sutter wrote:
One more bit of data I just noticed...
If I turn off ARP_QUEUEING, then etharp_query
Hey folks,
What's the status of zeroconf in LWIP? I saw in the archives that this was
a topic a few months ago. Anybody using it, working on it or thinking about it
anymore?
Thanks
Ed
___
lwip-users mailing list
lwip-users@nongnu.org
Well, I guess I can answer my own question...
Sorry, I didn't see this before. Looks like AUTOIP is in 1.3
Cool!
Ed
Ed Sutter wrote:
Hey folks,
What's the status of zeroconf in LWIP? I saw in the archives that this was
a topic a few months ago. Anybody using it, working on it or thinking
functions.
Anyway, I wanted to let folks know this will be available, and also wanted
to thank the LWIP developer community for a really-nice-little-tcpip-stack.
If anyone is interested, let me know and I'll post one more mailing to
this list when the 1.16 version is made available.
Regards,
Ed
Hey folks,,
I'm using 1.3.0, been running fine for quite a while now.
I just crashed somewhere in ip_reass() as a result of an
incoming IP fragment (MF bit set in header). Are there any
known problems with IP_REASSEMBLY in lwip1.3.0?
Thanks
Ed
___
Ceresoli Luca wrote:
Ed Sutter wrote:
I'm running LWIP 1.3.0 on a Blackfin, which is picky about
...
The ethernet_input() function then sees that it is IP,
increments the payload
pointer by 14 (size of ethernet header) and passes the pbufs
to ip_input().
Note that at this point, the payload pointer
[EMAIL PROTECTED] wrote:
Kieran Mansley wrote:
On Fri, 2008-10-10 at 07:21 -0400, Ed Sutter wrote:
Ok, I am running with the BF537, I'll take a look at that setting.
However, it still seems to me that this is a problem in the code
because the combination of...
1. MEM_ALIGNMENT = 4
2
Simon Goldschmidt wrote:
The way I fixed this was to change the helper structure to this...
struct ip_reass_helper {
PACK_STRUCT_FIELD(u16_t start);
PACK_STRUCT_FIELD(struct pbuf *next_pbuf);
PACK_STRUCT_FIELD(u16_t end);
};
If that works for you its OK. But to be more portable,
Folks,
I'm running with 1.3.0 and I have an HTTP server and a UDP-based
server running on my target for months.
Last night I accidentally sent that target a tftp packet (it does
not have a tftp server running) and I got an assertion failure...
Assertion p-payload == iphdr failed at line 293 in
Ed Sutter wrote:
Folks,
I'm running with 1.3.0 and I have an HTTP server and a UDP-based
server running on my target for months.
Last night I accidentally sent that target a tftp packet (it does
not have a tftp server running) and I got an assertion failure...
Assertion p-payload == iphdr
Jonathan Larmour wrote:
Ed Sutter wrote:
To be more efficient, I changed this by using PBUF_REF and
setting the payload pointer to the packet buffer...
len = mon_recvenetpkt((char *)ipacket,sizeof(ipacket));
if (len) {
p = pbuf_alloc(PBUF_RAW, len, PBUF_REF
bill wrote:
Ed,
p = pbuf_alloc(PBUF_RAW, len, PBUF_REF);
I do the same but use PBUF_POOL, but PBUF_RAW. I think this is the problem.
Bill
Bill,
Unless I misunderstand what you're suggesting (quite likely), using
the PBUF_RAW/PBUF_POOL combination requires that I do the memcpy
Jonathan Larmour wrote:
Ed Sutter wrote:
Jonathan Larmour wrote:
Ah I see in the implementation of pbuf_header, that it can't expand
PBUF_REFs to the front. That will be your problem.
I think the only reason it doesn't do it is because there's no way to
sanity check that it's a valid thing
Jonathan Larmour wrote:
Ed Sutter wrote:
Jonathan Larmour wrote:
Ed Sutter wrote:
Jonathan Larmour wrote:
Ah I see in the implementation of pbuf_header, that it can't expand
PBUF_REFs to the front. That will be your problem.
I think the only reason it doesn't do it is because there's
Jonathan Larmour wrote:
[EMAIL PROTECTED] wrote:
Ed Sutter wrote:
Ok, I see what you're talking about in pbuf_header(). I don't know
the history
of the code to comment on whether or not the change should be in the
master
code base; but it would seem to me that if this is forcing a driver
17 matches
Mail list logo
