Hi Stefan,

Sorry for the delay. The following diff should be enough to explain the issue :

diff --git a/repos/os/include/net/dhcp.h b/repos/os/include/net/dhcp.h
index da492d0..ea8e712 100644
--- a/repos/os/include/net/dhcp.h
+++ b/repos/os/include/net/dhcp.h
@@ -22,6 +22,7 @@
 #include <net/ethernet.h>
 #include <net/ipv4.h>
 #include <net/udp.h>
+#include <base/printf.h>
 
 namespace Net { class Dhcp_packet; }
 
@@ -215,6 +216,7 @@ class Net::Dhcp_packet
             void *ptr = &_opts;
             while (true) {
                 Option *ext = new (ptr) Option();
+                PLOG("DHCP Option : %d %d", (int)ext->code(), (int)ext->length());
                 if (ext->code() == op)
                     return ext;
                 if (ext->code() == END || ext->code() == 0)
diff --git a/repos/os/src/server/nic_bridge/nic.cc b/repos/os/src/server/nic_bridge/nic.cc
index 949f5a1..389d4ce 100644
--- a/repos/os/src/server/nic_bridge/nic.cc
+++ b/repos/os/src/server/nic_bridge/nic.cc
@@ -79,11 +79,15 @@ bool Net::Nic::handle_ip(Ethernet_frame *eth, Genode::size_t size) {
         if (Dhcp_packet::is_dhcp(udp)) {
             Dhcp_packet *dhcp = new (udp->data())
                 Dhcp_packet(size - sizeof(Ipv4_packet) - sizeof(Udp_packet));
+            PLOG("DHCP Packet received");
 
             /* check for DHCP ACKs containing new client ips */
             if (dhcp->op() == Dhcp_packet::REPLY) {
+                PLOG("DHCP reply");
                 Dhcp_packet::Option *ext = dhcp->option(Dhcp_packet::MSG_TYPE);
+                PLOG("Got MSG_TYPE option");
                 if (ext) {
+                    PLOG("if(ext) succeeded");
                     /*
                      * extract the IP address and set it in the
                      * client's session-component
@@ -97,7 +101,7 @@ bool Net::Nic::handle_ip(Ethernet_frame *eth, Genode::size_t size) {
                         if (node)
                             node->component()->set_ipv4_address(dhcp->yiaddr());
                     }
-                }
+                } else PLOG("if(ext) failed");
             }
         }
     }

With these modifications, I get the following debug output when a DHCP Offer is received (following a request from the VM) :

[init -> nic_bridge] DHCP Packet received
[init -> nic_bridge] DHCP reply
[init -> nic_bridge] DHCP Option : 1 4
[init -> nic_bridge] DHCP Option : 172 16
[init -> nic_bridge] DHCP Option : 111 114
[init -> nic_bridge] DHCP Option : 0 0
[init -> nic_bridge] Got MSG_TYPE option
[init -> nic_bridge] if(ext) failed

While the options in the actual packet (as seen in wireshark) should be :

Option: (1) Subnet Mask
    Length: 4
    Subnet Mask: 255.255.0.0 (255.255.0.0)
Option: (3) Router
    Length: 4
    Router: 172.16.254.254 (172.16.254.254)
Option: (6) Domain Name Server
    Length: 4
    Domain Name Server: 172.16.254.253 (172.16.254.253)
Option: (12) Host Name
    Length: 23
    Host Name: #######################
Option: (15) Domain Name
    Length: 11
    Domain Name: ###########
Option: (42) Network Time Protocol Servers
    Length: 4
    Network Time Protocol Server: 172.16.254.254 (172.16.254.254)
Option: (51) IP Address Lease Time
    Length: 4
    IP Address Lease Time: (600s) 10 minutes
Option: (53) DHCP Message Type
    Length: 1
    DHCP: Offer (2)
Option: (54) DHCP Server Identifier
    Length: 4
    DHCP Server Identifier: 172.24.100.53 (172.24.100.53)
Option: (58) Renewal Time Value
    Length: 4
    Renewal Time Value: (300s) 5 minutes
Option: (59) Rebinding Time Value
    Length: 4
    Rebinding Time Value: (1800s) 30 minutes
Option: (255) End
    Option End: 255

0110                                 01 04 ff ff 00 00
0120   03 04 ac 10 fe fe 06 04 ac 10 fe fd 0c 17 ## ##
0130   ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
0140   ## ## ## ## ## 0f ## ## ## ## ## ## ## ## ## ##
0150   ## ## 2a 04 ac 10 fe fe 33 04 00 00 02 58 35 01
0160   02 36 04 ac 18 64 35 3a 04 00 00 01 2c 3b 04 00
0170   00 07 08 ff

So the first jump from option 1 to option 3 actually landed two bytes off (or elsewhere entirely but that seems unlikely). I guess the next step should be to check the memory addresses of the bytes to see why this happened... The bridge isn't really critical to my setup though anyway.

Regards,
Charles


On Fri, Jun 3, 2016 at 8:05 AM, Stefan Kalkowski <stefan.kalkowski@...52...1...> wrote:
Hi Charles,

On 06/01/2016 06:03 PM, Charles HH wrote:
> Hello Stefan,
>
> Indeed, I'm quite doubtful that the dhcp offsets are really at cause. I had
> the following setup :
> Genode running on nova, booted directly from hard disk with grub. In
> Genode, virtualbox running a ubuntu 16.04 server VM, installed on a vdi
> accessed through rump_fs.
> I launched a dhclient on the VM, and monitored the network with wireshark
> from another computer (which also listened to the serial output).
> The dhclient never received any response, but I could see from wireshark
> that the DHCP server sent an offer with the correct IP.
> So I added several PDBG checks in the nic_bridge code and saw that the DHCP
> reply was processed in Nic::handle_ip, but the if(ext) condition was never
> entered.
> Naturally, I checked dhcp->option in net/dhcp.h to see why it didn't return
> a valid pointer, and, by adding debug messages (I included base/printf.h),
> I compared the options parsed with the ones from the packet (in wireshark)
> and noticed the incorrect "jump" (despite the first option's ext->length()
> being correct). I have no idea how to proceed from there...
>

its hard to follow without knowing the exact options etc. Can you please
provide your changes (printf) in form of a diff/patch, and in addition
the log output, and tell me exactly what header is wroing by means of
the output?

> I haven't had the time to check 16.05 and see if the issue is still
> relevant though...

It might be an option, but actually the nic_bridge did not changed recently.

Regards
Stefan