Dariush Debian Diary

About

Diariusz Dariusza

index | rss1.0

Categories

Archives

Valid XHTML 1.1 | Valid CSS
powered by blosxom.

2007-12-14

PowerDNS on PostgreSQL


CREATE TABLE domains (
    id serial NOT NULL,
    name character varying(255) NOT NULL,
    master character varying(20),
    last_check integer,
    "type" character varying(6) NOT NULL,
    notified_serial integer,
    account character varying(40)
);


CREATE TABLE records (
    id serial NOT NULL,
    domain_id integer,
    name character varying(255),
    "type" character varying(6),
    content character varying(255),
    ttl integer,
    prio integer,
    change_date integer
);

CREATE TABLE supermasters (
    ip character varying(25) NOT NULL,
    nameserver character varying(255) NOT NULL,
    account character varying(40)
);



COPY domains (id, name, master, last_check, "type", notified_serial, account) FROM stdin;
1       kuszelas.eu    \N      \N      NATIVE  \N      \N
\.


--
-- Data for TOC entry 22 (OID 17153)
-- Name: records; Type: TABLE DATA; Schema: public; Owner: postgres
--

COPY records (id, domain_id, name, "type", content, ttl, prio, change_date) FROM stdin;
2       1       localhost.kuszelas.eu  A       127.0.0.1       120     \N      \N
20      1       kuszelas.eu    MX      mail2.kuszelas.eu      300     10      \N
21      1       mail2.kuszelas.eu      A       212.182.115.24  120     \N      \N
1       1       kuszelas.eu    SOA     localhost user.kuszelas.eu 1   86400   \N      \N
17      1       kuszelas.eu    NS      ns.kuszelas.eu 300     \N      \N
18      1       kuszelas.eu    MX      mail.kuszelas.eu       300     5       \N
12      1       _jabber._tcp.jabber.kuszelas.eu        SRV     0 5269 kuszelas.eu     300     10      \N
13      1       _xmpp-server._tcp.jabber.kuszelas.eu   SRV     0 5269 kuszelas.eu     300     10      \N
14      1       _xmpp-client._tcp.jabber.kuszelas.eu   SRV     0 5222 kuszelas.eu     300     10      \N
16      1       kuszelas.eu    TXT     Serwer  300     \N      \N
3       1       www.kuszelas.eu        A       195.242.124.71  120     \N      \N
5       1       dns.kuszelas.eu        A       195.242.124.71  120     \N      \N
6       1       ftp.kuszelas.eu        A       195.242.124.71  120     \N      \N
7       1       poczta.kuszelas.eu     A       195.242.124.71  120     \N      \N
8       1       pop3.kuszelas.eu       A       195.242.124.71  120     \N      \N
9       1       smtp.kuszelas.eu       A       195.242.124.71  120     \N      \N
10      1       ssh.kuszelas.eu        A       195.242.124.71  120     \N      \N
11      1       jabber.kuszelas.eu     A       195.242.124.71  120     \N      \N
4       1       mail.kuszelas.eu       A       195.242.124.71  120     \N      \N
\.


Audit trail:
CREATE TABLE audit_domains (
    operation         char(1)   NOT NULL,
    stamp             timestamp NOT NULL,
    userid            text      NOT NULL,
    id serial NOT NULL,
    name character varying(255) NOT NULL,
    master character varying(20),
    last_check integer,
    "type" character varying(6) NOT NULL,
    notified_serial integer,
    account character varying(40)
);


CREATE TABLE audit_records (
    operation         char(1)   NOT NULL,
    stamp             timestamp NOT NULL,
    userid            text      NOT NULL,
    id serial NOT NULL,
    domain_id integer,
    name character varying(255),
    "type" character varying(6),
    content character varying(255),
    ttl integer,
    prio integer,
    change_date integer
);

CREATE OR REPLACE FUNCTION process_audit_domains() RETURNS TRIGGER AS $audit_domains$
    BEGIN
        --
        -- Create a row in audit_domains to reflect the operation performed on domains,
        -- make use of the special variable TG_OP to work out the operation.
        --
        IF (TG_OP = 'DELETE') THEN
            INSERT INTO audit_domains SELECT 'D', now(), user, OLD.*;
            RETURN OLD;
        ELSIF (TG_OP = 'UPDATE') THEN
            INSERT INTO audit_domains SELECT 'U', now(), user, NEW.*;
            RETURN NEW;
        ELSIF (TG_OP = 'INSERT') THEN
            INSERT INTO audit_domains SELECT 'I', now(), user, NEW.*;
            RETURN NEW;
        END IF;
        RETURN NULL; -- result is ignored since this is an AFTER trigger
    END;
$audit_domains$ LANGUAGE plpgsql;

CREATE TRIGGER audit_domains
AFTER INSERT OR UPDATE OR DELETE ON domains
    FOR EACH ROW EXECUTE PROCEDURE process_audit_domains();

--

CREATE OR REPLACE FUNCTION process_audit_records() RETURNS TRIGGER AS $audit_records$
    BEGIN
        --
        -- Create a row in audit_records to reflect the operation performed on records,
        -- make use of the special variable TG_OP to work out the operation.
        --
        IF (TG_OP = 'DELETE') THEN
            INSERT INTO audit_records SELECT 'D', now(), user, OLD.*;
            RETURN OLD;
        ELSIF (TG_OP = 'UPDATE') THEN
            INSERT INTO audit_records SELECT 'U', now(), user, NEW.*;
            RETURN NEW;
        ELSIF (TG_OP = 'INSERT') THEN
            INSERT INTO audit_records SELECT 'I', now(), user, NEW.*;
            RETURN NEW;
        END IF;
        RETURN NULL; -- result is ignored since this is an AFTER trigger
    END;
$audit_records$ LANGUAGE plpgsql;

CREATE TRIGGER audit_records
AFTER INSERT OR UPDATE OR DELETE ON records
    FOR EACH ROW EXECUTE PROCEDURE process_audit_records();



2007-12-13

dd_rescue /dev/zero test

host:/fs/t# dd_rescue /dev/zero test
dd_rescue: (info): ipos:   5831680.0k, opos:   5831680.0k, xferd:   5831680.0k
                   errs:      0, errxfer:         0.0k, succxfer:   5831680.0k
		                +curr.rate:   493402kB/s, avg.rate:   141304kB/s, avg.load: 34.6%
host:/fs/t# dd_rescue /dev/zero test
dd_rescue: (info): ipos:  22496256.0k, opos:  22496256.0k, xferd:  22496256.0k
                   errs:      0, errxfer:         0.0k, succxfer:  22496256.0k
		                +curr.rate:   366322kB/s, avg.rate:   150428kB/s, avg.load: 38.7%
IO/s: 590 Write BW: 148MB/s
host:/fs/t# time dd_rescue -w /dev/zero test
dd_rescue: (info): ipos: 535740416.0k, opos: 535740416.0k, xferd: 535740416.0k
                   errs:      0, errxfer:         0.0k, succxfer: 535740416.0k
+curr.rate:    28755kB/s, avg.rate:   151774kB/s, avg.load: 41.6%

real    58m53.858s
user    0m25.982s
sys     24m2.210s

2007-12-08

Vista ReadyBoost requirements

: 5MB/s(2.5M/s?) for random reads (4k) 3MB/s(1.75M/s?) for random writes (512k) Limits defined in: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt for example: Device Status 0x02 ReadSpeedKBs 0x1000 WriteSpeedKBs 0x1000 (you need to click 'do-not-retest', otherwise it will otherwrite your changes in registy)

2007-12-04

Compaq 6910p on debian lenny

  • kernel >=2.6.22 (for sound, intel x3100 graphics)
  • xorg >=7.2
  • alsaconfig -> snd_hda_intel
  • iwlwifi-4965-ucode -> /lib/firmware/
  • iwlwifi 1.2.22 (1.2.20 doesn't work)
  • s2ram -f --vbe_save --vbe_post --vbe_mode

2007-11-29

Setting Process Title On Linux

http://www.netsplit.com/2007/01/ and http://lightconsulting.com/~thalakan/process-title-notes.html with perl: Sys::Proctitle,

2007-11-27

Vserver VS OpenVZ - benchmark/posgresql/jira test

Jira reindex, same hardware, same database, with db on linux-vserver(2.6.18.8+vs2.0.3):
"Re-Indexing was successful and took: 1518 seconds."
with db on openvz (2.6.18+ovz028stab047.1):
"Re-Indexing was successful and took: 1488 seconds."
db on openvz, running on only one virtual cpu (vzctl set --cpus 1):
"Re-Indexing was successful and took: 1681 seconds."

HW: HP ProLiant DL360 G4 model name : Intel(R) Xeon(TM) CPU 3.00GHz

2007-11-20

Anti-RRD, don't loose information

logs are precious, rrd believes otherwise, that wouldn't be a problem if rrd wasn't so popular. Thus, one needs tool that sits on top of rrd/modifies rrd, and stop it from erasing data. That is the most economical course of action, since every data logging tool outthere uses rrd.

How to proceed?

  1. cron-fired tool that backs rrd-data into separate file
  2. patch to rrd, that stores removed data in alternate data stream (another file), with a little effort this might become an option to rrd, making historical data easily available to rrd-based tools

2007-11-19

Reverse Munin

- install reverse-munin, it reports stats every ~15m (stats collected every ~30s)

2007-11-13

Effect of CONCURRENCY_LEVEL variable on make-kpkg (kernel compilation) on dual Quad Core

System:
processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
stepping        : 7
cpu MHz         : 2333.422
cache size      : 4096 KB
physical id     : 1
siblings        : 4
core id         : 3
cpu cores       : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 4667.06
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

....
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
model name      : Intel(R) Xeon(R) CPU           E5345  @ 2.33GHz
Linux etchdev386 2.6.18.bsd40j-vz #1 SMP Sun Oct 28 10:14:55 UTC 2007 i686 GNU/Linux
CLrealusersys
1 36m8.773s 28m0.017s 5m11.427s
2 21m17.209s 28m19.778s 5m32.009s
3 16m24.912s 28m24.875s 5m47.002s
4 14m54.012s 28m30.863s 6m0.895s
5 14m50.449s 28m27.211s 6m4.799s
6 15m33.589s 28m15.798s 5m58.850s
7 16m23.849s 28m28.563s 6m5.475s
8 17m41.355s 28m16.958s 6m0.515s
9 17m49.368s 28m29.867s 6m3.207s
10 18m21.491s 28m26.071s 6m4.455s
11 18m46.612s 28m32.743s 6m6.239s
12 19m10.218s 28m31.855s 6m5.335s
13 19m36.510s 28m25.191s 6m2.123s
14 19m33.238s 28m45.360s 6m8.467s
15 19m50.454s 28m47.152s 6m10.283s
16 20m21.163s 28m42.168s 6m11.019s
17 19m56.470s 28m41.992s 6m5.219s
18 19m49.307s 28m48.364s 6m11.235s
19 19m56.618s 28m45.544s 6m11.047s
20 20m12.434s 28m51.164s 6m12.847s
21 20m37.028s 28m34.055s 6m9.423s
22 19m56.581s 29m0.861s 6m21.540s
23 20m52.650s 28m46.000s 6m10.259s
24 20m17.952s 28m41.556s 6m14.103s
25 20m39.504s 28m42.468s 6m14.483s
26 19m56.328s 29m26.562s 6m28.620s
27 20m0.562s 29m31.551s 6m36.301s
28 19m57.038s 29m34.491s 6m32.289s
29 20m3.414s 29m29.779s 6m33.901s
30 20m15.452s 29m38.131s 6m36.489s
31 19m58.292s 29m36.491s 6m35.749s
32 20m29.804s 28m57.513s 6m20.204s
33 20m8.699s 28m59.293s 6m23.452s
34 20m11.357s 28m55.916s 6m20.216s
35 20m31.274s 28m49.472s 6m14.579s
36 20m20.033s 28m48.772s 6m18.116s
CLrealusersys
1 36m9.151s 28m0.961s 5m13.396s
2 21m16.693s 28m15.106s 5m35.113s
3 16m14.933s 28m40.860s 5m53.790s
4 14m51.212s 28m30.335s 6m0.811s
5 14m49.351s 28m31.207s 6m7.995s
6 15m47.585s 28m11.794s 5m58.182s
2.6.22-amd64: (without vz)
export CONCURRENCY_LEVEL=6
...
real    9m51.049s
user    32m8.349s
sys     5m31.861s

CLrealusersys
1 35m47.262s 31m56.732s 4m24.081s
2 18m55.905s 31m26.558s 4m27.733s
3 13m46.587s 31m34.278s 4m28.333s
4 11m9.684s 31m26.130s 4m32.769s
5 9m40.245s 31m51.495s 4m41.050s
6 8m43.968s 32m3.032s 4m45.382s
7 8m7.112s 32m4.800s 4m45.218s
8 7m54.335s 32m8.845s 4m48.246s
9 8m14.461s 32m32.178s 4m53.662s
10 8m47.419s 33m1.660s 4m56.667s
11 9m48.772s 33m30.070s 4m59.543s
12 11m13.929s 33m35.218s 5m0.759s
# chroot on 2.6.18/amd64
CLrealusersys
1 39m0.566s 30m12.521s 4m26.485s
2 22m15.543s 30m34.999s 4m41.694s
3 17m15.496s 31m3.320s 4m52.818s
4 15m13.936s 31m14.269s 5m3.363s
5 15m7.533s 31m13.217s 5m4.987s
6 15m30.503s 31m25.142s 5m17.580s
# 2.6.22-vz004(git @ 2007-11-01) (amd64)
CLrealusersys
1 71m38.213s 27m44.876s 4m41.790s
5 31m17.052s 28m24.655s 5m27.836s
6 32m49.246s 28m5.849s 5m13.568s
with vzctl set etchdev --cpus 5:
CL: 1
real    35m55.736s
user    27m54.469s
sys     5m13.696s
CL: 2
real    21m21.611s
user    28m13.954s
sys     5m29.397s
CL: 3
real    17m3.690s
user    28m25.743s
sys     5m43.485s
CL: 4
real    15m42.706s
user    28m26.507s
sys     5m53.898s
CL: 5
real    16m59.589s
user    28m3.105s
sys     5m49.130s
CL: 6
real    18m24.560s
user    28m12.538s
sys     5m52.138s
CL: 7
real    19m22.321s
user    27m57.009s
sys     5m51.942s
with vzctl set etchdev --cpus 4:
CL: 1
real    35m25.464s
user    28m0.665s
sys     5m7.427s
CL: 2
real    21m12.749s
user    28m26.247s
sys     5m28.245s
CL: 3
real    17m9.802s
user    28m26.435s
sys     5m38.409s
CL: 4
real    16m55.358s
user    28m17.830s
sys     5m40.993s
CL: 5
real    18m58.317s
user    27m52.749s
sys     5m36.249s
CL: 6
real    19m57.399s
user    27m47.980s
sys     5m35.565s
CL: 7
real    20m26.853s
user    27m58.965s
sys     5m36.873s
with vzctl set etchdev --cpus 3:
CL: 1
real    35m6.224s
user    27m55.997s
sys     4m58.507s
CL: 2
real    21m38.178s
user    28m55.168s
sys     5m44.654s
CL: 3
real    17m36.461s
user    28m47.816s
sys     5m42.417s
CL: 4
real    19m50.483s
user    28m6.361s
sys     5m34.001s
CL: 5
real    20m58.151s
user    28m21.998s
sys     5m47.946s
CL: 6
real    21m36.935s
user    28m23.494s
sys     5m46.558s
CL: 7
real    22m8.818s
user    28m9.370s
sys     5m37.545s
with vzctl set etchdev --cpus 2:
CL: 1
real    34m11.380s
user    28m1.933s
sys     4m52.270s
CL: 2
real    21m7.797s
user    28m37.959s
sys     5m12.724s
CL: 3
real    22m4.511s
user    28m4.549s
sys     5m13.984s
CL: 4
real    22m42.487s
user    28m6.717s
sys     5m12.572s
CL: 5
real    24m43.785s
user    28m1.637s
sys     5m14.804s
CL: 6
real    24m9.467s
user    28m12.986s
sys     5m15.120s
CL: 7
real    24m49.795s
user    28m4.093s
sys     5m7.071s
.

2007-11-12

85C errors with 1-wire termometer

from http://www.nabble.com/Problem-with-temperature-reading-t3265726.html

by David Lissiuk Feb 21, 2007; 07:13pm 

Hi all,

 As I have done fairly extensive testing of various 1-wire issues I can
maybe help shed some light on possible hardware causes of seeing 85.0C
errors for those new to these issues.

In general a 85.0C reading indicates that a POR has occurred in the
chip:

The following issues are common, note that not all are things that
software alone can correct.

1) Poor 1-wire line levels
 A). If the chip is wired for parasitic operation, the VDD line must be
grounded. Otherwise unknown parasitic results may occur. (This is not
required with -PAR devices, which are internally grounded inside the
chip).

 B). While operating under powered mode of operation, the power supply
has to have a reasonably fast rise time, else the chip may enter an
internal test mode.  The voltage should ideally be 5 volts to insure
maximum signal headroom for the 1-wire signal. Line losses through the
cable need to be considered.

 C). The slave device (the DS18B20) may not have enough power/current to
complete the temperature conversion and this may cause a POR to occur in
the chip instead (Generating the 85.0C reading). This may be caused by
the following:

2). Insufficient weak-pull-up current on simple 1-wire bus master
designs
I've seen issues when the weak-pull up current is insufficient, causing
the chip to do a POR during the temp conversion time. Generally a value
between 1.1K and 2.5K for the weak pull-up resistor is what I recommend.
I've often seen this problem on bus master designs using a 4.7K or
greater weaker pull-up resistors.

3) Insufficient conversion time/current.
Parasitic driven devices take considerably longer to do their conversion
than a powered device does (for this reason I generally recommend
powered sensors (See 1WRJ45 for one way how to supply power through a
cable). You will get a 85.0 result if the conversion has not completed
and a POR had occurred previously.

A powered device temperature conversion is typically around 650ms at
12bits (750ms max).  The DS18B20 uses a relatively crude internal timing
oscillator. And variations from both, temperature and internal chip
composition, etc. may effect the duration needed for a successful
temperature conversion cycle to complete, and the chip may draw as much
as 1.5ma during the conversion processes.  This may be why one chip
works and the other doesn't if you're just marginal with the timings.
(generally a good time to redesign your network to fix the fundamental
problems). I have heard of one batch of DS18X20's working in a circuit
and another not due to these slight internal differences on marginal
designed networks. This is not a failure of the parts, just of poor
network design and is generally corrected by insuring sufficient
conversion current is received by the temperature device for the entire
temperature conversion cycle. Powered temperature sensors may also be
polled for when the temperature conversion is complete (thus saving
time). See the datasheet for more information on this.

Another source of errors is too long delays in providing a strong
pull-up current for parasitic device. The sensor is issued a conversion
command, but a strong pull-up current is not applied for one reason or
another and the device loses power. This is only an issue with parasitic
operated devices obviously. It is generally a poor bus master design or
improper programming of the strong pull-up of the bus master.

4), Current supply limitations:
Since during a temperature conversion current use in the device can be
fairly high, (1.5ma max by spec) limitation of the network design may
affect this supplied current.

A). Limitations of the Bus master to supply conversion current.
  A LINK based design bus master can supply more current than a DS2480B
design (DS9097U-S09). A DS2490 (USB) can supply slightly more current
than a DS2480B unit. The Impedance matching line filter on the bus
master must also be considered if added to a DS9097U-S) or USB unit
(Generally a highly recommended practice to add the filter for signal
reflection issues). If the bus master is also parasiticlly powered this
may also be an issue or limitation.

B). Any additional bus line resistance.
The use of a DS2409 adds additional current limiting to what can be
supplied to downstream devices. Each channel of a DS2409 has a different
resistance. So channel use may also effect operation.  In addition the
DS2409 chip package sets the maximum pass-gate current to 20ma max.
according to Dallas (info not in data sheet) This can be a limitation in
any attempt to do bulk temperature conversions of parasitic downstream
devices.

C) Time delays generated by inline devices
A DS2409 can also cause a POR to occur on a temperature sensor after
switching channels using a smart-on command. (There are several errors
in the DS2409 data sheet that I've notified Dallas about, including the
flow diagram. Dallas has verified them and is correcting them in a new
revision of the data sheet. Though I am not sure if all of them will be
corrected by then).

Much of this information has been developed in my efforts on basic
research for a hardware book on 1-wire I am developing in my free time
(Still in early stages of writing, as I have very little of that. I do
however welcome suggestions and reports of problems that need to be
researched (contact me off list)).

I hope this information can be of help by the software writers in
understanding some of the possible conditions that can cause the
reporting of a 85.0C error in the software that should be considered. As
you can see when reporting an 85.0C error it might also be useful to
others to report the bus master used, any line filter, the number and
channels used in any hubs (and the hub design being used), along with
the temperature sensor wiring (powered or parasitic), the delivered
power voltage and the chip revision if known.

Hope this helps the software efforts,
 Cheers

David Lissiuk
Sr. Computer Scientist
Springbok Digitronics 

2007-11-11

BSD - Bastard patcheset for Linux kernel. 2.6.18-bsd40n-ovz

Sat Nov 10 13:38:45 CET 2007 Realtek's r8168 driver, this one works reliably with:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
in contrast to lenny's r8169 driver which oops'es every ~few hours with:
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:721!
invalid opcode: 0000 [#1]
SMP
Modules linked in: vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev ipt_ttl xt_tcpmss ipt_TCPMSS ipt_tos ext2 mbcache xt_length xt_CLASSIFY iptable_mangle cls_u32 sch_sfq sch_htb ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_nat xt_multiport ipt_REJECT xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables ata_piix ip_set softdog tg3 evdev parport_pc pcspkr parport rtc xfs dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod ide_disk ahci libata sd_mod 8139too jmicron ehci_hcd aic7xxx uhci_hcd e100 8139cp generic scsi_transport_spi mii r8169 ide_core scsi_mod usbcore thermal processor fan
CPU:    3, VCPU: -1.3
EIP:    0060:[<c0220b2d>]    Not tainted VLI
EFLAGS: 00010202   (2.6.18.bsd40l-vz #1)
EIP is at pskb_expand_head+0x20/0x115
eax: 00000001   ebx: f58a2600   ecx: ffffffe2   edx: f71b6900
esi: f71b6800   edi: 00000000   ebp: 00000002   esp: f7a45e24
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, veid: 0, ti=f7a44000 task=f7a9e640 task.ti=f7a44000)
Stack: f6ea9d8c f7a5991c f58a2600 f78172e0 f7817000 00000002 c022120a 00000020
       02000000 0000003a f78172e0 f7817000 f58a2600 f8a28674 f71b6910 f6f6e000
       f7a59918 f687b600 0000003c f6f6e3c0 f8a7c000 00000000 dd66a540 f687b600
 Call Trace:
 [<c022120a>] skb_pad+0xa0/0x10b
 [<f8a28674>] rtl8169_start_xmit+0x222/0x370 [r8169]
 [<c0224f6f>] dev_hard_start_xmit+0x1a7/0x1fd
 [<c0232d25>] __qdisc_run+0xf5/0x1d1
 [<c0226974>] dev_queue_xmit+0x142/0x24a
 [<c025e717>] arp_xmit+0x4e/0x50
 [<c025fb66>] arp_solicit+0x14e/0x158
 [<c022b9b9>] neigh_timer_handler+0x247/0x2aa
 [<c022b772>] neigh_timer_handler+0x0/0x2aa
 [<c0124820>] run_timer_softirq+0x10e/0x177
 [<c012067e>] __do_softirq+0x84/0x109
 [<c0120739>] do_softirq+0x36/0x3a
 [<c010344b>] apic_timer_interrupt+0x1f/0x24
 [<c0101842>] mwait_idle+0x25/0x38
 [<c0101807>] cpu_idle+0x5e/0x74
Code: 00 00 5e e9 f7 08 f4 ff 5b 5e c3 55 57 89 d7 56 53 89 c3 83 ec 08 8b 90 b0 00 00 00 8b b0 a4 00 00 00 8b 80 a0 00 00 00 48 74 0b <0f> 0b 66 b8 d1 02 b8 a3 77 2a c0 29 f2 8d 44 17 1f 8b 54 24 1c
EIP: [<c0220b2d>] pskb_expand_head+0x20/0x115 SS:ESP 0068:f7a45e24
Kernel panic - not syncing: Fatal exception in interrupt
.....
....
.....
Unbalanced enable for IRQ 169
BUG: warning at kernel/irq/manage.c:118/enable_irq()
 [<c01485a9>] enable_irq+0x54/0x87
 [<f8a9d8ba>] probe_hwif+0x556/0x627 [ide_core]
 [<c020c4b8>] __driver_attach+0x0/0x5d
 [<f8a9e1b5>] probe_hwif_init_with_fixup+0xb/0x63 [ide_core]
 [<f8a9ff89>] ide_setup_pci_device+0x3c/0x6d [ide_core]
 [<f8a2411e>] generic_init_one+0x92/0xa0 [generic]
 [<c01bd75c>] pci_device_probe+0x36/0x57
 [<c020c419>] driver_probe_device+0x42/0x8b
 [<c020c4f0>] __driver_attach+0x38/0x5d
 [<c020bf3a>] bus_for_each_dev+0x33/0x55
 [<c020c383>] driver_attach+0x11/0x13
 [<c020c4b8>] __driver_attach+0x0/0x5d
 [<c020bc53>] bus_add_driver+0x64/0xfd
 [<c01bd898>] __pci_register_driver+0x47/0x63
 [<c013c175>] sys_init_module+0x16c9/0x184c
 [<c016c454>] cp_new_stat64+0xfd/0x10f
 [<f8a3cdf8>] e100_probe+0x2ea/0x5f7 [e100]
 [<f8a3c7b0>] e100_get_wol+0xc/0x2d [e100]
 [<f8a3c6c0>] e100_get_drvinfo+0x1b/0x4c [e100]
 [<f8a3c7d8>] e100_set_wol+0x7/0x41 [e100]
 [<f8a3b000>] e100_setup_ucode+0x0/0xcc [e100]
 [<f8a3c494>] e100_tx_clean+0x3a/0xb8 [e100]
 [<f8a3c800>] e100_set_wol+0x2f/0x41 [e100]
 [<c010297f>] syscall_call+0x7/0xb
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:721!
invalid opcode: 0000 [#1]
SMP
Modules linked in: vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev ipt_ttl xt_tcpmss ipt_TCPMSS ipt_tos ext2 mbcache xt_length xt_CLASSIFY iptable_mangle cls_u32 sch_sfq sch_htb ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_nat xt_multiport ipt_REJECT xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables ata_piix ip_set softdog tg3 rtc parport_pc evdev parport pcspkr xfs dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod ide_disk sd_mod ahci libata jmicron 8139too ehci_hcd e100 aic7xxx scsi_transport_spi scsi_mod uhci_hcd generic ide_core 8139cp r8169 mii usbcore thermal processor fan
CPU:    0, VCPU: -1.0
EIP:    0060:[<c0220b2d>]    Not tainted VLI
EFLAGS: 00010202   (2.6.18.bsd40l-vz #1)
EIP is at pskb_expand_head+0x20/0x115
eax: 00000001   ebx: da11a980   ecx: ffffffe2   edx: eca99f00
esi: eca99e00   edi: 00000000   ebp: 00000002   esp: c030fe48
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, veid: 0, ti=c030e000 task=c02c26c0 task.ti=c030e000)
Stack: f74a7d8c f6ebeadc da11a980 f78fc2e0 f78fc000 00000002 c022120a 00000020
       02000000 0000003a f78fc2e0 f78fc000 da11a980 f8a47674 eca99f10 f6f3f000
       f6ebead8 f6c97600 0000003d f6f3f3d0 f8a2a000 00000000 f0f7cc80 f6c97600
 Call Trace:
 [<c022120a>] skb_pad+0xa0/0x10b
 [<f8a47674>] rtl8169_start_xmit+0x222/0x370 [r8169]
 [<c0224f6f>] dev_hard_start_xmit+0x1a7/0x1fd
 [<c0232d25>] __qdisc_run+0xf5/0x1d1
 [<c0226974>] dev_queue_xmit+0x142/0x24a
 [<c025e717>] arp_xmit+0x4e/0x50
 [<c025fb66>] arp_solicit+0x14e/0x158
 [<c022b9b9>] neigh_timer_handler+0x247/0x2aa
 [<c022b772>] neigh_timer_handler+0x0/0x2aa
 [<c0124820>] run_timer_softirq+0x10e/0x177
 [<c012067e>] __do_softirq+0x84/0x109
 [<c0120739>] do_softirq+0x36/0x3a
 [<c010344b>] apic_timer_interrupt+0x1f/0x24
 [<c0101842>] mwait_idle+0x25/0x38
 [<c0101807>] cpu_idle+0x5e/0x74
 [<c0314723>] start_kernel+0x39c/0x3a3
Code: 00 00 5e e9 f7 08 f4 ff 5b 5e c3 55 57 89 d7 56 53 89 c3 83 ec 08 8b 90 b0 00 00 00 8b b0 a4 00 00 00 8b 80 a0 00 00 00 48 74 0b <0f> 0b 66 b8 d1 02 b8 a3 77 2a c0 29 f2 8d 44 17 1f 8b 54 24 1c
EIP: [<c0220b2d>] pskb_expand_head+0x20/0x115 SS:ESP 0068:c030fe48
Kernel panic - not syncing: Fatal exception in interrupt
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:721!
invalid opcode: 0000 [#1]
SMP
Modules linked in: vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev ipt_ttl xt_tcpmss ipt_TCPMSS ipt_tos ext2 mbcache xt_length xt_CLASSIFY iptable_mangle cls_u32 sch_sfq sch_htb ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_nat xt_multiport ipt_REJECT xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables ata_piix ip_set softdog tg3 parport_pc parport rtc pcspkr evdev xfs dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod ide_disk ahci libata jmicron sd_mod aic7xxx generic scsi_transport_spi ehci_hcd uhci_hcd e100 8139too 8139cp scsi_mod mii r8169 ide_core usbcore thermal processor fan
CPU:    1, VCPU: -1.1
EIP:    0060:[<c0220add>]    Not tainted VLI
EFLAGS: 00010202   (2.6.18.bsd40m-vz #1)
EIP is at pskb_expand_head+0x20/0x115
eax: 00000001   ebx: d2f5a500   ecx: ffffffe2   edx: d9ad1b00
esi: d9ad1a00   edi: 00000000   ebp: 00000002   esp: f7a03e24
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, veid: 0, ti=f7a02000 task=f7abf220 task.ti=f7a02000)
Stack: f6e73d8c f7d5bc9c d2f5a500 f78c02e0 f78c0000 00000002 c02211ba 00000020
       02000000 0000003a f78c02e0 f78c0000 d2f5a500 f8a285cc d9ad1b10 f79c7000
       f7d5bc98 f6ee3a00 00000030 f79c7300 f8a3c000 00000000 f6f26680 f6ee3a00
 Call Trace:
 [<c02211ba>] skb_pad+0xa0/0x10b
 [<f8a285cc>] rtl8169_start_xmit+0x222/0x370 [r8169]
 [<c0224f1f>] dev_hard_start_xmit+0x1a7/0x1fd
 [<c0232cd5>] __qdisc_run+0xf5/0x1d1
 [<c0226924>] dev_queue_xmit+0x142/0x24a
 [<c025e6be>] arp_xmit+0x4e/0x50
 [<c025fb0d>] arp_solicit+0x14e/0x158
 [<c022b969>] neigh_timer_handler+0x247/0x2aa
 [<c022b722>] neigh_timer_handler+0x0/0x2aa
 [<c0124820>] run_timer_softirq+0x10e/0x177
 [<c012067e>] __do_softirq+0x84/0x109
 [<c0120739>] do_softirq+0x36/0x3a
 [<c010344b>] apic_timer_interrupt+0x1f/0x24
 [<c0101842>] mwait_idle+0x25/0x38
 [<c0101807>] cpu_idle+0x5e/0x74
Code: 00 00 5e e9 47 09 f4 ff 5b 5e c3 55 57 89 d7 56 53 89 c3 83 ec 08 8b 90 b0 00 00 00 8b b0 a4 00 00 00 8b 80 a0 00 00 00 48 74 0b <0f> 0b 66 b8 d1 02 b8 72 77 2a c0 29 f2 8d 44 17 1f 8b 54 24 1c
EIP: [<c0220add>] pskb_expand_head+0x20/0x115 SS:ESP 0068:f7a03e24
Kernel panic - not syncing: Fatal exception in interrupt

2007-11-01

BSD - Bastard patcheset for Linux kernel. 2.6.18-bsd40m

Thu Nov 1 13:38:45 CET 2007 Backports for r8169 support, JMicron PATA support. Various fixes.. OpenVZ 028stab047.1 plus compilation fix

Compiling kernels inside openvz

Contenders:
simfs                 112G   26G   87G  23% /
/dev/shm              2.0G  369M  1.7G  18% /home/eyck/ramdysk
Fight:
export CONCURRENCY_LEVEL=8

eyck@etchdev386:~/40m-ovz/work$ time nice rm -r linux* patches Patching.log && time sh rediff.sh
...
make[1]: Leaving directory `/home/eyck/40m-ovz/work/linux-2.6.18'
====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]======
This is kernel package version 10.067.
echo done > stamp-kernel-headers
====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]======
This is kernel package version 10.067.

real    17m19.657s
user    28m30.859s
sys     6m11.603s

real    18m3.658s
user    28m44.144s
sys     6m40.757s
export CONCURRENCY_LEVEL=8

eyck@etchdev386:~/ramdysk/40m-ovz/work$ time nice rm -r linux* patches Patching.log && time sh rediff.sh
....
====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]======
This is kernel package version 10.067.
echo done > stamp-kernel-headers
====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]======
This is kernel package version 10.067.

real    17m19.916s
user    28m14.074s
sys     5m35.077s

real    17m56.725s
user    28m26.523s
sys     5m52.778s
Soo... it looks like (since this machine has 14G ram) it managed too cache all the files, and there's no visible advantage to using ramdisc. And now without openvz overhead:
export CONCURRENCY_LEVEL=8
....
make[1]: Leaving directory `/home/eyck/ramdysk/40m-ovz/work/linux-2.6.18'
====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]======
This is kernel package version 10.067.
echo done > stamp-kernel-headers
====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]======
This is kernel package version 10.067.

real    17m36.922s
user    28m8.894s
sys     5m30.633s

real    18m13.800s
user    28m21.430s
sys     5m48.630s

export CONCURRENCY_LEVEL=8
....

make[1]: Leaving directory `/home/eyck/40m-ovz/work/linux-2.6.18'
====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]======
This is kernel package version 10.067.
echo done > stamp-kernel-headers
====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]======
This is kernel package version 10.067.

real    17m55.724s
user    28m26.759s
sys     6m2.363s

real    18m45.132s
user    28m39.971s
sys     6m31.328s

eyck@codev64:~/40m-ovz/work$ export CONCURRENCY_LEVEL=16 eyck@codev64:~/40m-ovz/work$ time nice rm -r linux* patches Patching.log && time sh rediff.sh cp -pf debian/control.dist debian/control make[1]: Leaving directory `/home/eyck/40m-ovz/work/linux-2.6.18' ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 20m5.180s user 28m41.280s sys 5m57.190s real 20m52.680s user 28m54.396s sys 6m26.556s eyck@codev64:~/40m-ovz/work$ export CONCURRENCY_LEVEL=4 ... ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 15m11.809s user 28m24.991s sys 5m47.362s real 15m58.245s user 28m37.815s sys 6m16.424s eyck@codev64:~/40m-ovz/work$ export CONCURRENCY_LEVEL=2 ... ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 21m25.527s user 27m58.473s sys 5m22.156s real 22m9.967s user 28m11.438s sys 5m51.326s eyck@etchdev386:~/40m-ovz/work$ export CONCURRENCY_LEVEL=6 ... echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 15m8.466s user 28m36.763s sys 6m10.971s real 15m52.911s user 28m49.976s sys 6m40.661s real 16m3.678s user 28m50.100s sys 6m44.369s eyck@etchdev386:~/40m-ovz/work$ export CONCURRENCY_LEVEL=8 echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 17m56.831s user 28m18.070s sys 6m6.831s real 18m41.792s user 28m31.331s sys 6m36.289s real 18m53.592s user 28m31.447s sys 6m39.985s

2007-09-19

Blacklist module - stop it from being loaded by modprobe/udev

echo "blacklist intel_agp" >> /etc/modprobe.d/blacklist

2007-09-09

RaidF: FlashRaid - best solution for flash filesystems

  1. Divide your flash-based block device into >3 parts, for example let's use 12 sections.
  2. Raid5 (or Raid6 if you need more protection) them.
  3. use resulting block device as base for your filesystems/swap.

This way you can run without wear-levelling layer (which AFAIK can't work in general case, because you would need Size/blocksize bytes/nibbles of additional wear-resistant storage to keep statistics of your wear), AND you gain additional protection, for very little price ( less then 10% of your storage ).

Conventional wisdom says you shouldn't raid on single device, but since flash devices are not mechanical and don't suffer noticable seek penalty you can do this with very little loss of performance. If you'd do this in hardware inside your card, there would be no performance penalty.

Another problem is that raid5/raid6 are famouse for their poor write speed, but, since you're already writing whole blocks-at-a-time when dealing with flash devices, you're already paying the prices (writing block-at-a-time is the best case scenario for raid5/6, there's no need to recalculate checksums then)

  1. Effective protection for wear problems, plus additional protection for other block errors
  2. Very small price storage-wise (<10%)
  3. Very small performance penalty when you synchronise flash blocks with raid blocks (the penalty for writing less-then-block-at-a-time is already payed when dealing with flash, raid penalty is virtually non-existant then)
  4. Ideal for embedding in hardware, but doable on software-side

Note: it doesn't make much sense to use raid5 instead of raid4 in this case. And raid4e for double protection. TODO: implement RaidF as dm layer?

2007-09-06

Upgrade to LVM2 from LVM1 on running system

Problem:

homenode:/home/eyck# pvcreate /dev/cciss/c0d2p5
  Physical volume "/dev/cciss/c0d2p5" successfully created
homenode:/home/eyck# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "sys" using metadata type lvm1
homenode:/home/eyck# vgextend sys /dev/cciss/c0d2p5
  Physical volume /dev/cciss/c0d2p5 is of different format type (lvm2)
  Unable to add physical volume '/dev/cciss/c0d2p5' to volume group 'sys'.
homenode:/home/eyck# pvscan
  PV /dev/cciss/c0d0p3   VG sys   lvm1 [66.34 GB / 0    free]
  PV /dev/cciss/c0d1p5   VG sys   lvm1 [130.34 GB / 6.19 GB free]
  PV /dev/cciss/c0d2p5            lvm2 [33.91 GB]
  Total: 3 [230.60 GB] / in use: 2 [196.69 GB] / in no VG: 1 [33.91 GB]

Solution:


homenode:/home/eyck# vgconvert -M2 sys
  Volume group sys successfully converted
homenode:/home/eyck# pvscan 
  PV /dev/cciss/c0d0p3   VG sys   lvm2 [66.34 GB / 0    free]
  PV /dev/cciss/c0d1p5   VG sys   lvm2 [130.34 GB / 6.19 GB free]
  PV /dev/cciss/c0d2p5            lvm2 [33.91 GB]
  Total: 3 [230.60 GB] / in use: 2 [196.69 GB] / in no VG: 1 [33.91 GB]
homenode:/home/eyck# vgextend sys /dev/cciss/c0d2p5
  Volume group "sys" successfully extended
homenode:/home/eyck# pvscan 
  PV /dev/cciss/c0d0p3   VG sys   lvm2 [66.34 GB / 0    free]
  PV /dev/cciss/c0d1p5   VG sys   lvm2 [130.34 GB / 6.19 GB free]
  PV /dev/cciss/c0d2p5   VG sys   lvm2 [33.91 GB / 33.91 GB free]
  Total: 3 [230.59 GB] / in use: 3 [230.59 GB] / in no VG: 0 [0   ]

homenode:/home/eyck# lvextend -L+5G /dev/sys/v
  Extending logical volume v to 194.50 GB
  Logical volume v successfully resized
homenode:/home/eyck# xfs_growfs /fs/v/
meta-data=/dev/sys/v             isize=256    agcount=61, agsize=819200 blks
         =                       sectsz=512   attr=1
data     =                       bsize=4096   blocks=49676288, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=6400, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 49676288 to 50987008

2007-09-05

Create Degraded Raid1

gnoll2:~# mdadm --create /dev/md1 --level 1 --raid-devices=2 missing /dev/hdh5
mdadm: array /dev/md1 started.
gnoll2:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 hdh5[1]
      77152064 blocks [2/1] [_U]
            
unused devices: <none>

gnoll2:/fs/tmp# mdadm --add /dev/md1 /dev/hde5 
mdadm: added /dev/hde5
gnoll2:/fs/tmp# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 hde5[2] hdh5[1]
      77152064 blocks [2/1] [_U]
            [>....................]  recovery =  0.0% (18560/77152064) finish=414.6min speed=3093K/sec
	          
unused devices: <none>
gnoll2:/fs/tmp# 

2007-08-27

naviinittoolcli

./naviinittoolcli

...
Navisphere Array Initialization Tool Version 6.24.0.6.7


 # 17:10:54.728973 IP 10.11.12.231.35294 > 255.255.255.255.2162: UDP, length 71
 #
 # 17:14:28.211377 IP 10.11.12.231.35294 > 255.255.255.255.2162: UDP, length 71
 #        0x0000:  4500 0063 0000 4000 4011 bafa c0a8 bee7  E..c..@.@.......
 #        0x0010:  ffff ffff 89de 0872 004f f516 3c54 3120  .......r.O..<T1.
 #        0x0020:  5433 3d22 5434 2220 5432 3d22 4154 4154  T3="T4".T2="ATAT
 #        0x0030:  5544 4522 2054 373d 2231 3237 2e30 2e30  UDE".T7="127.0.0
 #        0x0040:  2e31 2220 5433 343d 2236 2e32 342e 3022  .1".T34="6.24.0"
 #        0x0050:  203e                                     .>

No storage systems discovered. Please verify the following items and try again.
1. The storage systems are powered up.
2. The storage systems are plugged in to the network.
3. This wizard is run on a client machine that is in the same physical subnet as the storage systems.

2007-08-04

Vserver and Xorg

(2.2.x) don't forget to procunhide /proc/bus/pci/ and /proc/bus in /etc/vservers/.defaults/apps/vprocunhide/files (create it based on /usr/lib/util-vserver/defaults/vprocunhide-files)

2007-06-27

Setting up Linux *SWAN Ipsec for nokia e61

Cached from: http://www.thorsten-knabe.de/linux/e61.jsp

Connecting the Nokia E61 Mobile VPN client to a Linux OpenSwan IPSEC gateway

This page describes how to configure and setup the Nokia E61 Mobile VPN client and Linux Openswan IPSEC gateway to establish an encrypted IPSEC tunnel between the two devices. The procedure described herein should work for other mobile devices equipped with a Nokia Mobile VPN Client as well, especially Symbian S60 3rd edition based mobile phones, but has not been tested.

Legal advice: This page contains links to external internet sites containing additional information, that might be helpful in the course of setting up the IPSEC tunnel. I have no influence on the content and disclaim any responsibilty for the content provided by those external internet sites.
All information on this page is provided as is without any warranty. I am not responsible or liable for any damage caused by following the steps described below. If you damage your phone, it is your fault not mine!

Prerequisites

Linux prerequisites

For my setup I chose a vanilla Linux 2.6.19.1 with IPSEC support and OpenSwan 2.4.6 from Debian testing. Other kernels, distributions and OpenSwan versions could work as well but have not been tested.

E61 prerequisites

In oder to establish a VPN connection from the Nokia Mobile VPN client, a policy file has to be uploaded to the phone. For some reason, such a policy file cannot be uploaded directly to the phone, but has to be packed into a signed SIS file first. To create such a signed SIS file, you need a developer certificate and two Windows executables from the S60 Platform SDK for Symbian OS for C++ 3rd edition. Luckily those two Windows executables and the Windows executable to create the developer certificate run happily using Wine under Linux.

The S60 Platform SDK for Symbian OS for C++ 3rd edition is available from http://www.forum.nokia.com -> Tools & SDKs -> C++ for Symbian OS Tools and SDKs -> S60 Platform for Symbian OS -> 3rd Edition. To unpack the SDK under Linux follow the instructions on Rudolf Königs page.

A free developer cetificate and the Windows executable to create such a certificate is available from https://www.symbiansigned.com. Follow the steps on this site to obtain a valid developer certificate. Afterwards you should have a .key and a corresponding .cer file which are later required to sign the SIS file containing the VPN policy file.

Configuration

Before you start configuration, you should collect the following information, which are required during the configuration process. The actual values are replaced by the following placeholders in the example configuration files below:

<group name>: Group name for IKE phase 1. This value is ignored by the current OpenSwan configuration.

<group password>: Group password for IKE phase 1. Choose a good password for this parameter and keep it secret as it is the only thing needed to know to get access to your internal network if you do not use XAUTH authentication.

<strlen(group password)>: Length of group password

<external gateway>: External static IP address of the OpenSwan gateway. This address is used for authentication and encrypted data exchange.

<internal gateway>: Internal IP address of the OpenSwan gateway. This address is used when sending packets from the VPN gateway through the VPN tunnel to the client.

<internal client>: Internal IP address assigned to the VPN client. This address is used by the client when sending packets through the VPN tunnel.

<key password>: The password of your developer key from www.symbiansigned.com.

OpenSwan configuration

On Debian there are 3 files that have to be edited or created in order to configure OpenSwan as a VPN gateway for the Nokia Mobile VPN client.

/etc/ipsec.secrets

Add a wildcard PSK (Pre-Shared Key) entry to your ipsec.secrets file. Afterwards your ipsec.secrets file should look like this:

: PSK "<group password>"

/etc/ipsec.conf

Add an include directive to the ipsec.conf configuration file. The included file contains the actual configuration for the newly created connection to the Mobile VPN client. Afterwards your ipsec.conf should look like this:

version 2.0

config setup
        nat_traversal=yes
        nhelpers=0
        #plutodebug=all

# Add connections here
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
include /etc/ipsec.d/examples/e61.conf

/etc/ipsec.d/examples/e61.conf

Create a file named e61.conf for the connection parameters with the following contents:

conn E61
        # Key exchange
        ike=aes256-sha1-modp1536
        # Data exchange
        esp=aes256-sha1
        # Authentication method PSK
        authby=secret
        auto=add
        keyingtries=3
        rekey=no
        pfs=no
        # Modeconfig setting
        modecfgpull=yes
        # local endpoint
        left=<external gateway>
        leftxauthserver=yes
        leftmodecfgserver=yes
        leftsourceip=<internal gateway>
        leftsubnet=0.0.0.0/0
        # remote endpoint
        right=%any
        rightxauthclient=yes
        rightmodecfgclient=yes
        rightsourceip=<internal client>
        rightsubnet=<internal client>/32

If you set leftxauthserver and rightxauthclient to no, XAUTH authentication will be disabled. Disabling XAUTH authentication might be helpful, if you experience problems during VPN setup, but should not be disabled in production use for security reasons.

Creating a signed SIS file containing the VPN policy

The Nokia Mobile VPN client is configured by the policy file VPN.pol shown below, that has to be uploaded to the phone in a signed SIS file.

In order to create a signed SIS file, two additional files are required. The VPN.pin file contains some (useless) meta information about the policy file, but is required and the VPN.pkg file, which describes the contents of the SIS file. Important: All 3 files have to be created with DOS line delimiters (in vi use: set ff=dos), otherwise the tools or the VPN will not work correctly.

VPN.pol

SECURITY_FILE_VERSION: 3
[INFO]
VPN
[POLICY]
sa ipsec_1 = {
 esp
 encrypt_alg 12
 max_encrypt_bits 256
 auth_alg 3
 identity_remote 0.0.0.0/0
 src_specific
 hard_lifetime_bytes 0
 hard_lifetime_addtime 3600
 hard_lifetime_usetime 3600
 soft_lifetime_bytes 0
 soft_lifetime_addtime 3600
 soft_lifetime_usetime 3600
}
remote 0.0.0.0 0.0.0.0 = { ipsec_1(<external gateway>) }
inbound = { }
outbound = { }
[IKE]
ADDR: <external gateway> 255.255.255.255
MODE: MAIN
SEND_NOTIFICATION: TRUE
ID_TYPE: 11
FQDN: <group name>
GROUP_DESCRIPTION_II: MODP_1536
USE_COMMIT: FALSE
IPSEC_EXPIRE: FALSE
SEND_CERT: FALSE
INITIAL_CONTACT: FALSE
RESPONDER_LIFETIME: TRUE
REPLAY_STATUS: TRUE
USE_INTERNAL_ADDR: FALSE
USE_NAT_PROBE: FALSE
ESP_UDP_PORT: 0
NAT_KEEPALIVE: 60
USE_XAUTH: TRUE
USE_MODE_CFG: TRUE
REKEYING_THRESHOLD: 90
PROPOSALS: 1
ENC_ALG: AES256-CBC
AUTH_METHOD: PRE-SHARED
HASH_ALG: SHA1
GROUP_DESCRIPTION: MODP_1536
GROUP_TYPE: DEFAULT
LIFETIME_KBYTES: 0
LIFETIME_SECONDS: 28800
PRF: NONE
PRESHARED_KEYS:
FORMAT: STRING_FORMAT
KEY: <strlen(group password)> <group password>

If you want to disable XAUTH authentication set USE_XAUTH to FALSE and modify the e61.conf file on the VPN gateway accordingly.

VPN.pin

[POLICYNAME]
VPN
[POLICYDESCRIPTION]
VPN
[POLICYVERSION]
1.1
[ISSUERNAME]
Do not edit
[CONTACTINFO]
Do not edit

VPN.pkg

;
; A VPN POLICY PACKAGE
;
%{"VPN"}
:"VPN"
&EN
; - None (English only by default)
; INSTALLATION HEADER
; - Only one component name is needed to support English only
; - UID is the UID of the VPN Policy Installer application
#{"VPN"},(0x3D08B4F7),1,0,0,TYPE = SA
; LIST OF FILES
; Policy file
"VPN.pol"-"C:\System\Data\Security\Install\VPN.pol"
; Policy-information file
; - NOTE: The policy-information file MUST be the last file in this
; list!
; - FM (FILEMIME) passes the file to the respective MIME handler
; (in this case, the VPN Policy Installer
    ; application).
"VPN.pin"-"C:\System\Data\Security\Install\VPN.pin",
FM, "application/x-ipsec-policy-info"
; REQUIRED FILES
; - The VPN Policy Installer application
(0x3D08B4F7), 1, 0, 0, {"VPN Policy Installer"}

Note: The two absolute paths are paths on the phone and must not be modified.

Create an unsigned SIS file

The unsigned SIS file is created by the makesis.exe utility. With the VPN.pol, VPN.pin and VPN.pkg file in the current working directory the makesis utility must be invoked as follows:

makesis.exe VPN.pkg VPN.sis

Afterwards you should have a VPN.sis file in your current working directory.

Create a signed SIS file

The SIS file created in the last step is still unsigned and has to be signed to be accepted by the phone. The SIS file is signed using the signsis.exe utility. It is invoked as follows, assuming the previously created SIS file and the VPN.key and VPN.cer file from www.symbiansigned.com are all located in the current working directory:

signsis.exe VPN.sis VPN.sisx VPN.cer VPN.key <key password>

Afterwards you should have a signed SIS file called VPN.sisx in your current working directory, which can be uploaded to your phone.

Mobile phone configuration

Before you start configuring the Nokia Mobile VPN client, you have to upload the signed SIS file created in the previous step to the phone. This can be done using an USB cable, infrared or Bluetooth or you can download the file from a web site. During installation of the policy file, you might get several warnings regarding the developer cerificate and phone incompatibilities, ignore and confirm all of them. After the installation completes the policy should be listed under VPN policies in the phone.

To create a new VPN connection configuration navigate to Menu -> Tools -> Settings -> Connection -> VPN -> VPN management -> VPN policies, highlight a policy and select Options -> Define VPN access point. Configure the connection by specifiying a name, a policy and an internet access point.

You should now be able to use the VPN connection like any other connection. If you have not disabled XAUTH authentication, you are asked for a username and password on connection setup. Enter a valid system user and password of the VPN gateway. That's it! You should now be connected to your VPN.

Caveats & Solutions

DNS servers

During connection setup the VPN client obtains IP address, netmask and DNS settings from the VPN gateway, there is no way to modify those parameters on the phone.
In OpenSwan 2.4.6 there is no (easy) way to configure the DNS servers to be used by the VPN client. DNS servers can only be set using PAM environment variables, which are only available when XAUTH is enabled.

To circumvent this shortcoming I have created a small patch against OpenSwan 2.4.6, which allows setting DNS servers using ordinary environment variables. If you set the environment variables DNS1 and DNS2 before you start OpenSwan, those parameters are transmitted to the VPN client as the primary and secondary DNS server. The patch is available here: openswan-2.4.6.diff

Connecting the Nokia E61 Mobile VPN client to a Linux OpenSwan IPSEC gateway This page describes how to configure and setup the Nokia E61 Mobile VPN client and Linux Openswan IPSEC gateway to establish an encrypted IPSEC tunnel between the two devices. The procedure described herein should work for other mobile devices equipped with a Nokia Mobile VPN Client as well, especially Symbian S60 3rd edition based mobile phones, but has not been tested. Legal advice: This page contains links to external internet sites containing additional information, that might be helpful in the course of setting up the IPSEC tunnel. I have no influence on the content and disclaim any responsibilty for the content provided by those external internet sites. All information on this page is provided as is without any warranty. I am not responsible or liable for any damage caused by following the steps described below. If you damage your phone, it is your fault not mine! Prerequisites Linux prerequisites For my setup I chose a vanilla Linux 2.6.19.1 with IPSEC support and OpenSwan 2.4.6 from Debian testing. Other kernels, distributions and OpenSwan versions could work as well but have not been tested. E61 prerequisites In oder to establish a VPN connection from the Nokia Mobile VPN client, a policy file has to be uploaded to the phone. For some reason, such a policy file cannot be uploaded directly to the phone, but has to be packed into a signed SIS file first. To create such a signed SIS file, you need a developer certificate and two Windows executables from the S60 Platform SDK for Symbian OS for C++ 3rd edition. Luckily those two Windows executables and the Windows executable to create the developer certificate run happily using Wine under Linux. The S60 Platform SDK for Symbian OS for C++ 3rd edition is available from http://www.forum.nokia.com -> Tools & SDKs -> C++ for Symbian OS Tools and SDKs -> S60 Platform for Symbian OS -> 3rd Edition. To unpack the SDK under Linux follow the instructions on Rudolf Königs page. A free developer cetificate and the Windows executable to create such a certificate is available from https://www.symbiansigned.com. Follow the steps on this site to obtain a valid developer certificate. Afterwards you should have a .key and a corresponding .cer file which are later required to sign the SIS file containing the VPN policy file. Configuration Before you start configuration, you should collect the following information, which are required during the configuration process. The actual values are replaced by the following placeholders in the example configuration files below: : Group name for IKE phase 1. This value is ignored by the current OpenSwan configuration. : Group password for IKE phase 1. Choose a good password for this parameter and keep it secret as it is the only thing needed to know to get access to your internal network if you do not use XAUTH authentication. : Length of group password : External static IP address of the OpenSwan gateway. This address is used for authentication and encrypted data exchange. : Internal IP address of the OpenSwan gateway. This address is used when sending packets from the VPN gateway through the VPN tunnel to the client. : Internal IP address assigned to the VPN client. This address is used by the client when sending packets through the VPN tunnel. : The password of your developer key from www.symbiansigned.com. OpenSwan configuration On Debian there are 3 files that have to be edited or created in order to configure OpenSwan as a VPN gateway for the Nokia Mobile VPN client. /etc/ipsec.secrets Add a wildcard PSK (Pre-Shared Key) entry to your ipsec.secrets file. Afterwards your ipsec.secrets file should look like this: : PSK "" /etc/ipsec.conf Add an include directive to the ipsec.conf configuration file. The included file contains the actual configuration for the newly created connection to the Mobile VPN client. Afterwards your ipsec.conf should look like this: version 2.0 config setup nat_traversal=yes nhelpers=0 #plutodebug=all # Add connections here #Disable Opportunistic Encryption include /etc/ipsec.d/examples/no_oe.conf include /etc/ipsec.d/examples/e61.conf /etc/ipsec.d/examples/e61.conf Create a file named e61.conf for the connection parameters with the following contents: conn E61 # Key exchange ike=aes256-sha1-modp1536 # Data exchange esp=aes256-sha1 # Authentication method PSK authby=secret auto=add keyingtries=3 rekey=no pfs=no # Modeconfig setting modecfgpull=yes # local endpoint left= leftxauthserver=yes leftmodecfgserver=yes leftsourceip= leftsubnet=0.0.0.0/0 # remote endpoint right=%any rightxauthclient=yes rightmodecfgclient=yes rightsourceip= rightsubnet=/32 If you set leftxauthserver and rightxauthclient to no, XAUTH authentication will be disabled. Disabling XAUTH authentication might be helpful, if you experience problems during VPN setup, but should not be disabled in production use for security reasons. Creating a signed SIS file containing the VPN policy The Nokia Mobile VPN client is configured by the policy file VPN.pol shown below, that has to be uploaded to the phone in a signed SIS file. In order to create a signed SIS file, two additional files are required. The VPN.pin file contains some (useless) meta information about the policy file, but is required and the VPN.pkg file, which describes the contents of the SIS file. Important: All 3 files have to be created with DOS line delimiters (in vi use: set ff=dos), otherwise the tools or the VPN will not work correctly. VPN.pol SECURITY_FILE_VERSION: 3 [INFO] VPN [POLICY] sa ipsec_1 = { esp encrypt_alg 12 max_encrypt_bits 256 auth_alg 3 identity_remote 0.0.0.0/0 src_specific hard_lifetime_bytes 0 hard_lifetime_addtime 3600 hard_lifetime_usetime 3600 soft_lifetime_bytes 0 soft_lifetime_addtime 3600 soft_lifetime_usetime 3600 } remote 0.0.0.0 0.0.0.0 = { ipsec_1() } inbound = { } outbound = { } [IKE] ADDR: 255.255.255.255 MODE: MAIN SEND_NOTIFICATION: TRUE ID_TYPE: 11 FQDN: GROUP_DESCRIPTION_II: MODP_1536 USE_COMMIT: FALSE IPSEC_EXPIRE: FALSE SEND_CERT: FALSE INITIAL_CONTACT: FALSE RESPONDER_LIFETIME: TRUE REPLAY_STATUS: TRUE USE_INTERNAL_ADDR: FALSE USE_NAT_PROBE: FALSE ESP_UDP_PORT: 0 NAT_KEEPALIVE: 60 USE_XAUTH: TRUE USE_MODE_CFG: TRUE REKEYING_THRESHOLD: 90 PROPOSALS: 1 ENC_ALG: AES256-CBC AUTH_METHOD: PRE-SHARED HASH_ALG: SHA1 GROUP_DESCRIPTION: MODP_1536 GROUP_TYPE: DEFAULT LIFETIME_KBYTES: 0 LIFETIME_SECONDS: 28800 PRF: NONE PRESHARED_KEYS: FORMAT: STRING_FORMAT KEY: If you want to disable XAUTH authentication set USE_XAUTH to FALSE and modify the e61.conf file on the VPN gateway accordingly. VPN.pin [POLICYNAME] VPN [POLICYDESCRIPTION] VPN [POLICYVERSION] 1.1 [ISSUERNAME] Do not edit [CONTACTINFO] Do not edit VPN.pkg ; ; A VPN POLICY PACKAGE ; %{"VPN"} :"VPN" &EN ; - None (English only by default) ; INSTALLATION HEADER ; - Only one component name is needed to support English only ; - UID is the UID of the VPN Policy Installer application #{"VPN"},(0x3D08B4F7),1,0,0,TYPE = SA ; LIST OF FILES ; Policy file "VPN.pol"-"C:\System\Data\Security\Install\VPN.pol" ; Policy-information file ; - NOTE: The policy-information file MUST be the last file in this ; list! ; - FM (FILEMIME) passes the file to the respective MIME handler ; (in this case, the VPN Policy Installer ; application). "VPN.pin"-"C:\System\Data\Security\Install\VPN.pin", FM, "application/x-ipsec-policy-info" ; REQUIRED FILES ; - The VPN Policy Installer application (0x3D08B4F7), 1, 0, 0, {"VPN Policy Installer"} Note: The two absolute paths are paths on the phone and must not be modified. Create an unsigned SIS file The unsigned SIS file is created by the makesis.exe utility. With the VPN.pol, VPN.pin and VPN.pkg file in the current working directory the makesis utility must be invoked as follows: makesis.exe VPN.pkg VPN.sis Afterwards you should have a VPN.sis file in your current working directory. Create a signed SIS file The SIS file created in the last step is still unsigned and has to be signed to be accepted by the phone. The SIS file is signed using the signsis.exe utility. It is invoked as follows, assuming the previously created SIS file and the VPN.key and VPN.cer file from www.symbiansigned.com are all located in the current working directory: signsis.exe VPN.sis VPN.sisx VPN.cer VPN.key Afterwards you should have a signed SIS file called VPN.sisx in your current working directory, which can be uploaded to your phone. Mobile phone configuration Before you start configuring the Nokia Mobile VPN client, you have to upload the signed SIS file created in the previous step to the phone. This can be done using an USB cable, infrared or Bluetooth or you can download the file from a web site. During installation of the policy file, you might get several warnings regarding the developer cerificate and phone incompatibilities, ignore and confirm all of them. After the installation completes the policy should be listed under VPN policies in the phone. To create a new VPN connection configuration navigate to Menu -> Tools -> Settings -> Connection -> VPN -> VPN management -> VPN policies, highlight a policy and select Options -> Define VPN access point. Configure the connection by specifiying a name, a policy and an internet access point. You should now be able to use the VPN connection like any other connection. If you have not disabled XAUTH authentication, you are asked for a username and password on connection setup. Enter a valid system user and password of the VPN gateway. That's it! You should now be connected to your VPN. Caveats & Solutions DNS servers During connection setup the VPN client obtains IP address, netmask and DNS settings from the VPN gateway, there is no way to modify those parameters on the phone. In OpenSwan 2.4.6 there is no (easy) way to configure the DNS servers to be used by the VPN client. DNS servers can only be set using PAM environment variables, which are only available when XAUTH is enabled. To circumvent this shortcoming I have created a small patch against OpenSwan 2.4.6, which allows setting DNS servers using ordinary environment variables. If you set the environment variables DNS1 and DNS2 before you start OpenSwan, those parameters are transmitted to the VPN client as the primary and secondary DNS server. The patch is available here: openswan-2.4.6.diff _____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Back 2356 visitors Imprint

2007-05-15

apt-get: Floating point exception

sid: ~# apt-get update
Floating point exception
Culprit: gcc 4.1.2 runtime (gcc-4.1-base libgcc and libstdc++ )
sid: ~# dpkg -i /var/cache/apt/archives/libstdc++6_4.1.1-21_i386.deb
dpkg - warning: downgrading libstdc++6 from 4.1.2-5 to 4.1.1-21.
(Reading database ... 17076 files and directories currently installed.)
Preparing to replace libstdc++6 4.1.2-5 (using .../libstdc++6_4.1.1-21_i386.deb) ...
Unpacking replacement libstdc++6 ...
Setting up libstdc++6 (4.1.1-21) ...

sid: ~# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done

2007-04-08

mount /dev/s/usr U && mv usr/* U/ && umount U && mount /dev/s/usr /usr && grep usr /etc/mtab >> /etc/fstab mount /dev/s/var V && mv var/* V/ && umount V && mount /dev/s/var /var && grep var /etc/mtab >> /etc/fstab

1) rmmod is missing 2) cfdisk is missing 3) ping is missing 4) tcpdump is missing 5) less is missing

2007-02-08

Display

RemoteDisplay.vnc.enabled = TRUE RemoteDisplay.vnc.port = 5901 RemoteDisplay.vnc.password = 12345678

2007-01-06

- Boot with `profile=1' on the kernel command line sudo readprofile -r sudo readprofile -M10 time readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 | tee ~/log

The only place where the large route cache seems to make sense is for larger servers that are servicing internet connections from many sites. Since the cache is completely flushed every 10 minutes by default, the above machine would have to be adding 55,924 routes per second that were ideally distrbuted throughout the hash space to even fill every bucket. The patch I am proposing is as follows. For the sites that need larger route hashes, they can use the rhash_entries command line option to set it as desired. (http://lkml.org/lkml/2004/12/9/92) gc_elesticity can best be described as the average bucket depth the kernel will accept before it starts expiring route hash entries. This will help maintain the upper limit of active routes. echo 8 > /proc/sys/net/ipv4/route/gc_elasticity (http://lwn.net/Articles/145406/) gc_thresh is another limiting factor in controlling how much RAM your policy routing will eat up. This number cannot be greater than the rhash_entries kernel parameter. As a rule of thumb, set your rhash_entries parameter REALLY high(mine is 2.4million) and control your running limit with gc_thresh. echo 1048576 > /proc/sys/net/ipv4/route/gc_thresh (http://lwn.net/Articles/145406/) IN:Hits are cache hits yes? Tot, are the total number of flows created since we last looked at the total flow count, correct? What would cause a packet to drop in the network stack and thus showup in /proc/net/softnet_stat?

/proc/net/softnet_stat

total droppped tsquz Throttl FR_hit FR_succe FR_defer FR_def_o cpu_coll 00379350 00000000 00000032 00000000 00000000 00000000 00000000 00000000 0000576c 23aa79eb 000045db 009d960c 00000000 00000000 00000000 00000000 00000000 00028a73 00bc9ef3 00000000 000123ab 00000000 00000000 00000000 00000000 00000000 0000896d 005f5298 00000000 0000002b 00000000 00000000 00000000 00000000 00000000 00004b61 00387deb 00000000 00000037 00000000 00000000 00000000 00000000 00000000 00008d0b 2c12916a 00000000 0000270a 00000000 00000000 00000000 00000000 00000000 0001ab8f ^ duzo dropped on eth1