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.kalkow...@genode-labs.com> 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@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@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
