Custom Query (16363 matches)
Results (2350 - 2352 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #18439 | invalid | broken VRDP in 6.0.4 on AMD HW | ||||||||||
| Description |
Linux rdesktop (1.8.4) and also vinagre cannot connect to port 3389 on AMD HW. This problem does not exist on an Intel PC, but is 100% reproducible on AMD HW. When rdesktop/vinagre fail they exit with error code 76 (protocol error). I have verified that ms-wbt-server is listening on port 3389 upon failure. The log file does not show any errors. This is for a Win 7 Pro 64bit guest. |
|||||||||||
| #6996 | obsolete | brigded network stops when virtual host changes mac address | ||||||||||
| Description |
Problem: When i change the mac address in the running guest system, there is no more network connectivitiy for the guest.
I can change the MAC adress in my guest: ifconfig eth0 down ifconfig eth0 hw ether <new mac address> ifconfig eth0 up Workaround: ifconfig eth0 promisc Setting the interface into promiscous mode re-establishes network connectivity.
|
|||||||||||
| #13714 | fixed | bridged-to-wifi adapter escapes the packets with guest dst-mac | ||||||||||
| Description |
This is how it works. A simple network: (server) ---eth--- (router) ---wlan--- (laptop)
. .
.... bridge ....
HWaddr: f8:16:54:d3:13:87
ipv4: 192.168.79.75
HWaddr: 08:00:27:bb:4b:cb
ipv4: 192.168.79.76
arping(192.168.79.75) = f8:16:54:d3:13:87
arping(192.168.79.76) = f8:16:54:d3:13:87
23:11:42.080835 f8:16:54:d3:13:87 (oui Unknown) > 08:00:27:bb:4b:cb (oui Unknown), ethertype IPv4 (0x0800), length 2962: 192.168.79.75.56815 > 192.168.79.76.5001: Flags [.], seq 4516312:4519208, ack 1, win 229, options [nop,nop,TS val 48947332 ecr 109821], length 2896
23:17:43.182499 f8:16:54:d3:13:87 (oui Unknown) > 08:00:27:bb:4b:cb (oui Unknown), ethertype IPv4 (0x0800), length 66: 192.168.79.75.5001 > 192.168.79.76.55686: Flags [.], ack 125813305, win 24576, options [nop,nop,TS val 49037609 ecr 200144], length 0 I speculate the issue is that the router's bridge has no idea where 08:00:27:bb:4b:cb (guest mac) lives, and therefore it ends up broadcasting it to everyone, desperately waiting for reply, that will never come with guest mac as src mac. This effectively:
Therefore, I believe this is a major defect that should be fixed. I further speculate this is because VirtualBox's bridge adapter sends the packets with "dst mac" == "guest mac" both to the guest and into the external network, that has no other alternative than to broadcast it. |
|||||||||||

