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