Questions about the Nic_bridge and VirtualBox bug
Charles HH
charleshh.genode at ...9...
Tue Jun 14 15:19:26 CEST 2016
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 at ...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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20160614/316fb6a4/attachment.html>
More information about the users
mailing list