Re: Reducing dhclient's syslog messages
On 7/11/12 10:00 AM, Otto Moerbeek wrote: Why? Nothing a littke syslog.conf tweaking can't fix. -Otto Agreed, but here's more: 1) User may run few dhclient instances (for different interfaces, needless to say), and wish to log some, while don't log other (too verbositive ones, which get low lease time, for example); 2) Logging to stderr, for debugging purposes. In final, i think it 'll not harm matching dhcpd's -f/-d flags. P.S.: Forgive me for noising about this.
Promos para el dia del amigo!!!
Si no podes visualizar este mail, ingresa a: http://news1.bonuscupon.com.ar/r.html?uid=1.1x.29hh.xk.4y053d6a9r
Re: dwm in base
On Tue, Jul 10, 2012 at 08:26:28PM -0400, Sean Howard wrote: > Almost everyone compiles dwm on their own, binaries are almost useless. At > least amongst the users I've known. > > On Tue Jul 10 2012 20:52, z...@sdf.org wrote: > > And, last but not least, its configuration is modified by editing its > > config.h by hand. So, everyone seriously using it compiles it from > > source, anyway. I think you are both wrong. Several people are fine with the more or less sane upstream defaults and do not tweak them. I seriously use dwm from OpenBSD packages since a long time and I know furthers doing the same (with other OS packages) as well. Regards, Joerg
Re: dwm in base
On Tue, Jul 10, 2012 at 08:52:14PM +, z...@sdf.org wrote: > Hello, > > there are a lot of nice window managers in OpenBSD base (fvwm, cwm, ...). > > I am a big fan of dwm and I think it shares the philosophy of minimalism > which is important to a lot of BSD lovers. Also, it has a good code > quality and is rock solid... > > Is there a reason why dwm isnt in OpenBSD base installation? Because there are already enough/too many window managers in base. Use the packages if you prefer to use another window manager. -- Matthieu Herrb
Re: dwm in base
On Wed, Jul 11, 2012 at 10:38:39AM +0200, Matthieu Herrb wrote: > On Tue, Jul 10, 2012 at 08:52:14PM +, z...@sdf.org wrote: > > Hello, > > > > there are a lot of nice window managers in OpenBSD base (fvwm, cwm, ...). > > > > I am a big fan of dwm and I think it shares the philosophy of minimalism > > which is important to a lot of BSD lovers. Also, it has a good code > > quality and is rock solid... > > > > Is there a reason why dwm isnt in OpenBSD base installation? > > Because there are already enough/too many window managers in base. > Use the packages if you prefer to use another window manager. > > > -- > Matthieu Herrb > I was surprised how many window managers are in base installation. So, I just was interested why dwm isnt. However, I understand that most people edit the config.h and compile dwm on there own and so do I. But it would be convenient to use dwm to compile my own dwm. Well, I can fork OpenBSD and make things properly :D. Jokes beside: dwm in base doesnt make much sense. Cheers -- z...@sdf.org
Re: does re-injection even work?
On Tue, Jul 10, 2012 at 09:34:04PM +0200, Peter J. Philipp wrote: > # pfctl -srules > pass all flags S/SA > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > block drop in on re0 inet from to any > pass in on re0 inet proto udp from any to any port = 53 scrub (reassemble > tcp) divert-packet port I have taken the code from divert(4) manpage and applied it to the above divert-packet rule. Here is what I see: # ./testd 192.168.4.1:41863 -> 192.168.4.2:53 192.168.4.2:53 -> 192.168.4.1:41863 But the packets never make it out to host 192.168.4.1 at all, they get dropped somewhere. netstat -s says there is no error on the divert: section. > Any small hint would be appreciated, -peter
Re: does re-injection even work?
On 2012-07-10, Matthew Dempsky wrote: > On Tue, Jul 10, 2012 at 12:34 PM, Peter J. Philipp wrote: >> I did this rather fast hoping to get it in for someone I know who is being >> used for a DNS amplifier attack but the final tests broke the hope of >> stopping it with this. > > Tangential, but setting "max-udp-size 512" in BIND will limit how > attractive your DNS server is for DNS amplification attacks. Also tangential but a lot of the current round of DNS amplification attacks seem to be targetting insecure CPE routers rather than intentional DNS servers.
openbsd running on asus eeepc 1000H?
hi misc, anybody out there w/ an asus eepc 1000H model running openbsd? I've found this netbook in a recycle hw store and I would be interested in using it for some needs. thanks -- see ya, giovanni
Re: does re-injection even work?
On Wed, Jul 11, 2012 at 11:52:41AM +0200, Peter J. Philipp wrote: > On Tue, Jul 10, 2012 at 09:34:04PM +0200, Peter J. Philipp wrote: > > > # pfctl -srules > > pass all flags S/SA > > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > > block drop in on re0 inet from to any > > pass in on re0 inet proto udp from any to any port = 53 scrub (reassemble > > tcp) divert-packet port > > I have taken the code from divert(4) manpage and applied it to the above > divert-packet rule. Here is what I see: > > # ./testd > 192.168.4.1:41863 -> 192.168.4.2:53 > 192.168.4.2:53 -> 192.168.4.1:41863 > > But the packets never make it out to host 192.168.4.1 at all, they get dropped > somewhere. netstat -s says there is no error on the divert: section. > > > Any small hint would be appreciated, > > -peter Obvious thing to check: return value from sendto(2). -Otto
Re: does re-injection even work?
On Wed, Jul 11, 2012 at 12:32:09PM +0200, Otto Moerbeek wrote: > On Wed, Jul 11, 2012 at 11:52:41AM +0200, Peter J. Philipp wrote: > > > On Tue, Jul 10, 2012 at 09:34:04PM +0200, Peter J. Philipp wrote: > > > > > # pfctl -srules > > > pass all flags S/SA > > > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > > > block drop in on re0 inet from to any > > > pass in on re0 inet proto udp from any to any port = 53 scrub (reassemble > > > tcp) divert-packet port > > > > I have taken the code from divert(4) manpage and applied it to the above > > divert-packet rule. Here is what I see: > > > > # ./testd > > 192.168.4.1:41863 -> 192.168.4.2:53 > > 192.168.4.2:53 -> 192.168.4.1:41863 > > > > But the packets never make it out to host 192.168.4.1 at all, they get > > dropped > > somewhere. netstat -s says there is no error on the divert: section. > > > > > Any small hint would be appreciated, > > > > -peter > > Obvious thing to check: return value from sendto(2). > > -Otto Also, first make sure that without diverting, packets make it through. You could be looking at a simple routing problem, for example. A couple of time, I managed to forget net.inet.ip.forwarding=1 while testing routing stuff. -Otto
Re: openbsd running on asus eeepc 1000H?
On Wed, Jul 11, 2012 at 12:25:24PM +0200, giovanni wrote: > hi misc, > > anybody out there w/ an asus eepc 1000H model running openbsd? > I've found this netbook in a recycle hw store and I would be interested > in using it for some needs. > > thanks > > -- > see ya, > giovanni > I had OpenBSD running on a 1000HE if I recall. Ken
overload rule for outgoing floods
Hello all, I know this is really stupid, but I'm trying to mitigate the effects of one hacked server on our (very large) network that is being used to DoS other computers on the Internet. I do not have access to the server and I cannot take it down (due to different reasons), so instead I'm trying to prevent it from attacking other servers using pf. First it was UDP-flooding some hosts, so I simply blocked it from doing that to anything outside our network with: block out quick on vlan100 proto udp from $HackedServer to ! Now it's SYN-flooding other servers on port 80, however I cannot simply block outgoing TCP/80, as that will disrupt the service on the machine. So I'm trying something like this: # targets being attacked table persist # block rule block out quick log on vlan100 from $HackedServer to # overload rule pass out quick log on vlan100 inet proto tcp from $HackedServer to any keep state (max-src-conn 100, max-src-conn-rate 15/5, overload flush global) Problem is, the only address that get added to the table is that of the sending server. Any ideas on how to get the attack victims added to the table? Thanks, Boutros
Re: overload rule for outgoing floods
> Any ideas on how to get the attack victims added to the table? > Thanks, > Boutros Hire a consultant specialised in OpenBSD firewall, before the damaged part will sue you.
Re: dwm in base
* z...@sdf.org [120711 04:34]: > On Wed, Jul 11, 2012 at 10:38:39AM +0200, Matthieu Herrb wrote: > > On Tue, Jul 10, 2012 at 08:52:14PM +, z...@sdf.org wrote: > > > Hello, > > > > > > there are a lot of nice window managers in OpenBSD base (fvwm, cwm, ...). > > > > > > I am a big fan of dwm and I think it shares the philosophy of minimalism > > > which is important to a lot of BSD lovers. Also, it has a good code > > > quality and is rock solid... > > > > > > Is there a reason why dwm isnt in OpenBSD base installation? > > > > Because there are already enough/too many window managers in base. > > Use the packages if you prefer to use another window manager. > > > > > > -- > > Matthieu Herrb > > > > I was surprised how many window managers are in base installation. > So, I just was interested why dwm isnt. However, I understand > that most people edit the config.h and compile dwm on there own > and so do I. But it would be convenient to use dwm to compile my own > dwm. > > Well, I can fork OpenBSD and make things properly :D. > > Jokes beside: dwm in base doesnt make much sense. > > Cheers > > -- > z...@sdf.org > You can also duplicate the dwm port into the mystuff directory, modify the patches to your liking, and maintain "your own" port of dwm. man bsd.port.mk and search for "mystuff" jim@
Re: overload rule for outgoing floods
On Wed, Jul 11, 2012 at 4:44 AM, Boutros Halingrad wrote: > Problem is, the only address that get added to the table is > that of the sending server. Right, sys/net/pf.c is hardcoded to use only the source address for the overload table. (Search for "overload_tbl" to see the relevant code.) > Any ideas on how to get the attack victims added to the table? I think you'll need to patch pf to support this.
Doubt with IPSEC
Hi, I`m having a problem to establish a IPSEC transport between two openbsd hosts (one with 5.1 and the other with 4.9). They are configured to use the transport mode (confs bellow). When I run "isakmpd -K ; ipsecctl -f /etc/ipsec.conf" on both hosts, no SA are created. What did I miss? Thanks, Mosconi OBSD51 (hubble): PF: # pfctl -sr pass all flags S/SA block drop in on ! lo0 proto tcp from any to any port 6000:6010 # ping -c 5 spitzer PING spitzer.domain (IP_SPITZER): 56 data bytes 64 bytes from IP_SPITZER: icmp_seq=0 ttl=244 time=69.193 ms 64 bytes from IP_SPITZER: icmp_seq=1 ttl=244 time=70.835 ms 64 bytes from IP_SPITZER: icmp_seq=2 ttl=244 time=70.223 ms 64 bytes from IP_SPITZER: icmp_seq=3 ttl=244 time=70.740 ms 64 bytes from IP_SPITZER: icmp_seq=4 ttl=244 time=69.469 ms --- spitzer.domain ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 69.193/70.092/70.835/0.661 ms # cat /etc/ipsec.conf # $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ # # See ipsec.conf(5) for syntax and examples. # Set up two tunnels using automatic keying with isakmpd(8): # # First between the networks 10.1.1.0/24 and 10.1.2.0/24, # second between the machines 192.168.3.1 and 192.168.3.2. # Use FQDNs as IDs. ike esp transport from hubble to spitzer \ main \ auth hmac-sha2-512 \ enc aes-256 \ group modp4096 \ srcid hubble.domain \ dstid spitzer.domain \ psk '/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy' # ipsecctl -vvf /etc/ipsec.conf @0 C set [Phase 1]:IP_SPITZER=peer-IP_SPITZER force C set [peer-IP_SPITZER]:Phase=1 force C set [peer-IP_SPITZER]:Address=IP_SPITZER force C set [peer-IP_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy force C set [peer-IP_SPITZER]:Configuration=phase1-peer-IP_SPITZER force C set [phase1-peer-IP_SPITZER]:EXCHANGE_TYPE=ID_PROT force C add [phase1-peer-IP_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force C set [peer-IP_SPITZER]:ID=id-hubble.domain force C set [id-hubble.domain]:ID-type=FQDN force C set [id-hubble.domain]:Name=hubble.domain force C set [peer-IP_SPITZER]:Remote-ID=id-spitzer.domain force C set [id-spitzer.domain]:ID-type=FQDN force C set [id-spitzer.domain]:Name=spitzer.domain force C set [from-IP_HUBBLE-to-IP_SPITZER]:Phase=2 force C set [from-IP_HUBBLE-to-IP_SPITZER]:ISAKMP-peer=peer-IP_SPITZER force C set [from-IP_HUBBLE-to-IP_SPITZER]:Configuration=phase2-from-IP_HUBBLE-to-IP_SPITZER force C set [from-IP_HUBBLE-to-IP_SPITZER]:Local-ID=from-IP_HUBBLE force C set [from-IP_HUBBLE-to-IP_SPITZER]:Remote-ID=to-IP_SPITZER force C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE force C set [from-IP_HUBBLE]:ID-type=IPV4_ADDR force C set [from-IP_HUBBLE]:Address=IP_HUBBLE force C set [to-IP_SPITZER]:ID-type=IPV4_ADDR force C set [to-IP_SPITZER]:Address=IP_SPITZER force C add [Phase 2]:Connections=from-IP_HUBBLE-to-IP_SPITZER @1 C set [Phase 1]:IP6_SPITZER=peer-IP6_SPITZER force C set [peer-IP6_SPITZER]:Phase=1 force C set [peer-IP6_SPITZER]:Address=IP6_SPITZER force C set [peer-IP6_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy force C set [peer-IP6_SPITZER]:Configuration=phase1-peer-IP6_SPITZER force C set [phase1-peer-IP6_SPITZER]:EXCHANGE_TYPE=ID_PROT force C add [phase1-peer-IP6_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force C set [peer-IP6_SPITZER]:ID=id-hubble.domain force C set [id-hubble.domain]:ID-type=FQDN force C set [id-hubble.domain]:Name=hubble.domain force C set [peer-IP6_SPITZER]:Remote-ID=id-spitzer.domain force C set [id-spitzer.domain]:ID-type=FQDN force C set [id-spitzer.domain]:Name=spitzer.domain force C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Phase=2 force C set [from-IP6_HUBBLE-to-IP6_SPITZER]:ISAKMP-peer=peer-IP6_SPITZER force C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Configuration=phase2-from-IP6_HUBBLE-to-IP6_SPITZER force C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Local-ID=from-IP6_HUBBLE force C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Remote-ID=to-IP6_SPITZER force C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE force C set [from-IP6_HUBBLE]:ID-type=IPV6_ADDR force C set [from-IP6_HUBBLE]:Address=IP6_HUBBLE force C set [to-IP6_SPITZER]:ID-type=IPV6_ADDR force C set [to-IP6_SPITZER]:Address=IP6_SPITZER force C add [Phase 2]:Connections=from-IP6_HUBBLE-to-IP6_SPITZER # cat /var/run/dmesg.boot OpenBSD 5.1 (GENERIC) #160: Sun Feb 12 09:46:33 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: QEMU Virtual CPU version 1.0 ("GenuineIntel" 686-class) 2.54 GHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,P
Re: Doubt with IPSEC
I would suggest passing the -vL option to iskampd. -v enables verbose logging which will report errors when trying to setup the SA. The -L option will create pcap file in /var/run which contains the packets exchanged to set up the SA. If you look at this pcap file w/ the verbose (-vv) option to tcpdump, you will see extensive info SA negotiations. On Wed, Jul 11, 2012 at 02:23:13PM -0300, Rodrigo Mosconi wrote: > Hi, > > I`m having a problem to establish a IPSEC transport between two > openbsd hosts (one with 5.1 and the other with 4.9). They are > configured to use the transport mode (confs bellow). > When I run "isakmpd -K ; ipsecctl -f /etc/ipsec.conf" on both hosts, > no SA are created. What did I miss? > > Thanks, > > Mosconi > > OBSD51 (hubble): > PF: > # pfctl -sr > pass all flags S/SA > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > > # ping -c 5 spitzer > PING spitzer.domain (IP_SPITZER): 56 data bytes > 64 bytes from IP_SPITZER: icmp_seq=0 ttl=244 time=69.193 ms > 64 bytes from IP_SPITZER: icmp_seq=1 ttl=244 time=70.835 ms > 64 bytes from IP_SPITZER: icmp_seq=2 ttl=244 time=70.223 ms > 64 bytes from IP_SPITZER: icmp_seq=3 ttl=244 time=70.740 ms > 64 bytes from IP_SPITZER: icmp_seq=4 ttl=244 time=69.469 ms > --- spitzer.domain ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 69.193/70.092/70.835/0.661 ms > > # cat /etc/ipsec.conf > # $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ > # > # See ipsec.conf(5) for syntax and examples. > > # Set up two tunnels using automatic keying with isakmpd(8): > # > # First between the networks 10.1.1.0/24 and 10.1.2.0/24, > # second between the machines 192.168.3.1 and 192.168.3.2. > # Use FQDNs as IDs. > > ike esp transport from hubble to spitzer \ > main \ > auth hmac-sha2-512 \ > enc aes-256 \ > group modp4096 \ > srcid hubble.domain \ > dstid spitzer.domain \ > psk '/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy' > > # ipsecctl -vvf /etc/ipsec.conf > @0 C set [Phase 1]:IP_SPITZER=peer-IP_SPITZER force > C set [peer-IP_SPITZER]:Phase=1 force > C set [peer-IP_SPITZER]:Address=IP_SPITZER force > C set > [peer-IP_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP_SPITZER]:Configuration=phase1-peer-IP_SPITZER force > C set [phase1-peer-IP_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Phase=2 force > C set [from-IP_HUBBLE-to-IP_SPITZER]:ISAKMP-peer=peer-IP_SPITZER force > C set > [from-IP_HUBBLE-to-IP_SPITZER]:Configuration=phase2-from-IP_HUBBLE-to-IP_SPITZER > force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Local-ID=from-IP_HUBBLE force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Remote-ID=to-IP_SPITZER force > C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP_HUBBLE-to-IP_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE > force > C set [from-IP_HUBBLE]:ID-type=IPV4_ADDR force > C set [from-IP_HUBBLE]:Address=IP_HUBBLE force > C set [to-IP_SPITZER]:ID-type=IPV4_ADDR force > C set [to-IP_SPITZER]:Address=IP_SPITZER force > C add [Phase 2]:Connections=from-IP_HUBBLE-to-IP_SPITZER > @1 C set [Phase 1]:IP6_SPITZER=peer-IP6_SPITZER force > C set [peer-IP6_SPITZER]:Phase=1 force > C set [peer-IP6_SPITZER]:Address=IP6_SPITZER force > C set > [peer-IP6_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP6_SPITZER]:Configuration=phase1-peer-IP6_SPITZER force > C set [phase1-peer-IP6_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP6_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP6_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP6_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Phase=2 force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:ISAKMP-peer=peer-IP6_SPITZER force > C set > [from-IP6_HUBBLE-to-IP6_SPITZER]:Configuration=phase2-from-IP6_HUBBLE-to-IP6_SPITZER > force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Local-ID=from-IP6_HUBBLE force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Remote-ID=to-IP6_SPITZER force > C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:Suite
Re: openbsd running on asus eeepc 1000H?
Yes, although its been a couple months since I turned it on. As i recall, the biggest obstacle was finding a USB stick it would deign to boot from Ben :wq On Jul 11, 2012, at 3:25 AM, giovanni wrote: > hi misc, > > anybody out there w/ an asus eepc 1000H model running openbsd? > I've found this netbook in a recycle hw store and I would be interested > in using it for some needs. > > thanks > > -- > see ya, > giovanni
Re: Doubt with IPSEC
One of the two hosts needs to use 'passive' in ipsec.conf so that it acts as server and listens/responds to incoming requests from peers. On Wed, Jul 11, 2012 at 02:23:13PM -0300, Rodrigo Mosconi wrote: > Hi, > > I`m having a problem to establish a IPSEC transport between two > openbsd hosts (one with 5.1 and the other with 4.9). They are > configured to use the transport mode (confs bellow). > When I run "isakmpd -K ; ipsecctl -f /etc/ipsec.conf" on both hosts, > no SA are created. What did I miss? > > Thanks, > > Mosconi > > OBSD51 (hubble): > PF: > # pfctl -sr > pass all flags S/SA > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > > # ping -c 5 spitzer > PING spitzer.domain (IP_SPITZER): 56 data bytes > 64 bytes from IP_SPITZER: icmp_seq=0 ttl=244 time=69.193 ms > 64 bytes from IP_SPITZER: icmp_seq=1 ttl=244 time=70.835 ms > 64 bytes from IP_SPITZER: icmp_seq=2 ttl=244 time=70.223 ms > 64 bytes from IP_SPITZER: icmp_seq=3 ttl=244 time=70.740 ms > 64 bytes from IP_SPITZER: icmp_seq=4 ttl=244 time=69.469 ms > --- spitzer.domain ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 69.193/70.092/70.835/0.661 ms > > # cat /etc/ipsec.conf > # $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ > # > # See ipsec.conf(5) for syntax and examples. > > # Set up two tunnels using automatic keying with isakmpd(8): > # > # First between the networks 10.1.1.0/24 and 10.1.2.0/24, > # second between the machines 192.168.3.1 and 192.168.3.2. > # Use FQDNs as IDs. > > ike esp transport from hubble to spitzer \ > main \ > auth hmac-sha2-512 \ > enc aes-256 \ > group modp4096 \ > srcid hubble.domain \ > dstid spitzer.domain \ > psk '/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy' > > # ipsecctl -vvf /etc/ipsec.conf > @0 C set [Phase 1]:IP_SPITZER=peer-IP_SPITZER force > C set [peer-IP_SPITZER]:Phase=1 force > C set [peer-IP_SPITZER]:Address=IP_SPITZER force > C set > [peer-IP_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP_SPITZER]:Configuration=phase1-peer-IP_SPITZER force > C set [phase1-peer-IP_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Phase=2 force > C set [from-IP_HUBBLE-to-IP_SPITZER]:ISAKMP-peer=peer-IP_SPITZER force > C set > [from-IP_HUBBLE-to-IP_SPITZER]:Configuration=phase2-from-IP_HUBBLE-to-IP_SPITZER > force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Local-ID=from-IP_HUBBLE force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Remote-ID=to-IP_SPITZER force > C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP_HUBBLE-to-IP_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE > force > C set [from-IP_HUBBLE]:ID-type=IPV4_ADDR force > C set [from-IP_HUBBLE]:Address=IP_HUBBLE force > C set [to-IP_SPITZER]:ID-type=IPV4_ADDR force > C set [to-IP_SPITZER]:Address=IP_SPITZER force > C add [Phase 2]:Connections=from-IP_HUBBLE-to-IP_SPITZER > @1 C set [Phase 1]:IP6_SPITZER=peer-IP6_SPITZER force > C set [peer-IP6_SPITZER]:Phase=1 force > C set [peer-IP6_SPITZER]:Address=IP6_SPITZER force > C set > [peer-IP6_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP6_SPITZER]:Configuration=phase1-peer-IP6_SPITZER force > C set [phase1-peer-IP6_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP6_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP6_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP6_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Phase=2 force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:ISAKMP-peer=peer-IP6_SPITZER force > C set > [from-IP6_HUBBLE-to-IP6_SPITZER]:Configuration=phase2-from-IP6_HUBBLE-to-IP6_SPITZER > force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Local-ID=from-IP6_HUBBLE force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Remote-ID=to-IP6_SPITZER force > C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE > force > C set [from-IP6_HUBBLE]:ID-type=IPV6_ADDR force > C set [from-IP6_HUBBLE]:Address=IP6_HUBBLE force > C set [to-IP6_SPITZER]:ID-type=IPV6_ADDR force > C set [to-IP6_SPITZ
apple : mac : mini : intel : core i5 : 5.2 : support?
would it be there? http://www.openbsd.org/plat.html shows nothing. googling around too showed information not upto date (from my location). need a reliable desktop system with a good resale value, hence a mac mini. :) thanks. -- simplicity can be marvelously powerful. - rahul jindal
Re: SIL 3512 sata card dma errors
LEVAI Daniel [l...@ecentrum.hu] wrote: > > 2) jmb0 at pci1 dev 0 function 0 "JMicron JMB363 IDE/SATA" rev 0x03 > > Worked nicely. According to systat it provided around 30MB/sec write > > speed, whereas the SiI3512A only had around 20MB/sec. > > This is good to know, I'm sure I'll prefer this kind of device in the > future. > That, or a 3124/3132/3531 suported by sili(4), or an AHCI based controller should all be better performers. "soft error" like you saw from pciide are likely CRC errors, that could be the controller or it could even be your cable or hard disk
Re: apple : mac : mini : intel : core i5 : 5.2 : support?
OpenBSD/amd64 and OpenBSD/i386 both support Core i5 based machines. Mayuresh Kathe [mayur...@kathe.in] wrote: > would it be there? > http://www.openbsd.org/plat.html shows nothing. > googling around too showed information not upto date (from my location). > > need a reliable desktop system with a good resale value, hence a mac mini. :) > > thanks. > > -- > simplicity can be marvelously powerful. > - rahul jindal -- Keep them laughing half the time, scared of you the other half. And always keep them guessing. -- Clair George
Re: apple : mac : mini : intel : core i5 : 5.2 : support?
On Jul 11 20:56:24, Mayuresh Kathe wrote: > would it be there? > http://www.openbsd.org/plat.html shows nothing. > googling around too showed information not upto date (from my location). > > need a reliable desktop system with a good resale value, hence a mac mini. :) Mine is not core i5, but runs 5.1 happily. Jan # uname -a OpenBSD mini.stare.cz 5.1 GENERIC#0 macppc # dmesg [ using 496832 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A]console in [keyboard] , using USB using parent ATY,RockHopper2Paren:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: memtag 8000, iotag 8000: width 800 linebytes 1024 height 600 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org uvm_km_kmem_grow: grown to 0xee00 OpenBSD 5.1-current (GENERIC) #0: Wed Jun 13 02:07:49 CEST 2012 r...@mini.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1032196096 (984MB) mainbus0 at root: model PowerMac10,2 cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 memc0 at mainbus0: uni-n "hw-clock" at memc0 not configured kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 vgafb0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01, mmio wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x5 pci1 at mpcpcibr1 bus 0 pchb1 at pci1 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 bwi0 at pci1 dev 18 function 0 "Broadcom BCM4318" rev 0x02: irq 52, address 00:11:24:bf:cb:2a macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE macgpio0 at macobio0 offset 0x50 "modem-reset" at macgpio0 offset 0x1d not configured "modem-power" at macgpio0 offset 0x1c not configured macgpio1 at macgpio0 offset 0x9 irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zsc0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zsc0 channel 0 zstty1 at zsc0 channel 1 aoa0 at macobio0 offset 0x1: irq 30,1,2 audio0 at aoa0 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets apm0 at adb0: battery flags 0x0, 0% charged piic0 at adb0 iic1 at piic0 maxtmp0 at iic1 addr 0xc8: max6642 kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x2 irq 24: DMA ohci0 at pci1 dev 24 function 0 "Apple Intrepid USB" rev 0x00: couldn't map interrupt ohci1 at pci1 dev 25 function 0 "Apple Intrepid USB" rev 0x00: couldn't map interrupt ohci2 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support ohci3 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 ohci4 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci2: USB revision 1.0 uhub1 at usb1 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb2 at ohci3: USB revision 1.0 uhub2 at usb2 "NEC OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci4: USB revision 1.0 uhub3 at usb3 "NEC OHCI root hub" rev 1.00/1.00 addr 1 mpcpcibr2 at mainbus0 pci: uni-north, Revision 0x6 pci2 at mpcpcibr2 bus 0 pchb2 at pci2 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00 wdc1 at kauaiata0 irq 39: DMA atapiscsi0 at wdc1 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable wd0 at wdc1 channel 0 drive 1: wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors cd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 wd0(wdc1:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 "Apple UniNorth Firewire" rev 0x81 at pci2 dev 14 function 0 not configured gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address 00:14:51:17:42:34 bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4 uhidev0 at uhub1 port 1 configuration 1 interface 0 "Apple Computer HID-proxy" rev 2.00/19.65 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 uhidev1 at uhub1 port 1 configuration 1 interface 1 "Apple Computer HID-proxy" rev 2.00/19.65 addr 2 uhidev1: iclass 3/1 ums0 at uhidev1: 5 buttons wsmouse0 at ums0 mux 0 uhidev2 at uhub2 port 1 configuration 1 interface 0 "Geni
Re: Doubt with IPSEC
2012/7/11 Paulm : > One of the two hosts needs to use 'passive' in ipsec.conf so that > it acts as server and listens/responds to incoming requests from peers. > > > > On Wed, Jul 11, 2012 at 02:23:13PM -0300, Rodrigo Mosconi wrote: >> Hi, >> >> I`m having a problem to establish a IPSEC transport between two >> openbsd hosts (one with 5.1 and the other with 4.9). They are >> configured to use the transport mode (confs bellow). >> When I run "isakmpd -K ; ipsecctl -f /etc/ipsec.conf" on both hosts, >> no SA are created. What did I miss? >> >> Thanks, >> >> Mosconi >> >> OBSD51 (hubble): >> PF: >> # pfctl -sr >> pass all flags S/SA >> block drop in on ! lo0 proto tcp from any to any port 6000:6010 >> >> # ping -c 5 spitzer >> PING spitzer.domain (IP_SPITZER): 56 data bytes >> 64 bytes from IP_SPITZER: icmp_seq=0 ttl=244 time=69.193 ms >> 64 bytes from IP_SPITZER: icmp_seq=1 ttl=244 time=70.835 ms >> 64 bytes from IP_SPITZER: icmp_seq=2 ttl=244 time=70.223 ms >> 64 bytes from IP_SPITZER: icmp_seq=3 ttl=244 time=70.740 ms >> 64 bytes from IP_SPITZER: icmp_seq=4 ttl=244 time=69.469 ms >> --- spitzer.domain ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/std-dev = 69.193/70.092/70.835/0.661 ms >> >> # cat /etc/ipsec.conf >> # $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ >> # >> # See ipsec.conf(5) for syntax and examples. >> >> # Set up two tunnels using automatic keying with isakmpd(8): >> # >> # First between the networks 10.1.1.0/24 and 10.1.2.0/24, >> # second between the machines 192.168.3.1 and 192.168.3.2. >> # Use FQDNs as IDs. >> >> ike esp transport from hubble to spitzer \ >> main \ >> auth hmac-sha2-512 \ >> enc aes-256 \ >> group modp4096 \ >> srcid hubble.domain \ >> dstid spitzer.domain \ >> psk >> '/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy' >> >> # ipsecctl -vvf /etc/ipsec.conf >> @0 C set [Phase 1]:IP_SPITZER=peer-IP_SPITZER force >> C set [peer-IP_SPITZER]:Phase=1 force >> C set [peer-IP_SPITZER]:Address=IP_SPITZER force >> C set >> [peer-IP_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy >> force >> C set [peer-IP_SPITZER]:Configuration=phase1-peer-IP_SPITZER force >> C set [phase1-peer-IP_SPITZER]:EXCHANGE_TYPE=ID_PROT force >> C add [phase1-peer-IP_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force >> C set [peer-IP_SPITZER]:ID=id-hubble.domain force >> C set [id-hubble.domain]:ID-type=FQDN force >> C set [id-hubble.domain]:Name=hubble.domain force >> C set [peer-IP_SPITZER]:Remote-ID=id-spitzer.domain force >> C set [id-spitzer.domain]:ID-type=FQDN force >> C set [id-spitzer.domain]:Name=spitzer.domain force >> C set [from-IP_HUBBLE-to-IP_SPITZER]:Phase=2 force >> C set [from-IP_HUBBLE-to-IP_SPITZER]:ISAKMP-peer=peer-IP_SPITZER force >> C set >> [from-IP_HUBBLE-to-IP_SPITZER]:Configuration=phase2-from-IP_HUBBLE-to-IP_SPITZER >> force >> C set [from-IP_HUBBLE-to-IP_SPITZER]:Local-ID=from-IP_HUBBLE force >> C set [from-IP_HUBBLE-to-IP_SPITZER]:Remote-ID=to-IP_SPITZER force >> C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force >> C set >> [phase2-from-IP_HUBBLE-to-IP_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE >> force >> C set [from-IP_HUBBLE]:ID-type=IPV4_ADDR force >> C set [from-IP_HUBBLE]:Address=IP_HUBBLE force >> C set [to-IP_SPITZER]:ID-type=IPV4_ADDR force >> C set [to-IP_SPITZER]:Address=IP_SPITZER force >> C add [Phase 2]:Connections=from-IP_HUBBLE-to-IP_SPITZER >> @1 C set [Phase 1]:IP6_SPITZER=peer-IP6_SPITZER force >> C set [peer-IP6_SPITZER]:Phase=1 force >> C set [peer-IP6_SPITZER]:Address=IP6_SPITZER force >> C set >> [peer-IP6_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy >> force >> C set [peer-IP6_SPITZER]:Configuration=phase1-peer-IP6_SPITZER force >> C set [phase1-peer-IP6_SPITZER]:EXCHANGE_TYPE=ID_PROT force >> C add [phase1-peer-IP6_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force >> C set [peer-IP6_SPITZER]:ID=id-hubble.domain force >> C set [id-hubble.domain]:ID-type=FQDN force >> C set [id-hubble.domain]:Name=hubble.domain force >> C set [peer-IP6_SPITZER]:Remote-ID=id-spitzer.domain force >> C set [id-spitzer.domain]:ID-type=FQDN force >> C set [id-spitzer.domain]:Name=spitzer.domain force >> C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Phase=2 force >> C set [from-IP6_HUBBLE-to-IP6_SPITZER]:ISAKMP-peer=peer-IP6_SPITZER force >> C set >> [from-IP6_HUBBLE-to-IP6_SPITZER]:Configuration=phase2-from-IP6_HUBBLE-to-IP6_SPITZER >> force >> C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Local-ID=from-IP6_HUBBLE force >> C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Remote-ID=to-IP6_SPITZER force >> C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force >> C set >> [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE >> force >> C set [from-IP6_HUBBLE]:ID-type=IPV6_AD
bsd.rd anonymous ftp login broken?
Trying to reinstall with the current i386/bsd.rd. All goes well until I actually select a ftp mirror, and asked for the ftp login, I accept the default of 'anonymous'. It keeps asking: ftp login ? anonymous [enter] ftp login ? anonymous [enter] ftp login ? anonymous [enter] and never gets past this. Tried with different ftp mirrors, so it's not that the one mirror is broken. Jan
Re: bsd.rd anonymous ftp login broken?
On Wed, Jul 11, 2012 at 12:55 PM, Jan Stary wrote: > Trying to reinstall with the current i386/bsd.rd. > All goes well until I actually select a ftp mirror, > and asked for the ftp login, I accept the default of > 'anonymous'. It keeps asking: > > ftp login ? anonymous [enter] > ftp login ? anonymous [enter] > ftp login ? anonymous [enter] > > and never gets past this. > > Tried with different ftp mirrors, > so it's not that the one mirror is broken. Works for me. Are you behind something? -Bryan
Re: SIL 3512 sata card dma errors
On Sun, 8 Jul 2012 22:46:59 +0200 LEVAI Daniel wrote: > My errors were triggered when I was copying from disk1 to disk2, both > connected to the SIL card. (in this case this was a 2 port card), not > when copying something in parallel to both disks from a separate > location. I think this makes the difference. Good point. So I did some more testing today by copying from one disk to the other (dd bs=4k), both on the same controller. Btw, I forgot to mention that the SiI is a PCI card and the JMB is a PCI-E. You probably don't have PCI-E in your Pentium 4 ;) 1) Both controllers (SiI3512A, JMB363) showed the same speed, around 17MB/sec (and 8000 interrupts/sec). 2) After more than 4h and 350GB, the JMB still showed no error. 3) But: the SiI3512A reported errors after ca. 3h: Jul 11 16:32:32 pc200 /bsd: wd0c: aborted command writing fsbn 565811920 of 565811920-565811927 (wd0 bn 565811920; cn 35220 tn 41 sn 37), retrying Jul 11 16:32:32 pc200 /bsd: wd0: soft error (corrected) Jul 11 16:50:56 pc200 /bsd: wd0c: aborted command writing fsbn 601990688 of 601990688-601990695 (wd0 bn 601990688; cn 37472 tn 47 sn 47), retrying Jul 11 16:50:56 pc200 /bsd: wd0: soft error (corrected) Jul 11 17:15:59 pc200 /bsd: wd0c: aborted command writing fsbn 651398952 of 651398952-651398959 (wd0 bn 651398952; cn 40547 tn 180 sn 57), retrying Jul 11 17:16:00 pc200 /bsd: wd0: soft error (corrected) Jul 11 17:22:01 pc200 /bsd: wd0c: aborted command writing fsbn 663235184 of 663235184-663235191 (wd0 bn 663235184; cn 41284 tn 122 sn 38), retrying Jul 11 17:22:01 pc200 /bsd: wd0: soft error (corrected) kind regards, Robert
Su Tarjeta Ha Sido Temporalmente Suspendida!
BBVA - Particulares SEGURIDAD. Le informamos que el accesso a su cuenta BBVAnet ha sido restringido por razones de seguridad. Para seguir utilizando los servicios de Banca por Internet de BBVA, debe reactivar su CLAVE DE ACCESO REACTIVACION Acuda a una de las oficinas de BBVA, o bien utilice nuestra pagina pulsando aqui, o en la nuestra web mas abajo: https://www.bbva.es/ -NOTA: : No responda a este mensaje. Utilice nuestra pagina o bien acuda a una de nuestras oficinas para restaurar su acceso.- Aviso legal Tarifas y otros avisos Mapa AtenciĆ³n al cliente Banco Bilbao Vizcaya Argentaria S.A. - 2012
Re: bsd.rd anonymous ftp login broken?
On Jul 11 13:13:39, Bryan Irvine wrote: > On Wed, Jul 11, 2012 at 12:55 PM, Jan Stary wrote: > > Trying to reinstall with the current i386/bsd.rd. > > All goes well until I actually select a ftp mirror, > > and asked for the ftp login, I accept the default of > > 'anonymous'. It keeps asking: > > > > ftp login ? anonymous [enter] > > ftp login ? anonymous [enter] > > ftp login ? anonymous [enter] > > > > and never gets past this. > > > > Tried with different ftp mirrors, > > so it's not that the one mirror is broken. > > Works for me. Are you behind something? Behind my ISP. Generaly, what does it mean if the 'ftp login' question gets repeated? That the FTP connection and/or FTP login failed? That's not the case here, as I have downloaded the bsd.rd from the very same anon FTP.
Re: bsd.rd anonymous ftp login broken?
* Jan Stary [120712 01:55]: > Trying to reinstall with the current i386/bsd.rd. > All goes well until I actually select a ftp mirror, > and asked for the ftp login, I accept the default of > 'anonymous'. It keeps asking: > > ftp login ? anonymous [enter] > ftp login ? anonymous [enter] > ftp login ? anonymous [enter] > > and never gets past this. Same here (amd64). I typed "anonymous" and it proceeded. > Tried with different ftp mirrors, > so it's not that the one mirror is broken. > > Jan
Re: bsd.rd anonymous ftp login broken?
Use http then? To get you out of trouble. Since other people dont have the problem, something fishy going on at your ISP? I was once with an ISP that had a transparent proxy for http. I noticed because it was serving dated content, and the IP address on my remote server logs were not my own. Maybe your ISP is transparent proxying ftp? My current ISP blocks a lot of ports by default. I needed to login and disable their firewall in my customer profile. On Wed, Jul 11, 2012 at 09:55:35PM +0200, Jan Stary wrote: > Trying to reinstall with the current i386/bsd.rd. > All goes well until I actually select a ftp mirror, > and asked for the ftp login, I accept the default of > 'anonymous'. It keeps asking: > > ftp login ? anonymous [enter] > ftp login ? anonymous [enter] > ftp login ? anonymous [enter] > > and never gets past this. > > Tried with different ftp mirrors, > so it's not that the one mirror is broken. > > Jan
birds of feather flocked together
anyone with expertise in setting up infrastructure for a small (3 member) team of volunteers doing part-time development for openbsd? the development effort will last for 12 months starting august 2012. no remuneration involved nor intent to fork. :) thanks.
relayd - url filtering actions?
Hello! I have a fun problem: 2 webhosts (backends) 1 relayd (loadbalancer) Some webapplications BUT one of the webapplications does not scale on a loadbalanced system so I need to use a specific backend to get that to work: so if users surfs to app.domain.tld/ they will go to either backend but if they go to app.domain.tld/banana I want them sent to a specific backend. I was under the impression (#openbsd@freenode) that this is possible? So my resolution was to add: http protocol "http" { things things request url filter "app.domain.tld/banana" redirect } Am I incorrect? Well I know that since relayd do not want to reload the config due to: /etc/relayd.conf:66: syntax error /etc/relayd.conf:80: no such protocol: http /etc/relayd.conf:83: syntax error /etc/relayd.conf:98: no such protocol: http Anyone that has done this before Im not sure about the redirect in the man it says that the option for url can be only change/replace actions is what I want even possible? Regards Joakim!