|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
So, I got the VPN software preloaded on the Nokia E71 to work with my NetScreen-5GT! I had to use the crummy Windows utility to create the VPN policy - but it's only a one-time task. Here's a dump of the goodness:
einstein-> get sa total configured sa: 1 HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys 00000003< 32.142.82.180 500 esp:a128/sha1 3593aefb 1999 unlim I/I 17 0 00000003> 32.142.82.180 500 esp:a128/sha1 29b89b2a 1999 unlim I/I 18 0 einstein-> get sa id 0x00000003 index 0, name Prolixium, peer gateway ip 32.142.82.180. vsys<Root> auto key. policy node, tunnel mode, policy id in:<17> out:<18> vpngrp:<-1>. sa_list_nxt:<-1>. tunnel id 3, peer id 0, NSRP Local. dialup, original. site-to-site. Local interface is untrust <71.75.169.196>. esp, group 2, a128 encryption, sha1 authentication autokey, IN inactive, OUT inactive monitor<0>, latency: 0, availability: 0 DF bit: clear app_sa_flags: 0x2400030 proxy id: local 10.3.0.0/255.255.0.0, remote 10.157.55.244/255.255.255.255, proto 0, port 0 ike activity timestamp: 1495567630 DSCP-mark : disabled nat-traversal map not available incoming: SPI 3593aefb, flag 00004000, tunnel info 40000003, pipeline life 3600 sec, 2014 remain, 0 kb, 0 bytes remain anti-replay off, idle timeout value <0>, idled 1023 seconds next pak sequence number: 0x0 bytes/paks:30412/208; sw bytes/paks:30412/208 outgoing: SPI 29b89b2a, flag 00000000, tunnel info 40000003, pipeline life 3600 sec, 2014 remain, 0 kb, 0 bytes remain anti-replay off, idle timeout value <0>, idled 1023 seconds next pak sequence number: 0x132 bytes/paks:58224/306; sw bytes/paks:58224/306
NAT-T isn't being used - just straight ESP over IP/50, which is interesting. I believe all Internet access through AT&T's network egresses through several Juniper ISG 2000s. So, they probably have a special DIP configured w/out port-xlate for traffic that doesn't work well with port translation (at least for the the MEdia Net plan, that doesn't assign out publicly-routable addresses). Judging from the above, my internal address is apparently 10.157.55.244, which gets translated to 32.142.82.180.
I used a policy-based VPN, since I didn't want to deal with XAUTH or IP pools, just yet. Maybe I'll write a document on this, after I'm all done playing with it …
Ok, I've been hung up on the Eee, lately. The power management and CPU throttling seems to be a mystery to me, and I need to figure it out otherwise I'm likely to go insane! Here's where I'm at:
On most laptops I've used, I'd typically load the appropriate CPUfreq module, and then use a combination of cpufreqd or cpufreq-set to throttle the clock speed on the CPU. The Eee initially was no different. The Celeron ULV apparently uses the p4-clockmod module (speedstep-centrino and acpi-cpufreq wouldn't load) and cpufreq-set worked as expected - or so I thought.
I first noticed the weirdness when I successfully played a 1080p MPEG-2 video stream on the Eee. It played fine (I was pleasantly surprised). However, when I tried to play it a day later, it was dropping frames all over the place, and MPlayer spat out the dreaded "your system is not fast enough to play this!" message. Both times, the CPUfreq scaling governor was set to performance. What gives? I couldn't make heads or tails of it, initially. Sometimes the video played, and sometimes it didn't. I then realized it was directly related to whether I had the AC adapter connected upon resuming the Eee from sleep (suspend to RAM).
If the AC adapter connected before the Eee is resumed, it'll play the MPEG-2 stream without a hitch. If I resume the Eee without the AC power connected, the video won't play smoothly. It doesn't even matter if I plug in the AC adapter after the Eee is running, it won't make a difference. Apparently there is some variable or power saving mode that is set upon a cold start or resume from sleep, and persists until the machine is suspended or turned off.
But, if the CPU was getting throttled somehow, shouldn't /proc/cpuinfo reflect the change in the "cpu MHz" line? Nope, apparently not. To make matters worse, there's the /proc/acpi/processor/CPU1/throttling knob, which apparently is separate from the p4-clockmod driver and the mysterious throttling that's set at resume - it doesn't change AT ALL. I can, however, set it, and the CPU will go down to ~77MHz, but this isn't reflected in /proc/cpuinfo, either. I don't even want to know what happens if I use the /proc/acpi/processor/CPU1/throttling knob in combination with the CPUfreq subsystem. Eesh.
Anyway, I did some tests with bzip2 and a 32MiB test file, just to see how much the CPU is getting throttled by this unknown mechanism. The first one below is when the Eee was resumed without the AC adapter connected:
(six:19:33)% cpufreq-info
cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@lists.linux.org.uk, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
(six:19:34)% cat /proc/acpi/processor/CPU1/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
(six:19:34)% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 900MHz
stepping : 8
cpu MHz : 900.117
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca \
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 1802.47
clflush size : 64
power management:
(six:19:35)% time bunzip2 -t 32MiB.bin.bz2
bunzip2 -t 32MiB.bin.bz2 19.90s user 0.12s system 99% cpu 20.022 total
(six:19:36)% sudo modprobe p4-clockmod
(six:19:36)% sudo cpufreq-set -g performance
(six:19:37)% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 900MHz
stepping : 8
cpu MHz : 900.000
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca \
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 1802.47
clflush size : 64
power management:
(six:19:37)% cat /proc/acpi/processor/CPU1/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
(six:19:37)% time bunzip2 -t 32MiB.bin.bz2
bunzip2 -t 32MiB.bin.bz2 19.94s user 0.08s system 100% cpu 20.018 total
(six:19:37)% sudo cpufreq-set -g powersave
(six:19:38)% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 900MHz
stepping : 8
cpu MHz : 112.500
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca \
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 1802.47
clflush size : 64
power management:
(six:19:38)% cat /proc/acpi/processor/CPU1/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
(six:19:38)% time bunzip2 -t 32MiB.bin.bz2
bunzip2 -t 32MiB.bin.bz2 117.82s user 1.47s system 99% cpu 1:59.88 total
Now, the SAME test with the AC adapter connected:
(six:19:44)% cpufreq-info
cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@lists.linux.org.uk, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
(six:19:45)% cat /proc/acpi/processor/CPU1/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
(six:19:46)% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 900MHz
stepping : 8
cpu MHz : 900.117
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca \
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 1802.47
clflush size : 64
power management:
(six:19:46)% time bunzip2 -t 32MiB.bin.bz2
bunzip2 -t 32MiB.bin.bz2 13.86s user 0.04s system 99% cpu 13.917 total
(six:19:47)% sudo modprobe p4-clockmod
(six:19:47)% sudo cpufreq-set -g performance
(six:19:47)% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 900MHz
stepping : 8
cpu MHz : 900.000
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca \
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 1802.47
clflush size : 64
power management:
(six:19:47)% cat /proc/acpi/processor/CPU1/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
(six:19:48)% time bunzip2 -t 32MiB.bin.bz2
bunzip2 -t 32MiB.bin.bz2 13.84s user 0.05s system 99% cpu 13.897 total
(six:19:48)% sudo cpufreq-set -g powersave
(six:19:48)% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 900MHz
stepping : 8
cpu MHz : 112.500
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca \
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 1802.47
clflush size : 64
power management:
(six:19:49)% cat /proc/acpi/processor/CPU1/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
(six:19:49)% time bunzip2 -t 32MiB.bin.bz2
bunzip2 -t 32MiB.bin.bz2 81.83s user 0.98s system 99% cpu 1:23.34 total
Ok, here's what we've got:
Judging from the numbers, it's throttling the CPU to about 70% of full-speed. I Googled around a little bit, and it seems like this is expected behavior, but nobody has a solution on how to change this via software, or how the /proc/acpi/processor/CPU1/throttling stuff fits into the equation, either. There's nothing in the BIOS that provides any clue…
Blarg.
I was playing around with TemperatureMonitor on my parents' iMac, today, and decided to add support for it to mrtg-rmt. Adding support was easy (included in the 1.8.3 release), but I didn't know exactly how to get the daemon started at boot. Legacy support in OS X for the usual rc.local hacks probably exist, but I figured I would do it right. So, I stumbled upon launchd, which is a subsystem in OS X that provides granular control to the starting and stopping of daemons and optionally can act as a full-blown xinetd/inetd replacement.
I started out by reading parts of the launchd.plist(5) and launchctl(1) manpages, and threw together a simple XML propertly list file for mrtg-rmt:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.prolixium.mrtg-rmt</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/sbin/mrtg-rmt</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
Apparently there are a couple locations for the plist files. The system (ie, don't touch) ones are in /System/Library/LaunchDaemons, and the custom ones should go in /Library/LaunchDaemons. I placed com.prolixium.mrtg-rmt.plist in there, and ran the following:
% sudo launchctl load -w /Library/LaunchDaemons/com.prolixium.mrtg-rmt.plist
Neat, it started up all by itself:
% ps ax | grep mrtg-rmt 866 ?? Ss 0:00.04 /usr/bin/perl -w /usr/local/sbin/mrtg-rmt 870 s001 S+ 0:00.00 grep --color -i mrtg
The plist XML schema has several other nifty options, too, but I didn't really explore them. The whole thing sure beats putting scripts into /etc/init.d! launchd reminds me of Sun's SMF stuff, too - but somehow more elegant and easier to use…
Read more: Getting Started with launchd
Enjoy turkey, or something. Read about it if you want.
Oh, also - I figured out that tapping the touchpad with two fingers on the Eee acts as the 3rd button.
Ever notice that your 6in4 (sit) tunnels on GNU/Linux all have a ton of weird-looking link-local addresses attached to them?
sit2 Link encap:IPv6-in-IPv4
inet6 addr: fe80::a03:71e/64 Scope:Link
inet6 addr: 2001:4830:122d:ffff::2/126 Scope:Global
inet6 addr: fe80::a03:fe0b/64 Scope:Link
inet6 addr: fe80::a03:fe1c/64 Scope:Link
inet6 addr: fe80::a03:fe11/64 Scope:Link
inet6 addr: fe80::a03:405/64 Scope:Link
inet6 addr: fe80::a03:fe02/64 Scope:Link
inet6 addr: fe80::a03:7fa/64 Scope:Link
inet6 addr: fe80::4bb5:4d73/64 Scope:Link
inet6 addr: fe80::a03:fd06/64 Scope:Link
inet6 addr: fe80::a03:5fe/64 Scope:Link
inet6 addr: fe80::a03:fe07/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:83817047 errors:0 dropped:0 overruns:0 frame:0
TX packets:49313462 errors:86 dropped:0 overruns:0 carrier:86
collisions:0 txqueuelen:0
RX bytes:2897105421 (2.6 GiB) TX bytes:776361358 (740.3 MiB)
Yeah, like that.
The last four bytes of each address is an IPv4 address attached (or was attached) to another interface on the box. Let's break down the above example:
fe80::a03:71e/64 -> 10.3.7.30 (eth1.2) fe80::a03:fe0b/64 -> 10.3.254.11 (been gone for awhile) fe80::a03:fe1c/64 -> 10.3.254.28 (tun4) [...] fe80::4bb5:4d73/64 -> 75.181.77.115 (used to be on eth0)
I think eth0 used to have 75.181.77.115 about a year ago. It looks like these LL addresses are stored somewhere, and reused over and over again. I suppose it makes sense - LL addresses only need be unique per link.
I haven't been able to find any hard documentation on this, though, so I'm just guessing…
I'm really not sure what prompted it, but ever since I've been in NJ (for the holidays), the Wi-Fi on my Eee PC 900 has been less than stellar.
What is less than stellar? PL and very high latency over a 10-15 second duration, almost every minute. It's not a signal strength issue - wavemon indicates a signal level of roughly -55 dBm, an SNR of +39 dB, and a link qualty of 40/70. The packets either get queued somewhere and are processed after 4-8 seconds, or lost completely. The orientation of the Eee seems to have an impact on this behavior, too, but it all seems circumstantial. I can even be 1 meter away from the AP and still get PL.
I didn't drop the Eee, or anything like that. I did have to run it through security at the Charlotte Airport before I left, though. The conspiracy theorist in me says there's more going on in there than just x-rays!
I initially thought this was just the WRT54GS at my parents' place not playing nice with the Atheros AR2425 chip in the Eee. However, two other laptops, including my IBM T42 with an Atheros AR5212, have no problems. I even brought the Eee it to public Wi-Fi hotspot (the Omega Diner, in North Brunswick) and experienced the same issue. Back in Charlotte, my Cisco 1232 AP at home, whatever AP they have at Panera, and the Cisco Airspace stuff at work all worked great with the Eee. Nope, not an AP issue.
It's not a software problem. The problems started happening in NJ. I haven't rebooted the laptop in two weeks - and I just suspended to RAM before boarding the plane, and resumed when I got to my destination. Of course, I did reboot after that, to make sure it wasn't something transient. Took the battery out, did the whole power cycle yadda yadda. I didn't upgraded any drivers or kernel modules. I ended up trying that, though - no dice.
So, what's left? Firmware problem? I didn't touch it -- although I'm not sure how to flash the firmware on the Atheros card. Perhaps it's an antenna problem? Maybe antenna diversity is confgured by default (didn't see an iwpriv ioctl for it), and the Tx antenna got bumped, or something. If so, that would explain how signal quality was great, yet packets get dropped. So I opened it up:
See the entire gallery here.
So, I jostled the antenna connectors, and that didn't help. However, I ended up breaking something because the tilda (~/`) key is gone, now. Gone, as in it's now assumed the role of the F1 key, and all the other function keys have shifted down one. I re-seated the keyboard connector several times, but to no avail. My ~/` key is now dead.
BAH.
Yeah, I bought a new Eee PC. I can't believe I did it. However, it works. I swapped the SSD and my 2GiB RAM upgrade, and booted it up. The wireless works as expected, and the ~/` key lives again.
I'm going to do some more hacking on the old Eee when I get back from vacation, because I'm really curious about the whole thing - and worried that whatever happened to it might plague my new Eee in the future. Getting a 3rd Eee is NOT an option.
So there you have it. Sorry that the story didn't have a better ending. At least you got a chance to take a peep at some nekkid Eee photos. :-S
I've become really lazy, lately, and haven't been posting here as often as I should. As a result, things pile up, blargh.
I don't know what happened when I went through security at CLT, but ever since flying up to NJ, the Wi-Fi has been performing very poorly on my Eee.
I'll get tons of PL (packet loss) and very high latency for a duration of 10-15 seconds, every minute or so. Link quality is solid the whole time. It doesn't matter if I'm 1 or 10 meters away from the AP (ANY AP, any type of encryption/authentication), it always happens. Sometimes I can fix it by tilting the Eee to the side, and keeping it very steady, which makes me worry about an antenna or hardware problem. Here's a PING to the default gateway:
PING 10.3.1.254 (10.3.1.254) 56(84) bytes of data. 64 bytes from 10.3.1.254: icmp_seq=1 ttl=64 time=1.59 ms 64 bytes from 10.3.1.254: icmp_seq=2 ttl=64 time=1.20 ms 64 bytes from 10.3.1.254: icmp_seq=3 ttl=64 time=1.28 ms 64 bytes from 10.3.1.254: icmp_seq=4 ttl=64 time=1.26 ms 64 bytes from 10.3.1.254: icmp_seq=5 ttl=64 time=1.65 ms 64 bytes from 10.3.1.254: icmp_seq=6 ttl=64 time=1.17 ms 64 bytes from 10.3.1.254: icmp_seq=7 ttl=64 time=1.37 ms 64 bytes from 10.3.1.254: icmp_seq=8 ttl=64 time=1.16 ms 64 bytes from 10.3.1.254: icmp_seq=9 ttl=64 time=1.24 ms 64 bytes from 10.3.1.254: icmp_seq=10 ttl=64 time=24.3 ms 64 bytes from 10.3.1.254: icmp_seq=11 ttl=64 time=1.67 ms 64 bytes from 10.3.1.254: icmp_seq=12 ttl=64 time=1467 ms 64 bytes from 10.3.1.254: icmp_seq=13 ttl=64 time=4567 ms 64 bytes from 10.3.1.254: icmp_seq=14 ttl=64 time=3589 ms 64 bytes from 10.3.1.254: icmp_seq=15 ttl=64 time=2950 ms 64 bytes from 10.3.1.254: icmp_seq=16 ttl=64 time=1954 ms 64 bytes from 10.3.1.254: icmp_seq=17 ttl=64 time=960 ms 64 bytes from 10.3.1.254: icmp_seq=18 ttl=64 time=1.25 ms 64 bytes from 10.3.1.254: icmp_seq=19 ttl=64 time=1.54 ms 64 bytes from 10.3.1.254: icmp_seq=20 ttl=64 time=1.24 ms
I found some similar symptoms at this thread, although folks there seem to be using Windows XP.
I guess I'm going to try to put Knoppix on it, just to completely rule out software issues.
I just picked up Armin van Buuren's A State of Trance 2008 (ASIN) album the other day. Just like the others, it's a great listen. Of course, I haven't listened to the whole album yet, just started halfway through the In The Club disc (2) with Blueprint, by Stoneface & Terminal, and kept listening.
So, the cat is apparently out of the bag. I've been promoted to the role of Network Architect at my place of employment. Lots of design work, and some software/web development on the side. Should be fun!
One of my colleagues found some HTML Guidelines the other day. Most of them seem commonsense, but we don't all use commonsense, and need to be reminded every once and awhile…
I need a bailout from the government. They need to buy me a new CPU.
Displaying page 32 of 121 of 965 results
     |
This HTML for this page was generated in 0.003 seconds. |