Questions about the Nic_bridge and VirtualBox bug

Fri Jun 3 08:05:20 CEST 2016

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

> 
> 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
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> 
> 
> 
> _______________________________________________
> 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/