lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] RE: [lwip] Linux 2.2


From: Steve Reynolds
Subject: [lwip-users] RE: [lwip] Linux 2.2
Date: Wed, 08 Jan 2003 23:09:15 -0000

Hi

I am working with Jason Morgan.

Thanks for your help.

I have just loaded the CVS version and Simhost works now. 
(although simrouter does not make in this version).

For the interest of anyone trying to make the latest official
download work...

I recompiled with IP debugging turned on and the packets do get into 
the lwIP stack but they are rejected with a bad header.

I have not gone too deeply (as it seems fixed) into this but there is either
an offset problem
or an ARP (is there an ARP?) problem on the lwip side.

The second point is that I believe in the 'latest' version that the IP
addresses
on the Linux interface and the lwip interface need to be swapped since the
linux and lwip
interfaces seem to both be .2 - this seems to be changed in the cvs version
to make 
the linux ifconfig interface be .1

Anyway I can move on with the CVS version


Thanks and Cheers

Steve
 

-----Original Message-----
From: Adam Dunkels [mailto:address@hidden
Sent: 06 November 2001 15:24
To: address@hidden
Subject: Re: [lwip] Linux 2.2


On Tuesday 06 November 2001 15.43, you wrote:
> As you know we are porting the lwIP to the C166, we've now embarked on
> IGMP. In order to speed up development we've adopted
> Linux as a test platform for testing.
>
> We're running Redhat 6.2 with the 2.2.x kernel.
>
> We're having trouble getting round that stack structure, in that we ping
> the IP address of the tap interface created by lwIP, but
> the packets seem to try and go to the wrong adapter.
>
> i.e. tap0 is 192.168.0.2/255.255.255.0 and pinging it causes packets to
> arrive at lo (127.0.0.1)
>
> Removing lo results in no ping reply.
>
> Pinging 192.168.0.1 however, does enter the stack as we get
> tapif_irq_handler() calls, but never a response.
>
> We are confused as the ip address of the unix ip stack is the same as the
> ip address on lwIP, can you send us a model of
> how the two stacks co-exist.
>
> Here's how we understand it (obviously wrongly)
>
> We believe that the tap interface installs under the linux IP stack like a
> normal ethernet, the lwIP sits on the other
> end of a similar adapter connected to the same virtual ethernet, that way
> the two stacks are connected internally within a single PC.

This is correct - the tap interface should work as a simulated Ethernet with

ARP and other typical ethernet stuff. The "Linux connection" to the tap 
interface should have the IP address 192.168.0.1, so pinging 192.168.0.1 
should provoke a response from Linux. The response could arrive on the lo 
(loopback) interface as well (I am not sure how Linux does it's routing in 
cases such as this).

The "lwIP connection" to the tap interface should have the IP address 
192.168.0.2 so pinging 192.168.0.2 should make lwIP respond. With the
default 
debugging configuration, it should print "Pong" in the terminal window.

> We don't see two tap interfaces in ifconfig as one exists in the lwIP
> domain and can't be seen from linux.

Correct.

You can try running "tcpdump -l -n -i tap0" (as root) to see what packets
are 
sent over the tap interface. This is how it looks for me when I ping 
192.168.0.2:

# tcpdump -l -n -i tap0
tcpdump: listening on tap0
16:17:54.704154 arp who-has 192.168.0.2 tell 192.168.0.1
16:17:54.704285 arp reply 192.168.0.2 is-at 1:12:23:34:45:56
16:17:54.704412 192.168.0.1 > 192.168.0.2: icmp: echo request
16:17:54.706219 192.168.0.2 > 192.168.0.1: icmp: echo reply
16:17:55.711474 192.168.0.1 > 192.168.0.2: icmp: echo request
16:17:55.712568 192.168.0.2 > 192.168.0.1: icmp: echo reply

Running "ifconfig tap0" should show the IP address 192.168.0.1:

> ifconfig tap0
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::2bd:4bff:fee9:700%tap0 prefixlen 64 scopeid 0x7 
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        ether 00:bd:4b:e9:07:00 
        Opened by PID 960

Also, check the routing table in Linux with "netstat -nr". It should show 
that packets for the 192.168.0 network should be sent out on the tap 
interface. The command "route add 192.168.0.0/24 192.168.0.1" or simillar 
(see "man route") should set up the routing table correctly if it isn't 
working.

> The other confusion comes from the three applications generated by the
> unixsim makefile
> simhost
> simrouter
> simnode
>
> How do these differ?
>
> For the above results (packets on lo) we were running just simhost.
>
> If we run simrouter, we get a message "please run the client" what does
> that mean?

These three binaries do different things: "simhost" is a single lwIP
instance 
with IP address 192.168.0.2. "simnode" and "simrouter" work together and
form 
a small network where simrouter is a router with two IP addresses, 
192.168.0.2 and 192.168.1.1 and simnode has IP address 192.168.1.2. Packets 
for simnode are routed by simrouter.

In order for the communication between simrouter and simnode to work, 
simrouter must be started before simnode. The message "Please run client" is

actually a small mistake - it should say "Please run ./simnode" instead.

Hope this helps!

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]
[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]