My Name
eyck-blog@ddiary:eu
Subscribe
Subscribe to a syndicated feed of my weblog,
brought to you by the wonders of RSS.
Fri, 14 Dec 2007
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();
[/Howto] permanent link
Thu, 13 Dec 2007
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
[/Benchmark] permanent link
Sat, 08 Dec 2007
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)
[/Tips] permanent link
[/Tips] permanent link
Tue, 04 Dec 2007
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
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
[/Tips] permanent link
Sun, 11 Nov 2007
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:
[/Projects/bsd] permanent link
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
[/Projects/bsd] permanent link
Thu, 01 Nov 2007
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
[/Projects/bsd] permanent link
[/Projects/bsd] permanent link
Compiling kernels inside openvz
Contenders:
[/Ugly notepad] permanent link
simfs 112G 26G 87G 23% / /dev/shm 2.0G 369M 1.7G 18% /home/eyck/ramdyskFight:
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.778sSoo... 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.328seyck@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
[/Ugly notepad] permanent link
Wed, 19 Sep 2007
Blacklist module - stop it from being loaded by modprobe/udev
Sun, 09 Sep 2007
RaidF: FlashRaid - best solution for flash filesystems
- Divide your flash-based block device into >3 parts, for example let's use 12 sections.
- Raid5 (or Raid6 if you need more protection) them.
- 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)
- Effective protection for wear problems, plus additional protection for other block errors
- Very small price storage-wise (<10%)
- 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)
- 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?
[/Quests] permanent link
Thu, 06 Sep 2007
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
[/Howto] permanent link
Wed, 05 Sep 2007
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#
[/Howto] permanent link
Mon, 27 Aug 2007
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.
[/Howto] permanent link
Sat, 04 Aug 2007
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)
[/Tips] permanent link
[/Tips] permanent link
Wed, 27 Jun 2007
Setting up Linux *SWAN Ipsec for nokia e61
Cached from:
http://www.thorsten-knabe.de/linux/e61.jsp
[/Howto] permanent link
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
[/Howto] permanent link
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
[/Howto] permanent link
[/Howto] permanent link
Tue, 15 May 2007
apt-get: Floating point exception
sid: ~# apt-get update Floating point exceptionCulprit: 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
[/Problems] permanent link
Sun, 08 Apr 2007
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
[/Tips] permanent link
[/Tips] permanent link
1) rmmod is missing
2) cfdisk is missing
3) ping is missing
4) tcpdump is missing
5) less is missing
[/Problems] permanent link
[/Problems] permanent link
Thu, 08 Feb 2007
Display
RemoteDisplay.vnc.enabled = TRUE
RemoteDisplay.vnc.port = 5901
RemoteDisplay.vnc.password = 12345678
[/Tips] permanent link
[/Tips] permanent link
Sat, 06 Jan 2007
- 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
[] permanent link
[] permanent link
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?
[] permanent link
[] permanent link
/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
[] permanent link
[] permanent link
| December 2007 | ||||||
|---|---|---|---|---|---|---|
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||