Guan,
For the first question, I expect the problem is you
haven't enabled LWIP_NETIF_LOOPBACK in your lwipopts.h. See the definition in
opt.h.
If LWIP_NETIF_LOOPBACK is 0 (which it is by
default), then LWIP won't recognise that you are trying to send packets to your
own IP address and will instead attempt to send them out on the network,
starting with an ARP to your own IP address. The ARP cannot be received by the
device which sent it, so it never succeeds.
If LWIP_NETIF_LOOPBACK is 1 (which you would have
to set in lwipopts.h) then LWIP will recognise it is attempting to transmit to
its own IP address and will loop the transmit packet back to itself without it
appearing on the network interface at all.
For the second question, the names like patrolview, drmsfsd, dpcp, and igo-incognito are coming from tcpdump using its own list to look up the
port numbers that LWIP happens to be using. In many cases, this information
is completely useless as a port number can be used for anything, especially when
the transmitting device is the client end of a TCP connection, which typically
allocates a random port number for its end of the connection. The only one of
the above which is likely to be accurate is "dhcp", which would be used when
LWIP is attempting to contact a DHCP server (via UDP).
On a Unix/Linux system there is a file
/etc/services which has a list of known port numbers. tcpdump probably gets its
list from there. On my system, /etc/services
lists a "patrolview" assigned to port 4097, so I expect this simply means LWIP
happened to pick port 4097 for its outgoing connection. The "patrolview" name
would only be significant if a device was listening for a connection on that
port number and needed to work on the same computer as the patrolview
software (whatever that might be).
You can tell tcpdump to not do any name lookups
(either DNS or port names) with the -n option.
For the third question (why the ICMP packets cannot
reach 192.168.122.1), you are misreading the tcpdump output. LWIP is sending TCP
SYN packets to that IP address (attempting to connect to port 10), and the
device at that IP address is responding with ICMP packets telling LWIP that it
is unreachable. The problem is likely to be that nothing is listening for
incoming connections at port 10 on the device at
192.168.122.1.
Regards,
David
----- Original Message -----
Sent: Friday, October 15, 2010 12:41
AM
Subject: [lwip-users] Testing the
internet app based on lwIP-1.3.0 and Mini-OS
Hi
All,
lwIP-1.3.0 had been ported to Mini-OS, which is a para-virtualized
operating system running on Xen. I just design some experiment to test simple
application and I have some problems.
Experiment 1.
I written a
simple server and client using the lwIP API. All are running in the Mini-OS.
The server start firstly, and then the client start after 10 seconds. However,
the client cannot connect to the sever. I used tcpdump to listen to
virtual net bridge interface virbr0 and get message as following. ( The
virbr0's IP is 192.168.122.1 )
address@hidden Download]# tcpdump -i
virbr0
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on virbr0, link-type EN10MB (Ethernet), capture size 96
bytes
17:21:26.284036 arp who-has 192.168.122.20 tell
192.168.122.20
17:21:29.034378 arp who-has 192.168.122.20 tell
192.168.122.20
17:21:32.034868 arp who-has 192.168.122.20 tell
192.168.122.20
17:21:35.035378 arp who-has 192.168.122.20 tell
192.168.122.20
17:21:38.036055 arp who-has 192.168.122.20 tell
192.168.122.20
17:21:41.036521 arp who-has 192.168.122.20 tell
192.168.122.20
17:21:44.036927 arp who-has 192.168.122.20 tell
192.168.122.20
Why Mini-OS cannot connect to itself? Does lwIP
cannot deal with the case.
Experiment 2.
I just running the
client, mentioned in experiment 1, but I set the client to connect to the
virbr0 ( which ip is 192.168.122.1 ). The tcpdump caught the following
data.
address@hidden Download]# tcpdump -i virbr0
tcpdump:
verbose output suppressed, use -v or -vv for full protocol decode
listening
on virbr0, link-type EN10MB (Ethernet), capture size 96
bytes
19:27:49.690633 arp who-has 192.168.122.1 tell
192.168.122.20
19:27:50.191296 arp reply 192.168.122.1 is-at
fe:ff:ff:ff:ff:ff (oui Unknown)
19:27:50.191474 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:27:49.690656 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
19:27:52.441109 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:27:52.441148 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
19:27:54.698700 arp who-has
192.168.122.20 tell 192.168.122.1
19:27:54.698746 arp reply 192.168.122.20
is-at 00:16:3e:60:bb:a1 (oui Unknown)
19:27:55.441726 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:27:55.441756 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
19:27:58.442208 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:27:58.442241 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
19:28:01.442863 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:28:01.442901 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
19:28:04.443371 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:28:04.443405 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
19:28:07.444012 IP
192.168.122.20.patrolview > 192.168.122.1.10: S 6509:6509(0) win 2048
<mss 1500>
19:28:07.444050 IP 192.168.122.1 > 192.168.122.20: ICMP host 192.168.122.1
unreachable - admin prohibited, length 52
So, my question is what
the "patrolview" mean? I also got other like "drmsfsd", "dpcp",
"igo-incognito". What are they mean?
Why the ICMP packets can not reach to
host 192.168.122.1?
My Mini-OS net bridge interface information
is like these:
address@hidden mini-os]# brctl show
bridge
name bridge
id
STP enabled
interfaces
eth0
8000.0024e839fa54
no
peth0
virbr0
8000.feffffffffff
no
vif15.0
Any advice is appreciated.
Best Wishes.
Bei Guan