Custom Query (16363 matches)
Results (1816 - 1818 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #8669 | duplicate | 32bit color problem w/ Windows GUEST guest additions... | ||
| Description |
Program that has worked perfectly in previous VirtualBox versions
Problem is with Windows Guest Additions > 4.0.0
Program is : "NeoPaint for Windows" version 4.7c
System is as follows:
Dell XPS 420 (Custom Modified)
VBOX : 4.0.4
If you need more information, just ask. JeZ+Lee |
|||
| #12984 | obsolete | [4.3.10]-Linux Host-Windows XP/7 Guest-OpenGL Problems? | ||
| Description |
Hi, Running current VirtualBox version 4.3.10 on a Kubuntu 14.04 64Bit fully updated Host with both a Microsoft XP Pro 32Bit SP3 Guest and a Microsoft Windows 7 Ultimate 64Bit SP1 Guest. I've installed Windows Guest Guest Additions to both Virtual Machines. Problem in both with OpenGL hardware accelerated games. I made a post on the forums here: https://forums.virtualbox.org/viewtopic.php?f=2&t=61379 I've attached a photo to this bug report too. This is a regression bug, as downgrading to VirtualBox version 4.1.32 solves the issue. Jesse |
|||
| #14055 | duplicate | UDP source port changes, breaking VPN connections | ||
| Description |
I am having a problem very similar to the one described in #6667, except that it's on OSX using official packages version 4.3.26. After discussion of a disconnect problem I was having with the OpenVPN developers, they believed the issue could lie with the VM NAT stack. They suggested capturing traffic on the OpenVPN server and indeed, when I did so I could see that in the middle of a connection (running rsync between two VMs via the server) the UDP source port for the VPN connection suddenly changed: ... 20:46:59.274161 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.274547 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.274555 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.276917 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445 20:46:59.277719 IP 172.19.45.154.59878 > 172.27.102.152.443: UDP, length 1445 20:46:59.277993 IP 172.19.45.154.59878 > 172.27.102.152.443: UDP, length 1445 ... When this happens, of course, the VPN software thinks the old connection has died, and eventually times out and disconnects. At this point I can trigger the problem extremely reliably by rsyncing files over the VPN connection -- it will happen within a minute. This suggests to me that what's triggering this problem is either the total data rate back and forth through the NAT stack or some total number of packets or bytes through the NAT stack. That, or for some reason at some point the NAT stack stops correctly tracking the connection, decides that it's a new connection, and gives it a new outbound port. Just my guesses. |
|||

