[kde-linux] KDE on the go

[Duncan]

Jerome Yuzyk posted on Sat, 04 Aug 2012 14:09:11 -0600 as excerpted:

> I Googled   KDE mobile travel laptop   among other terms to try to find
> what KDE-using road warriors do to manage their mobile computer(s). I'm
> just getting back to a mobile computing life after a decade
> desktop-bound,
> so I've done a lot of laptop/Linux/Fedora research and setup and some
> testing, but none of the travelling yet.
> 
> For example, KNetworkManager seems to be really solid at handling
> wired/wireless switching, so when I'm on wireless I'd like my traffic
> routed through some SSH tunnels to my home LAN. Ideally a VPN, but my
> initial attempts using OpenVPN get me a connection, but it drops after
> about 30 seconds and I need to do some research.
> 
> But generically, what could KDE do for a mobile user that needs to
> juggle secure vs non-secure connections and environments? What widgets
> are worth using? Could I put 'Activities' to any use?
> 
> Or what terms should I be Googling?

OK, I do have a netbook but my main machine is a non-mobile workstation, 
and I don't even have my netbook setup for wifi at all, only wired 
ethernet, so obviously, my usage is WAY different than yours.  As such, I 
won't attempt a direct answer to your question.  But I do have a few 
hints that you might find useful.

1) Laptop-mode-tools.  This is a collection of tools and configuration 
that help with advanced power conservation, automating a whole collection 
of otherwise individually configured and managed settings to change along 
with power events.

The setting from which it gets its name is the kernel's "laptop mode" 
setting, which configures the system to cache writes for far longer than 
normal, thus keeping the drive from having to spin up so often to write 
to disk, thus saving the power keeping the drive spinning would take (but 
of course the tradeoff is in turn that you lose that data that otherwise 
/would/ have been written to disk already, if the system crashes in 
between disk spinups).

Laptop-mode-tools helps you automate turning this on when the system is 
unplugged and thus switched to battery, and turning it off when switched 
back to wall power.

But of course there's all sorts of other settings that make sense to 
switch at the same time, when you're switching between battery and wall 
power, or (optionally) when you're on battery and it drops to say 20% 
charge, conserving power even more to give you those few extra minutes of 
work time.  If you never use the wired network on battery, for instance, 
for some devices it can turn that off entirely when you switch to 
battery.  It can handle automatically dimming the display on battery, 
brightening it back up when you plugin (of course, only if you want it 
to).  It can handle setting the sound system to powersave mode on 
battery, and turning it off entirely once you hit low-battery threshold, 
etc.  These are just a couple examples of the available control modules 
that it'll let you configure for automatic management with power status, 
but they're all entirely configurable, so if you want it to leave 
something alone, just configure it so and it will.

The one caveat is that it's not GUI-configured.  It's mostly the 
traditional edit the config file type configuration.  So if you're not 
comfortable with that, don't bother, unless of course you find a GUI 
front-end for it.  But I just configured mine with the traditional text 
editor config editor, and have it doing exactly what I want. =:^)

2) You didn't mention it so I don't know whether this applies to you or 
not, but FWIW, while kde will notice when you plugin an external monitor 
and let you configure your desktop to use it, at present, there's only 
the single profile that it remembers.  There's no way (yet) to handle 
multiple display profiles, say laptop-display-only while mobile, with an 
external monitor of one size/resolution at work, another at home, and 
another for a projector to do presentations with.  So basically, you 
either have to reconfigure manually each time you plug/unplug an external 
monitor, or you have to manage the profiles using your own scripts 
(perhaps with xrandr calls).

There's plans to support multiple display profiles in the future, but I 
don't know how far in the future we're talking.  It's quite possible 
that'd be kde5 aka kde frameworks, maybe after switching from xorg to 
wayland.  I simply don't know.  (FWIW, now that kde 4.9's out, I really 
should update my netbook and see if support has improved much.  I keep my 
workstation current and actually ran the 4.9 betas and rcs, and in fact 
haven't updated to 4.9 final on it yet so I'm still running rc2, but my 
netbook is actually still running 4.6, and that's the one I'd need the 
multiple display profiles on, so I really should update it and see what 
has changed in that area, recently.  But AFAIK, there's still only one 
display profile.)

3) I limit my remote connections to text-mode SSH for admin purposes, 
from my workstation to my netbook (I don't even run an ssh server on my 
workstation), and only on the home LAN (behind a Linksys router running 
OpenWRT, configured for wired Ethernet only) since the workstation's 
setup with dual full-HD monitors so is much easier to work at, so won't 
be able to help you with that end of things much.  However, I do know a 
bit about IP networking in general, and...

30-second then dropped connections are a classic symptom of only 
partially completed authentication with more complex protocols such as 
FTP, VPNs, etc.  What happens is that there's a timeout on the connection 
setup, so if it isn't fully authenticated and working within that 
timeout, often 30 seconds or so, the connections resets.

These complex protocols with multiple ports, packet mangling, etc, need 
additional NAT/firewall helpers that understand the specific protocol and 
know how to mangle the IP packet payload (not just the IP headers) 
appropriately, since they pass protocl control data in the IP packet 
payload, not just the IP headers, which firewalls and NAT devices 
normally handle.  If that helper isn't available or configured correctly, 
the initial connection will be made via the normal IP packet header 
mangling, but the vital connection control information won't be mangled 
since the helper that understands where in the packet it is and how to 
mangle it isn't working, so the connection will die after the initial 
handshake timeout, because the control information wasn't mangled along 
with the IP headers and the rest of the connection wasn't completed.

But I'm most familiar with the problem on FTP, since that's what I've 
worked with.

So check both machine's IPTables setups (assuming you're running that as 
a firewall on them), and check any router NAPT/firewalls you're 
connectiong thru as well.  I'd lay money on at least one of them not 
having the necessary helper for your VPN configured.

So try this:

a) Consider the firewall and policies at the location you're going to be 
connecting from, and whether you have access/authorization to run the 
protocol you're considering.  If you don't control that firewall or its 
policies, that seriously limits your remote protocol choices, since many 
of the otherwise possible choices will likely be blocked.  Obviously, 
chose a protocol that's going to be allowed. =:^)

b) Direct-connect machine to machine with an Ethernet crossover cable 
only, no wifi on, just the Ethernet, and direct machine to machine via 
cross-over cable.  Drop the firewalls on both machines (they're only 
connected to each other, thus the no wifi specified above, so firewalls 
shouldn't be necessary).   Get that working, so you know the software 
itself is working.

c) Turn on the firewall on one of the machines and get that working.  
Assuming an IPTables/Netfilter based firewall, you'll probably have to 
load the appropriate helper module for your VPN protocol and get it 
configured.

d) Do the same with the other machine, so it's talking thru both 
machine's firewalls.

e) Assuming you have an internet gateway/router (and that it's running 
OpenWRT or something similarly configurable with the appropriate helper 
modules, etc), unplug it from the internet and connect your laptop in 
place of the modem.  (Note that to get this step to work you'll need to 
either manually assign IPs on the router WAN side and laptop, or be 
running a DHCP server on the laptop, since the router is likely 
configured to use DHCP to get its IP from the ISP.)  Get THAT working, 
configuring the router with the appropriate helper modules and protocols, 
etc.

f) Only once you have it working locally, thru the router, with both 
machine's firewalls and the router passing the traffic, try the truly 
remote connection.  Here's where your research and choice in A pays 
off... or not, if you find yourself blocked, with no way thru the block 
due to firewall policy that you don't control.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman