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@...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@...49....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@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main