lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Unix port does not work on Ubuntu 14.04


From: Edgar Bonet
Subject: [lwip-users] Unix port does not work on Ubuntu 14.04
Date: Mon, 04 May 2015 10:01:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Hello every one!

I am new to lwIP and to this list. Right now I am just trying to get the
Unix port work on my box (Ubuntu 14.04 on x86_64) in order to get
started with lwIP. My understanding is that echop (minimal project) and
unixsim (the development platform, according to the README) are good
starting points... but I am struggling to get these work.

What I did is basically the following:

    # Get a development snapshot
    git clone --depth 1 git://git.sv.gnu.org/lwip.git
    git clone --depth 1 git://git.sv.gnu.org/lwip/lwip-contrib.git

    # First, try the minimal project
    cd lwip-contrib/ports/unix/proj/minimal
    make  # -> fail
    # fix the compile errors
    make  # -> success
    sudo ./echop  # test -> fail

    # Next, try simhost
    cd ../unixsim
    make  # -> fail
    # fix the compile errors
    make  # -> success
    sudo ./simhost  # test -> fail

As shown above, I had to edit a few files in order to get this compile.
Here is the list of the edits, as patches attached to this message:

  * patches to lwip:

    + define-fd-set-val.patch:
        In src/include/lwip/sockets.h, define FD_SET_VAL() if needed. Do
        not assume defined(FD_SET) implies defined(FD_SET_VAL).

    + const-mib_node.patch
        In src/core/snmp/mib2.c, add a const qualifier to a struct
        mib_node* array. This array is used to initialize a struct
        mib_array_node which requires the qualifier.

  * patches to lwip-contrib:

    + contrib-const-mib_node.patch
        Same as above, but for several arrays in
        apps/snmp_private_mib/lwip_prvmib.c.

    + snmp_set_stuff-nbargs.patch
        In ports/unix/proj/minimal/main.c, call snmp_set_syscontact()
        and snmp_set_syslocation() with the proper number of arguments
        (3 instead of 2).

Now that it compiles, the results of my tests are the following:

  * Both echop and simhost create a tap0 interface bound to
    192.168.0.1/24 on the Linux side. Both display, upon startup, the
    message:

        Host at 192.168.0.2 mask 255.255.255.0 gateway 192.168.0.1

    Both respond to arp and ping requests to 192.168.0.2. However, TCP
    connection requests (on port 7 for echop and port 80 for simhost)
    are not answered. According to Wireshark, the SYN packets are just
    silently dropped.

  * On echop, the -d (debug) option has no effect. On simhost, this
    same option triggers a very verbose output. When simhost receives a
    TCP SYN while in verbose mode, it outputs

        ip_route: No route to 192.168.0.1

    This makes little sense to me: 192.168.0.1 is on the same local net
    (192.168.0.0/24) than simhost itself, how come it cannot find the
    route?

  * Stracing echop shows that it reads all the incoming packets from
    /dev/net/tun and writes the replies (arp and ping) to the same
    special file. Nothing is written in response to TCP SYNs.

Now I come with a lot of questions: Is this the proper venue to get help
on debugging all this? Should I go to lwip-devel instead? What should I
do with my patches? Should I open a bug on the savannah bug tracker for
each of them? If so, should I attach the patch to the bug or put it on
the patch tracker instead? Anyone an idea on how to debug the "No route
to 192.168.0.1" problem? Anyone managed to get this Unix port working on
a Debian-like system?

Oh, BTW, I also tried the 1.4.1 release: simhost works fine on that
version (after applying a different set of patches to make it compile):
I can see a nice web page on http://192.168.0.2/ . echop does not work.

Regards,

Edgar Bonet.

PS: This is the second time I am sending this message. First time was
last Thursday, and it did not get through. At this point I assume it has
been dropped, not just delayed. This time I am omitting the patches that
where originally attached, on the assumption that the list server may
just be filtering out any message with attachments.



reply via email to

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