Hey folks,
I'm having some trouble with the nic_bridge provided. When using the nic_drv as single instance, everything works fine.
But when I replace it with the nic_bridge, the requests don't seem to make it through. In qemu's TCP dump, I recognized a difference regarding the DHCP broadcast:
13:08:25.494579 IP (tos 0x0, ttl 64, id 5118, offset 0, flags [none], proto UDP (17), length 341) 0.0.0.0.68 > 255.255.255.255.67: [bad udp cksum 0x9134 -> 0xd233!] BOOTP/DHCP, Request from 02:02:02:02:02:02, length 313, xid 0x292e1940, Flags [Broadcast] (0x8000) Client-Ethernet-Address 02:02:02:02:02:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 42: "dhcpcd-5.2.7:Linux-3.5.0:i686:NOVA microHV" Hostname Option 12, length 2: "vm" Parameter-Request Option 55, length 15: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, NTP, Lease-Time, Server-ID RN, RB, Option 119
The bad checksum irritated me. When I used the nic_drv session, it worked (checksum OK, qemu's DHCP responds correctly with an IP address). Could there be a problem with the bridge itself or is it definitely my problem? Do you have example setups using the bridge that work?
Best,
Markus
I confirm this problem. Although I was using VMware, and it could only be reproduced on some physical machines, and worked perfectly on others. DHCP just didn't get through.
14.09.2012, в 16:38, Markus Partheymueller <mail@...119...> написал(а):
Hey folks,
I'm having some trouble with the nic_bridge provided. When using the nic_drv as single instance, everything works fine.
But when I replace it with the nic_bridge, the requests don't seem to make it through. In qemu's TCP dump, I recognized a difference regarding the DHCP broadcast:
13:08:25.494579 IP (tos 0x0, ttl 64, id 5118, offset 0, flags [none], proto UDP (17), length 341) 0.0.0.0.68 > 255.255.255.255.67: [bad udp cksum 0x9134 -> 0xd233!] BOOTP/DHCP, Request from 02:02:02:02:02:02, length 313, xid 0x292e1940, Flags [Broadcast] (0x8000) Client-Ethernet-Address 02:02:02:02:02:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 42: "dhcpcd-5.2.7:Linux-3.5.0:i686:NOVA microHV" Hostname Option 12, length 2: "vm" Parameter-Request Option 55, length 15: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, NTP, Lease-Time, Server-ID RN, RB, Option 119
The bad checksum irritated me. When I used the nic_drv session, it worked (checksum OK, qemu's DHCP responds correctly with an IP address). Could there be a problem with the bridge itself or is it definitely my problem? Do you have example setups using the bridge that work?
Best,
Markus
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I just used a dirty hack which set the udp checksum to 0 in the nic_bridge and DHCP worked. But now I can't ping the qemu gateway anymore, which was possible with just using the nic_drv. tcpdump shows that qemu replies, but the reply doesn't come through. It seems to me that the bridging has some problems.
On 14 September 2012 16:29, Alexander Domo <domo@...62...> wrote:
I confirm this problem. Although I was using VMware, and it could only be reproduced on some physical machines, and worked perfectly on others. DHCP just didn't get through.
14.09.2012, в 16:38, Markus Partheymueller <mail@...119...> написал(а):
Hey folks,
I'm having some trouble with the nic_bridge provided. When using the nic_drv as single instance, everything works fine.
But when I replace it with the nic_bridge, the requests don't seem to make it through. In qemu's TCP dump, I recognized a difference regarding the DHCP broadcast:
13:08:25.494579 IP (tos 0x0, ttl 64, id 5118, offset 0, flags [none], proto UDP (17), length 341) 0.0.0.0.68 > 255.255.255.255.67: [bad udp cksum 0x9134 -> 0xd233!] BOOTP/DHCP, Request from 02:02:02:02:02:02, length 313, xid 0x292e1940, Flags [Broadcast] (0x8000) Client-Ethernet-Address 02:02:02:02:02:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 42: "dhcpcd-5.2.7:Linux-3.5.0:i686:NOVA microHV" Hostname Option 12, length 2: "vm" Parameter-Request Option 55, length 15: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, NTP, Lease-Time, Server-ID RN, RB, Option 119
The bad checksum irritated me. When I used the nic_drv session, it worked (checksum OK, qemu's DHCP responds correctly with an IP address). Could there be a problem with the bridge itself or is it definitely my problem? Do you have example setups using the bridge that work?
Best,
Markus
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Update on that:
- The DHCP problem is solved as described here: https://github.com/genodelabs/genode/issues/360 - The other problem was actually my fault.
Cheers
Markus
On 14 September 2012 16:49, Markus Partheymueller <mail@...119...> wrote:
I just used a dirty hack which set the udp checksum to 0 in the nic_bridge and DHCP worked. But now I can't ping the qemu gateway anymore, which was possible with just using the nic_drv. tcpdump shows that qemu replies, but the reply doesn't come through. It seems to me that the bridging has some problems.
On 14 September 2012 16:29, Alexander Domo <domo@...62...> wrote:
I confirm this problem. Although I was using VMware, and it could only be reproduced on some physical machines, and worked perfectly on others. DHCP just didn't get through.
14.09.2012, в 16:38, Markus Partheymueller <mail@...119...> написал(а):
Hey folks,
I'm having some trouble with the nic_bridge provided. When using the nic_drv as single instance, everything works fine.
But when I replace it with the nic_bridge, the requests don't seem to make it through. In qemu's TCP dump, I recognized a difference regarding the DHCP broadcast:
13:08:25.494579 IP (tos 0x0, ttl 64, id 5118, offset 0, flags [none], proto UDP (17), length 341) 0.0.0.0.68 > 255.255.255.255.67: [bad udp cksum 0x9134 -> 0xd233!] BOOTP/DHCP, Request from 02:02:02:02:02:02, length 313, xid 0x292e1940, Flags [Broadcast] (0x8000) Client-Ethernet-Address 02:02:02:02:02:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 42: "dhcpcd-5.2.7:Linux-3.5.0:i686:NOVA microHV" Hostname Option 12, length 2: "vm" Parameter-Request Option 55, length 15: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, NTP, Lease-Time, Server-ID RN, RB, Option 119
The bad checksum irritated me. When I used the nic_drv session, it worked (checksum OK, qemu's DHCP responds correctly with an IP address). Could there be a problem with the bridge itself or is it definitely my problem? Do you have example setups using the bridge that work?
Best,
Markus
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Markus,
thank you very much for discovering the cause! Yes, you're right parentheses make sense here ;-)
regards Stefan
On 17.09.2012 17:31, Markus Partheymueller wrote:
Update on that:
- The DHCP problem is solved as described here:
https://github.com/genodelabs/genode/issues/360
- The other problem was actually my fault.
Cheers
Markus
On 14 September 2012 16:49, Markus Partheymueller <mail@...119...> wrote:
I just used a dirty hack which set the udp checksum to 0 in the nic_bridge and DHCP worked. But now I can't ping the qemu gateway anymore, which was possible with just using the nic_drv. tcpdump shows that qemu replies, but the reply doesn't come through. It seems to me that the bridging has some problems.
On 14 September 2012 16:29, Alexander Domo <domo@...62...> wrote:
I confirm this problem. Although I was using VMware, and it could only be reproduced on some physical machines, and worked perfectly on others. DHCP just didn't get through.
14.09.2012, в 16:38, Markus Partheymueller <mail@...119...> напиÑал(а):
Hey folks,
I'm having some trouble with the nic_bridge provided. When using the nic_drv as single instance, everything works fine.
But when I replace it with the nic_bridge, the requests don't seem to make it through. In qemu's TCP dump, I recognized a difference regarding the DHCP broadcast:
13:08:25.494579 IP (tos 0x0, ttl 64, id 5118, offset 0, flags [none], proto UDP (17), length 341) 0.0.0.0.68 > 255.255.255.255.67: [bad udp cksum 0x9134 -> 0xd233!] BOOTP/DHCP, Request from 02:02:02:02:02:02, length 313, xid 0x292e1940, Flags [Broadcast] (0x8000) Client-Ethernet-Address 02:02:02:02:02:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 42: "dhcpcd-5.2.7:Linux-3.5.0:i686:NOVA microHV" Hostname Option 12, length 2: "vm" Parameter-Request Option 55, length 15: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, NTP, Lease-Time, Server-ID RN, RB, Option 119
The bad checksum irritated me. When I used the nic_drv session, it worked (checksum OK, qemu's DHCP responds correctly with an IP address). Could there be a problem with the bridge itself or is it definitely my problem? Do you have example setups using the bridge that work?
Best,
Markus
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Alexander Domo -
Markus Partheymueller -
Stefan Kalkowski