Discussion:
Questions about the Nic_bridge and VirtualBox bug
Charles HH
2016-05-13 16:19:23 UTC
Permalink
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).

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?

Finally, the recent commits on master (between the 04-11 and the 04-25)
have broken my vbox scenario : virtual box refuses to access
Charles HH
2016-05-13 16:22:42 UTC
Permalink
(sorry) a vdi virtual disk and reports a permission problem, but when I
revert to the previous genode version, I have no problem. Is that a known
issue or should Isend further informations?

Best regards,
Charles
Post by Charles HH
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).
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?
Finally, the recent commits on master (between the 04-11 and the 04-25)
have broken my vbox scenario : virtual box refuses to access
Stefan Kalkowski
2016-05-26 11:12:32 UTC
Permalink
Hello Charles,
Post by Charles HH
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?
Post by Charles HH
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
Post by Charles HH
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
Post by Charles HH
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/genode-main
--
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
Alexander Boettcher
2016-05-26 12:00:20 UTC
Permalink
Post by Stefan Kalkowski
Post by Charles HH
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.
Please provide the last known good git commit of master and the one
which seem to break your setup. Please provide also a branch with a run
script showing this issue, so that we may try to reproduce it.
Additionally we would need to know whether you run Genode as 32bit or
64bit host, virtualized or on native hardware, and which Guest OS you use.

Cheers,

Alex.
Charles HH
2016-06-01 16:03:36 UTC
Permalink
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 <
Post by Stefan Kalkowski
Hello Charles,
Post by Charles HH
Hi,
I've been experimenting with the nic_bridge a bit, and I came upon
several
Post by Charles HH
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
Post by Charles HH
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
Post by Charles HH
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?
Post by Charles HH
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
Post by Charles HH
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
------------------------------------------------------------------------------
Post by Charles HH
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!
Post by Charles HH
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
genode-main mailing list
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
https://lists.sourceforge.net/lists/listinfo/genode-main
Stefan Kalkowski
2016-06-03 06:05:20 UTC
Permalink
Hi Charles,
Post by Charles HH
Hello Stefan,
Indeed, I'm quite doubtful that the dhcp offsets are really at cause. I had
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?
Post by Charles HH
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
Post by Charles HH
Regards,
Charles
On Thu, May 26, 2016 at 1:12 PM, Stefan Kalkowski <
Post by Stefan Kalkowski
Hello Charles,
Post by Charles HH
Hi,
I've been experimenting with the nic_bridge a bit, and I came upon
several
Post by Charles HH
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
Post by Charles HH
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
Post by Charles HH
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?
Post by Charles HH
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
Post by Charles HH
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
------------------------------------------------------------------------------
Post by Charles HH
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!
Post by Charles HH
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
genode-main mailing list
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
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
https://lists.sourceforge.net/lists/listinfo/genode-main
--
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
Charles HH
2016-06-14 13:19:26 UTC
Permalink
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 <
Post by Stefan Kalkowski
Hi Charles,
Post by Charles HH
Hello Stefan,
Indeed, I'm quite doubtful that the dhcp offsets are really at cause. I
had
Post by Charles HH
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
Post by Charles HH
reply was processed in Nic::handle_ip, but the if(ext) condition was
never
Post by Charles HH
entered.
Naturally, I checked dhcp->option in net/dhcp.h to see why it didn't
return
Post by Charles HH
a valid pointer, and, by adding debug messages (I included
base/printf.h),
Post by Charles HH
I compared the options parsed with the ones from the packet (in
wireshark)
Post by Charles HH
and noticed the incorrect "jump" (despite the first option's
ext->length()
Post by Charles HH
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?
Post by Charles HH
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
Christian Helmuth
2016-06-14 14:25:55 UTC
Permalink
Hello Charles,

I think there is an issue in the calculation of the pointer to the
next DHCP option. Could you please try the attached patch?

Greets
--
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
GeschÀftsfÌhrer: Dr.-Ing. Norman Feske, Christian Helmuth
Charles HH
2016-06-15 09:22:01 UTC
Permalink
Hi Christian,

The patch worked. The options are now parsed correctly.
I still have a problem with the DHCP server sending the Offer to the VM mac
address (taken from the DHCP options I would assume) instead of to the
bridge. I think that's quite an unusual behavior for a DHCP server though,
so I don't think it deserves particular attention...

Thank you for your time,
Charles

On Tue, Jun 14, 2016 at 4:25 PM, Christian Helmuth <
Post by Stefan Kalkowski
Hello Charles,
I think there is an issue in the calculation of the pointer to the
next DHCP option. Could you please try the attached patch?
Greets
--
Christian Helmuth
Genode Labs
http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
GeschÀftsfÌhrer: Dr.-Ing. Norman Feske, Christian Helmuth
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/genode-main
Christian Helmuth
2016-06-15 10:30:38 UTC
Permalink
Hello Charles,
Post by Charles HH
The patch worked. The options are now parsed correctly.
Great.
Post by Charles HH
I still have a problem with the DHCP server sending the Offer to the VM mac
address (taken from the DHCP options I would assume) instead of to the
bridge. I think that's quite an unusual behavior for a DHCP server though,
so I don't think it deserves particular attention...
This may result from the simplicity of our current bridge
implementation. It may be better to implement DHCP relaying

https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_relaying

to force the DHCP server to send an unicast reply to the bridge MAC
address. Also, it may be the case that our implementation misses one
picky detail when constructing the DHCP request packet.

Regards
--
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Stefan Kalkowski
2016-06-16 12:39:20 UTC
Permalink
Thanks to Charles for reporting!
And thanks to Christian for investigating the root cause!

This is the second bug in the net/*.h files of the nic_bridge and it
indicates that we have to review these old rotten piece of network
headers. Mea culpa!

Regards
Stefan
Post by Stefan Kalkowski
Hello Charles,
Post by Charles HH
The patch worked. The options are now parsed correctly.
Great.
Post by Charles HH
I still have a problem with the DHCP server sending the Offer to the VM mac
address (taken from the DHCP options I would assume) instead of to the
bridge. I think that's quite an unusual behavior for a DHCP server though,
so I don't think it deserves particular attention...
This may result from the simplicity of our current bridge
implementation. It may be better to implement DHCP relaying
https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_relaying
to force the DHCP server to send an unicast reply to the bridge MAC
address. Also, it may be the case that our implementation misses one
picky detail when constructing the DHCP request packet.
Regards
--
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
Loading...