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