Re: [gentoo-user] Re: OT: SeAndroid build on a Gentoo System?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.02.2012 16:23, James wrote: Hinnerk van Bruinehsen h.v.bruinehsen at fu-berlin.de writes: I own a Galaxy Nexus - up to now I encountered a bug in finding the tools.jar of JDK (Google helped here) and a problem due to the fact that I use hardened for building (TEXTREL, I think). I'll try a stage 3 non hardened chroot later... How do you like the G. Nexus so far? Who is your (cell) service provider? I'm not sure I posted this link: http://marc.info/?l=selinuxr=1b=201201w=4 Note. Russell Coker (dev for SElinux and SEandroid) is very cool and has his up and running on Debian (Wheezy). If you get stuck, you can search him out for help. In my experiences with Russell, he is very friendly and helpful, particularly on the last thingy he is focused on, like SEandroid. thanks for keeping me posted, James It seems as if I'm not able to setup a proper build-environment with hardened (due to chroot hardening the chroot isn't an option, either). I'll try to find time to test it on a non-hardened host or in a vm (which seems like a bad option, too, due to hardened restrictions). If I get any further, I'll try to post some updates. Concerning the phone: I'm very happy with it, as it is. It's a big upgrade from my old Wildfire. My cell service provider is Vodafone (Germany). With kind regards, Hinnerk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPNNDQAAoJEJwwOFaNFkYcfdQIAI/xLQkTveIxvRuJw4BYelFr nQ01IFPla+1mjMu30DWoW7dY4O++tdheRxhKKAz7jEA+e54g8mrxDaIs70bealiP p0IMRp1OGtxW7hj/BABGk5Gab91iH6aq6BWi7eeEuw47W24UuYUHJHiJiD7GZMiY /APTZxiaw82xLvfKJz3OEtC9Qiaruf9u4jRKP3GMRqpdG+8fSkX6zXvO1s8n45H3 gYaMyofIi/9KvC8qIhfrK+ODA+2xloyhV5d2lI5WIoMhgQ77KKC0TseRoGK8h9vC 68xJnmDnySLBm1RAMIJMFOJ8GIC97HNR/0TJFovo0bQSFBgZerAAFtUn2/aAjkM= =Xupa -END PGP SIGNATURE-
Re: [gentoo-user] (s)mplayer problems
On 02/08/2012 03:04:50 PM, Carlos Hendson wrote: On Wed, 2012-02-08 at 14:40 +0100, Helmut Jarausch wrote: On 02/08/2012 02:07:55 PM, Nilesh Govindrajan wrote: On Wed 08 Feb 2012 06:31:19 PM IST, Helmut Jarausch wrote: Hi, I need some advice. Since a short time I have tremendous problems with mplayer / smplayer and I don't know why. First, vlc works just fine, i.e. video and audio Second, mplayer produces a segment fault within fglrx (ati- drivers-12.1-r1 with gentoo-sources-3.2.x) Third, smplayer does show the video (without a segment fault) but doesn't play audio. How can I isolate the problem? Many thanks for a hint, Helmut. Run mplayer on the command line and see what error it throws. Paste it here. Unfortunately, that's impossible. mplayer starts, opens a window and then segfaults, i.e. kills Xorg and forces me to reboot the machine. Xorg.0.log.old shows Backtrace: [ 1669.886] 0: /usr/bin/X (xorg_backtrace+0x26) [0x564f86] [ 1669.886] 1: /usr/bin/X (0x40+0x168bc9) [0x568bc9] [ 1669.886] 2: /lib64/libpthread.so.0 (0x7fa7aa5f4000+0x10ff0) [0x7fa7aa604ff0] [ 1669.887] 3: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (xs111LookupPrivate+0x22) [0x7fa7a778c372] [ 1669.887] 4: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (xclLookupPrivate+0xd) [0x7fa7a7167cdd] [ 1669.887] 5: /usr/lib64/xorg/modules/amdxmm.so (X740XvPutImage +0x12e) [0x7fa7a441f81e] [ 1669.887] 6: /usr/bin/X (0x40+0x8a84e) [0x48a84e] [ 1669.888] 7: /usr/lib64/xorg/modules/extensions/libextmod.so (0x7fa7a83f8000+0xf53e) [0x7fa7a840753e] [ 1669.888] 8: /usr/bin/X (0x40+0x36979) [0x436979] [ 1669.888] 9: /usr/bin/X (0x40+0x2613a) [0x42613a] [ 1669.888] 10: /lib64/libc.so.6 (__libc_start_main+0xed) [0x7fa7a952b3cd] [ 1669.888] 11: /usr/bin/X (0x40+0x2645d) [0x42645d] [ 1669.888] Segmentation fault at address 0x20 Thanks, Helmut. Did you read this and follow the advice to work around Xv as mentioned in the elog? This release of ati-drivers has a crashing bug when using Xv video. To avoid this problem, configure your video playback software for OpenGL output. See https://bugs.gentoo.org/show_bug.cgi?id=391193 Many thanks, the workaround mentioned in this link fixes the segment fault. Still, audio doesn't work, yet. Helmut.
Re: [gentoo-user] (s)mplayer problems
On Fri, 2012-02-10 at 09:31 +0100, Helmut Jarausch wrote: Many thanks, the workaround mentioned in this link fixes the segment fault. Still, audio doesn't work, yet. It seems mplayer doesn't have the codec required for the WMV format. You should check mplayer has the win32codecs use flag enabled. You can do this with equery or eix (or other equivalent tools). equery uses mplayer eix mplayer Use the information from the the wiki to help you pick the right flags and required packages: http://en.gentoo-wiki.com/wiki/MPlayer For example, the mplayer output posted in another message has the text: Xlib: extension NV-GLX missing on display :0. [vdpau] Error when calling vdp_device_create_x11: 1 The use flag description for vdpau says: + + vdpau : Enables experimental VDPAU support (requires nVidia video cards) to offload MPEG2/MPEG4/VC1/WMV CPU processing to video card Since you have an ATI graphics card in this machine, you can safely disable the vdpau use flag. Hope that helps. Regards, Carlos
Re: [gentoo-user] KMail
On Friday 10 Feb 2012 03:23:11 Frank Steinmetzger wrote: On Thu, Feb 09, 2012 at 06:33:12PM -0500, Daniel D Jones wrote: I was one of those bitten by the upgrade to KMail back in October. After spending nearly two days without access to email while trying to get the upgrade and migration to work, I gave up and pinned KMail to version 4.4.11.1. With the recent upgrade to KDE, I'm curious if anyone knows whether the bugs have been worked out and the KMail upgrade will go smoother now? I tried it as soon as the 4.8 upgrade was done. After I added an IMAP resource, it didn't show up in the folder pane, although its folders were listed in the dialog where one can select folder subscriptions (right click in folder pane→Manage local subscriptions). I have no interest right now to bother with it, I became fairly happy with mutt. ^^ Does anyone know if this fork is offering a KDEPIM that actually works? http://www.trinitydesktop.org/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Friday 10 Feb 2012 04:42:51 Pandu Poluan wrote: On Fri, Feb 10, 2012 at 10:48, Pandu Poluan pa...@poluan.info wrote: Scenario: I have a server in the cloud that needs to connect to an internal server in the office. There are 2 incoming connections into my office, ISP A and ISP B. The primary connection is A, but if A goes down, we can use B. The app running on the cloud server has no automatic failover ability (i.e., if A goes down, someone must change the app's conf to point to B). My thought: If I can make a tunnel from the server to the FortiGate firewall currently guarding the HQ, the cloud app can simply be configured to connect to the internal IP address of the internal server. No need to manually change the app's conf. The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. + has automatic failover and failback ability Right, I don't know if one exists with this functionality - because this is not a typical VPN function but one offered by load balancers/fall back servers or routers. *solutions involving iptables and iproute2 are also acceptable I am convinced that you can do that by clever enough routing on a linux box, but cannot recall where I last read about it. Can anyone point me to the right direction re: what package and the relevant howto? Thanks in advance. I have been doing some research, and... Do you think I can do that using HAProxy running in tcp mode? My thought goes like this: Have the cloud app connect the IP:port of HAProxy, and let HAProxy perform a TCP proxy (NAT?) to connect to the internal server via A or B according to the server checks. I haven't used HAProxy, but would consider setting up a fallback route at the HQ router end. This is also called a failover configuration. The router pings one address, say ISP A and if that fails more than x times over y pings then it switches over the connection to ISP B. This keeps it at a lower level in the OSI model, which is less complicated and therefore easier to manage. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Recommended VPN Tunnel client?
On Thu, Feb 9, 2012 at 10:48 PM, Pandu Poluan pa...@poluan.info wrote: Scenario: I have a server in the cloud that needs to connect to an internal server in the office. There are 2 incoming connections into my office, ISP A and ISP B. The primary connection is A, but if A goes down, we can use B. The app running on the cloud server has no automatic failover ability (i.e., if A goes down, someone must change the app's conf to point to B). My thought: If I can make a tunnel from the server to the FortiGate firewall currently guarding the HQ, the cloud app can simply be configured to connect to the internal IP address of the internal server. No need to manually change the app's conf. The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* + has automatic failover and failback ability *solutions involving iptables and iproute2 are also acceptable Can anyone point me to the right direction re: what package and the relevant howto? Thanks in advance. Rgds, Not exactly what you're looking for, but this might help: http://www.ntop.org/products/n2n/ That would set up reliable visibility on layer 2. You probably want to employ something like 802.1x on top of it. -- :wq
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Feb 10, 2012 10:08 PM, Mick michaelkintz...@gmail.com wrote: On Friday 10 Feb 2012 04:42:51 Pandu Poluan wrote: On Fri, Feb 10, 2012 at 10:48, Pandu Poluan pa...@poluan.info wrote: Scenario: I have a server in the cloud that needs to connect to an internal server in the office. There are 2 incoming connections into my office, ISP A and ISP B. The primary connection is A, but if A goes down, we can use B. The app running on the cloud server has no automatic failover ability (i.e., if A goes down, someone must change the app's conf to point to B). My thought: If I can make a tunnel from the server to the FortiGate firewall currently guarding the HQ, the cloud app can simply be configured to connect to the internal IP address of the internal server. No need to manually change the app's conf. The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. + has automatic failover and failback ability Right, I don't know if one exists with this functionality - because this is not a typical VPN function but one offered by load balancers/fall back servers or routers. *solutions involving iptables and iproute2 are also acceptable I am convinced that you can do that by clever enough routing on a linux box, but cannot recall where I last read about it. Can anyone point me to the right direction re: what package and the relevant howto? Thanks in advance. I have been doing some research, and... Do you think I can do that using HAProxy running in tcp mode? My thought goes like this: Have the cloud app connect the IP:port of HAProxy, and let HAProxy perform a TCP proxy (NAT?) to connect to the internal server via A or B according to the server checks. I haven't used HAProxy, but would consider setting up a fallback route at the HQ router end. This is also called a failover configuration. The router pings one address, say ISP A and if that fails more than x times over y pings then it switches over the connection to ISP B. HAproxy seems to be able to do that. It can check for A's status, and failover to B if A is down, but still keep checking for A to come up; and if A indeed comes back up, perform a failback to A. (I haven't actually tested this, just some informed guess based on its documentation) This keeps it at a lower level in the OSI model, which is less complicated and therefore easier to manage. HAproxy seems to work using double NAT technique (i.e., apps connect to HAproxy, and HAproxy connects to the actual destination) It's decidedly more complex than a route change, but according to its developer, more reliable (plus it employs some TCP tricks to optimize the connection) I'll post more info when I actually have done experience with it. Rgds,
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On 02/10/12 11:46, Pandu Poluan wrote: On Feb 10, 2012 10:08 PM, Mick michaelkintz...@gmail.com mailto:michaelkintz...@gmail.com wrote: The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. I must have missed the original message. OpenVPN can do this. Just specify multiple remote vpn.example.com lines in your client configs, one for each VPN server. It also handles updating the routing table for you. Rather than match IP address of internal server, it will match IP address on internal network and route through the VPN automatically.
Re: [gentoo-user] Re: OT: SeAndroid build on a Gentoo System?
On Feb 10, 2012 3:13 PM, Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.02.2012 16:23, James wrote: Hinnerk van Bruinehsen h.v.bruinehsen at fu-berlin.de writes: I own a Galaxy Nexus - up to now I encountered a bug in finding the tools.jar of JDK (Google helped here) and a problem due to the fact that I use hardened for building (TEXTREL, I think). I'll try a stage 3 non hardened chroot later... How do you like the G. Nexus so far? Who is your (cell) service provider? I'm not sure I posted this link: http://marc.info/?l=selinuxr=1b=201201w=4 Note. Russell Coker (dev for SElinux and SEandroid) is very cool and has his up and running on Debian (Wheezy). If you get stuck, you can search him out for help. In my experiences with Russell, he is very friendly and helpful, particularly on the last thingy he is focused on, like SEandroid. thanks for keeping me posted, James It seems as if I'm not able to setup a proper build-environment with hardened (due to chroot hardening the chroot isn't an option, either). I'll try to find time to test it on a non-hardened host or in a vm (which seems like a bad option, too, due to hardened restrictions). If I get any further, I'll try to post some updates. Concerning the phone: I'm very happy with it, as it is. It's a big upgrade from my old Wildfire. My cell service provider is Vodafone (Germany). With kind regards, Hinnerk There are grsec knobs in sysctl that you can temporarily disable to weaken chroot for awhile. aW simple reboot will return these knobs to its default secure settings. (There's a thread I started when I have trouble doing things in a chroot, and the solution was to temporarily stable done grkernelsec features before going into chroot) Rgds,
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Feb 11, 2012 12:16 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 02/10/12 11:46, Pandu Poluan wrote: On Feb 10, 2012 10:08 PM, Mick michaelkintz...@gmail.com mailto:michaelkintz...@gmail.com wrote: The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. I must have missed the original message. OpenVPN can do this. Just specify multiple remote vpn.example.com lines in your client configs, one for each VPN server. It also handles updating the routing table for you. Rather than match IP address of internal server, it will match IP address on internal network and route through the VPN automatically. I'm still torn between OpenVPN and HAproxy. The former works with both TCP and UDP, while the latter is lighter and simpler but works with TCP only*. *The traffic will be pure TCP, but who knows I might need a UDP tunnel in the future. Any experience with either? Do note that I don't actually need a strong security (e.g. IPsec); I just need automatic failover *and* fallback. Rgds,
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Fri, Feb 10, 2012 at 12:29 PM, Pandu Poluan pa...@poluan.info wrote: On Feb 11, 2012 12:16 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 02/10/12 11:46, Pandu Poluan wrote: On Feb 10, 2012 10:08 PM, Mick michaelkintz...@gmail.com mailto:michaelkintz...@gmail.com wrote: The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. I must have missed the original message. OpenVPN can do this. Just specify multiple remote vpn.example.com lines in your client configs, one for each VPN server. It also handles updating the routing table for you. Rather than match IP address of internal server, it will match IP address on internal network and route through the VPN automatically. I'm still torn between OpenVPN and HAproxy. The former works with both TCP and UDP, while the latter is lighter and simpler but works with TCP only*. *The traffic will be pure TCP, but who knows I might need a UDP tunnel in the future. Any experience with either? Do note that I don't actually need a strong security (e.g. IPsec); I just need automatic failover *and* fallback. We're not using multiple internet connections to the same network where I work, but we do use UDP-based OpenVPN to connect a few networks. TCP OpenVPN connections are very, very bad, IMO. With a TCP VPN, you easily break systems' TCP stacks' link bandwidth estimation. I once had a 30s ping time, because the pipe was hogged and backlogged from a mail client synchronizing. -- :wq
[gentoo-user] Re: OT: SeAndroid build on a Gentoo System?
Hinnerk van Bruinehsen h.v.bruinehsen at fu-berlin.de writes: If I get any further, I'll try to post some updates. Very cool! thanks for the feedback. James
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Feb 11, 2012 12:42 AM, Michael Mol mike...@gmail.com wrote: On Fri, Feb 10, 2012 at 12:29 PM, Pandu Poluan pa...@poluan.info wrote: On Feb 11, 2012 12:16 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 02/10/12 11:46, Pandu Poluan wrote: On Feb 10, 2012 10:08 PM, Mick michaelkintz...@gmail.com mailto:michaelkintz...@gmail.com wrote: The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. I must have missed the original message. OpenVPN can do this. Just specify multiple remote vpn.example.com lines in your client configs, one for each VPN server. It also handles updating the routing table for you. Rather than match IP address of internal server, it will match IP address on internal network and route through the VPN automatically. I'm still torn between OpenVPN and HAproxy. The former works with both TCP and UDP, while the latter is lighter and simpler but works with TCP only*. *The traffic will be pure TCP, but who knows I might need a UDP tunnel in the future. Any experience with either? Do note that I don't actually need a strong security (e.g. IPsec); I just need automatic failover *and* fallback. We're not using multiple internet connections to the same network where I work, but we do use UDP-based OpenVPN to connect a few networks. TCP OpenVPN connections are very, very bad, IMO. With a TCP VPN, you easily break systems' TCP stacks' link bandwidth estimation. I once had a 30s ping time, because the pipe was hogged and backlogged from a mail client synchronizing. No, no, no. What I meant was running TCP and UDP *on top of* OpenVPN (which uses UDP). HAproxy seems to be able to perform its magic with TCP connections. Rgds,
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Fri, Feb 10, 2012 at 1:05 PM, Pandu Poluan pa...@poluan.info wrote: On Feb 11, 2012 12:42 AM, Michael Mol mike...@gmail.com wrote: On Fri, Feb 10, 2012 at 12:29 PM, Pandu Poluan pa...@poluan.info wrote: On Feb 11, 2012 12:16 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 02/10/12 11:46, Pandu Poluan wrote: On Feb 10, 2012 10:08 PM, Mick michaelkintz...@gmail.com mailto:michaelkintz...@gmail.com wrote: The need: a VPN client that: + can selectively send packets fulfilling a criteria (in this case, dest= IP address of internal server)* As far as I know typical VPNs require the IP address (or FQDN) of the VPN gateway. If yours changes because ISP A goes down then the tunnel will fail and be torn down. I must have missed the original message. OpenVPN can do this. Just specify multiple remote vpn.example.com lines in your client configs, one for each VPN server. It also handles updating the routing table for you. Rather than match IP address of internal server, it will match IP address on internal network and route through the VPN automatically. I'm still torn between OpenVPN and HAproxy. The former works with both TCP and UDP, while the latter is lighter and simpler but works with TCP only*. *The traffic will be pure TCP, but who knows I might need a UDP tunnel in the future. Any experience with either? Do note that I don't actually need a strong security (e.g. IPsec); I just need automatic failover *and* fallback. We're not using multiple internet connections to the same network where I work, but we do use UDP-based OpenVPN to connect a few networks. TCP OpenVPN connections are very, very bad, IMO. With a TCP VPN, you easily break systems' TCP stacks' link bandwidth estimation. I once had a 30s ping time, because the pipe was hogged and backlogged from a mail client synchronizing. No, no, no. What I meant was running TCP and UDP *on top of* OpenVPN (which uses UDP). HAproxy seems to be able to perform its magic with TCP connections. That's what I was talking about. Where I work, we use OpenVPN, operating in UDP mode. This is after several bad experiences using it in TCP mode. By UDP mode and TCP mode, I mean OpenVPN's connections to other OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's connections operate over TCP (and thus it gets guarantee'd delivery), you can create a situation where a tunneled TCP connection attempts to push data faster than your Internet connection can allow because it never gets any congestion feedback; OpenVPN was accepting packets faster than it could shove them through, and was buffering the rest. In the situation I encountered, I was syncing my email over the vpn, but I couldn't quickly reach any internal services; their response time got slower and slower until I bounced my openvpn daemon (breaking any outstanding tunneled TCP connections), but then they rapidly degraded again. Towards the end, I discovered I had a non-tunneled ping time of 100 ms, but a tunneled ping time of 30m. If HAProxy is smart about congestion management, you shouldn't see this behavior. If not, you may. -- :wq
Re: [gentoo-user] wireless newbee needs help
On 9 February 2012 17:00, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, it's the first time I have to set up a wireless network on a notebook. Save yourself some hassle and use either wicd or NetworkManager - both wrap wpa_supplicant, and make for a much smoother mobile experience.
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On 02/10/12 13:05, Pandu Poluan wrote: No, no, no. What I meant was running TCP and UDP *on top of* OpenVPN (which uses UDP). HAproxy seems to be able to perform its magic with TCP connections. I was about to say that we use it over UDP, but... we don't. We have a small number of clients, maybe ten(?) that use the VPN for remote administration. UDP is recommended, references[1] are easy to google. Why we're running it over TCP I don't know. I must have had a good reason =) It performs fine anyway, but now I'm considering flipping it to UDP to see what happens. At least I'll be in the office when it breaks. [1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
* Michael Mol mike...@gmail.com [120210 12:51]: [..] That's what I was talking about. Where I work, we use OpenVPN, operating in UDP mode. This is after several bad experiences using it in TCP mode. By UDP mode and TCP mode, I mean OpenVPN's connections to other OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's connections operate over TCP (and thus it gets guarantee'd delivery), you can create a situation where a tunneled TCP connection attempts to push data faster than your Internet connection can allow because it never gets any congestion feedback; OpenVPN was accepting packets faster than it could shove them through, and was buffering the rest. So obviously OpenVPN wasn't handling congestion appropriately and should have been using some queueing discipline to discard instead of letting transmit queues grow unbounded. But switching to UDP from TCP just pushes the problem off your OpenVPN gateway and onto the outside network. If you're really receiving more traffic than can be sent over the outside network, now you're relying on intermediate routers to do the right thing with your excess UDP traffic and most likely impacting TCP traffic through the same router. Todd
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman t...@bonedaddy.net wrote: * Michael Mol mike...@gmail.com [120210 12:51]: [..] That's what I was talking about. Where I work, we use OpenVPN, operating in UDP mode. This is after several bad experiences using it in TCP mode. By UDP mode and TCP mode, I mean OpenVPN's connections to other OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's connections operate over TCP (and thus it gets guarantee'd delivery), you can create a situation where a tunneled TCP connection attempts to push data faster than your Internet connection can allow because it never gets any congestion feedback; OpenVPN was accepting packets faster than it could shove them through, and was buffering the rest. So obviously OpenVPN wasn't handling congestion appropriately and should have been using some queueing discipline to discard instead of letting transmit queues grow unbounded. Sure, that contributed to the problem, and may qualify as a bug. On the flip side, by operating OpenVPN in TCP mode, you're saying you want guaranteed delivery across the link. But switching to UDP from TCP just pushes the problem off your OpenVPN gateway and onto the outside network. If you're really receiving more traffic than can be sent over the outside network, now you're relying on intermediate routers to do the right thing with your excess UDP traffic and most likely impacting TCP traffic through the same router. OpenVPN was running on the router on both ends. The sending side was on the lean side of an ADSL modem, plugged directly into the same, so the entire issue was handled locally. Even if OpenVPN wasn't running on the router itself, there'd wouldn't *be* excess UDP traffic when running OpenVPN in UDP mode, as congestion management would be behaving properly. so other traffic would not be unduly impacted. -- :wq
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
* Michael Mol mike...@gmail.com [120210 13:36]: On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman t...@bonedaddy.net wrote: * Michael Mol mike...@gmail.com [120210 12:51]: [..] That's what I was talking about. Where I work, we use OpenVPN, operating in UDP mode. This is after several bad experiences using it in TCP mode. By UDP mode and TCP mode, I mean OpenVPN's connections to other OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's connections operate over TCP (and thus it gets guarantee'd delivery), you can create a situation where a tunneled TCP connection attempts to push data faster than your Internet connection can allow because it never gets any congestion feedback; OpenVPN was accepting packets faster than it could shove them through, and was buffering the rest. So obviously OpenVPN wasn't handling congestion appropriately and should have been using some queueing discipline to discard instead of letting transmit queues grow unbounded. Sure, that contributed to the problem, and may qualify as a bug. On the flip side, by operating OpenVPN in TCP mode, you're saying you want guaranteed delivery across the link. Yes, certainly. And certainly TCP has far more resource requirements on the sending side. However, it also has congestion avoidance built in to it, which UDP does not. But switching to UDP from TCP just pushes the problem off your OpenVPN gateway and onto the outside network. If you're really receiving more traffic than can be sent over the outside network, now you're relying on intermediate routers to do the right thing with your excess UDP traffic and most likely impacting TCP traffic through the same router. OpenVPN was running on the router on both ends. The sending side was on the lean side of an ADSL modem, plugged directly into the same, so the entire issue was handled locally. There was no infrastructure between the two routers? They had a direct connection between them? It would be slightly strange to go through the hassle of running OpenVPN in that case... Even if OpenVPN wasn't running on the router itself, there'd wouldn't *be* excess UDP traffic when running OpenVPN in UDP mode, as congestion management would be behaving properly. so other traffic would not be unduly impacted. Why do you think congestion management would be behaving properly? What congestion management are you referring to for UDP traffic? The only thing intermediate routers can do in the case of congestion due to UDP traffic is to drop. And depending on the queueing implementation they may end up dropping TCP traffic as well. Almost certainly they'll signal congestion to TCP endpoints with traffic through them, hence impacting TCP traffic as well. Todd
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On Fri, Feb 10, 2012 at 2:21 PM, Todd Goodman t...@bonedaddy.net wrote: * Michael Mol mike...@gmail.com [120210 13:36]: On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman t...@bonedaddy.net wrote: * Michael Mol mike...@gmail.com [120210 12:51]: [..] That's what I was talking about. Where I work, we use OpenVPN, operating in UDP mode. This is after several bad experiences using it in TCP mode. By UDP mode and TCP mode, I mean OpenVPN's connections to other OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's connections operate over TCP (and thus it gets guarantee'd delivery), you can create a situation where a tunneled TCP connection attempts to push data faster than your Internet connection can allow because it never gets any congestion feedback; OpenVPN was accepting packets faster than it could shove them through, and was buffering the rest. So obviously OpenVPN wasn't handling congestion appropriately and should have been using some queueing discipline to discard instead of letting transmit queues grow unbounded. Sure, that contributed to the problem, and may qualify as a bug. On the flip side, by operating OpenVPN in TCP mode, you're saying you want guaranteed delivery across the link. Yes, certainly. And certainly TCP has far more resource requirements on the sending side. However, it also has congestion avoidance built in to it, which UDP does not. And that's perfectly fine, when you're going to be tunneling an entire IP stack inside OpenVPN. If a tunneled application needs low latency, low guarantee of delivery, it can use UDP. If a tunneled application needs guarantee of delivery, it can use TCP. But if the OpenVPN tunnel is itself using TCP, you lose low latency opportunities, and you deny your tunneled applications' ability to respond to congestion. But switching to UDP from TCP just pushes the problem off your OpenVPN gateway and onto the outside network. If you're really receiving more traffic than can be sent over the outside network, now you're relying on intermediate routers to do the right thing with your excess UDP traffic and most likely impacting TCP traffic through the same router. OpenVPN was running on the router on both ends. The sending side was on the lean side of an ADSL modem, plugged directly into the same, so the entire issue was handled locally. There was no infrastructure between the two routers? They had a direct connection between them? It would be slightly strange to go through the hassle of running OpenVPN in that case... workstation - ovpn - ADSL 6Mbs/512Kbs - ATT - ADSL(6Mbs/512Kbs) - ovpn - server Both sides would be pushing up the weak end of ADSL, and both sides' local routers would be discarding layer 3 packets that won't fit. ATT wouldn't even have seen the excess traffic. Even if OpenVPN wasn't running on the router itself, there'd wouldn't *be* excess UDP traffic when running OpenVPN in UDP mode, as congestion management would be behaving properly. so other traffic would not be unduly impacted. Why do you think congestion management would be behaving properly? What congestion management are you referring to for UDP traffic? The fact that the tunneled TCP packets and fragments would be dropped, causing the tunneled connections' relevant TCP stacks to scale back. The only thing intermediate routers can do in the case of congestion due to UDP traffic is to drop. And depending on the queueing implementation they may end up dropping TCP traffic as well. Which is *fine*, as long as the TCP packets are encapsulated inside the tunnel, and the tunnel itself is UDP; the connection owners for the encapsulated tunnels would scale back their throughput automatically. If the TCP packet dropped is what's carrying the tunnel itself, then one of the openvpn instances will resend, and the encapsulated connection's packet will still ultimately reach its destination. Almost certainly they'll signal congestion to TCP endpoints with traffic through them, hence impacting TCP traffic as well. Not sure what you mean here. Michael Orlitsky had a decent, relevant link: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html Though instead of stacking TCP/IP/PPP on top of SSH/TCP/IP, I was packing IMAP/TCP/IP on top of OpenVPN/TCP/IP. -- :wq
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
On 02/10/12 13:36, Michael Orlitzky wrote: UDP is recommended, references[1] are easy to google. Why we're running it over TCP I don't know. I must have had a good reason =) Oh my school blocks outgoing UDP. Running on TCP/443 allows me to connect from their network.
Re: [gentoo-user] Re: Recommended VPN Tunnel client?
Congestion isn't the only reason to use TCP and a VPN. 3G smartphone network (Optus in Oz) has a large number of duplicate and dropped packets - openvpn performance over TCP is much better. Similar case with a cheap French network while on holiday there. This was an extreme case though with non VPN traffic very poor as well. Otherwise use openvpn with fqdn's and not IP numbers then use ospf across them with suitable route metrics to either share or prefer a route. Works well with dynamic IP's from my ISP so should be ok in your scenario. You could also use openvpns route push if you dont need complex dynamic routing - this works better than ospf on bad links anyway. BillK On 11/02/2012, at 2:36, Michael Orlitzky mich...@orlitzky.com wrote: On 02/10/12 13:05, Pandu Poluan wrote: No, no, no. What I meant was running TCP and UDP *on top of* OpenVPN (which uses UDP). HAproxy seems to be able to perform its magic with TCP connections. I was about to say that we use it over UDP, but... we don't. We have a small number of clients, maybe ten(?) that use the VPN for remote administration. UDP is recommended, references[1] are easy to google. Why we're running it over TCP I don't know. I must have had a good reason =) It performs fine anyway, but now I'm considering flipping it to UDP to see what happens. At least I'll be in the office when it breaks. [1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
[gentoo-user] Amazon Streaming broken, need hal-0.5.14-gentoo-patches-5.tar.bz2
Amazon Streaming is broken and installing hal fixes it according to the following thread: http://www.amazon.com/forum/amazon%20video%20on%20demand?_encoding=UTF8cdForum=Fx3EQAX98ED5WQ3cdPage=1cdSort=newestcdThread=TxFTGOK5LRL3JM I added the layman overlays multilib and kde-sunset in order to install hal, but the emerge fails because it can't download hal-0.5.14-gentoo-patches-5.tar.bz2. The following thread provides a few links to this file but they no longer work, and I tried downloading hal-0.5.14-gentoo-patches-4.tar.bz2, extracting, adding the missing file as indicated, and recreating the bz2 tar archive, but there is a checksum failure with that file: http://forums.gentoo.org/viewtopic-t-906838-start-0.html Does anyone have advice for navigating this? - Grant
Re: [gentoo-user] Amazon Streaming broken, need hal-0.5.14-gentoo-patches-5.tar.bz2
Grant wrote: Amazon Streaming is broken and installing hal fixes it according to the following thread: http://www.amazon.com/forum/amazon%20video%20on%20demand?_encoding=UTF8cdForum=Fx3EQAX98ED5WQ3cdPage=1cdSort=newestcdThread=TxFTGOK5LRL3JM I added the layman overlays multilib and kde-sunset in order to install hal, but the emerge fails because it can't download hal-0.5.14-gentoo-patches-5.tar.bz2. The following thread provides a few links to this file but they no longer work, and I tried downloading hal-0.5.14-gentoo-patches-4.tar.bz2, extracting, adding the missing file as indicated, and recreating the bz2 tar archive, but there is a checksum failure with that file: http://forums.gentoo.org/viewtopic-t-906838-start-0.html Does anyone have advice for navigating this? - Grant You may want to ask on -desktop too. The gurus that keep KDE3 and friends going are on there but it may take a day for them to reply. I did some searching, I found the same thing you did. Me, I would try commenting the patch out of the ebuild and see if it works. Maybe, just maybe, hal will work well enough for what you are doing. Then again, it might not compile either. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] KMail
Am Donnerstag, 9. Februar 2012, 18:33:12 schrieb Daniel D Jones: I was one of those bitten by the upgrade to KMail back in October. After spending nearly two days without access to email while trying to get the upgrade and migration to work, I gave up and pinned KMail to version 4.4.11.1. With the recent upgrade to KDE, I'm curious if anyone knows whether the bugs have been worked out and the KMail upgrade will go smoother now? I switched a long time ago, so I can't say anything about 'smoother' but it does work, as long as you remove all mail ressources and add them back one after another. -- #163933
