----- Original Message -----
Sent: Monday, October 18, 2010 10:18
PM
Subject: Re: [lwip-users] Testing the
internet app based on lwIP-1.3.0 and Mini-OS
Hi David,
Thank you very much for your reply!
However,
there is no LWIP_NETIF_LOOPBACK in the definition in opt.h in lwIP
1.3.0. I am afraid this variable has been used from the version 1.4.0.
Is that to say lwIP 1.3.0 can not support sending packets with a
destination IP address equal to the netif IP address?
It looks like that feature was introduced in LWIP 1.3.1. You will have to
upgrade your port to a later version of LWIP to be able to send IP traffic to
your own address on the network interface (or work out what changed between
1.3.0 and 1.3.1 to implement that feature in your port).
An alternative is to use the loopback network interface (127.0.0.1).
This requires enabling LWIP_HAVE_LOOPIF (which is supported
by 1.3.0).
I have another problem with the API functions provided by lwIP.
I
set 0.0.0.0 as my Mini-OS IP address. And run a server to listen to the port
13.
0.0.0.0 is not a valid IP
address.
Another question:
If Mini-OS's IP address was set as 0.0.0.0 and using
the client to connect to outside internet (such as ip 61.135.169.125). I can
get some packet information from tcpdump as following.
address@hidden
~]# tcpdump -i virbr0 -nn
tcpdump: verbose output suppressed, use -v or -vv
for full protocol decode
listening on virbr0, link-type EN10MB (Ethernet),
capture size 96 bytes
15:54:13.554632 arp who-has 61.135.169.125 tell
0.0.0.0
15:54:16.304944 arp who-has 61.135.169.125 tell
0.0.0.0
15:54:19.305261 arp who-has 61.135.169.125 tell
0.0.0.0
15:54:22.305566 arp who-has 61.135.169.125 tell
0.0.0.0
15:54:25.305872 arp who-has 61.135.169.125 tell
0.0.0.0
However, if the Mini-OS's IP was set as 192.168.122.20.(The ip
address of net bridge is 192.168.122.1) I could not get anything from the
tcpdump. So why this happened? What's the most reason in your
opinion?
Where were you doing the tcpdump? If it was on the
network segment beyond the bridge, perhaps the bridge wasn't forwarding packets
from that IP address, or if there was an Ethernet switch involved it may have
been filtering out packets which weren't broadcasts or addressed to the computer
running tcpdump.
|