Re: [lwip-users] Testing the internet app based on lwIP-1.3.0 and Mini-OS

[Bei Guan]

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?


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.

struct ip_addr listenaddr = { 0 };
rc = netconn_bind(listener, &listenaddr, 13);

In my client, API netconn_connect() is used to connect to the server. 

struct ip_addr addr = { 0 };
rc = netconn_connect(conn, &addr, 13);
if (rc != ERR_OK) {
        tprintk("Failed to connect the server: %i\n", rc);
        return;
}

But always I get the output message: 
[client] Failed to connect the server: -4

The data caught 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
16:57:08.630688 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>
16:57:11.381259 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>
16:57:14.381926 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>
16:57:17.382615 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>
16:57:20.383156 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>
16:57:23.383607 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>
16:57:26.384046 IP 0.0.0.0.4097 > 0.0.0.0.13: S 6509:6509(0) win 2048 <mss 1500>

So is there anything error in the my operations? Why the netconn_connect function always return error value -4 ?


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?


The last question. Does the lwIP provide the API to show the OS's (such as Mini-OS) arp table list? Because If the situation mentioned above happened, I want to know whether the Mini-OS own a correct arp table.


Thank you very much!
Best Wishes!

Bei Guan

2010/10/15 David Empson <address@hidden>

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 -----

From: Bei Guan

To: address@hidden

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

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users