xenocara errors
I am running 4.7-current amd64, not sure what this means, I am guessing it is an issue with xf86-video-mga driver Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I/usr/xenocara/driver/xf86-video-mga/src -I.. -I/usr/X11R6/include/xorg -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/include/dev/pci/drm -I/usr/X11R6/include/X11/dri -O2 -pipe -MT mga_dri.lo -MD -MP -MF .deps/mga_dri.Tpo -c /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c -fPIC -DPIC -o .libs/mga_dri.o /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:50:21: mga_drm.h: No such file or directory /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c: In function `MGAWaitForIdleDMA': /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:323: error: `DRM_MGA_FLUSH' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:323: error: (Each undeclared identifier is reported only once /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:323: error: for each function it appears in.) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:343: error: `DRM_MGA_RESET' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c: In function `MGADRIBootstrapDMA': /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:552: error: syntax error before "dma_bs" /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:555: error: `dma_bs' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:562: error: `DRM_MGA_DMA_BOOTSTRAP' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c: In function `MGADRIKernelInit': /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:786: error: syntax error before "init" /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:794: error: `init' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:794: error: `drm_mga_init_t' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:796: error: `MGA_INIT_DMA' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:827: error: `DRM_MGA_INIT' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c: In function `MGADRICloseScreen': /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:1470: error: syntax error before "init" /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:1484: error: `init' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:1484: error: `drm_mga_init_t' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:1485: error: `MGA_CLEANUP_DMA' undeclared (first use in this function) /usr/xenocara/driver/xf86-video-mga/src/mga_dri.c:1486: error: `DRM_MGA_INIT' undeclared (first use in this function) *** Error code 1 Stop in /usr/xenocara/driver/xf86-video-mga/obj/src (line 382 of Makefile). *** Error code 1 Stop in /usr/xenocara/driver/xf86-video-mga/obj (line 329 of Makefile). *** Error code 1 Stop in /usr/xenocara/driver/xf86-video-mga/obj (line 236 of Makefile). *** Error code 1 Stop in /usr/xenocara/driver/xf86-video-mga (line 142 of /usr/X11R6/share/mk/bsd.xorg.mk). *** Error code 1 Stop in /usr/xenocara/driver/xf86-video-mga (line 203 of /usr/X11R6/share/mk/bsd.xorg.mk). *** Error code 1 Stop in /usr/xenocara/driver (line 48 of /usr/share/mk/bsd.subdir.mk). *** Error code 1 Stop in /usr/xenocara (line 48 of /usr/share/mk/bsd.subdir.mk).
Re: How to figure out the error location?
On Mon, May 24, 2010 at 12:52:39AM +0200, Roger Schreiter wrote: > Hi, > > we've been running a BGP router on OpenBSD for > the months without problems. > > Now it crashed two times within 4 days. After the > second crash, I could have a look on the screen: > >uvm_fault (0xd088cfc0, 0x6c4e2000, 0, 1) -> e >kernel: page fault trap, code=0 >Stopped at pool_do_get+0x11b: movl 0(%ebx),%eax > > Is there any mean to figure out, which driver did cause > the problem? Yes, by following the instructions which accompanied this message. WTF is it with people unable to do that lately? > There is a 4xFE-NIC from D-Link (interface ste0 .. 3), > whose driver seems to be new at OpenBSD-4.6. > > Should I try updating to OpenBSD-4.7? > > > Regards, > Roger.
Re: allowing inbound icmp6
On Sun, May 23, 2010 at 07:15:07PM -0700, TimH wrote: > I have tried a number of ways to allow icmp6, as the notes in my > pf.conf (look for #) explain below. What few examples I could find > online (http://www.benzedrine.cx/pf.conf) seemed to suggest it > shouldn't be hard, but I'm not having any success. Is anyone doing > this with 4.7? > # I have tried all three of these to no effect > #pass on $tunnel_if inet6 proto ipv6-icmp > #pass in on $tunnel_if inet6 proto ipv6-icmp from any to $ipv6_net > #pass quick proto icmp6 all How about the following? pass in quick proto ipv6-icmp -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 [demime 1.01d removed an attachment of type application/pgp-signature]
Re: allowing inbound icmp6
On Mon, 24 May 2010 12:46:21 +1000, Rod Whitworth wrote: >On Sun, 23 May 2010 19:15:07 -0700, TimH wrote: > >>My home OpenBSD machine acts as my home router for NAT and for my HE >>ipv6 tunnel. Everything works great except that I can't figure out how >>to allow inbound ping6. HE has an IPv6 portscan function that can never >>manage to ping6 me. If I tell it to not ping (-PN) it does indeed >>succeed to scan just the open ports I intend it to. >8>< snip > >I have an HE tunnel too and, although I can't find it in a hurry, I'm >sure that somewhere on an HE page there was info that you could not >pass any traffic to a /64 endpoint except replies to packets sent from >it and the routed traffic to your /48. > >So I can't ping you and you can't ping me. > >I don't have a /48 yet because the main reason to get the tunnel was to >check reachability of local v6 servers without using a local tunnel >that already "knows" the route to use. > >maybe you can find the info at HE. I'll look again later and pass on >anything I find, maybe it's in a forum. > >Best, This is not the info I saw previously but is a parallel case: http://www.tunnelbroker.net/forums/index.php?topic=621.0 *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: allowing inbound icmp6
On Sun, 23 May 2010 19:15:07 -0700, TimH wrote: >My home OpenBSD machine acts as my home router for NAT and for my HE >ipv6 tunnel. Everything works great except that I can't figure out how >to allow inbound ping6. HE has an IPv6 portscan function that can never >manage to ping6 me. If I tell it to not ping (-PN) it does indeed >succeed to scan just the open ports I intend it to. 8>< snip I have an HE tunnel too and, although I can't find it in a hurry, I'm sure that somewhere on an HE page there was info that you could not pass any traffic to a /64 endpoint except replies to packets sent from it and the routed traffic to your /48. So I can't ping you and you can't ping me. I don't have a /48 yet because the main reason to get the tunnel was to check reachability of local v6 servers without using a local tunnel that already "knows" the route to use. maybe you can find the info at HE. I'll look again later and pass on anything I find, maybe it's in a forum. Best, *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
allowing inbound icmp6
My home OpenBSD machine acts as my home router for NAT and for my HE
ipv6 tunnel. Everything works great except that I can't figure out how
to allow inbound ping6. HE has an IPv6 portscan function that can never
manage to ping6 me. If I tell it to not ping (-PN) it does indeed
succeed to scan just the open ports I intend it to.
I have tried a number of ways to allow icmp6, as the notes in my
pf.conf (look for #) explain below. What few examples I could find
online (http://www.benzedrine.cx/pf.conf) seemed to suggest it
shouldn't be hard, but I'm not having any success. Is anyone doing
this with 4.7?
#/etc/pf.conf
outside_if = "fxp0"
inside_if = "fxp1"
tunnel_if = "gif0"
local_if = "lo0"
nofilt_ifs = "{" $inside_if $local_if "}"
ipv6_net = "{ 2001:470:a:x::2, 2001:470:b:x::/64 }"
tunnel_peer = "216.218.xxx.xxx"
nat_range = "10.0.0.0/24"
ok_in_tcp_ports = "{" ftp ssh auth "}"
table persist
# no filtering on my inside stuff
set skip on $nofilt_ifs
#pass # to establish keep-state
altq on $outside_if priq queue { std_out, ssh_out, dns_out,
tcp_ack_out }
queue std_out priq(default)
queue ssh_out priority 4 priq(red)
queue dns_out priority 5
queue tcp_ack_out priority 6
# NAT for inside IPv4 network
match out on ! $inside_if inet from $nat_range to any nat-to
($outside_if:0)
# Block networks that bang on my SSH port right away
block in quick inet proto tcp from to any port ssh
# Block X.org traffic as the default ruleset does.
block in quick on ! lo0 proto tcp to port 6000:6010
# Block everything by default
block
# HE IPv6 Tunnel
pass out on $outside_if inet proto ipv6 from ($outside_if) to
$tunnel_peer pass in on $outside_if inet proto ipv6 from $tunnel_peer
to ($outside_if)
# Some stuff has to come in.
pass in on $outside_if proto tcp to ($outside_if) port $ok_in_tcp_ports
pass in on $tunnel_if inet6 proto tcp from any to $ipv6_net port
$ok_in_tcp_ports
pass on $outside_if inet proto icmp icmp-type 8 code 0
# I have tried all three of these to no effect
#pass on $tunnel_if inet6 proto ipv6-icmp
#pass in on $tunnel_if inet6 proto ipv6-icmp from any to $ipv6_net
#pass quick proto icmp6 all
# Outbound rules and our queues
pass out on $outside_if proto tcp from ($outside_if) to any\
queue(std_out, tcp_ack_out)
pass out on $tunnel_if inet6 proto tcp from $ipv6_net to any\
queue(std_out, tcp_ack_out)
pass out on $outside_if proto { udp icmp } from ($outside_if) to any
pass out on $tunnel_if inet6 proto udp from $ipv6_net to any
# tried this, outbound ping6 works without it
#pass out on $tunnel_if inet6 proto ipv6-icmp from $ipv6_net to any
pass out on $outside_if proto { tcp udp } from ($outside_if) to any
port domain\ queue dns_out
pass out on $tunnel_if inet6 proto udp from $ipv6_net to any port
domain\ queue dns_out
--TimH
Re:
On Mon, 24 May 2010 00:00:07 +0200 patrick kristensen wrote: > I have managed to get a working connection with the following script > > > /etc/ppp/ppp.conf > > default: > set log Phase Chat LCP IPCP CCP tun command > set device /dev/cuaU0 > set speed 460800 > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK > ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > esp: > set device /dev/cuaU0 > set speed 460800 > set timeout 0 > set dial "ABORT BUSY TIMEOUT 5 \ > \"\" \ > AT OK-AT-OK \ > AT+CPIN=\\\"7291\\\" OK-AT-OK \ > AT+CFUN=1 OK-AT-OK \ > AT+CGDCONT=1,\\\"IP\\\",\\\"movistar.es\\\" OK-AT-OK \ > \\dATDT*99***1# TIMEOUT 30 CONNECT" > > > set ifaddr 0 81.47.192.13 255.255.255.255 > add default HISADDR > enable dns > > # ./. > > Setting 'set ifaddr to 0.0.0.0/0 0.0.0.0/0 255.255.255.255' gave me an > ipadress to MYADDR but i did not get a route. > Setting 'set ifaddr 0.0.0.0/0 194.179.1.100 (which was DNS) > 255.255.255.255' made it possible to nslookup movistar.es. > After nslookup the APN and hardcoding the ip to HISADDR i got a > working connection. > The APN (Movistar (Telefonica) Spain) is correct > (http://www.vysoo.com/apn.php#415 and other sources). (I have not been > able to find other data networks for movistar as with your example > with Verizon) > This setup works so far (i can ping external addresses). > My understanding of ppp(8) is that it should have been enough to 'set > ifaddr 0 0 255.255.255.255 (0)' and 'add default HISADDR' (if the > CGDCONT is correct). > I appreciate any input on the script and log. It seems your routing is hosed. As the ppp(8) manual states, if you use "add" it will not overwrite your default route (typically stored in /etc/mygate). When you want to overwrite the default route, you need to use "add!" such as: add! default HISADDR Typically, you want to overwrite the default route, but note, you'll probably see some harmless warnings for routes that ppp cannot overwrite (such as IPv6 when it's not supported by your provider). As for setting up the interface addresses, you should define all four parts, rather than defining only three as you have done above. set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 part#1 part#2 part#3 part#4 In your script above, your part#1 of "0" is *DEMANDING* that your address be 0.0.0.0/32 and nothing else, or in other words, you are *DEMANDING* that you become the default route for the remote system. Needless to say the remote system will just laugh at you and refuse to change it's default route (i.e. address your end as 0.0.0.0). Setting the netmask (part#3) to 0.0.0.0 forces ppp to assign an appropriate netmask. Since it is a point-to-point link and some operating systems/kernels do not understand a POINTTOPOINT netmask, you'll typically end up with 255.255.255.255 or 255.255.255.0 for the netmask of your tun0 interface *even* if the remote gateway address is outside of the netmask. Using part#4 is important. This the address you *SUGGEST* that your side should be, but you *DEMAND* your side gets and address defined by part#1 (the /0 netmask on part#1 says any IP address). Additionally, part#4 is also the "trigger" address when using '-auto' mode to connect or reconnect. Lastly, there's no point in defining 'device' 'speed' and 'dial' in the "default:" section of your config file since you are redefining them in the "esp:" section. Once you have the above corrected, look at your CHAP settings. Though you were able to negotiate IP addresses (according to the log), it seems your provider wanted to use CHAP authentication. If you made the previous corrections and you still cannot connect, then you may need to use CHAP: set authname myusername set authkey mypassword set login Not all providers require PAP/CHAP authentication through 'authname' 'authkey' and 'login' because the real authentication is being done by device identifiers (MEID and/or IMEI). jcr -- The OpenBSD Journal - http://www.undeadly.org
mount_portal on 4.7+
mount_portal work? if yes, then give some working(tested) example for fs, please ps: sorry for english
rdr, match, tag -somewhere here bug
on current 20 may ext->gw->int block match in proto tcp to (self) port 23 rdr-to 192.168.2.2 tag PASS pass tagged PASS -connection established(its bug?) block tag ANYTAG match in proto tcp to (self) port 23 rdr-to 192.168.2.2 tag PASS pass tagged PASS -connection rejected(is absurd, and therefore cant be bug) ps: sorry for english
How to figure out the error location?
Hi, we've been running a BGP router on OpenBSD for the months without problems. Now it crashed two times within 4 days. After the second crash, I could have a look on the screen: uvm_fault (0xd088cfc0, 0x6c4e2000, 0, 1) -> e kernel: page fault trap, code=0 Stopped at pool_do_get+0x11b: movl 0(%ebx),%eax Is there any mean to figure out, which driver did cause the problem? There is a 4xFE-NIC from D-Link (interface ste0 .. 3), whose driver seems to be new at OpenBSD-4.6. Should I try updating to OpenBSD-4.7? Regards, Roger.
Re: DISKLESS kernel for moving an install to a larger disk
On Thu, 20 May 2010 15:40:07 +0200
Henning Brauer wrote:
> From: Henning Brauer
> To: misc@openbsd.org
> Subject: Re: DISKLESS kernel for moving an install to a larger disk
> Date: Thu, 20 May 2010 15:40:07 +0200
> User-Agent: Mutt/1.5.20 (2009-06-14)
>
> there is plain no need for a special diskless kernel any more, generic
> figures out where it was booted from, the ramdisks don't need to.
>
Well, I set up my dhcpd server like so:
# $OpenBSD: dhcpd.conf,v 1.2 2008/10/03 11:41:21 sthen Exp $
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
#
# Network: 192.168.1.0/255.255.255.0
# Domain name: my.domain
# Name servers: 192.168.1.3 and 192.168.1.5
# Default router: 192.168.1.1
# Addresses:192.168.1.32 - 192.168.1.127
#
option domain-name "my.domain";
#option domain-name-servers 192.168.1.3, 192.168.1.5;
option domain-name-servers 208.67.222.222, 208.67.222.220;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
#
range 192.168.1.200 192.168.1.248;
#
host static-client {
hardware ethernet 22:33:44:55:66:77;
fixed-address 192.168.1.200;
}
host pxe-client {
#hardware ethernet 02:03:04:05:06:07;
hardware ethernet 00:c0:4f:14:cd:00;
next-server 192.168.1.130;
filename "pxeboot";
fixed-address 192.168.1.40;
option root-path "192.168.1.130:/var/mason/root";
option swap-server 192.168.10.130;
option host-name "mason";
}
}
#rc.conf.local
xdm_flags=
#smbd_flags="-D"# for normal use: "-D"
#nmbd_flags="-D" # for normal use: "-D"
rarpd_flags="-a"
bootparamd_flags=""
dhcpd_flags=""
nfs_server=YES
portmap=YES
Where MASON is the client, a PIII 450MHz with 384MB of RAM.
This is what happens:
trap: 13(61f8): double fault
cn_tab=0x4d060
eax 20ecx 3e8 edx 4d060 ebx 4e400
esp ff34 ebp ff80 esi 4bf9b0b0 edi 4e400
eip 18 eflags 10cs 282 ss10
ds 20 es 20 fs 10 gs 10
Code dump[0x18]:
f000b110 3ef000b1 b23ef000 b23ef0 fooob23e a5f00b2 fea5f000 feasf0
Memory dump[0x1a000] (may be bad transcript)
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Stack trace[0xff34]:
d f800 61f8 61f8000 61f8 1861 18 1800
18 8200 282 2820 282 1002 10 1000
10 1000 10 4001000 40010 1400 141 1000
10 1000 10 1000 10 0 e4000 4e4
4eff00 b4e4 b0b4 f9b0b000 4bf9b060 804bf9b0 ff804bf9 ff804b
ff80 74ff ff74 ff7400 ff74 ff e400 4e4
It happens even if I compile a DISKLESS kernel using the "root on nfs
swap on nfs" option.
The client has run OpenBSD 4.3, 4.4, 4.5, 4.6 and -current up through
about December, so I have doubts that it's simply unable to do this at
all.
--
Edward Ahlsen-Girard
Ft Walton Beach, FL
Re:
2010/5/23 J.C. Roberts :
> On Sat, 22 May 2010 22:08:57 +0200 patrick kristensen
> wrote:
>> Thanks for taking the time to answer and your fast replies.
>>
>
> Actually, ppp and TDMA/CDMA are nice break from the other headaches I've
> been trying to solve. ;)
>
> First of all, you either haven't mentioned the name of your service
> provider, or I forgot what it was. Either way, it matters.
>
> From what I can tell, you're in Spain, and I'm not familiar with the
> providers there.
>
> Ted Roby recently posted his config for Virgin Mobile:
> http://marc.info/?l=openbsd-tech&m=127285929411780&w=2
>
> The above may not help, but it's nice to see working examples.
>
>> In absence of cdce (using ue0 as ethernet interface (and minicom) to
>> connect to isp) i have tried several ppp and pppd configurations to
>> get a working internet connection on -release with no success.
>>
>> The following is my ppp (# ppp -auto movistar) and pppd (# pppd call
>> movistar) attempts.
>
> Since pppd(8) is in the kernel, it can be faster, but since ppp(8) is
> in userland, it can be much easier to work with when figuring things
> out. Once you figure out how to make things work with ppp(8), you can
> easily write a new config for pppd(8).
>
>
>>
>> /etc/ppp/ppp.conf (appended to ppp.conf.sample)
>>
>> movistar:
>> set device /dev/cuaU0
>> set speed 460800
>> set timeout 0
>> set dial "ABORT BUSY TIMEOUT 5 \
>> \"\" \
>> AT OK-AT-OK \
>> AT+CFUN=1 OK-AT-OK \
>> AT+CPIN? +CPIN:\\sREADY-AT+CPIN\\\""\\\"-OK \
>
> The above looks wrong. Not all wireless service providers and not
> all cellular wireless devices require using the Personal Identification
> Number (PIN) when making a connection. And worse, the responses you
> can get varies from device to device. (see below)
>
> Also, it is unwise to post your PIN to a public mailing list. It's not
> too dangerous without the IMEI and MEID device, but it's still not a
> good idea.
>
>> AT+CGDCONT=1,\\\"IP\\\",\\\"movistar.es\\\" OK \
>
> The above is most likely wrong. The AT+CGDCONT= command sets the primary
> CONText of the device and the network it is attaching to. The first
> value argument states whether or not the device can be reconfigured (1),
> or cannot be reconfigured (3). The second argument is a string which
> defines the protocol used on the network. The third argument is also
> a string and it defines the Packet Data Network (PDN) name or Access
> Point Name (APN).
>
> As far as I know "movistar.es" is not the proper name of any Packet Data
> Network (PDN) or Access Point Name (APN). For example Virgin Mobile uses
> "VDATA" as the APN/PDN name, while AirTel uses "airtelgprs.com" as the name
> and of course, what your provider uses is unknown.
>
> You need to be careful with this setting since many providers have multiple
> data networks. With Verizon here in the silicon valley, I can choose from
> three different data networks (actually four if you count EVDO Rel. 0 as a
> different network than EVDO Rev. A).
>
>> "ATDT*99***1#"
>>
>
> The above is wrong because it has no timeout or 'CONNECT'. Also, you should
> have noticed the leading double quote (") which is prematurely ending
> your chat script *BEFORE* the required number is dialed. The above should
be:
>
>\\dATDT*99***1# TIMEOUT 30 CONNECT"
>
> The leading "\\d" gives a two second delay before calling. It may or may
not
> be necessary with your hardware/provider.
>
>>
>> set mtu maximum 750
>
> The above is most likely wrong.
>
>> resolv rewrite
>
> The above is often unnecessary to get things working, but rewriting
> /etc/resolv.conf is mostly a matter of personal choice/needs. The
> command you have below, namely `enable dns` should suffice.
>
>> set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0.
>> add default HISADDR
>> enable dns
>>
>> # ./.
>>
>>
>>
>> /var/log/ppp.log
>>
>> May 22 17:57:51 x200s ppp[8742]: Phase: Using interface: tun0
>> May 22 17:57:51 x200s ppp[8742]: Phase: deflink: Created in closed
>> state May 22 17:57:51 x200s ppp[8742]: tun0: Command: default: set
>> device /dev/cuaU0 May 22 17:57:51 x200s ppp[8742]: tun0: Command:
>> default: set speed 460800 May 22 17:57:51 x200s ppp[8742]: tun0:
>> Command: default: set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 ""
>> AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT
>> May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: set
>> device /dev/cuaU0 May 22 17:57:51 x200s ppp[8742]: tun0: Command:
>> movistar: set speed 460800 May 22 17:57:51 x200s ppp[8742]: tun0:
>> Command: movistar: set timeout 0 May 22 17:57:51 x200s ppp[8742]:
>> tun0: Command: movistar: set dial ABORT BUSY TIMEOUT 5
>> "" AT OK-AT-OK AT
>> +CFUN=1 OK-AT-OK AT+CPIN? +CPIN:\\sREADY-AT+CPIN\\"7291\\"-OK AT
>> +CGDCONT=1,\\"IP\\",\\"movistar.es\\" OK ATDT*99***1# May 22 17:57:51
Re: X exiting after update (inteldrm error)
I am having the same problem on a Lenovo R60e running snapshots from
May12th and May 22nd.
Looks like it may be "fixed":
http://marc.info/?l=openbsd-cvs&m=127457255931742&w=2 , will try the
next snapshot.
Thanks.
>From /var/log/messages:
May 17 14:11:42 CN212314 /bsd: render error detected, EIR: 0x0010
May 17 14:11:42 CN212314 /bsd: page table error
May 17 14:11:42 CN212314 /bsd: PGTBL_ER: 0x0002
May 17 14:11:42 CN212314 /bsd: render error detected, EIR: 0x0010
May 17 14:11:42 CN212314 /bsd: page table error
May 17 14:11:42 CN212314 /bsd: PGTBL_ER: 0x0002
May 17 14:11:42 CN212314 /bsd: no reset function for chipset.
May 17 14:11:42 CN212314 /bsd: no reset function for chipset.
May 17 14:19:39 CN212314 /bsd: error: [drm:pid3286:inteldrm_lastclose]
*ERROR* failed to idle hardware: 5
May 18 14:24:04 CN212314 /bsd: render error detected, EIR: 0x0010
May 18 14:24:04 CN212314 /bsd: page table error
May 18 14:24:04 CN212314 /bsd: PGTBL_ER: 0x0002
May 18 14:24:04 CN212314 /bsd: render error detected, EIR: 0x0010
May 18 14:24:04 CN212314 /bsd: page table error
May 18 14:24:04 CN212314 /bsd: PGTBL_ER: 0x0002
May 18 14:24:04 CN212314 /bsd: no reset function for chipset.
May 18 14:24:04 CN212314 /bsd: no reset function for chipset.
May 18 14:24:21 CN212314 /bsd: error:
[drm:pid31257:inteldrm_lastclose] *ERROR* failed to idle hardware: 5
May 18 14:28:14 CN212314 /bsd: error: [drm:pid2116:inteldrm_lastclose]
*ERROR* failed to idle hardware: 5
May 18 14:28:16 CN212314 /bsd: error:
[drm:pid2116:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged
hardware, good luck
May 18 14:28:16 CN212314 /bsd: render error detected, EIR: 0x0010
May 18 14:28:16 CN212314 /bsd: page table error
May 18 14:28:16 CN212314 /bsd: PGTBL_ER: 0x0002
May 18 14:28:16 CN212314 /bsd: render error detected, EIR: 0x0010
May 18 14:28:16 CN212314 /bsd: page table error
May 18 14:28:16 CN212314 /bsd: PGTBL_ER: 0x0002
May 18 14:28:16 CN212314 /bsd: no reset function for chipset.
May 18 14:28:16 CN212314 /bsd: error:
[drm:pid6:i915_gem_evict_inactive] *ERROR* Pinned object in unbind
list
May 18 14:28:16 CN212314 /bsd: no reset function for chipset.
May 18 14:28:16 CN212314 /bsd: error:
[drm:pid6:i915_gem_evict_inactive] *ERROR* Pinned object in unbind
list
May 19 09:37:46 CN212314 /bsd: render error detected, EIR: 0x0010
May 19 09:37:47 CN212314 /bsd: page table error
May 19 09:37:47 CN212314 /bsd: PGTBL_ER: 0x0002
May 19 09:37:47 CN212314 /bsd: render error detected, EIR: 0x0010
May 19 09:37:47 CN212314 /bsd: page table error
May 19 09:37:47 CN212314 /bsd: PGTBL_ER: 0x0002
May 19 09:37:47 CN212314 /bsd: no reset function for chipset.
May 19 09:37:47 CN212314 /bsd: no reset function for chipset.
May 23 12:56:48 CN212314 /bsd: render error detected, EIR: 0x0010
May 23 12:56:48 CN212314 /bsd: page table error
May 23 12:56:48 CN212314 /bsd: PGTBL_ER: 0x0002
May 23 12:56:48 CN212314 /bsd: render error detected, EIR: 0x0010
May 23 12:56:48 CN212314 /bsd: page table error
May 23 12:56:48 CN212314 /bsd: PGTBL_ER: 0x0002
May 23 12:56:48 CN212314 /bsd: no reset function for chipset.
May 23 12:56:48 CN212314 /bsd: no reset function for chipset.
May 23 14:15:31 CN212314 /bsd: error:
[drm:pid20034:inteldrm_lastclose] *ERROR* failed to idle hardware: 5
May 22th dmesg and Xorg.0.log:
===
OpenBSD 4.7-current (GENERIC) #652: Sat May 22 13:08:53 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) M CPU 410 @ 1.46GHz ("GenuineIntel"
686-class) 1.47 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,SSE3,MWAIT,TM2,xTPR,PDCM
real mem = 526872576 (502MB)
avail mem = 500920320 (477MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/16/06, BIOS32 rev. 0 @
0xfd690, SMBIOS rev. 2.4 @ 0xe0010 (67 entries)
bios0: vendor LENOVO version "7EETB6WW (2.06 )" date 10/16/2006
bios0: LENOVO 06573PU
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) EXP0(S4) EXP1(S4) EXP2(S4)
EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 132MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1
acpipwrres0 at acpi0: PUBS
acpitz0 at acpi0: critical temperature 127 degC
acpitz1 at acpi0: critical temperature 98 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acp
Re: 4.7 pf: quick and rdr-to/nat-to
2010/5/24 Rene Maroufi : > On Sun, May 23, 2010 at 08:07:38PM +0200, Henning Brauer wrote: >> * Rene Maroufi [2010-05-23 14:04]: >> > Hi, >> > >> > i update my firewall to 4.7 and changed my rdr and nat rules. But there >> > is one thing i don't understand: I use a transparent proxy (Squid) on >> > the same machine and in pf.conf this rdr-rule: >> > >> > pass in quick on $ifklan proto tcp from $klan to ! port 80 >> > rdr-to 127.0.0.1 port 3128 >> > >> > This works fine. If I comment this rule out, traffic is blocked. Thats >> > OK. If i remove only the "quick" word, traffic is passed through the >> > firewall without being proxied. But there is no other rule after this >> > rule to let traffic through the firewall. If there was a other rule, >> > comment this rule out, can't stop the traffic. I don't understand this >> > behaviour. >> >> well, there HAS to be another rule that matches later, or this would >> not happen. > > If thats the case: Why the traffic is blocked if i comment the rule out? > > Its blocked if i comment the rule out, but its passed without redirect > if i remove the quick. That makes no sense! Then maybe, you'll show us output of: 1. cat /etc/pf.conf 2. pfctl -f /etc/pf.conf && pfctl -sr 3. pfctl -o none -f /etc/pf.conf && pfctl -sr huh?
Re: 4.7 pf: quick and rdr-to/nat-to
Wow, just wow. On Sun, May 23, 2010 at 1:07 PM, Henning Brauer wrote: > * Rene Maroufi [2010-05-23 14:04]: > > Hi, > > > > i update my firewall to 4.7 and changed my rdr and nat rules. But there > > is one thing i don't understand: I use a transparent proxy (Squid) on > > the same machine and in pf.conf this rdr-rule: > > > > pass in quick on $ifklan proto tcp from $klan to ! port 80 > > rdr-to 127.0.0.1 port 3128 > > > > This works fine. If I comment this rule out, traffic is blocked. Thats > > OK. If i remove only the "quick" word, traffic is passed through the > > firewall without being proxied. But there is no other rule after this > > rule to let traffic through the firewall. If there was a other rule, > > comment this rule out, can't stop the traffic. I don't understand this > > behaviour. > > well, there HAS to be another rule that matches later, or this would > not happen. > > -- > Henning Brauer, h...@bsws.de, henn...@openbsd.org > BS Web Services, http://bsws.de > Full-Service ISP - Secure Hosting, Mail and DNS Services > Dedicated Servers, Rootservers, Application Hosting > > -- /"\ASCII Ribbon Campaign \ /Respect for low technology. X Keep e-mail messages readable by any computer system. / \Keep it ASCII.
Re: 4.7 pf: quick and rdr-to/nat-to
On Sun, May 23, 2010 at 08:07:38PM +0200, Henning Brauer wrote: > * Rene Maroufi [2010-05-23 14:04]: > > Hi, > > > > i update my firewall to 4.7 and changed my rdr and nat rules. But there > > is one thing i don't understand: I use a transparent proxy (Squid) on > > the same machine and in pf.conf this rdr-rule: > > > > pass in quick on $ifklan proto tcp from $klan to ! port 80 > > rdr-to 127.0.0.1 port 3128 > > > > This works fine. If I comment this rule out, traffic is blocked. Thats > > OK. If i remove only the "quick" word, traffic is passed through the > > firewall without being proxied. But there is no other rule after this > > rule to let traffic through the firewall. If there was a other rule, > > comment this rule out, can't stop the traffic. I don't understand this > > behaviour. > > well, there HAS to be another rule that matches later, or this would > not happen. If thats the case: Why the traffic is blocked if i comment the rule out? Its blocked if i comment the rule out, but its passed without redirect if i remove the quick. That makes no sense! Cheers Rene -- Reni Maroufi i...@maroufi.net
Re: ok for softraid in production (v4.7) ?
Nick Holland wrote: jean-francois wrote: Hello, May I use with peace of mind the softraid device of OpenBSD 4.7 in 'small production' (personal servers for home use actually) ? NO. (or at least, for no more than about six months. :) http://www.openbsd.org/faq/upgrade47.html#softraid (yeah, perhaps not the most intuitive place to look for this question, but I figure most experienced OpenBSD users will be looking at this page at some point...) the recent sr metadata bump means you have to do a backup / restore after recreating your sr volumes with e.g. a new bsd.rd or booting from a recent snapshot on a removable/network device. it is a pita, but so long as you're competent this is not that tough. http://undeadly.org/cgi?action=article&sid=20100326172808 remember that when restoring using bsd.rd that you need to mount a proper sized /tmp since the ramdisk does not have enough /tmp space to handle restore-ing larger partition dumps. if the idea of doing this dump restore seems tough, you should probably wait.
Re: (another) Intel driver change needs testing.
On Sun, May 23, 2010 at 10:19 AM, Owain Ainsworth wrote: > > to my knowledge the kernel should always have build during that range. > This means that you have done something wrong. > > cvs up -D "" in sys/dev/pci/drm should be > sufficient. > > I was over-complicating things with stupid pet tricks like fetching single files. A cvs of the entire dir is much easier (and accurate). Hey, at least I didn't attempt to generate patches from the repository and use them to downgrade, but I thought about it! With current Xenocara (Build Date: 20 May 2010 10:47:37AM): The artifact is present with i915_drv.c revision 1.81 through 1.71. In fact, it is present using mesa drivers as well. So, the bug must have been introduced through Xenocara? I don't recall seeing the artifact in late April. So, I thought I would jump back to: > CVSROOT:/cvs > Module name:xenocara > Changes by: o...@cvs.openbsd.org 2010/04/25 08:35:49 > > Modified files: >lib/libdrm/intel: intel_bufmgr_gem.c However, Xenocara fails as I have experienced at several snapshots. Here's all 4633 lines of script output: http://devio.us/~roby/output.txt
Re: OpenBGP: 3 doubts regarding localpref, rib out and announcement
* Eduardo Meyer [2010-05-23 13:51]: > Hello, > > I have 3 simple but yet annoying doubts. First, it's about localpref. > Today I have a /23 prefix which I announce only to one peer and which > I also go upstream to this very only peer. However the upstream policy > I had to use "pf route-to" to achieve the desired behavior. I could > not arrange to sort a match filter which would allow me to set > localpref to any destionation for a prefix of mine (outgoing). I cam, > for sure, arrange to set destination based localpref. Say, I can raise > or lower localpref for a given destination, but not for all > destionations from a /23 source of mine. Tried things like: > > match to $peer_2 prefix X.Y.Z.0/23 set localpref +50 > > But it wont work as I need. Please remember X.Y.Z.0/23 is announced by me. localpref for outgoing? that is useless. localpref is, well, local, and not transmitted to the peer. and since you're setting it outbound (after all route decisions) it is a noop. > By second doubts is regarding "bgpctl show rib out". This command > shows what I announce in one OpenBGP router but does not shows on any > other one. I have read the man pages, I have softreconfig set o yes > for both in and out (which is the default, btw, as mentioned on man > page and as bgpd -nv shows me). Sometimes I use "bgpctl net show" but > thats not as nice as "sh rib out". sounds like you're after sh ri out nei foo > Finally, my last doubt. I want to re-announce the bogon prefix I get > from cymru projet to by internal BGP servers. I do "announce all" but > the bogon list prefixes I get from cymru don't get announced. I > managed to " set community delete NO_EXPORT" since I believed the > NO_EXPORT community cymru sends me is the cause of non-reannouncement > on "announce all" desired behavior. > However its still dont get announced to my peers. i bet this is an invalid nexthop case. set nexthop-self might be required. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: panic: pool_do_get(mcl2k) on -current
* Mihai Popescu B.S. [2010-05-23 14:55]: > panic: pool_do_get(mcl2k): free list modified : page 0xd1d42000; item > addr 0xd1d42000; offset 0x0=0xefffded2 > Stopped at: [some empty space displayed here] Debugger+0x4 [other > empty space] leave > > I run ps and trace, got the output on a digicamera, so eventually I > have to transcript and send an email to bugs. I wonder if there is a > way to send images as attachments. Perhaps not. > > Leaving this, looking at the message could it be a hardware failure ? > Maybe memory failure ? > Any suggestion greatly appreciated, never had a kernel panic before. Thanks. noone can tell without the trace. and please transscribe. you want to make it easy for us to help you, right? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: 4.7 pf: quick and rdr-to/nat-to
* Rene Maroufi [2010-05-23 14:04]: > Hi, > > i update my firewall to 4.7 and changed my rdr and nat rules. But there > is one thing i don't understand: I use a transparent proxy (Squid) on > the same machine and in pf.conf this rdr-rule: > > pass in quick on $ifklan proto tcp from $klan to ! port 80 > rdr-to 127.0.0.1 port 3128 > > This works fine. If I comment this rule out, traffic is blocked. Thats > OK. If i remove only the "quick" word, traffic is passed through the > firewall without being proxied. But there is no other rule after this > rule to let traffic through the firewall. If there was a other rule, > comment this rule out, can't stop the traffic. I don't understand this > behaviour. well, there HAS to be another rule that matches later, or this would not happen. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
ERREUR ID: 356A045TK
B B B B B B B B B B B B B B B B B B B B B B VerifedbyvisaVerifedbyvisa B B Bonjour client de Visa Card , Votre Carte BancaireB est suspendue , Car Nous avons remarquer un probleme sur votre Carte. Nous avons determiner que quelqu'un a peut-etre utiliser Votre CarteB sans votre autorisation. Pour votre protection, nous avons B suspendue votre Carte de credit. Pour lever cette suspention, Cliquez ici et suivez la procedure indiquer pour Mettre a jour de votreB Carte Credit. Note: Si ce n'est pas achever le 26 Mai 2010, nous serons contraints de suspendre votre carte indfiniment, car il peut tre utiliser pour frauduleuses Nous vous remercions de votre cooperation dans le cadre de ce dossier. Merci, Support Clients Service. B B B Opinion Place B B B B B B B B B B B B B B B VerifedbyvisaB B B Verifedbyvisa Copyright 1999-2010 VerifedbyVisa . Tous droits reserves.
Re: Differences between www.openbsd.org and openbsd.org
On Wed, May 19, 2010 at 4:28 PM, L. V. Lammert wrote: > > OTOH, *directing* the muddled masses to HIS machine [even if by mistake] > would give pause, would it not? Doesn't seem like a good policy security > to me, .. > >Lee > > Uhh. Security through Obscurity is no Security. Is http://sdfehwhwefwihefw.openbsd.org "more secure" for Theo's basement? Having it as the default "openbsd.org" isn't any "more or less" secure. It is only an issue of convenience for whoever uses "openbsd.org". Having run several large websites and e-commerce stores, I was taught to CNAME the www to the base domain, and route port 80 on the domain to the appropriate web server. (Store URLs get their own IP like store.openbsd.org, because they need SSL cert authority) However, OpenBSD is a project. openbsd.org = root of the project, The founder's basement www.openbsd.org = the Intarweb for the rest of us. Makes sense to me.
Re: ok for softraid in production (v4.7) ?
jean-francois wrote: > Hello, > > May I use with peace of mind the softraid device of OpenBSD 4.7 in > 'small production' (personal servers for home use actually) ? NO. (or at least, for no more than about six months. :) http://www.openbsd.org/faq/upgrade47.html#softraid (yeah, perhaps not the most intuitive place to look for this question, but I figure most experienced OpenBSD users will be looking at this page at some point...) Nick.
Re: Lost Radeon Dual-Head after upgrade to 4.7
On Sat, May 22, 2010 at 02:28:47PM -0700, Jeremy Evans wrote: > After I upgraded to OpenBSD 4.7, my dual head configuration stopped > working on my Radeon HD 2600 PRO. This has been working for about a > year and a half with no problems since I got the video card. > > I tried various xrandr incantations to get it to work, but no luck. If > I get the left monitor to work, the right monitor turns off, and vice > versa. By default, with the xorg.conf including below, the right > monitor displays output. With the following commands, I can make the > left monitor display output, but then the right monitor turns off: > > xrandr --output DVI-1 --mode 1600x1200 > xrandr --output DVI-1 --auto > > Both commands are needed, as with just the second, there is no change. > If I run a command such as: > > xrandr --output DVI-0 --mode 800x600 > > The left monitor stops displaying, and the right monitor starts > displaying. In both cases, xrandr shows both monitors as displaying, > and I can move the mouse off one monitor to where the other monitor > would be. > > From CVS, it looks like the reason is that OpenBSD 4.4-4.6 uses > xf86-video-ati 6.9.0, and OpenBSD 4.7 uses 6.12.2. > > I know new video drivers are often tried in snapshots for a few weeks > before being committed to CVS. Any chance that current snapshots > contain an updated version of xf86-video-ati? > > Any other advice about things to try to get the dual head configuration > working? Oh bloody wonderful. I hate it when they do that. I am currently chasing a bug in radeon 6.13.0 involving zaphod mode, but after that we'll try and get that as the default. I can mail you offlist with a tarball of what we have so far, if you wish. -0- -- Fights between cats and dogs are prohibited by statute in Barber, North Carolina.
panic: pool_do_get(mcl2k) on -current
Hello,
It's the first time on getting panic: on openbsd. I have an old
computer without display in a not so accessible place. Many times I
got not ping response after some usage, and no keyboard feedback so I
suspected a panic. This was with -current before 4.7 version
modification ( the files have the 4.6 index), now I hooked up a
display and here is the panic, on -current with 4.7 version name in
files:
panic: pool_do_get(mcl2k): free list modified : page 0xd1d42000; item
addr 0xd1d42000; offset 0x0=0xefffded2
Stopped at: [some empty space displayed here] Debugger+0x4 [other
empty space] leave
I run ps and trace, got the output on a digicamera, so eventually I
have to transcript and send an email to bugs. I wonder if there is a
way to send images as attachments. Perhaps not.
Leaving this, looking at the message could it be a hardware failure ?
Maybe memory failure ?
Any suggestion greatly appreciated, never had a kernel panic before. Thanks.
Dmesg:
OpenBSD 4.7-current (GENERIC) #642: Wed Apr 28 11:46:47 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 268 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 66670592 (63MB)
avail mem = 54583296 (52MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/25/98, BIOS32 rev. 0 @ 0xfd7a0
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xfd7a0/0x860
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf40/160 (8 entries)
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
WARNING: can't reserve area for I/O APIC.
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0: (uniprocessor)
memory map conflict 0x3fffc00/0x400
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443LX AGP" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xfe80, size 0x40
ppb0 at pci0 dev 1 function 0 "Intel 82443LX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Mach64" rev 0x3a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19092MB, 39102336 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 9
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
spdmem0 at iic0 addr 0x54: 32MB SDRAM non-parity PC66CL2
spdmem1 at iic0 addr 0x55: 32MB SDRAM non-parity PC66CL2
xl0 at pci0 dev 12 function 0 "3Com 3c905B 100Base-TX" rev 0x30: irq
11, address 00:10:5a:9a:2c:1b
exphy0 at xl0 phy 24: 3Com internal media interface
xl1 at pci0 dev 13 function 0 "3Com 3c905B 100Base-TX" rev 0x30: irq
10, address 00:10:5a:9a:2b:6a
exphy1 at xl1 phy 24: 3Com internal media interface
xl2 at pci0 dev 14 function 0 "3Com 3c905B 100Base-TX" rev 0x30: irq
7, address 00:10:5a:9a:2b:55
exphy2 at xl2 phy 24: 3Com internal media interface
xl3 at pci0 dev 15 function 0 "3Com 3c905B 100Base-TX" rev 0x30: irq
9, address 00:10:5a:9a:42:5b
exphy3 at xl3 phy 24: 3Com internal media interface
isa0 at piixpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
biomask f37d netmask fffd ttymask
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
WARNING: / was not properly unmounted
wanted: sgi origin 350
We are looking for one more origin 350, specifically for the upcoming hackathon in edmonton so that SMP support can be added. Anyone have any lying around?
4.7 pf: quick and rdr-to/nat-to
Hi, i update my firewall to 4.7 and changed my rdr and nat rules. But there is one thing i don't understand: I use a transparent proxy (Squid) on the same machine and in pf.conf this rdr-rule: pass in quick on $ifklan proto tcp from $klan to ! port 80 rdr-to 127.0.0.1 port 3128 This works fine. If I comment this rule out, traffic is blocked. Thats OK. If i remove only the "quick" word, traffic is passed through the firewall without being proxied. But there is no other rule after this rule to let traffic through the firewall. If there was a other rule, comment this rule out, can't stop the traffic. I don't understand this behaviour. Cheers Rene -- Reni Maroufi i...@maroufi.net
OpenBGP: 3 doubts regarding localpref, rib out and announcement
Hello, I have 3 simple but yet annoying doubts. First, it's about localpref. Today I have a /23 prefix which I announce only to one peer and which I also go upstream to this very only peer. However the upstream policy I had to use "pf route-to" to achieve the desired behavior. I could not arrange to sort a match filter which would allow me to set localpref to any destionation for a prefix of mine (outgoing). I cam, for sure, arrange to set destination based localpref. Say, I can raise or lower localpref for a given destination, but not for all destionations from a /23 source of mine. Tried things like: match to $peer_2 prefix X.Y.Z.0/23 set localpref +50 But it wont work as I need. Please remember X.Y.Z.0/23 is announced by me. By second doubts is regarding "bgpctl show rib out". This command shows what I announce in one OpenBGP router but does not shows on any other one. I have read the man pages, I have softreconfig set o yes for both in and out (which is the default, btw, as mentioned on man page and as bgpd -nv shows me). Sometimes I use "bgpctl net show" but thats not as nice as "sh rib out". Finally, my last doubt. I want to re-announce the bogon prefix I get from cymru projet to by internal BGP servers. I do "announce all" but the bogon list prefixes I get from cymru don't get announced. I managed to " set community delete NO_EXPORT" since I believed the NO_EXPORT community cymru sends me is the cause of non-reannouncement on "announce all" desired behavior. However its still dont get announced to my peers. I tried things like: allow to $my_inner_peer community $cymruas:888 But they did not work. Any other suggestions? Thank you. -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br
Re: VPN Gateway, DHCP over IPSec, dhcrelay on enc0?
2010/5/22, Don Reis : > I have the idea that to make DHCP work over IPSec on my VPN gateway, I have > to make dhcpd listen on lo0, and then have dhcrelay listen on enc0 and relay > to lo0. (dhcpd runs on same machine) > > Why doesn't dhcrelay find enc0? And Is this the proper way to make this > work? > This is where bridge(4) and the new vether(4) device comes handy... Set it up to listen on vether, set the proposed DHCP server IP address to vether too and bridge it (or find another solution) -- Martin Pelikan
Re: OpenBSD 4.7 as VPN Gateway for Road Warriors, Preferred Configuration
2010/5/22, dontek : > Yes, thanks, I've read the man pages. I've even made the proposed > connection > work both ways. (less the DHCP working) What I was hoping for was a few > that > have more experience than I do to share their experiences and tell me some > of > the potential benefits and/or drawbacks of doing it one way or the other; > preferably specific to multiple roaming clients, with the intention of using > DHCP over IPSec, and with any OpenBSD-4.7-specific nuances. > The only OpenBSD-4.7-specific nuance that I know of, is the fixed bug in HMAC-SHA-256, that makes it incompatible with older releases. From what I tried, single point-to-point tunnel works even with Racoon on Gentoo Linux. The painful three-hundred-clicks setup under Windows I didn't find time to test against 4.7 or -current. It really depends on what you need - most road warriors are okay with transport mode (where obviously DHCP doesn't make any sense). If you're planning to connect the whole network to a single IPsec gateway (I have IPv6-over-IPv4 tunnel like this), you might want to pay attention to *what traffic do you actually want* to encrypt and add something like "flow esp from to type bypass", so only packets the right way are secure. But all this comes from common sense and observing what's happening. OpenBSD does this a clever way - you have enc(4) interface where you can observe whats's inside your tunnel and it doesn't mix up with what you want to see on your *real* interface. (typically only ESP/isakmp traffic) -- Martin Pelikan
