Questions about the Nic_bridge and VirtualBox bug

[Charles HH]

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

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

Regards,
Charles

On Thu, May 26, 2016 at 1:12 PM, Stefan Kalkowski <
stefan.kalkowski at ...1...> wrote:

> Hello Charles,
>
> On 05/13/2016 06:19 PM, Charles HH wrote:
> > Hi,
> >
> > I've been experimenting with the nic_bridge a bit, and I came upon
> several
> > problems/questions.
> > First, when trying to connect a Linux VM through the bridge, it failed to
> > obtain a IP from the DHCP server. I invistigated a little : the Discover
> > packet get through, but the Offer is never transmitted to the client. The
> > config shouldn't be the problem, considering the network worked fine with
> > static IPs. I'm not sure if it is the origin of the issue, but the
> handling
> > of the offer packet in nic.cc failed to parse the DHCP options (by adding
> > debug prints in the option() function in dhcp.h, I saw that it got the
> > first one right with the correct length 4, but then jumped 6 octet
> instead
> > for the next option code).
>
> Parsing the DHCP responses and interpreting the option fields is done
> hardcoded within the nic_bridge. I would wonder if those field
> descriptions that are always used by it from dhcp.h should be wrong. As
> we use the nic_bridge permanently, and also used it in context of
> virtualization mechanisms provided by seoul and virtualbox, the
> hardcoded offsets should fail in our scenarios too.
>
> However, its difficult for me to actually understand the possibly wrong
> behavior taken your description. Are you sure that the nic_bridge really
> processes DHCP offer packets, did you used e.g., wireshark to validate
> that the offer packet is actually received via your test-machine? Are
> you using some weird combination of virtualization techniques underneath
> your Genode setup, or is it running on bare hardware?
>
> >
> > I was also wondering if it would be possible to use several bridges in
> > cascade. If I understand correctly, each Nic session opened on the bridge
> > has an assigned mac address, but would it be feasible to use a single
> > session for a sort of subnetwork?
>
> I would discourage you from using the nic_bridge in a cascade. Even if
> it works properly you do not win anything apart from performance
> degradation. The NIC bridge provides multiple sessions of the 'Nic'
> service while using a single 'Nic' session for forwarding requests. It
> implements a flavor of the Proxy-ARP protocol (RFC 1027). That means it
> allocates a virtual MAC address for each client. Whenever a client sends
> a packet, NIC bridge changes the sender's MAC address to the one it
> memorized for the client. Moreover, it monitors DHCP packets, and tracks
> the IP addresses assigned to each of its clients. Whenever
> ARP packets come from the outside, NIC bridge will answer them with the
> corresponding MAC address. Therefore, when you use cascade NIC bridges
> you do not cover the different clients, each client has a visible MAC
> address anyway that can be seen "on the wire". If you want to cover that
> multiple IP stacks are using the same MAC/IP you have to implement NAT,
> which is aimed according to our roadmap to be released soon. You can
> follow or participate in the discussion here:
>
> >
> > Finally, the recent commits on master (between the 04-11 and the 04-25)
> > have broken my vbox scenario : virtual box refuses to access
>
> Sorry, I have no clue why this happening. Maybe somebody more into
> VirtualBox scenarios can help you.
>
> Regards
> Stefan
>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Mobile security can be enabling, not merely restricting. Employees who
> > bring their own devices (BYOD) to work are irked by the imposition of MDM
> > restrictions. Mobile Device Manager Plus allows you to control only the
> > apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >
> >
> >
> > _______________________________________________
> > genode-main mailing list
> > genode-main at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/genode-main
> >
>
> --
> Stefan Kalkowski
> Genode Labs
>
> http://www.genode-labs.com/ · http://genode.org/
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20160601/92da191d/attachment.html>