On May 4, 2008, at 6:42 AM, [EMAIL PROTECTED] wrote:
P.S. I've written a unix driver that actually binds to eth0 (or
other
device) and operates there. This allows you to test inter-computer
communication in unix (tap/tun seem to only work on the machine
running the
program and no other m
P.S. I've written a unix driver that actually binds to eth0 (or other
device) and operates there. This allows you to test inter-computer
communication in unix (tap/tun seem to only work on the machine running the
program and no other machine can access this). Is this something that is
useful to
On 5/1/08, Rishi Khan <[EMAIL PROTECTED]> wrote:
> Ok. Maybe the tapif.c should be updated in ports/unix/netif because that's
> where I got the hairbrained idea to remove the ethernet header.
>
> -rishi
>
> P.S. I've written a unix driver that actually binds to eth0 (or other
> device) and
On May 2, 2008, at 5:14 AM, [EMAIL PROTECTED] wrote:
Kieran Mansley wrote:
On Thu, 2008-05-01 at 14:16 -0400, Rishi Khan wrote:
P.S. I've written a unix driver that actually binds to eth0 (or
other device) and operates there. This allows you to test inter-
computer communication in unix
Kieran Mansley wrote:
On Thu, 2008-05-01 at 14:16 -0400, Rishi Khan wrote:
P.S. I've written a unix driver that actually binds to eth0 (or other
device) and operates there. This allows you to test inter-computer
communication in unix (tap/tun seem to only work on the machine
running the
On Thu, 2008-05-01 at 14:16 -0400, Rishi Khan wrote:
> P.S. I've written a unix driver that actually binds to eth0 (or other
> device) and operates there. This allows you to test inter-computer
> communication in unix (tap/tun seem to only work on the machine
> running the program and no othe
Ok. Maybe the tapif.c should be updated in ports/unix/netif because
that's where I got the hairbrained idea to remove the ethernet header.
-rishi
P.S. I've written a unix driver that actually binds to eth0 (or other
device) and operates there. This allows you to test inter-computer
Rishi Khan wrote:
So, if you call
NETIF_FLAG_ETHARP, they you should leave the header alone, but if you
don't call NETIF_FLAG_ETHARP, you should leave it there. Doesn't that
seem weird? Why should the TCP/IP stack handle ARP? This is
inherently an ethernet problem.
Just for better under
have to call pbuf_header on your
pbuf before post if with tcpip_input.
- Original Message - From: "Rishi Khan"
<[EMAIL PROTECTED]>
To: "Mailing list for lwIP users"
Sent: Thursday, May 01, 2008 5:20 PM
Subject: [lwip-users] Possible bug in src/api/tcpip.c
=1, you have to call pbuf_header on your
pbuf before post if with tcpip_input.
- Original Message - From: "Rishi Khan"
<[EMAIL PROTECTED]>
To: "Mailing list for lwIP users"
Sent: Thursday, May 01, 2008 5:20 PM
Subject: [lwip-users] Possible bug in src/api/t
quot;
Sent: Thursday, May 01, 2008 5:20 PM
Subject: [lwip-users] Possible bug in src/api/tcpip.c
I'm using the unix port to try to get some ideas as to the performance of
the lwIP stack. I think I have found a bug when the NETIF_FLAG_ETHARP is
set. Typically tcpip_input expects t
I'm using the unix port to try to get some ideas as to the
performance of the lwIP stack. I think I have found a bug when the
NETIF_FLAG_ETHARP is set. Typically tcpip_input expects to see a TCP/
IP packet with the ethernet header already stripped. It sends this to
a MBOX which gets processe
12 matches
Mail list logo
