correct way to clear sensitive data from env?
hi, case in point: openvpn passing username/password in the environment to openvpn_bsdauth. so there's actually a bit of a sensitive data in env that current wisdom rightly tends to want to junk as soon as possible. getenv(3) states, "If getenv() is successful, the string returned should be considered read-only.", operative word being "should". what's the correct way to deal with this (specifically on openbsd if there are any facilities that help here, as well as on other systems perhaps)? thanks, -- [-] mkdir /nonexistent
4.0-stable panic with pppoe(4)
ok, so i'm not *entirely* sure it's with pppoe(4), but as far as i can put bits and pieces together, it's always happening after "ifconfig pppoe0 down; ifconfig pppoe0 destroy" and then either "sh /etc/netstart pppoe0" or (the second case) starting ppp(8). box has 4 interfaces, one of them (vr0) is unused. fxp0 is plain ethernet, there's a plain old pppoe(8)/ppp(8) driving fxp1 (these are the ppp/pppoe processes that can be seen in the process list), and rl0 is driven by pppoe(4). i'm switching back and forth between pppoe(4) and pppoe/ppp on this one, panic always seems to occur a couple of seconds after the last command (see above) is given. it doesn't happen absolutely all the time, but it does happen quite regularly every other day or so. thanks for any ideas. login: pppoe0: LCP keepalive timeoutmultiply freed item 0xd0c62480 panic: free: duplicated free Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND 32587 5086 5086 0 30x86 netio tcpdump 5086 7823 5086 76 3 0x4186 bpftcpdump 13042 28245 13042 0 3 0x4086 ttyin ksh 28245 5850 28245 0 3 0x4184 select sshd 7823 24482 7823 0 3 0x4086 pause ksh 24482 5850 24482 0 3 0x4184 select sshd 13534 1 13534 0 3 0x4086 ttyin getty 29162 1 29162 0 3 0x4086 ttyin getty 27900 1 27900 0 3 0x4086 ttyin getty 5419 1 5419 0 3 0x4086 ttyin getty 0 1 0 0 3 0x4086 ttyin getty 26509 1 26509 0 3 0x4086 ttyin ksh 30944 1 30944 0 30x84 select cron 9208 17357 17357 62 3 0x184 piperd spamd 15575 17357 17357 62 3 0x184 select spamd 17357 1 17357 62 3 0x184 nanosleep spamd 5850 1 5850 0 30x84 select sshd 12694 23856 23856 83 3 0x184 poll ntpd 23856 1 23856 0 30x84 poll ntpd *32613 17223 17223 68 7 0x104 isakmpd 17223 1 17223 0 30x84 netio isakmpd 3938 23555 23555 70 3 0x184 select named 23555 1 23555 0 3 0x184 netio named 14867 15702 15702 73 2 0x184 syslogd 15702 1 15702 0 30x8c netio syslogd 2944 1 5430 82 3 0x4184 select pppoe 5430 1 5430 0 3 0x40184 select ppp 12 0 0 0 30x100204 crypto_wa crypto 11 0 0 0 30x100204 aiodoned aiodoned 10 0 0 0 30x100204 syncer update 9 0 0 0 30x100204 cleanercleaner 8 0 0 0 30x100204 reaper reaper 7 0 0 0 30x100204 pgdaemon pagedaemon 6 0 0 0 30x100204 pftm pfpurge 5 0 0 0 30x100204 wait wskbd_hotkey 4 0 0 0 30x100204 usbtsk usbtask 3 0 0 0 30x100204 usbevt usb0 2 0 0 0 30x100204 kmallockmthread 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper ddb> trace Debugger(d0716a84,d0cc0800,daf08c60,d0c62480,9) at Debugger+0x4 panic(d065e4d1,d0c62480,46045c3d,0,db0f9300) at panic+0x63 free(d0c62480,9,14,d0cc0800) at free+0x40 ifafree(d0c62480,daf08e3c,daf08d30,d3c84a6c) at ifafree+0x27 rtfree(d3ca843c,0,daf08d30,d039b67e) at rtfree+0x8d in_selectsrc(d3cd3014,d3c84a6c,200,0,daf08d40,813e46c3,0,daf08e08) at in_select src+0x135 in_pcbconnect(d3c84a24,d3cd3000,daf08d80,0) at in_pcbconnect+0x137 udp_output(d3d09e00,d3c84a24,d3cd3000,0,0) at udp_output+0xa8 sosend(d3c838cc,d3cd3000,daf08e38,d3d09e00,0,0,10,3) at sosend+0x389 sendit(d3d5ae14,1c,daf08ed8,0,daf08f58) at sendit+0x157 sys_sendmsg(d3d5ae14,daf08f68,daf08f58,87a59380,daf08f58) at sys_sendmsg+0x79 syscall() at syscall+0x2ea --- syscall (number 28) --- 0x1c097411: ddb> == login: multiply freed item 0xd0c00600 panic: free: duplicated free Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace Debugger(d0716a84,d076e4e0,d089eca4,d0c00600,9) at Debugger+0x4 panic(d065e4d1,d0c00600,d089ed14,d038876e,2) at panic+0x63 free(d0c00600,9,0,0) at free+0x40 ifafree(d0c00600,d089ed7c,d089ed84,d039b1e4) at ifafree+0x27 rtfree(d3cb42f8,0,0,5) at rtfree+0x8d in_losing(d3c036c8,1900,d089edc4,d032f91a,d0716968) at in_losing+0x62 t
Re: Password escrow
On Thu, 13 Jul 2006, Chris Kuethe wrote: > Secret Sharing schemes. > http://freshmeat.net/projects/sharesecret/ > http://freshmeat.net/projects/shsecret/ also http://freshmeat.net/projects// -- [-] mkdir /nonexistent
multiple Local-IDs for isakmpd
hi,
i have a situation where a branch office with multiple,
non-overlapping, non-aggregatable local networks need to connect to
the head office, via an ipsec tunnel. "of course", the security
gateway is also acting as a gateway to the internet (nat and the usual
collateral stuff), and, as a matter of fact, some of the "local"
networks are connected to it via openvpn (that is, it itself is a vpn
concentrator of sorts, for openvpn tunnels).
rough sketch:
-- branch office -- | | -- head office --
| |
172.16.187.0/24 - | |
172.19.47.0/24 \ +---+ | | +---+
+- |security gw| - (ipsec tun) - |security gw| - ...
192.168.114.0/24 / ++--+ | | +---+
192.168.2.0/24 - |
\
(internet etc..)
it may also be the case that at the head office end, there will be
more than one hosts/networks to be accessed, this is not clarified
yet. i am not in control of the head office's concentrator, but i know
that they are using a cisco 3060.
how is this realized within isakmpd's configuration? i already have
tried putting more than one ipv4_addr_subnets into the ipsec-id
section, and even more than one ipsec-id section, but isakmpd throw
them out (not surprise).
if this cannot be realized within isakmpd, what other options do i
have? pf route-tos/reply-tos are about the only thing i can think
of... anything else?
tia,
--
[-]
mkdir /nonexistent
bridge panic on -current
hi, i was fooling around with bridging together ural0 and dc0, when out of bad habit i wanted to assign an ip address to bridge0 (yes, i understand it's not how it works on probably anything else than linux, it was my fat fingers), which got me an instant panic. upon further investigation, it looks like that when ifconfig is used to add an ip to bridge0, it's properly handled, but dhclient, for some reason crashes the kernel. below are stuff from my playground alpha, but i can reliably reproduce the symptoms with -current running inside vmware; more interestingly, 3.7-stable does not exhibit this behaviour. there, dhclient simply reports `bridge0: not found', and exits normally. i understand i'm not supposed to turn the knob that way, but it seems somewhat more logical to handle this situation gracefully. thanks, # ifconfig -a lo0: flags=8049 mtu 33192 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 dc0: flags=8802 mtu 1500 lladdr 08:00:2b:86:3e:f2 media: Ethernet autoselect (100baseTX full-duplex) status: active pflog0: flags=0<> mtu 33192 pfsync0: flags=0<> mtu 2020 enc0: flags=0<> mtu 1536 ural0: flags=8802 mtu 1500 lladdr 00:11:2f:6b:e0:e0 media: IEEE802.11 autoselect status: no network ieee80211: nwid "" 100dBm # ifconfig bridge0 create # brconfig bridge0 add dc0 up # ifconfig bridge0 192.168.2.100 netmask 255.255.255.0 up ifconfig: SIOCAIFADDR: Invalid argument # dhclient bridge0 DHCPDISCOVER on panic: trap Stopped at Debugger+0x4: ret zero,(ra) RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND 17339 16572 16572 0 30x86 poll dhclient *16572 3182 16572 77 7 0x4106 dhclient 3182 1 3182 0 3 0x4086 pause ksh 30963 1 30963 0 3 0x4086 ttyin getty 17207 1 17207 0 3 0x4086 ttyin getty 10546 1 10546 0 3 0x4086 ttyin getty 21194 1 21194 0 3 0x4086 ttyin getty 28226 1 28226 0 3 0x4086 ttyin getty 499 1499 0 30x84 select cron 23674 1 23674 62 3 0x184 select spamd 25488 1 25488 0 30x84 select sshd 5920 1 5920 0 3 0x184 select inetd 3297 1 3297 0 30x84 poll ntpd 29429 1 14802 83 3 0x186 poll ntpd 5312 31829 31829 68 3 0x184 select isakmpd 31829 1 31829 0 30x84 netio isakmpd 14496 30599 30599 73 3 0x184 poll syslogd 30599 1 30599 0 30x84 netio syslogd 9 0 0 0 30x100204 crypto_wa crypto 8 0 0 0 30x100204 aiodoned aiodoned 7 0 0 0 30x100204 syncer update 6 0 0 0 30x100204 cleanercleaner 5 0 0 0 30x100204 reaper reaper 4 0 0 0 30x100204 pgdaemon pagedaemon 3 0 0 0 30x100204 usbtsk usbtask 2 0 0 0 30x100204 usbevt usb0 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper ddb> trace Debugger(4, fc783648, 5, 8, 3, 8) at Debugger+0x4 panic(fc762ed4, 1, 0, 2, fe00120c3950, fc0002add168) at panic+0x130 trap(?, ?, 0, 2, fe00120c3950, fc0002add168) at trap+0x51c XentMM(?, ?, 0, 2, ?, fc0002add168) at XentMM+0x20 bridge_output(?, fc0002795d00, fe00120c3ae8, 0, fe2ef380, fc0002add168) at bridge_output+0x7c bpfwrite(?, ?, ?, ?, ?, fc0002add168) at bpfwrite+0x150 spec_write(?, ?, ?, ?, ?, fc0002add168) at spec_write+0x108 ufsspec_write(?, ?, ?, ?, ?, fc0002add168) at ufsspec_write+0x44 VOP_WRITE(?, fe00120c3d38, ?, fc000279c280, ?, fc0002add168) at VOP_WRITE+0x44 vn_write(?, ?, ?, ?, ?, fc0002add168) at vn_write+0x104 dofilewritev(?, 8, ?, ?, ?, fc0002add168) at dofilewritev+0x1c8 sys_writev(?, ?, ?, ?, ?, ?) at sys_writev+0x88 syscall(?, ?, ?, ?, ?, ?) at syscall+0x248 XentSys(8, 1d920, 2, , 4300, 16252c058) at XentSys+0x50 ddb> [ using 470232 bytes of bsd ELF symbol table ] consinit: not using prom console Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2005 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 3.7-current (GENERIC) #0: Tue Jul 5 14:43:24 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/alpha/compile/GENERIC Digital Personal WorkStat
Re: Modifying man pages and composing new ones
On Sun, 21 Aug 2005, Rod.. Whitworth wrote: > I suppose that I'm going to have to try to remember something about the > [gnt]roff things I had very small experience with back in the '70s > > So apart from the mdoc-samples man page are there other > required/recommended documents for rust-removal / new learning please? to amend jmc and stuart, http;//www.oreilly.com/openbook/utp/ may also be of interest, though its a bit more heavyweight stuff than just man pages (you should follow the link `troff and postscript files--beta'). this is probably the single best resource you can get on *roff today. -- [-] mkdir /nonexistent
Re: Spamd/Postfix behaving strangely
On Sun, 11 Sep 2005, Jason Dixon wrote: > Yes, there is a PIX (eventually to be replaced with OpenBSD/PF), but > I don't understand how that could interfere. If I remove the > external system from , I get redirected to spamd as > expected: pix interferes in every possible way, but your current particular problem seems to be it "fixing" smtp. iirc what you will have to tell the pix is `no fixup protocol smtp 25'. or something like that. > (unlikely), but I still see the connections in my maillog, so it's > not intercepting the SMTP session. yes, it does... -- [-] mkdir /nonexistent
ipsecctl, ipsecadm and friends
On Wed, 14 Sep 2005, Spruell, Darren-Perot wrote: > Incidentally, something I hadn't noticed before was the updates to the IPsec > control framwork - this looks terribly exciting as well. ;) actually, now that we are on the subject, i don't really understand the relation between ipsecadm and ipsecctl. at a quick skim, they seem to share quite a bit of functionality, but then, i'm not sure. could anyone sched some light? thanks, -- [-] mkdir /nonexistent
alpha panic; cpu_initclocks: no clock attached
hi, i ultimately wanted to try martin reindl's alpha patch on my pws500au (even if i wouldn't have scored extra anyway), when i realized my alpha was hosed, so i grabbed the sept 10 snapshot, installed it fine, cvs'd src/, compiled a generic kernel, and upon reboot: [...] sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed sd0: 4091MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sec, 8380080 sec total root on sd0a swap on sd0b panic: cpu_initclocks: no clock attached Stopped at Debugger+0x4: ret zero,(ra) RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace Debugger(0, fc789598, 5, 8, 3, 8) at Debugger+0x4 panic(fc764f46, 48, 0, 0, 0, fc702a90) at panic+0x130 cpu_initclocks(?, 48, 0, 0, 0, fc702a90) at cpu_initclocks+0x3c initclocks(?, 48, 0, 0, 0, fc702a90) at initclocks+0x2c main(?, ?, ?, ?, 0, fc702a90) at main+0x4b8 __start(?, ?, ?, ?, 0, fc702a90) at __start+0x64 __start(?, ?, ?, ?, 0, fc702a90) at __start+0x64 __start(?, ?, ?, ?, 0, fc702a90) at __start+0x64 [ repeating seemingly indefinitely ] ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x80204 swapper ddb> i seem to remember having this about a week ago too (that was when the box got hosed, but i didn't have time to investigate it further, i thought i screwed something up), but definitely before sept 10. for quick reference, here's the diff between the dmesg of the snapshot kernel and that of the -current one (both of them are there in full towards the end of this mail): -OpenBSD 3.8 (GENERIC) #587: Sat Sep 10 15:55:00 MDT 2005 -[EMAIL PROTECTED]:/usr/src/sys/arch/alpha/compile/GENERIC +OpenBSD 3.8-current (GENERIC) #0: Wed Sep 14 14:38:19 CEST 2005 +[EMAIL PROTECTED]:/usr/src/sys/arch/alpha/compile/GENERIC -avail memory = 226942976 (221624K) +avail memory = 226934784 (221616K) -sio0 at pci0 dev 7 function 0 "Contaq Microsystems CY82C693U ISA" rev 0x00 -pciide0 at pci0 dev 7 function 1 "Contaq Microsystems CY82C693U ISA" rev 0x00: DMA, channel 0 wired to compatibility -pciide0: channel 0 disabled (no drives) -pciide1 at pci0 dev 7 function 2 "Contaq Microsystems CY82C693U ISA" rev 0x00: no DMA, channel 0 wired to compatibility -atapiscsi0 at pciide1 channel 0 drive 0 +pciide0 at pci0 dev 7 function 0 "Contaq Microsystems CY82C693U ISA" rev 0x00: unexpected PCI function 0 +pciide1 at pci0 dev 7 function 1 "Contaq Microsystems CY82C693U ISA" rev 0x00: DMA, channel 0 wired to compatibility +pciide1: channel 0 disabled (no drives) +pciide2 at pci0 dev 7 function 2 "Contaq Microsystems CY82C693U ISA" rev 0x00: no DMA, channel 0 wired to compatibility +atapiscsi0 at pciide2 channel 0 drive 0 -cd0(pciide1:0:0): using PIO mode 4 -ohci0 at pci0 dev 7 function 3 "Contaq Microsystems CY82C693U ISA" rev 0x00: isa irq 10, version 1.0, legacy support -usb0 at ohci0: USB revision 1.0 -uhub0 at usb0 -uhub0: Contaq Microsys OHCI root hub, rev 1.00/1.00, addr 1 -uhub0: 2 ports with 2 removable, self powered +cd0(pciide2:0:0): using PIO mode 4 +pciide3 at pci0 dev 7 function 3 "Contaq Microsystems CY82C693U ISA" rev 0x00: unexpected PCI function 3 -isa0 at sio0 -isadma0 at isa0 -com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo -com0: console -com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo -pckbc0 at isa0 port 0x60/5 -pcppi0 at isa0 port 0x61 -midi0 at pcppi0: -spkr0 at pcppi0 -isabeep0 at pcppi0 -lpt0 at isa0 port 0x3bc/4 irq 7 -fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 -fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec -mcclock0 at isa0 port 0x70/2: mc146818 or compatible -stray isa irq 3 -ural0 at uhub0 port 2 -ural0: ASUS 802.11g WLAN Drive, rev 2.00/0.01, addr 2 -ural0: MAC/BBP RT2570 (rev 0x03), RF RT2526, address 00:11:2f:6b:e0:e0 -rootdev=0x800 rrootdev=0x800 rawdev=0x802 -stray isa irq 3 also tried booting without the ural device attached, same result (used to work fine anyway). plugging, unplugging and otherwise abusing ural keeps it working fine. with the snapshot kernel, the box behaves absolutely normal. if any other information is needed, happy to provide them as well. thanks, details: >>>show config Firmware SRM Console: V7.2-1Mar 6 2000 14:47:02 ARC Console: 5.70 PALcode: OpenVMS PALcode V1.20-16, Tru64 UNIX PALcode V1.22-18 SROM Version: v5.90 Processor DECchip (tm) 21164A-2 Pass 500 MHz 96 KBytes SCache 2 MB BCache PYXIS ASIC Pass 257 MEMORY Memory Size = 256Mb Bank Size/Sets Base Addr ---- - 0128Mb 1128Mb 0800 BCache Size = 2Mb Tested Memory = 256Mbytes PCI Bus Bus 00 Slot 03: Digital Semiconductor 21143 Network Controller ewa0.0.0.3.0 08-00-2B-86-3E-F2 Bus 00 Slot 07: Cypress PCI Periphe
Re: alpha panic; cpu_initclocks: no clock attached
On Thu, 15 Sep 2005, Martin Reindl wrote: > > i ultimately wanted to try martin reindl's alpha patch on my pws500au > > (even if i wouldn't have scored extra anyway), when i realized my > > alpha was hosed, so i grabbed the sept 10 snapshot, installed it fine, > > cvs'd src/, compiled a generic kernel, and upon reboot: > > I just don't recall what patch this might have could been, Date: Wed, 14 Sep 2005 13:47:13 +0200 To: [EMAIL PROTECTED] Subject: Alpha testers needed ^- this one (didn't get to the part of even thinking about trying to, tho). > but you disabled ISA. The clock attaches to ISA. Don't disable ISA. you mean as in `editing arch/alpha/conf/GENERIC'? no i didn't. swear to god. not even with config(8). or anything that can do this and i'm aware of. i went like: netboot bsd.rd as per install.alpha, install it, cvs co src, cd /usr/src/sys/alpha/conf, config GENERIC, cd ../compile/GENERIC, make clean depend bsd, mv bsd /bsd && chmod 0644 /bsd && chown root:wheel /bsd && reboot. this is exactly what resulted in no clocks. and i didn't disable it in srm either (if that is possible at all, which i do not know, but would nevertheless be quite surprised). according to config, ukc> find isa 111 isa* at pceb*|sio* flags 0x0 ukc> i have followed -current with this box up until maybe one and a half weeks ago semi-regularly, never had any problems, except for the phenomenon which matthieu described as `the alpha bug' and is known, but never anything like that. now i'm getting confused... -- [-] mkdir /nonexistent
Re: alpha panic; cpu_initclocks: no clock attached
On Thu, 15 Sep 2005, Miod Vallat wrote: > This problem is caused by a bug in sys/dev/pci/pciide.c. If you revert > it to revision 1.201, your kernel will work again on your machine. confirmed. by the time i woke up, jsg already reverted it in cvs, i just took that. machine is a happy hippo again. thanks, -- [-] mkdir /nonexistent
pf weirdness with pfctl -f nonexistent.file
hi, i just observed a strange phenomenon, which, if it's intended behavior, i could not really find it documented anywhere (or failed to understand the doc, if it is). in its simplest form, it is as follows. given is a machine with a de0, part of a simple lan. the following configuration is loaded into pf: -- set skip on de0 block log all pass in on de0 from 192.168.1.10 to any keep state -- i'm logged in from 192.168.1.12 via de0, make a fat-fingered typo of `pfctl -f all' (instead of -F all), poof, get thrown out (connection reset by peer). from 192.168.1.10, the box is accessible. logged in from 1.10, looked around, generally everything looks ok, pfctl -sa shows the rules, shows pf enabled, whatnot, but it acts as if the `set skip on de0' part was somehow forgotten. i can not verify my suspicion as i couldn't find a way to get the current (as in `loaded into the kernel') `skip these interfaces' list (shouldn't that be included in -sr anyway?), but i couldn't find any other explanations. reproducible on 3.8-stable i386 and -current (as of 2-3 days ago) alpha. what's that? thanks, -- [-] mkdir /nonexistent
Re: pf weirdness with pfctl -f nonexistent.file
On Fri, 11 Nov 2005, Daniel Hartmeier wrote: > I'm pretty sure your theory is correct. You can query the list of > interfaces with pfctl -vsI, which prints '(skip)' on those that are > currently being skipped. ah, yes, thank you. i did check, and yes, it's the skip flag that gets cleared. > Reloading the ruleset does (and should) clear the 'set skip' set, as we > agreed that there should be no (or as little as possible) state in the > kernel that persists across ruleset reloads. Other options are similarly > cleared on reload (and then re-instated, if you reload a ruleset similar > to the old one). So loading an empty ruleset should clear all such > options. > > Now, if the ruleset doesn't exist at all (I assume you didn't have a > file called 'all' lying in the cwd when running pfctl -f all), I guess > nothing should happen except for the error message. I'll check about > that. > > Or what would you prefer instea > exactly that. unless there's some master idea i'm not aware of (or can't think of), that seems to be the most reasonable behavior, no? -- [-] mkdir /nonexistent
pf.conf(5) buglet wrt logging
hi,
diff below removes the `log' keyword from the nat, binat and rdr bnf
descriptions. ok, i can't quite read code as much to actually verify
the validity of this, but i simply couldn't get it to work (it doesn't
seem so hard to insert a `log' between a `nat' and a `pass' in an
otherwise working setup now does it?), didn't find any references
doing so anyplace, and seem to remember something about it being
removed (but it may have well been log-all...).
questions: if the diff below is not correct, what's the correct syntax
for logging in a nat(/binat/rdr) rule? "nat on pcn0 from
192.168.1.0/24 to any -> (pcn0)" works fine, "nat log on pcn..." gives
a syntax error).
if the diff below is correct, how can one log nats/rdrs/binats as they
happen?
thanks,
Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.339
diff -u -r1.339 pf.conf.5
--- pf.conf.5 17 Nov 2005 22:18:20 - 1.339
+++ pf.conf.5 10 Dec 2005 01:45:27 -
@@ -2639,21 +2639,18 @@
"queue" ( string | "(" string [ [ "," ] string ] ")" ) |
"probability" number"%"
-nat-rule = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
- [ "on" ifspec ] [ af ]
+nat-rule = [ "no" ] "nat" [ "pass" ] [ "on" ifspec ] [ af ]
[ protospec ] hosts [ "tag" string ] [ "tagged" string ]
[ "->" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] [ "static-port" ] ]
-binat-rule = [ "no" ] "binat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
- [ "on" interface-name ] [ af ]
- [ "proto" ( proto-name | proto-number ) ]
+binat-rule = [ "no" ] "binat" [ "pass" ] [ "on" interface-name ]
+ [ af ] [ "proto" ( proto-name | proto-number ) ]
"from" address [ "/" mask-bits ] "to" ipspec
[ "tag" string ] [ "tagged" string ]
[ "->" address [ "/" mask-bits ] ]
-rdr-rule = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
- [ "on" ifspec ] [ af ]
+rdr-rule = [ "no" ] "rdr" [ "pass" ] [ "on" ifspec ] [ af ]
[ protospec ] hosts [ "tag" string ] [ "tagged" string ]
[ "->" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] ]
--
[-]
mkdir /nonexistent
road warrior nat'ing on an ipsec tunnel
hello, judging from google and the archives, this does (or used to) give headaches to people. it does so to me as well. the situation is pretty ordinary, a road warrior having established a tunnel with a network behind some other peer's security gateway, needs to nat its own internal network so that they too can access to the other network that of the other party, while appearing to have arrived from the roar warrior's routeable ip address. (in my case, the remote "network" is just a host, actually.) i've read many stuff in the archives, google, read ipsec(4), i quite believe i understand how it's supposed to work, but it does not. sketch: ,, enc0 \ [192.168.1.0/24] -- [fxp0 -- tun0] -- || -- [peer sgw] -- [10.6.10.98 @ peer's] 192.168.1.6a.b.c.185 d.e.f.3 using the below-quoted isakmpd.conf [1], the tunnel gets established properly, 10.6.10.98 can be pinged, services on it accessed, whatnot. $ openssl s_client -host 10.6.10.98 -port 443 CONNECTED(0004) [...] HEAD / HTTP/1.0 HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 [...] gorgeous. the encap routing table at this point looks like this: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.6.10.98/32 0 a.b.c.185/32 0 0 d.e.f.3/50/use/in a.b.c.185/32 0 10.6.10.98/32 0 0 d.e.f.3/50/require/out all's well thus far. now, if i understand ipsec(4) and several posts by claudio here and there right, one needs to manually teach the kernel about a flow from "my private network" to "remote private network" via "peer's security gateway". the only purpose of this flow is that so that the packets matching these criteria get selected for ipsec processing (in fact the "via ..." seems to be superfluous, but it also doesn't seem to make a difference in practice). in my case, the following ipsec.conf seems to be just about fine: # cat /etc/ipsec.conf flow esp from 192.168.1.0/24 to 10.6.10.98 peer d.e.f.3 # gently hammering it into the kernel, everything still seems fine, to the best of my understanding: # ipsecctl -f /etc/ipsec.conf # netstat -nrfencap Routing tables Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 10.6.10.98/32 0 192.168.1/24 0 0 d.e.f.3/50/use/in 10.6.10.98/32 0 a.b.c.185/32 0 0 d.e.f.3/50/use/in 192.168.1/24 0 10.6.10.98/32 0 0 d.e.f.3/50/require/out a.b.c.185/32 0 10.6.10.98/32 0 0 d.e.f.3/50/require/out # the only thing left is pf. so as not to complicate matters, the following configuration is what i'm trying to use: # cat /etc/pf.conf nat on enc0 from 192.168.1.0/24 to 10.6.10.98 -> a.b.c.185 nat on tun0 from 192.168.1.0/24 to $sometesthost -> a.b.c.185 pass log (all) all keep state # that should be all. but it doesn't work, and it does so in interesting (to me) ways. the `pass log (all)' in pf is so that i could spy on packets closely; this revealed something i can't explain, but i suspect it has to do something with the problem. as a test, from 192.168.1.12, i try to connect to $sometesthost:25: # tcpdump -nettti pflog0 not port 22 and not port 500 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG Dec 10 07:21:53.638006 rule 0/(match) pass in on fxp0: 192.168.1.12.52812 > $sometesthost.25: [|tcp] (DF) [tos 0x10] Dec 10 07:21:53.638072 rule 0/(match) pass out on tun0: a.b.c.185.57197 > $sometesthost.25: [|tcp] (DF) [tos 0x10] Dec 10 07:21:53.652114 rule 0/(match) pass in on tun0: $sometesthost.25 > 192.168.1.12.52812: [|tcp] (DF) Dec 10 07:21:53.652134 rule 0/(match) pass out on fxp0: $sometesthost.25 > 192.168.1.12.52812: [|tcp] (DF) fine, shows a packet coming in, after translation going out, blah blah, everything looks perfect. now, lets try to ping 10.6.10.98: # tcpdump -nettti pflog0 not port 22 and not port 500 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG Dec 10 07:30:55.432061 rule 0/(match) pass in on fxp0: 192.168.1.12 > 10.6.10.98: icmp: echo request (DF) Dec 10 07:30:56.431228 rule 0/(match) pass in on fxp0: 192.168.1.12 > 10.6.10.98: icmp: echo request (DF) Dec 10 07:30:57.430875 rule 0/(match) pass in on fxp0: 192.168.1.12 > 10.6.10.98: icmp: echo request (DF) and... that's it. a packet comes in, and disappears. this is a packet that, if my ipsec.conf above was right, should have gotten selected for ipsec processing, and, according to ipsec(4), after having gotten nat'ed, should have been processed by ipsec, and thus, should have appeared in the above tcpdump. why did it not? where does a packet go when it disappears? how can i find out at which point does it get lost? is it perhaps nat, ipsec, where? setting pf's debuglevel to loud kept it dead silent. if none of th
Re: pf.conf(5) buglet wrt logging
On Sat, 10 Dec 2005, Adriaan Misc wrote: > I interpret it that you need a "pass" before the log ;) that was unfair. sorry for the noise :( -- [-] mkdir /nonexistent
Re: Alpha Disklabel Question
On Fri, 16 Dec 2005, J.C. Roberts wrote: > (1) When booting the cd38.iso with either bsd or bsd.rd you go into UKC > rather than directly into the installation. I'm guessing this is normal > since I'm sure there might be some things that need doing for some of > the more esoteric alpha hardware but it's worth asking to make sure. you probably have a rogue `-s' in boot_osflags (try `show boot_osflags' or even `show boot*' in srm). -- [-] mkdir /nonexistent
Re: Alpha Disklabel Question
On Fri, 16 Dec 2005, J.C. Roberts wrote: > Eventually, the boot_osflags in the SRM needs to be set to "a" but the > default is "A" -The case would make no difference for some OS's but > OpenBSD probably won't like it. ;-) fwiw i've been doing fine with `A' for ages. -- [-] mkdir /nonexistent
isakmpd does not enter phase 2
hello, dec 18 snap, running on i386 given is an ipsec gateway (i think it's running some older openswan or some other swan) to which i need to connect, establishing a net-net tunnel. the parameters needed are "IKE rekeying 1440 minutes (24 hours), IPSEC 3600 seconds (1 hour), both with 3DES/SHA1, no PFS", and these are carved in stone, i was told. i can't seem to get isakmpd to establish a tunnel with that site. it seems as if phase 1 would have been negotiatied fine, but when isakmpd then sends an `initial contact', then gets back an ipv4_addr, then things literally stop happening here. i checked isakmpd packet dumps on other machines, and from what i gather, here my isakmpd is the one who should start entering into phase 2 negotiations, but that never happens. that's what the packet log tells me (X.Y.Z.185 is isakmpd, the local side; A.B.C.42 is the remote side) Dec 20 03:45:23.465777 0.0.0.0.500 > A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0-> msgid: len: 164 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 00015180 payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 192) Dec 20 03:45:23.530916 A.B.C.42.500 > X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: len: 84 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 1 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 00015180 [ttl 0] (id 1, len 112) Dec 20 03:45:23.548557 X.Y.Z.185.500 > A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: len: 180 payload: KEY_EXCH len: 132 payload: NONCE len: 20 [ttl 0] (id 1, len 208) Dec 20 03:45:24.141436 A.B.C.42.500 > X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: len: 184 payload: KEY_EXCH len: 132 payload: NONCE len: 24 [ttl 0] (id 1, len 212) Dec 20 03:45:24.162027 X.Y.Z.185.500 > A.B.C.42.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: len: 92 payload: ID len: 12 type: IPV4_ADDR = X.Y.Z.185 payload: HASH len: 24 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (636b40261faa87b0->83821d77d8a07cd2) [ttl 0] (id 1, len 120) Dec 20 03:45:24.899941 A.B.C.42.500 > X.Y.Z.185.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: len: 68 payload: ID len: 12 type: IPV4_ADDR = A.B.C.42 payload: HASH len: 24 [ttl 0] (id 1, len 96) and then silence. there's nothing not even down the road (i waited for like 20 minutes for something, anything to happen) as `no proposal chosen', or any other kind of message that would give a clue as to where to start. with an other peer, at this point i also see Dec 20 03:55:29.817971 me.500 > otherpeer.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 24 payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256) Dec 20 03:55:29.914622 otherpeer.500 > me.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 24 payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256) and this is when phase2 negotiations actually begin, and eventually complete, and a tunnel is es
Re: cruft?
On Tue, 20 Dec 2005, J.C. Roberts wrote: > I hit a panic while doing make build on the Alpha PSW-433. My uneducated > guess http://marc.theaimsgroup.com/?t=11082572061&r=1&w=2 -- [-] mkdir /nonexistent
Re: isakmpd does not enter phase 2
On Tue, 20 Dec 2005, Matthew Closson wrote: matt, all, [Remote-peer-quick-mode] EXCHANGE_TYPE= QUICK_MODE Transforms= QM-ESP-3DES-SHA-SUITE notice the typo (s/Transforms/Suites/ for correct operation) that only became obvious after a healthy dose of sleep. thanks anyway. -- [-] mkdir /nonexistent
ffs panic on i386 3.8/stable
hello, i was setting up my wrap.1e board when the following happened. this is not the first actual installation of 3.8 on this very hardware, but i never got around to actually start configuring the box (i was playing with the etherboot upgrade mentioned earlier). everything is via wrap's serial console, 57600 8n1; -stable sans today's pf_norm fix. barghest:/etc/ppp# uudecode [demime removed a uuencoded section named ppp.conf which was 2 lines] barghest:/etc/ppp# ls -l ppp. ls: ppp.: No such file or directory barghest:/etc/ppp# ls -l ppp.conf -rw-r--r-- 1 root wheel 660 Jan 14 03:30 ppp.conf barghest:/etc/ppp# chmod 06panic: ffs_read: type 0 Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace Debugger(0,4003,0,400,d3b712a4) at Debugger+0x4 panic(d0509aed,d0509ae4,0,,0) at panic+0x63 ffs_read(dab0fe18,cfc0,dab0fe40,d0242974,d0580540) at ffs_read+0x36d VOP_READ(d3b712a4,dab0fe98,0,d3bf3230,d01021e1) at VOP_READ+0x34 vn_read(d3bdadb0,d3bdadcc,dab0fe98,d3bf3230) at vn_read+0x72 dofileread(d3ba9a44,5,d3bdadb0,87979000,400) at dofileread+0x6c sys_read(d3ba9a44,dab0ff68,dab0ff58,1000,8bb) at sys_read+0x47 syscall() at syscall+0x2ee --- syscall (number 3) --- 0x9bb6581: ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND *16387 4580260 0 7 0x4004 perl 5086260260 0 3 0x4084 piperd mail 10260260 0 3 0x4084 piperd tee 4580260260 0 3 0x4084 pause sh 260 25521260 0 3 0x4084 pause sh 25521 4174 4174 0 30x84 piperd cron 22204 1 22204 0 3 0x4086 ttyin ksh 4174 1 4174 0 30x84 select cron 12542 1 12542 0 3 0x40184 select sendmail 24235 1 24235 0 30x84 select sshd 2516 1 2516 0 3 0x184 select inetd 317 2344 2344 83 3 0x184 poll ntpd 2344 1 2344 0 30x84 poll ntpd 5611 20614 20614 73 3 0x184 poll syslogd 20614 1 20614 0 30x84 netio syslogd 11063 1 11063 77 3 0x184 poll dhclient 18491 1 7301 0 30x86 poll dhclient 9 0 0 0 30x100204 crypto_wa crypto 8 0 0 0 30x100204 aiodoned aiodoned 7 0 0 0 30x100204 syncer update 6 0 0 0 30x100204 cleanercleaner 5 0 0 0 30x100204 reaper reaper 4 0 0 0 30x100204 pgdaemon pagedaemon 3 0 0 0 30x100204 pftm pfpurge 2 0 0 0 30x100204 kmallockmthread 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper ddb> show panic ffs_read: type 0 ddb> boot reboot panic: mtx_enter: locking against myself Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace Debugger(16e2f4,dab0eea0,d04462e4,d0957e68,d057f960) at Debugger+0x4 panic(d01021a3,dab0eeb0,d021a21c,d057f990,d0587d70) at panic+0x63 mtx_enter(d057f990,d0587d70,dab0eec0,d01e98a6,1) at mtx_enter+0x5b timeout_del(d0957e68,0,dab0eef0,d01e99f5,dab0eee4) at timeout_del+0x14 sis_stop(d0957c00,dab0ef74,dab0ef20,d01e9b05) at sis_stop+0x3a dohooks(d057f960,1,dab0ef50,d01e9ba1) at dohooks+0x5e boot(4804,b0,dab0ef70,0,0) at boot+0x55 db_boot_poweroff_cmd(d0337fd0,0,,dab0ef78,d057dd80) at db_boot_poweroff_cmd db_command(d057dd80,d057dba0,dab0f080,d01e8b41,b0) at db_command+0xff db_command_loop(0,dab0f118,dab0f0c0,d0337e1f,1) at db_command_loop+0x8a db_trap(1,0,0,0,0) at db_trap+0x86 kdb_trap(1,0,dab0f118,d057fac4) at kdb_trap+0xab trap() at trap+0xa9 --- trap (number 1) --- Debugger(16e2f4,dab0f194,dab0f230,d0957a68,d057f960) at Debugger+0x4 panic(d01021a3,dab0f1a4,d021a21c,d057f990,) at panic+0x63 mtx_enter(d057f990,,dab0f1b4,d01e98a6,1) at mtx_enter+0x5b timeout_del(d0957a68,0,dab0f1e4,d01e99f5,dab0f1d8) at timeout_del+0x14 sis_stop(d0957800,dab0f268,dab0f214,d01e9b05) at sis_stop+0x3a dohooks(d057f960,1,dab0f244,d01e9ba1) at dohooks+0x5e boot(4804,d04f0caf,dab0f264,0,0) at boot+0x55 db_boot_poweroff_cmd(d0337fd0,0,,dab0f26c,d057dd80) at db_boot_poweroff_cmd db_command(d057dd80,d057dba0,dab0f374,d01e8b41,b0) at db_command+0xff db_command_loop(0,dab0f40c,dab0f3b4,d0337e1f,1) at db_command_loop+0x8a db_trap(1,0,0,0,0) at db_trap+0x86 kdb_trap(1,0,dab0f40c,d057fac4) at kdb_trap+0xab trap() at trap+0xa9 --- trap (number 1) --- Debugger(16e2f4,dab0f488,d04462e4,d0957668,d057f960) at De
