Re: npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

2021-03-08 Thread YASUOKA Masahiko
Hi,

I looked into the ICCN packets you sent me separately.  Its "Proxy Authen
Challenge" length is 31 and "Proxy Authen Type" is PPP CHAP.  The
message seems to comply RFC 2661.

Also what I said
>> It's for CHAP or MSCHAPv1.  If MD5 is selected for PPP CHAP, the
>> challenge length for CHAP is 16 octet.  The challenge for MSCHAPv1 is
>> also 8 octet, but npppd doesn't support MSCHAv1 anyway.  So 24 must be
>> enough for RFC 2661.

is false.  Length of callenge is "independent of the hash algorithm".

In RFC 1994 (PPP CHAP):
|  The Challenge Value is a variable stream of octets.  The
|  importance of the uniqueness of the Challenge Value and its
|  relationship to the secret is described above.  The Challenge
|  Value MUST be changed each time a Challenge is sent.  The length
|  of the Challenge Value depends upon the method used to generate
|  the octets, and is independent of the hash algorithm used.

it doesn't state the limit clearly.

I suppose 24 had been long enough for many implementations, but
actually new Junipor is using 31-63

>> > Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 Received 
>> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 40 > 24
>> > Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 Received 
>> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 62 > 24
>> > Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 Received 
>> > bad ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 46 > 24
>> > Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 Received bad 
>> > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 63 > 24
>> > Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none

So I suppose changing the following limit will solve the problem.

  #define MAX_CHALLENGE_LENGTH24

Also I found a Junipor's document,

  
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/challenge-length-edit-dynamic-profiles-chap.html

the max challenge length can be configured 63 at the maximum.

I'm thinking change the limit in npppd to 96.


On Mon, 8 Mar 2021 20:33:21 +
Ryan Freeman  wrote:
> Thank you for the reply!  I have been given permission to show a bit
> more about our setup.  I snipped out some of the original message, and
> I'll post the additions at the bottom.
> 
> On Sat, Mar 06, 2021 at 07:45:03PM +0900, YASUOKA Masahiko wrote:
>> Hi,
>> 
>> On Fri, 5 Mar 2021 19:07:45 +
>> Ryan Freeman  wrote:
>> > Full disclosure: this took place over the course of about a month, and
>> > I've done my best to include the relevant info..
>> > 
>> > Unsure if this is really a bug, and I don't have a real diff for a fix, 
>> > just a
>> > work-around, so misc it is.
>> > 
>> > This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed.
>> > We considered trying -current, but noticed no activity in the npppd tree
>> > that might make a difference.
>> > 
>> > 'old' and 'new' equipment types from upstream are both Juniper, though
>> > unsure of exact models.  Old  should be Juniper ERX of some type, new
>> > I only know this from packet capture: Juniper Networks/Unisphere(4874).
>> > 
>> > I work for a small ISP and we are exploring the use of npppd(8) for
>> > termination of L2TP with incumbent for xDSL connections. 
>> > 
>> > Working with the provider, their 'old' equipment works fine[1], however,
>> > the 'new' network would always cause these errors upon receipt of Proxy 
>> > AVP:
>> > 
>> > Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad 
>> > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24
>> > Feb  5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN 
>> > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
>> > 
>> > Looking at RFC 2661, I can't actually figure where a limit of 24 is 
>> > imposed,
>> >
> ...snip...
>> 
>> Yes.  The limit is come from 

Re: npppd(8) and PROXY_AUTHEN_CHALLENGE bad length with Juniper

2021-03-06 Thread YASUOKA Masahiko
vs/src/usr.sbin/npppd/l2tp/l2tp_call.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 l2tp_call.c
> --- l2tp/l2tp_call.c  5 Dec 2015 16:10:31 -   1.19
> +++ l2tp/l2tp_call.c  5 Mar 2021 17:46:12 -
> @@ -546,7 +546,8 @@ l2tp_call_recv_ICCN(l2tp_call *_this, u_
>   dpi->last_recv_lcp.ldata = avp_attr_length(avp);
>   break;
>   case L2TP_AVP_TYPE_PROXY_AUTHEN_CHALLENGE:
> - AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall));
> + /* XXX: disable to try and skirt 'too long' errors */
> + /* AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall)); */
>   memcpy(dpi->auth_chall, avp->attr_value,
>   avp_attr_length(avp));
>   dpi->lauth_chall = avp_attr_length(avp);
> 
> We've been running this modified npppd for a week now, our upstream is happy
> that they can continue phasing out their 'old' gear, and our endusers are

Do you mean that the endusers can connect with the above diff?

> Neither myself nor my colleague can figure out how '24' is chosen for _maxlen,
> but as this finally got us moving forward, wanted to share what we had and see
> if we are on the right track.

diff --git a/usr.sbin/npppd/npppd/ppp.h b/usr.sbin/npppd/npppd/ppp.h
index 1bb8bfc6cf3..219b47c6172 100644
--- a/usr.sbin/npppd/npppd/ppp.h
+++ b/usr.sbin/npppd/npppd/ppp.h
@@ -82,7 +82,7 @@
 
 #defineMAX_USERNAME_LENGTH 256
 #defineMAX_PASSWORD_LENGTH 256
-#define MAX_CHALLENGE_LENGTH24
+#define MAX_CHALLENGE_LENGTH256
 
 #define INADDR_IPCP_OBEY_REMOTE_REQ0xL
 
is better if it works.

> I am thinking that we would want a maximum length set there still, but perhaps
> it can be pushed up?  I've seen many of those error types, all seem to stay
> below 100:
> 
> Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 Received bad 
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 40 > 24
> Feb  8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 SendCDN 
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 Received bad 
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 62 > 24
> Feb  8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 SendCDN 
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 Received bad 
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 46 > 24
> Feb  8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 SendCDN 
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 Received bad 
> ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 63 > 24
> Feb  8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 SendCDN 
> result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none
> 
> [1] at some point over the course of debugging, I did notice that this
> error would /sometimes/ print on the connections from the 'old' equipment,
> but would continue to work anyway:
> 
> Mar  5 10:21:44 edge9 npppd[35209]: ppp id=4108 layer=chap proto=unknown 
> "Proxy Authen Challenge" is too long.
> 
> This now also prints on all the 'new equipment' successful connections since
> disabling the AVP_MAXLEN_CHECK.

-- 
  YASUOKA Masahiko  http://yasuoka.net/~yasuoka/
  mailto:yasu...@yasuoka.net  mobile:090-8801-1637



Re: npppd - changing clients' route table

2021-02-21 Thread YASUOKA Masahiko
Hi,

On Sun, 21 Feb 2021 19:18:48 +0100
Radek  wrote:
>> The interface which terminate the tunnel has "192.168.4.254".
>> Right?
> Do you mean the other end of the tunnel? It is 10.109.4.254
> interface pppx0 address 10.109.4.254 ipcp IPCP

Sorry, "192.168.4.244" should have been "10.109.4.254".

>> How about if you configure the npppd-users
>> 
>> rdk:
>>   :password=pasword:\
>>   :framed-ip-address=10.109.4.254:\
>>   :framed-ip-netmask=255.255.255.0:
>> 
>> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
>> session authenticated by the above "rdk".
> I have tried to configure npppd-users with netmask /24, but it doesnt make 
> any changes. Still have all traffic to 10.0.0.0/8 going across the tunnel to 
> 10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 through 
> the tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through default gw 
> or sometimes some traffic to 10.0.0.0/8 through another tunnel at the same 
> time. Now if the PPP tunnel is established the VPN catches all the 10.0.0.0/8 
> traffic.
> 
> The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.
> 
> Example:
> I have a public, static IP. There is configured route to 10.55.0.0/24 at the 
> ISP's side and I dont need any VPN tunnel to access 10.55.. Somewhere 
> over the rainbow is a router with LAN 10.109.3.0/24 and npppd.
> If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I 
> can't access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.

The route to the natural netmask of the tunnel address, 10.0.0.0/8 in
this case, is configured by Windows automatically.  I don't know a way
to stop or override this.  But by using another addresses for the
tunnel, you can avoid the problem.  Also we can use dhcpd(8) to push
routes configuration.

For example,

1. Use 192.168.255.0/24 for the tunnel to avoid the conflict on
   10.0.0.0/8.

   ipcp IPCP {
  pool-address 192.168.255.1-192.168.255.32
:
   interface pppx0 address 192.168.255.254 ipcp IPCP
   ---
   rdk:
:password=pasword:\
:framed-ip-address=192.168.255.32:

2. Configure dhcpd

   /etc/dhcpd-l2tp.conf
   
   subnet 192.168.255.0 netmask 255.255.255.0 {
 option classless-ms-static-routes 10.109.3.0/24 192.168.255.254;
 option classless-static-routes10.109.3.0/24 192.168.255.254;
   }
   ---
  
   $ doas /usr/sbin/dhcpd -u255.255.255.255 -c /etc/dhcpd-l2tp.conf

> On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
> YASUOKA Masahiko  wrote:
> 
>> Hello,
>> 
>> On Sat, 20 Feb 2021 21:14:24 +0100
>> Radek  wrote:
>> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
>> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
>> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes 
>> > via 10.109.4.254
>> > 
>> > client> route print 
>> > Network Destination   Netmask  Gateway  Interface Metric
>> >   0.0.0.0  0.0.0.0   192.168.1.1
>> > 192.168.1.101 20
>> > 10.0.0.0  255.0.0.0 10.109.4.254  
>> > 10.109.4.1 21
>> > 10.109.4.1  255.255.255.255 On-link10.109.4.1  
>> >   276
>> > [...]
>> 
>> The interface which terminate the tunnel has "192.168.4.254".
>> Right?
>> 
>> > $ cat /etc/npppd/npppd-users
>> > rdk:\
>> > :password=pasword:\
>> > :framed-ip-address=10.109.4.1:
>> > #:framed-ip-netmask=255.255.255.0:
>> 
>> How about if you configure the npppd-users
>> 
>> rdk:
>>   :password=pasword:\
>>   :framed-ip-address=10.109.4.254:\
>>   :framed-ip-netmask=255.255.255.0:
>> 
>> ?
>> 
>> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
>> session authenticated by the above "rdk".
>> 
>> 
>> On Sat, 20 Feb 2021 21:14:24 +0100
>> Radek  wrote:
>> > Hi, 
>> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
>> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
>> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes 
>> > via 10.109.4.254
>> > 
>> > client> route print 
>> > Network Destination   Netmask  Gateway  Interface Metric
>> >   0.0.0.0  0.0.0.0   192.168.1.1
>> > 192.168.1.101 20
>> > 10.0.0.0  255.0.0.0 10.109.4.254  
>> > 

Re: npppd - changing clients' route table

2021-02-21 Thread YASUOKA Masahiko
Hello,

On Sat, 20 Feb 2021 21:14:24 +0100
Radek  wrote:
> I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes via 
> 10.109.4.254
> 
> client> route print 
> Network Destination   Netmask  Gateway  Interface Metric
>   0.0.0.0  0.0.0.0   192.168.1.1192.168.1.101 
> 20
> 10.0.0.0  255.0.0.0 10.109.4.254  10.109.4.1  
>21
> 10.109.4.1  255.255.255.255 On-link10.109.4.1
> 276
> [...]

The interface which terminate the tunnel has "192.168.4.254".
Right?

> $ cat /etc/npppd/npppd-users
> rdk:\
> :password=pasword:\
> :framed-ip-address=10.109.4.1:
> #:framed-ip-netmask=255.255.255.0:

How about if you configure the npppd-users

rdk:
  :password=pasword:\
  :framed-ip-address=10.109.4.254:\
  :framed-ip-netmask=255.255.255.0:

?

The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
session authenticated by the above "rdk".


On Sat, 20 Feb 2021 21:14:24 +0100
Radek  wrote:
> Hi, 
> I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes via 
> 10.109.4.254
> 
> client> route print 
> Network Destination   Netmask  Gateway  Interface Metric
>   0.0.0.0  0.0.0.0   192.168.1.1192.168.1.101 
> 20
> 10.0.0.0  255.0.0.0 10.109.4.254  10.109.4.1  
>21
> 10.109.4.1  255.255.255.255 On-link10.109.4.1
> 276
> [...]
> 
> I need to redirect the traffic to 10.109.4.254 only if it goes to the remote 
> LAN (10.109.3.0/24), the rest should go via def gw.
> How can I configure it on the router/server side ?
> 
> $ cat /etc/npppd/npppd.conf
> # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $
> # sample npppd configuration file.  see npppd.conf(5)
> 
> set max-session 200
> set user-max-session 4
> 
> authentication LOCAL type local {
> users-file "/etc/npppd/npppd-users"
> }
> tunnel L2TP protocol l2tp {
> listen on X.X.X.X
> }
> 
> ipcp IPCP {
> pool-address 10.109.4.1-10.109.4.32
> dns-servers 1.1.1.1
> }
> 
> # use pppx(4) interface.  use an interface per a ppp session.
> interface pppx0 address 10.109.4.254 ipcp IPCP
> bind tunnel from L2TP authenticated by LOCAL to pppx0
> 
> $ cat /etc/npppd/npppd-users
> rdk:\
> :password=pasword:\
> :framed-ip-address=10.109.4.1:
> #:framed-ip-netmask=255.255.255.0:
> 
> $ dmesg | head
> OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021
> 
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> -- 
> Radek
> 



Re: npppd - problem with simultaneous sessions

2021-01-08 Thread YASUOKA Masahiko

Hi,


It seems that only last person can use the tunnel.  This reminds me
problems through NAT.

True. Can it be caused by wrong PF rules?


No, I don't think so.

I suppose I could repeat the problem.

When the problem is happening, is the counter "dropped due to missing 
IPsec protection" incremented?


  % netstat -sp udp
  udp:
  655 datagrams received
  0 with incomplete header
  0 with bad data length field
  0 with bad checksum
  297 with no checksum
  356 input packets software-checksummed
  236 output packets software-checksummed
  46 dropped due to no socket
  0 broadcast/multicast datagrams dropped due to no socket
  3 dropped due to missing IPsec protection
  0 dropped due to full socket buffers
  609 delivered
  236 datagrams output
  354 missed PCB cache

I started looking into this problem.

On Thu, 7 Jan 2021 09:45:07 +0100
radek  wrote:

Hi,


It seems that only last person can use the tunnel.  This reminds me
problems through NAT.

True. Can it be caused by wrong PF rules?


Both sessions seem to be connected from A.B.C.D.  Are the clients
behind a NAT?

Yes, both client are behind the same router/NAT.
I have a 66/i386 box running npppd on producion and my two clients 
can be connected the same time flawlessly.



How about the npppd side?  Does the client directly connect to

> tunnel L2TP protocol l2tp {
> listen on X.Y.Z.13
> }

X.Y.Z.13 ?  Or a NAT is there?

It is directly connected do X.Y.Z.13, no NAT.

On Thu, 07 Jan 2021 16:27:57 +0900 (JST)
YASUOKA Masahiko  wrote:


Hi,

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:
> I have a box with relatively fresh install of 68/amd64, fully
> syspatched. There is a npppd server running on it. The problem is
> that I can have only one nppp session at one time. If the second
> vpn user connects the box, the first nppp session hangs/drops. I
> probably have missed something obvious in my setup but I really
> can't find what it is.

It seems that only last person can use the tunnel.  This reminds me
problems through NAT.

> Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base
> logtype=TUNNELSTART user="rdk" duration=1sec layer2=L2TP
> layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.1 
iface=pppx0


> Jan  6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base
> logtype=TUNNELSTART user="rdk-test" duration=1sec layer2=L2TP
> layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.11 
iface=pppx0


Both sessions seem to be connected from A.B.C.D.  Are the clients
behind a NAT?

How about the npppd side?  Does the client directly connect to

> tunnel L2TP protocol l2tp {
> listen on X.Y.Z.13
> }

X.Y.Z.13 ?  Or a NAT is there?

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:
> Hi @misc,
>
> I have a box with relatively fresh install of 68/amd64, fully
> syspatched. There is a npppd server running on it. The problem is
> that I can have only one nppp session at one time. If the second
> vpn user connects the box, the first nppp session hangs/drops. I
> probably have missed something obvious in my setup but I really
> can't find what it is.
>
> Please help me to solve the problem.
> Thank you.
>
> $cat /etc/npppd/npppd.conf
> authentication LOCAL type local {
> users-file "/etc/npppd/npppd-users"
> }
> tunnel L2TP protocol l2tp {
> listen on X.Y.Z.13
> }
> ipcp IPCP {
> pool-address 10.109.4.1-10.109.4.32
> dns-servers 1.1.1.1
> }
> # use pppx(4) interface.  use an interface per a ppp session.
> interface pppx0 address 10.109.4.254 ipcp IPCP
> bind tunnel from L2TP authenticated by LOCAL to pppx0
>
> $cat /etc/hostname.enc0
> up
>
>
> $cat /etc/sysctl.conf
> net.inet.ip.forwarding=1
> net.inet.ipcomp.enable=1
> net.inet.esp.enable=1
> net.inet.gre.allow=1
> net.pipex.enable=1
>
> $cat /etc/rc.conf.local
> ipsec=YES
> ipsec_rules=/etc/ipsec.conf
> isakmpd_flags="-K"
> npppd_flags=""
>
> $cat /etc/ipsec.conf
> wan_ipv4 = X.Y.Z.13
> ike passive esp transport \
>  proto udp from $wan_ipv4 to any port 1701 \
>  main auth "hmac-sha1" enc "3des" group modp1024 \
>  quick auth "hmac-sha1" enc "aes" group modp1024 \
>  psk "pskpskpsk"
>
> $cat /etc/pf.conf
> [...]
> vpn_if = "pppx"
> vpn_local  = "10.109.4.0/24"
>
> pass in on $ext_if proto udp from any to (egress:0) port
> {isakmp,ipsec-nat-t,l2tp}
> pass in on $ext_if proto {ah,esp}
> pass log proto { gre } from any to any keep state
>
> # filter all IPSec traffic on the enc interface
> pass on enc0 keep state (if-bound)
>
> # allow all trafic in on and o

Re: npppd - problem with simultaneous sessions

2021-01-06 Thread YASUOKA Masahiko

Hi,

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:
I have a box with relatively fresh install of 68/amd64, fully 
syspatched. There is a npppd server running on it. The problem is 
that I can have only one nppp session at one time. If the second 
vpn user connects the box, the first nppp session hangs/drops. I 
probably have missed something obvious in my setup but I really 
can't find what it is.


It seems that only last person can use the tunnel.  This reminds me 
problems through NAT.


Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base 
logtype=TUNNELSTART user="rdk" duration=1sec layer2=L2TP 
layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.1 iface=pppx0


Jan  6 20:53:44 fw-u npppd[82720]: ppp id=1 layer=base 
logtype=TUNNELSTART user="rdk-test" duration=1sec layer2=L2TP 
layer2from=A.B.C.D:1701 auth=MS-CHAP-V2  ip=10.109.4.11 iface=pppx0


Both sessions seem to be connected from A.B.C.D.  Are the clients 
behind a NAT?


How about the npppd side?  Does the client directly connect to


tunnel L2TP protocol l2tp {
listen on X.Y.Z.13
}


X.Y.Z.13 ?  Or a NAT is there?

On Wed, 6 Jan 2021 21:33:49 +0100
Radek  wrote:

Hi @misc,

I have a box with relatively fresh install of 68/amd64, fully 
syspatched. There is a npppd server running on it. The problem is 
that I can have only one nppp session at one time. If the second 
vpn user connects the box, the first nppp session hangs/drops. I 
probably have missed something obvious in my setup but I really 
can't find what it is.


Please help me to solve the problem.
Thank you.

$cat /etc/npppd/npppd.conf
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP protocol l2tp {
listen on X.Y.Z.13
}
ipcp IPCP {
pool-address 10.109.4.1-10.109.4.32
dns-servers 1.1.1.1
}
# use pppx(4) interface.  use an interface per a ppp session.
interface pppx0 address 10.109.4.254 ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to pppx0

$cat /etc/hostname.enc0
up


$cat /etc/sysctl.conf
net.inet.ip.forwarding=1
net.inet.ipcomp.enable=1
net.inet.esp.enable=1
net.inet.gre.allow=1
net.pipex.enable=1

$cat /etc/rc.conf.local
ipsec=YES
ipsec_rules=/etc/ipsec.conf
isakmpd_flags="-K"
npppd_flags=""

$cat /etc/ipsec.conf
wan_ipv4 = X.Y.Z.13
ike passive esp transport \
 proto udp from $wan_ipv4 to any port 1701 \
 main auth "hmac-sha1" enc "3des" group modp1024 \
 quick auth "hmac-sha1" enc "aes" group modp1024 \
 psk "pskpskpsk"

$cat /etc/pf.conf
[...]
vpn_if = "pppx"
vpn_local  = "10.109.4.0/24"

pass in on $ext_if proto udp from any to (egress:0) port 
{isakmp,ipsec-nat-t,l2tp}

pass in on $ext_if proto {ah,esp}
pass log proto { gre } from any to any keep state

# filter all IPSec traffic on the enc interface
pass on enc0 keep state (if-bound)

# allow all trafic in on and out to the VPN network
pass on $vpn_if from $vpn_local
pass on $vpn_if to $vpn_local

# NAT VPN traffic going out on the public interface with the public 
IP
match out log on $ext_if inet proto { tcp, udp, icmp } from 
$vpn_local nat-to ($ext_if) set prio (3,7)


some logs...

Jan  6 20:53:14 fw-u last message repeated 4 times
Jan  6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC

Jan  6 20:53:16 fw-u last message repeated 2 times
Jan  6 20:53:16 fw-u isakmpd[11638]: attribute_unacceptable: 
GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 logtype=Started 
RecvSCCRQ from=A.B.C.D:1701/udp tunnel_id=1/26 protocol=1.0 
winsize=8 hostname=w520 vendor=Microsoft firm=0601

Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendSCCRP
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvSCCN
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 SendZLB
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 RecvZLB
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 RecvICRQ 
session_id=1
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 SendICRP 
session_id=6499
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 RecvICCN 
session_id=1 calling_number= tx_conn_speed=1 framing=sync
Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 
logtype=PPPBind ppp=0
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=base 
logtype=Started tunnel=L2TP(A.B.C.D:1701)

Jan  6 20:53:16 fw-u npppd[82720]: l2tpd ctrl=1 call=6499 SendZLB
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp 
logtype=Opened mru=1360/1400 auth=MS-CHAP-V2 magic=e916be4d/3c630a24
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId 
magic=3c630a24 text=MSRASV5.20
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId 
magic=3c630a24 text=MSRAS-0-W520
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=lcp RecvId 
magic=3c630a24 text=.=. .`.M
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=chap 
proto=mschap_v2 logtype=Success username="rdk" realm=LOCAL
Jan  6 20:53:16 fw-u npppd[82720]: ppp id=0 layer=mppe mismatch 

Re: OpenBSD UEFI on QEMU emulator

2020-10-22 Thread YASUOKA Masahiko
On Fri, 23 Oct 2020 09:59:24 +0800
Kevin Shell  wrote:
> I want to try out OpenBSD UEFI.
> How to install OpenBSD with UEFI boot on qemu?
> The install68.iso has no UEFI support.
> My following command on Linux can't boot OpenBSD UEFI.
> 
> qemu-system-x86_64 -enable-kvm \
>-machine q35 \
>-cpu host \
>-smp cores=4,threads=1 \
>-m 1G \
>-bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
>-drive file=install68.img,format=raw

Does the drive of "install68.img" appear on the boot menu on BIOS?

At least on my linux machine,

  qemu-system-x86_64 -machine q35 -smp cores=4,threads=1 -m 1G
-bios /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
-drive file=install68.img,format=raw

doesn't boot as well.  The drive doesn't appear on the boot menu.
But by removing "-machine q35" from the line, it booted successfully.



Re: EFI boot on Dell PowerEdge R610

2020-06-17 Thread YASUOKA Masahiko
Hi,

On Wed, 17 Jun 2020 00:37:48 -0700
Johan Hattne  wrote:
> On 2020-05-29 17:01, Johan Hattne wrote:
>> 
>>> On May 28, 2020, at 20:38, YASUOKA Masahiko 
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, 28 May 2020 09:46:23 -0700
>>> Johan Hattne  wrote:
>>>>> On May 28, 2020, at 06:42, Nick Holland 
>>>>> wrote:
>>>>>
>>>>> On 2020-05-28 05:15, Johan Hattne wrote:
>>>>>> On 2020-05-28 00:56, Johan Hattne wrote:
>>>>>>> On 2020-05-28 00:43, YASUOKA Masahiko wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Wed, 27 May 2020 22:32:58 -0700
>>>>>>>> Johan Hattne  wrote:
>>>>>>>>> I've been trying to boot the 6.7 installation media from USB via EFI
>>>>>>>>> on a Dell PowerEdge R610.  The screen goes blank and then the thing
>>>>>>>>> resets (so no kernel output or anything).  I can boot the same stick
>>>>>>>>> via BIOS.
>>>>>>>>>
>>>>>>>>> I've been searching for a while without results.  Firmware settings
>>>>>>>>> look sane to me. Is this something anybody has seen before? Any hint
>>>>>>>>> on where I could even start looking for problems would be very much
>>>>>>>>> appreciated!
>>>>>>>>
>>>>>>>> I'd like you to try the diff attached with the following message.
>>>>>>>>
>>>>>>>> https://marc.info/?l=openbsd-tech=158280719421562=2
>>>>>>>
>>>>>>> Thanks a lot, Yasuoka! Is there any chance you could provide a
>>>>>>> compiled
>>>>>>> BOOTX64.EFI?  I don't have an amd64 build environment at the moment.
>>>>>>
>>>>>> After a bit of off-list discussion, Yasuoka concluded that above diff
>>>>>> won't help here.  To clarify the issue: there is no output at all
>>>>>> before
>>>>>> the machine resets, in particular there is no prompt from the EFI boot
>>>>>> program.
>>>>>>
>>>>>> // Johan
>>>>>>
>>>>>
>>>>> Have you tried firmware updates?
>>>>> That machine is many years old, I'd not be the slightest bit surprised
>>>>> if
>>>>> the firmware was buggy and didn't boot much of anything in EFI mode
>>>>> other
>>>>> than Windows and maybe Linux.
>>>>
>>>> Thanks, Nick!  The firmware is up to date.  And the machine does boot
>>>> e.g. NetBSD through EFI.
>>>
>>> Probing serial devices is one of the differences from NetBSD efiboot.
>>>
>>> diff --git a/sys/arch/amd64/stand/efiboot/conf.c
>>> b/sys/arch/amd64/stand/efiboot/conf.c
>>> index 3eb745d808d..8d385a4f198 100644
>>> --- a/sys/arch/amd64/stand/efiboot/conf.c
>>> +++ b/sys/arch/amd64/stand/efiboot/conf.c
>>> @@ -89,7 +89,7 @@ int ndevs = nitems(devsw);
>>>
>>> struct consdev constab[] = {
>>> { efi_cons_probe, efi_cons_init, efi_cons_getc, efi_cons_putc },
>>> -   { efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
>>> +   //{ efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
>>> { NULL }
>>> };
>>> struct consdev *cn_tab = constab;
>>>
>>> I put a compiled binary on https://yasuoka.net/~yasuoka/BOOTX64.EFI
>> Thanks a lot, Yasuoka!  The binary you compiled still exhibits the
>> same problem (it immediately resets the machine).
> 
> Another difference to NetBSD's efiboot is the way the heap is
> allocated: OpenBSD does AllocateMaxAddress, whereas NetBSD does
> AllocateAnyPages. Turns out the EFI on this machine fails with
> AllocateMaxAddress (so I guess Nick was right).  For what it's worth,
> the patch below allowed me to eventually boot the kernel through EFI.

Nice finding.

I remember that HEAP_LIMIT was for some machines.

  https://marc.info/?t=14425410003=1=2

Do you have or can you take the result of "machine memory" on efiboot?

> Index: Makefile.common
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efi64/Makefile.common,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile.common
> --- Makefile.common 5 Mar 2020 16:36:30 -   1.5
> +++ Make

Re: EFI boot on Dell PowerEdge R610

2020-05-28 Thread YASUOKA Masahiko
Hi,

On Thu, 28 May 2020 09:46:23 -0700
Johan Hattne  wrote:
>> On May 28, 2020, at 06:42, Nick Holland  wrote:
>> 
>> On 2020-05-28 05:15, Johan Hattne wrote:
>>> On 2020-05-28 00:56, Johan Hattne wrote:
>>>> On 2020-05-28 00:43, YASUOKA Masahiko wrote:
>>>>> Hi,
>>>>> 
>>>>> On Wed, 27 May 2020 22:32:58 -0700
>>>>> Johan Hattne  wrote:
>>>>>> I've been trying to boot the 6.7 installation media from USB via EFI
>>>>>> on a Dell PowerEdge R610.  The screen goes blank and then the thing
>>>>>> resets (so no kernel output or anything).  I can boot the same stick
>>>>>> via BIOS.
>>>>>> 
>>>>>> I've been searching for a while without results.  Firmware settings
>>>>>> look sane to me.  Is this something anybody has seen before?  Any hint
>>>>>> on where I could even start looking for problems would be very much
>>>>>> appreciated!
>>>>> 
>>>>> I'd like you to try the diff attached with the following message.
>>>>> 
>>>>> https://marc.info/?l=openbsd-tech=158280719421562=2
>>>> 
>>>> Thanks a lot, Yasuoka!  Is there any chance you could provide a compiled 
>>>> BOOTX64.EFI?  I don't have an amd64 build environment at the moment.
>>> 
>>> After a bit of off-list discussion, Yasuoka concluded that above diff 
>>> won't help here.  To clarify the issue: there is no output at all before 
>>> the machine resets, in particular there is no prompt from the EFI boot 
>>> program.
>>> 
>>> // Johan
>>> 
>> 
>> Have you tried firmware updates?
>> That machine is many years old, I'd not be the slightest bit surprised if
>> the firmware was buggy and didn't boot much of anything in EFI mode other
>> than Windows and maybe Linux.
> 
> Thanks, Nick!  The firmware is up to date.  And the machine does boot e.g. 
> NetBSD through EFI.

Probing serial devices is one of the differences from NetBSD efiboot.

diff --git a/sys/arch/amd64/stand/efiboot/conf.c 
b/sys/arch/amd64/stand/efiboot/conf.c
index 3eb745d808d..8d385a4f198 100644
--- a/sys/arch/amd64/stand/efiboot/conf.c
+++ b/sys/arch/amd64/stand/efiboot/conf.c
@@ -89,7 +89,7 @@ int ndevs = nitems(devsw);
 
 struct consdev constab[] = {
{ efi_cons_probe, efi_cons_init, efi_cons_getc, efi_cons_putc },
-   { efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
+   //{ efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
{ NULL }
 };
 struct consdev *cn_tab = constab;

I put a compiled binary on https://yasuoka.net/~yasuoka/BOOTX64.EFI



Re: EFI boot on Dell PowerEdge R610

2020-05-28 Thread YASUOKA Masahiko
Hi,

On Wed, 27 May 2020 22:32:58 -0700
Johan Hattne  wrote:
> I've been trying to boot the 6.7 installation media from USB via EFI
> on a Dell PowerEdge R610.  The screen goes blank and then the thing
> resets (so no kernel output or anything).  I can boot the same stick
> via BIOS.
> 
> I've been searching for a while without results.  Firmware settings
> look sane to me.  Is this something anybody has seen before?  Any hint
> on where I could even start looking for problems would be very much
> appreciated!

I'd like you to try the diff attached with the following message.

https://marc.info/?l=openbsd-tech=158280719421562=2

Thanks,

Index: sys/arch/amd64/amd64/machdep.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.264
diff -u -p -r1.264 machdep.c
--- sys/arch/amd64/amd64/machdep.c  16 May 2020 14:44:44 -  1.264
+++ sys/arch/amd64/amd64/machdep.c  28 May 2020 07:40:14 -
@@ -1395,11 +1395,6 @@ init_x86_64(paddr_t first_avail)
i8254_startclock();
 
/*
-* Attach the glass console early in case we need to display a panic.
-*/
-   cninit();
-
-   /*
 * Initialize PAGE_SIZE-dependent variables.
 */
uvm_setpagesize();
@@ -1421,6 +1416,8 @@ init_x86_64(paddr_t first_avail)
} else
panic("invalid /boot");
 
+   cninit();
+
 /*
  * Memory on the AMD64 port is described by three different things.
  *
@@ -1927,12 +1924,6 @@ getbootinfo(char *bootinfo, int bootinfo
bios_ddb_t *bios_ddb;
bios_bootduid_t *bios_bootduid;
bios_bootsr_t *bios_bootsr;
-   int docninit = 0;
-
-#undef BOOTINFO_DEBUG
-#ifdef BOOTINFO_DEBUG
-   printf("bootargv:");
-#endif
 
for (q = (bootarg32_t *)bootinfo;
(q->ba_type != BOOTARG_END) &&
@@ -1942,24 +1933,15 @@ getbootinfo(char *bootinfo, int bootinfo
switch (q->ba_type) {
case BOOTARG_MEMMAP:
bios_memmap = (bios_memmap_t *)q->ba_arg;
-#ifdef BOOTINFO_DEBUG
-   printf(" memmap %p", bios_memmap);
-#endif
break;
case BOOTARG_DISKINFO:
bios_diskinfo = (bios_diskinfo_t *)q->ba_arg;
-#ifdef BOOTINFO_DEBUG
-   printf(" diskinfo %p", bios_diskinfo);
-#endif
break;
case BOOTARG_APMINFO:
/* generated by i386 boot loader */
break;
case BOOTARG_CKSUMLEN:
bios_cksumlen = *(u_int32_t *)q->ba_arg;
-#ifdef BOOTINFO_DEBUG
-   printf(" cksumlen %d", bios_cksumlen);
-#endif
break;
case BOOTARG_PCIINFO:
/* generated by i386 boot loader */
@@ -1983,15 +1965,8 @@ getbootinfo(char *bootinfo, int bootinfo
comconsaddr = consaddr;
comconsrate = cdp->conspeed;
comconsiot = X86_BUS_SPACE_IO;
-
-   /* Probe the serial port this time. */
-   docninit++;
}
 #endif
-#ifdef BOOTINFO_DEBUG
-   printf(" console 0x%x:%d",
-   cdp->consdev, cdp->conspeed);
-#endif
}
break;
case BOOTARG_BOOTMAC:
@@ -2023,8 +1998,6 @@ getbootinfo(char *bootinfo, int bootinfo
 
case BOOTARG_EFIINFO:
bios_efiinfo = (bios_efiinfo_t *)q->ba_arg;
-   if (bios_efiinfo->fb_addr != 0)
-   docninit++;
break;
 
case BOOTARG_UCODE:
@@ -2032,18 +2005,9 @@ getbootinfo(char *bootinfo, int bootinfo
break;
 
default:
-#ifdef BOOTINFO_DEBUG
-   printf(" unsupported arg (%d) %p", q->ba_type,
-   q->ba_arg);
-#endif
break;
}
}
-   if (docninit > 0)
-   cninit();
-#ifdef BOOTINFO_DEBUG
-   printf("\n");
-#endif
 }
 
 int



Re: UEFI Issue

2019-07-29 Thread YASUOKA Masahiko
On Tue, 16 Jul 2019 18:32:28 +
Charlie Burnett  wrote:
> Hey, I'm looking to get OpenBSD working in UEFI only mode on newer Thinkpad
> X1 devices, because for whatever reason it hangs when loading into memory
> without CSM enabled, and some of the X1 devices no longer have a CSM
> option. Does anyone have a fix, or advice on where I would start looking if
> I was going to patch it myself?

I don't know any known issue even if it's running in UEFI only mode.
So providing the detailed information is welcome.

 - screen shot when hang
 - boot loader and kernel version
 - result of "machine memory" command on the boot problem



Re: cvs2gitdump dumps core when trying process src

2017-12-24 Thread YASUOKA Masahiko
Hi,

On Sun, 24 Dec 2017 03:32:05 +0530
Dinesh Thirumurthy  wrote:
>> The conversion on github is done with cvs2gitdump. 
> 
> git2cvsdump dumps core on latest current.
> I am stumped after some basic investigation.
> 
> /usr/local/bin/cvs2gitdump dumps core.
(snip)
> What I did:
> 
> mkdir x
> cd x
> cvs -qd anon...@anoncvs.jp.openbsd.org:/cvs checkout -P src
> mv src src0 # save a copy for later use
> cp -r src0 src1 # use a copy of the repo

src1 seems to be a check outted source code.

> pkg_add -vvv cvs2gitdump 
> # follow instructions given in source also at
> https://github.com/yasuoka/cvs2gitdump/blob/master/cvs2gitdump.py
> git init --bare git1.git
> cvs2gitdump -k OpenBSD -e openbsd.org /home/user/x/src1 > openbsd.dump

Last argument for cvs2gitdump should be a CVS repository, not source
code.

To get a copy of OpenBSD CVS repository, you can see
http://www.openbsd.org/cvsync.html

--yasuoka



Re: Boot installation problem on laptop with Intel N3350 CPU

2017-10-13 Thread YASUOKA Masahiko
On Fri, 13 Oct 2017 14:50:50 +0900 (JST)
YASUOKA Masahiko <yasu...@openbsd.org> wrote:
> On Thu, 12 Oct 2017 00:46:20 -0400
> Ken Withee <wit...@protonmail.ch> wrote:
>> I had something similar and had to change to legacy in bios or something 
>> like that.
>> 
>> Sent from ProtonMail Mobile
>> 
>> On Wed, Oct 11, 2017 at 4:51 PM, Pedro Ramos <ra...@pedroramos-si.com> wrote:
>> 
>>> Hello, I am having troubles installing OpenBSD 6.2 on a white label laptop 
>>> with an Intel N3350 CPU and AMI UEFI BIOS. When the kernel start booting, 
>>> the system hangs with a blank screen. I also tried the installation with 
>>> OpenBSD 6.1 and the same behaviour happens. Any idea how to find and fix 
>>> this issue? Thanks. Best regards, Pedro Ramos
> 
> Similar problem happens on bhyve + uefi.  The diff below is fix the
> problem on bhyve.  Can you try this?

Also HP DL20 Gen9 with "UEFI optimized mode"=ON has another similar
problem.  The diff below fix that problem.  I'd like you to try the
diff separately.

diff --git a/sys/arch/amd64/amd64/wscons_machdep.c 
b/sys/arch/amd64/amd64/wscons_machdep.c
index 461441c4d43..90f1f4fcc37 100644
--- a/sys/arch/amd64/amd64/wscons_machdep.c
+++ b/sys/arch/amd64/amd64/wscons_machdep.c
@@ -192,10 +192,12 @@ wscn_input_init(int pass)
}
 
 #if (NPCKBC > 0)
+#if 0
if (pass == 0 &&
pckbc_cnattach(X86_BUS_SPACE_IO, IO_KBD, KBCMDP, 0) == 0)
return;
 #endif
+#endif
 #if (NUKBD > 0)
if (ukbd_cnattach() == 0)
return;



Re: Boot installation problem on laptop with Intel N3350 CPU

2017-10-12 Thread YASUOKA Masahiko
On Thu, 12 Oct 2017 00:46:20 -0400
Ken Withee  wrote:
> I had something similar and had to change to legacy in bios or something like 
> that.
> 
> Sent from ProtonMail Mobile
> 
> On Wed, Oct 11, 2017 at 4:51 PM, Pedro Ramos  wrote:
> 
>> Hello, I am having troubles installing OpenBSD 6.2 on a white label laptop 
>> with an Intel N3350 CPU and AMI UEFI BIOS. When the kernel start booting, 
>> the system hangs with a blank screen. I also tried the installation with 
>> OpenBSD 6.1 and the same behaviour happens. Any idea how to find and fix 
>> this issue? Thanks. Best regards, Pedro Ramos

Similar problem happens on bhyve + uefi.  The diff below is fix the
problem on bhyve.  Can you try this?

diff --git a/sys/arch/amd64/amd64/machdep.c b/sys/arch/amd64/amd64/machdep.c
index 150d2d43112..5f7828b3e4e 100644
--- a/sys/arch/amd64/amd64/machdep.c
+++ b/sys/arch/amd64/amd64/machdep.c
@@ -1254,16 +1254,6 @@ init_x86_64(paddr_t first_avail)
 
x86_bus_space_init();
 
-   /*
-* Attach the glass console early in case we need to display a panic.
-*/
-   cninit();
-
-   /*
-* Initialize PAGE_SIZE-dependent variables.
-*/
-   uvm_setpagesize();
-
/*
 * Boot arguments are in a single page specified by /boot.
 *
@@ -1272,14 +1262,23 @@ init_x86_64(paddr_t first_avail)
 *
 * locore copies the data into bootinfo[] for us.
 */
-   if ((bootapiver & (BAPIV_VECTOR | BAPIV_BMEMMAP)) ==
-   (BAPIV_VECTOR | BAPIV_BMEMMAP)) {
-   if (bootinfo_size >= sizeof(bootinfo))
-   panic("boot args too big");
-
-   getbootinfo(bootinfo, bootinfo_size);
-   } else
+   if ((bootapiver & (BAPIV_VECTOR | BAPIV_BMEMMAP)) !=
+   (BAPIV_VECTOR | BAPIV_BMEMMAP) ||
+   bootinfo_size >= sizeof(bootinfo)){
+   cninit();
panic("invalid /boot");
+   }
+   getbootinfo(bootinfo, bootinfo_size);
+
+   /*
+* Attach the glass console early in case we need to display a panic.
+*/
+   cninit();
+
+   /*
+* Initialize PAGE_SIZE-dependent variables.
+*/
+   uvm_setpagesize();
 
 /*
  * Memory on the AMD64 port is described by three different things.
@@ -1783,10 +1782,10 @@ getbootinfo(char *bootinfo, int bootinfo_size)
bios_ddb_t *bios_ddb;
bios_bootduid_t *bios_bootduid;
bios_bootsr_t *bios_bootsr;
-   int docninit = 0;
 
 #undef BOOTINFO_DEBUG
 #ifdef BOOTINFO_DEBUG
+   cninit();
printf("bootargv:");
 #endif
 
@@ -1839,9 +1838,6 @@ getbootinfo(char *bootinfo, int bootinfo_size)
comconsaddr = consaddr;
comconsrate = cdp->conspeed;
comconsiot = X86_BUS_SPACE_IO;
-
-   /* Probe the serial port this time. */
-   docninit++;
}
 #endif
 #ifdef BOOTINFO_DEBUG
@@ -1879,8 +1875,6 @@ getbootinfo(char *bootinfo, int bootinfo_size)
 
case BOOTARG_EFIINFO:
bios_efiinfo = (bios_efiinfo_t *)q->ba_arg;
-   if (bios_efiinfo->fb_addr != 0)
-   docninit++;
break;
 
default:
@@ -1891,8 +1885,6 @@ getbootinfo(char *bootinfo, int bootinfo_size)
break;
}
}
-   if (docninit > 0)
-   cninit();
 #ifdef BOOTINFO_DEBUG
printf("\n");
 #endif



Re: Change Time zones cause ddb in 6.2 snapshot

2017-10-03 Thread YASUOKA Masahiko
The problem is fixed

https://marc.info/?l=openbsd-cvs=150702971726161=2

Thank you for your report.

On Fri, 29 Sep 2017 18:33:50 +0800
"Fung"  wrote:
> snapshots/amd64/
> Build date: 1506531075 - Wed Sep 27 16:51:15 UTC 2017
> 
> how to repeat the problem
> 
> # config -ef /bsd
> [...]
> Enter 'help' for information
> ukc> timezone -480
> timezone = -480, dst = 0
> ukc> quit
> Saving modified kernel.
> 
> reboot 
> 
> wait boot 
> ...
> ...
> ddb>



Re: OpenBSD 6.1: BOOTIA32 3.32 issue

2017-05-14 Thread YASUOKA Masahiko
On Fri, 12 May 2017 16:15:52 +0200
Michele Curti <michele.cu...@gmail.com> wrote:
> On Fri, May 12, 2017 at 06:01:35PM +0900, YASUOKA Masahiko wrote:
>> > And something like this?
>> 
>> Yes.  What we need to do is comparing the device path node before
>> MEDIA_DEVICE_PATH type.  So I rewrote it like
>> 
>>   media_idx = device_path_index(rootdp, MEDIA_DEVICE_PATH);
>>   for (...)
>> if (device_path_ncmp(rootdp, dp, media_idx) == 0)
>>bootdev = 1;
>> 
>> ok? comment?
>> 
> 
> The device order is correct, the laptop boots without problems,

Thank you for your test.

> but executing "machine diskinfo" prints a source file now..
> 
> https://www.youtube.com/watch?v=EUao9Fq5Bww
> 
> It seems gnu/llvm/lib/Target/Mips/AsmParser/MipsAsmParser.cpp

It seems the problem which had been fixed previous is happening again.
Does efidev.c have following $OpenBSD$?

  /*  $OpenBSD: efidev.c,v 1.25 2017/05/11 01:37:24 yasuoka Exp $ */


Also let me update the diff.

diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
b/sys/arch/amd64/stand/efiboot/efiboot.c
index efa371f2ecd..19df6b1dc64 100644
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -52,7 +52,9 @@ static EFI_GUIDblkio_guid = BLOCK_IO_PROTOCOL;
 static EFI_GUID devp_guid = DEVICE_PATH_PROTOCOL;
 u_long  efi_loadaddr;
 
-static int  efi_device_path_cmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *, int);
+static int  efi_device_path_depth(EFI_DEVICE_PATH *dp, int);
+static int  efi_device_path_ncmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *,
+   int);
 static void efi_heap_init(void);
 static void efi_memprobe_internal(void);
 static void efi_video_init(void);
@@ -159,7 +161,7 @@ struct disklist_lh efi_disklist;
 void
 efi_diskprobe(void)
 {
-   int  i, bootdev;
+   int  i, bootdev = 0, depth = -1;
UINTNsz;
EFI_STATUS   status;
EFI_HANDLE  *handles = NULL;
@@ -180,8 +182,10 @@ efi_diskprobe(void)
if (handles == NULL || EFI_ERROR(status))
panic("BS->LocateHandle() returns %d", status);
 
+   if (efi_bootdp != NULL)
+   depth = efi_device_path_depth(efi_bootdp, MEDIA_DEVICE_PATH);
+
for (i = 0; i < sz / sizeof(EFI_HANDLE); i++) {
-   bootdev = 0;
status = EFI_CALL(BS->HandleProtocol, handles[i], _guid,
(void **));
if (EFI_ERROR(status))
@@ -193,53 +197,57 @@ efi_diskprobe(void)
di = alloc(sizeof(struct diskinfo));
efid_init(di, blkio);
 
-   if (efi_bootdp == NULL)
+   if (efi_bootdp == NULL || depth == -1 || bootdev != 0)
goto next;
status = EFI_CALL(BS->HandleProtocol, handles[i], _guid,
(void **));
if (EFI_ERROR(status))
goto next;
-   if (!efi_device_path_cmp(efi_bootdp, dp, HARDWARE_DEVICE_PATH)&&
-   !efi_device_path_cmp(efi_bootdp, dp, ACPI_DEVICE_PATH) &&
-   !efi_device_path_cmp(efi_bootdp, dp, MESSAGING_DEVICE_PATH))
+   if (efi_device_path_ncmp(efi_bootdp, dp, depth) == 0) {
+   TAILQ_INSERT_HEAD(_disklist, di, list);
bootdev = 1;
+   continue;
+   }
 next:
-   if (bootdev)
-   TAILQ_INSERT_HEAD(_disklist, di, list);
-   else
-   TAILQ_INSERT_TAIL(_disklist, di, list);
+   TAILQ_INSERT_TAIL(_disklist, di, list);
}
 
free(handles, sz);
 }
 
 static int
-efi_device_path_cmp(EFI_DEVICE_PATH *dpa, EFI_DEVICE_PATH *dpb, int dptype)
+efi_device_path_depth(EFI_DEVICE_PATH *dp, int dptype)
 {
-   int  cmp;
-   EFI_DEVICE_PATH *dp, *dpt_a = NULL, *dpt_b = NULL;
+   int i;
 
-   for (dp = dpa; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
-   if (DevicePathType(dp) == dptype) {
-   dpt_a = dp;
-   break;
-   }
-   }
-   for (dp = dpb; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
-   if (DevicePathType(dp) == dptype) {
-   dpt_b = dp;
-   break;
-   }
+   for (i = 0; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp), i++) {
+   if (DevicePathType(dp) == dptype)
+   return (i);
}
 
-   if (dpt_a && dpt_b) {
-   cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
+   return (-1);
+}
+
+static int
+efi_device_path_ncmp(E

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

2017-05-12 Thread YASUOKA Masahiko

On Fri, 12 May 2017 09:33:04 +0200
Michele Curti  wrote:
> On Fri, May 12, 2017 at 07:27:45AM +0200, Michele Curti wrote:
>> 
>> The efi_device_path_cmp() compares only a path node.
>> I tried the following diff just to see if I undestood something, 
>> hd0 is now set corrctly to the 29GB disk.
>> 
>> 
>> Index: efiboot/efiboot.c
>> ===
>> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
>> retrieving revision 1.17
>> diff -u -p -r1.17 efiboot.c
>> --- efiboot/efiboot.c3 Mar 2017 08:56:18 -   1.17
>> +++ efiboot/efiboot.c12 May 2017 05:23:21 -
>> @@ -233,10 +233,21 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
>>  }
>>  
>>  if (dpt_a && dpt_b) {
>> -cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
>> -if (cmp)
>> -return (cmp);
>> -return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
>> +for (;!IsDevicePathEnd(dpt_a);) {
>> +cmp = DevicePathNodeLength(dpt_a) - 
>> DevicePathNodeLength(dpt_b);
>> +if (cmp)
>> +return (cmp);
>> +cmp = memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a));
>> +if (cmp)
>> +return (cmp);
>> +dpt_a = NextDevicePathNode(dpt_a);
>> +dpt_b = NextDevicePathNode(dpt_b);
>> +cmp = IsDevicePathEnd(dpt_a) - IsDevicePathEnd(dpt_b);
>> +if (cmp)
>> +return (cmp);
>> +}
>> +
>> +return 0;
>>  }
>>  
>>  return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);
> 
> And something like this?

Yes.  What we need to do is comparing the device path node before
MEDIA_DEVICE_PATH type.  So I rewrote it like

  media_idx = device_path_index(rootdp, MEDIA_DEVICE_PATH);
  for (...)
if (device_path_ncmp(rootdp, dp, media_idx) == 0)
   bootdev = 1;

ok? comment?

diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
b/sys/arch/amd64/stand/efiboot/efiboot.c
index efa371f2ecd..b78ca2b350e 100644
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -52,7 +52,9 @@ static EFI_GUIDblkio_guid = BLOCK_IO_PROTOCOL;
 static EFI_GUID devp_guid = DEVICE_PATH_PROTOCOL;
 u_long  efi_loadaddr;
 
-static int  efi_device_path_cmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *, int);
+static int  efi_device_path_index(EFI_DEVICE_PATH *dp, int);
+static int  efi_device_path_ncmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *,
+   int);
 static void efi_heap_init(void);
 static void efi_memprobe_internal(void);
 static void efi_video_init(void);
@@ -159,7 +161,7 @@ struct disklist_lh efi_disklist;
 void
 efi_diskprobe(void)
 {
-   int  i, bootdev;
+   int  i, media_idx, bootdev;
UINTNsz;
EFI_STATUS   status;
EFI_HANDLE  *handles = NULL;
@@ -180,6 +182,8 @@ efi_diskprobe(void)
if (handles == NULL || EFI_ERROR(status))
panic("BS->LocateHandle() returns %d", status);
 
+   media_idx = efi_device_path_index(efi_bootdp, MEDIA_DEVICE_PATH);
+
for (i = 0; i < sz / sizeof(EFI_HANDLE); i++) {
bootdev = 0;
status = EFI_CALL(BS->HandleProtocol, handles[i], _guid,
@@ -199,9 +203,7 @@ efi_diskprobe(void)
(void **));
if (EFI_ERROR(status))
goto next;
-   if (!efi_device_path_cmp(efi_bootdp, dp, HARDWARE_DEVICE_PATH)&&
-   !efi_device_path_cmp(efi_bootdp, dp, ACPI_DEVICE_PATH) &&
-   !efi_device_path_cmp(efi_bootdp, dp, MESSAGING_DEVICE_PATH))
+   if (efi_device_path_ncmp(efi_bootdp, dp, media_idx) == 0)
bootdev = 1;
 next:
if (bootdev)
@@ -214,32 +216,39 @@ next:
 }
 
 static int
-efi_device_path_cmp(EFI_DEVICE_PATH *dpa, EFI_DEVICE_PATH *dpb, int dptype)
+efi_device_path_index(EFI_DEVICE_PATH *dp, int dptype)
 {
-   int  cmp;
-   EFI_DEVICE_PATH *dp, *dpt_a = NULL, *dpt_b = NULL;
+   int idx = 0;
 
-   for (dp = dpa; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
-   if (DevicePathType(dp) == dptype) {
-   dpt_a = dp;
+   for (idx = 0; !IsDevicePathEnd(dp); idx++) {
+   if (DevicePathType(dp) == dptype)
break;
-   }
-   }
-   for (dp = dpb; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
-   if (DevicePathType(dp) == dptype) {
-   dpt_b = dp;
-   break;
-   }
+   dp = NextDevicePathNode(dp);
}

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

2017-05-11 Thread YASUOKA Masahiko
On Thu, 11 May 2017 23:45:17 +0200
Michele Curti  wrote:
> On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
>> 
>> I don't think this is the correct fix.  It might solve your issue, but I
>> don't think it's completely right.  So EFI has those so called device
>> paths.  A path is basically a list of nodes.  To compare two paths you
>> need to compare the whole path and not just a single node of it.  If you
>> store dp instead of dp0 you will basically only save a part of the path,
>> not the full path.
>> 
>> What you can do is print the full path of efi_bootdp like..
>> 
>> for (dp = efi_bootdp; !IsDevicePathEnd(dp);
>> dp = NextDevicePathNode(dp)) {
>> printf("%x %x - ", DevicePathType(dp), DevicePathSubType(dp));
>> }
>> printf("\n");
>> 
>> And do the same for the DPs that are being put into the
>> efi_device_path_cmp function.  That will at least print the types, but
>> not the content of the nodes.  That's a start into figuring out why it
>> does not correctly compare the paths.
>> 
>> Maybe there's a bug in the compare code?
> 
> Sorry, only now I understood what you said... Got
> 
> 2 1 - 1 1 - 1 5 - 4 1 -
> 
> (2 1) (2 1) da db cmp da db cmp diff bootdev 1
> (2 1) (2 1) da db cmp da db cmp diff bootdev 1
> (2 1) (2 1) da db cmp da db cmp diff bootdev 1
> 
> with the following diff

All disks are identical in HARDWARE_DEVICE_PATH and ACPI_DEVICE_PATH
and they all don't have MESSAGING_DEVICE_PATH.  So the boot loader
mistakenly treats all of them as the bootdisk..

I'd like to know whether there is a way to distigish those disks.  Can
you try the diff following?

diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
b/sys/arch/amd64/stand/efiboot/efiboot.c
index efa371f2ecd..891b6c75cc9 100644
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -208,6 +208,14 @@ next:
TAILQ_INSERT_HEAD(_disklist, di, list);
else
TAILQ_INSERT_TAIL(_disklist, di, list);
+
+   printf("%d\n", i);
+   for (; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
+   int ii;
+   for (ii = 0; ii < DevicePathNodeLength(dp); ii++)
+   printf("%x ", *((u_char *)dp + ii));
+   printf("\n");
+   }
}
 
free(handles, sz);



Re: OpenBSD 6.1: BOOTIA32 3.32 issue

2017-05-11 Thread YASUOKA Masahiko
Hi,

Thank you for your tests,

On Thu, 11 May 2017 07:40:42 +0200
Michele Curti  wrote:
> On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
>> On Wed, May 10, 2017 at 03:14:30PM +0200, Stefan Sperling wrote:
>> > On Tue, May 09, 2017 at 09:47:14PM +0200, Michele Curti wrote:
>> > > On Tue, May 09, 2017 at 09:36:02PM +0200, Michele Curti wrote:
>> > > > On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote:
>> > > > > Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay
>> > > > > trail, 32 bit efi, 64 bit os) but the bootloader do not correctly
>> > > > > detect the internal disk.
>> > > > > 
>> > > > > I also tried a fresh install, but things do not change.  Boot fails
>> > > > > and when I do a "machine diskinfo" I got a lot of "?" symbols (a 
>> > > > > video
>> > > > > here https://www.youtube.com/watch?v=fsomNX-oFTQ )
>> > > > > 
> 
> Thanks to yasuoka fix I just noted that using dp0 instead of dp 
> changes the diskinfo disks order

Yes,

> # setting efi_bootdp = dp;
> 
> Disk  BlkSiz  IoAlign SizeFlags   Checksum
> hd0   512 1   29GB0x2 0xad4a42c3
> hd1   512 1   4MB 0x0 0x0
> hd2   512 1   4MB 0x0 0x0
> 
> # setting efi_bootdp = dp0;
> 
> Disk  BlkSiz  IoAlign SizeFlags   Checksum
> hd0   512 1   4MB 0x0 0x0
> hd1   512 1   4MB 0x0 0x0
> hd2   512 1   29GB0x2 0xad4a42c3
> 
> So I can use the stock bootloader without changes but I must do a 
> 
> boot> set device hd2a

I'm not clear whether we still have a problem.

Does the boot loader select the booted disk as "hd0" correctly?

If you booted from 29GB disk, "machine diskinfo" must be:

  Disk  BlkSiz  IoAlign SizeFlags   Checksum
  hd0   512 1   29GB0x2 0xad4a42c3
  hd1   512 1   4MB 0x0 0x0
  hd2   512 1   4MB 0x0 0x0

--yasuoka



Re: OpenBSD 6.1: BOOTIA32 3.32 issue

2017-05-10 Thread YASUOKA Masahiko
Hi,

On Tue, 9 May 2017 10:20:03 +0200
Michele Curti  wrote:
> I also tried a fresh install, but things do not change.
> Boot fails and when I do a "machine diskinfo" I got a lot of "?" 
> symbols (a video here https://www.youtube.com/watch?v=fsomNX-oFTQ )

Hanging on "machine diskinfo" seems to be a different problem.
The diff is already committed.  Can you test this?

(I'll look into another problem later)

Index: sys/arch/amd64/stand/efiboot/efidev.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efidev.c,v
retrieving revision 1.24
diff -u -p -r1.24 efidev.c
--- sys/arch/amd64/stand/efiboot/efidev.c   24 Dec 2016 08:41:13 -  
1.24
+++ sys/arch/amd64/stand/efiboot/efidev.c   11 May 2017 01:31:13 -
@@ -789,7 +789,7 @@ efi_dump_diskinfo(void)
printf("hd%d\t%u\t%u\t%u%s\t0x%x\t0x%x\t%s\n",
(bdi->bios_number & 0x7f),
ed->blkio->Media->BlockSize,
-   ed->blkio->Media->IoAlign, siz, sizu,
+   ed->blkio->Media->IoAlign, (int)siz, sizu,
bdi->flags, bdi->checksum,
(ed->blkio->Media->RemovableMedia)? "Removable" : "");
}



Re: non-PAP in radiusd

2017-01-11 Thread YASUOKA Masahiko
On Tue, 10 Jan 2017 01:50:31 +
Pete Zabagel  wrote:
> I noticed in the radiusd.conf man page that the bsdauth module only
> supports PAP:
> 
> "It only supports PAP, password based authentication."
> 
> Is there a specific reason as to why CHAP isn't implemented?

This limitation is come from the "bsdauth" module.  The BSD
authentication requires the plain password for authentication.  See
bsd_userokay(3).  So radiusd(8) needs to get the plain password from
the RADIUS client and the client can't use "CHAP" since the client
doesn't get the plain password through "CHAP".

> I am assuming it is due to time / interest constraints but perhaps the
> quality of CHAP is in question too -- I see in the RFC that MD5 is
> assigned a specific value, making me wonder if MD5 is the predominant
> algorithm of CHAP implementations in the wild and perhaps considered
> insecure by the community.
> 
> On a side note, does anyone know which algorithms are used in CHAP
> besides MD5?

Currently MS-CHAP version 2 is also supported by the "radius" module
as well.

I'd like to add EAP capability to radiusd(8) to support stronger
algorithms.

--yasuoka



Re: macbook EFI bootloader

2016-12-29 Thread YASUOKA Masahiko
On Tue, 27 Dec 2016 18:24:38 -0800
Byron Klippert  wrote:
> This setup gets as far as shown below and then stops...
> 
> probing: pc0 mem[572K 64K 3039M 11M 60K 48K]
> disk: hd0
>>> OpenBSD/amd64 BOOTIA32 3.32
> boot>
> booting hd0a:/bsd: 6979304+2212872+258624+0+765952
> [72+710280+477696]=0xae2350
> entry point at 0xf001000 [7205c766, 3404, 24448b12, 1240a304]
> 
> 
> I've tried booting with `boot> hd0a:/bsd.rd'. Also tried writing
> install60.tgz and miniroot60.tgz to USB and got similar results there as
> well.
> 
> 
> Curious to know if the native EFI bootloader is designed to work with
> this hardware?

I'm not sure.  OpenBSD efiboot supports GOP for the graphic protocol
but it doesn't support UGA.  FreeBSD supports both.

Is there anyone who are sure whether the macbook is using UGA?

--yasuoka



Re: OpenBSD Current on MacBook Air 7,1

2016-12-29 Thread YASUOKA Masahiko
Hi,

On Mon, 12 Dec 2016 20:19:19 +0100
Piotr Isajew  wrote:
> There seems to be a problem with a bootloader though. Once the
> system is installed on the SSD, the bootloader just stucks after
> probing HDDs. Also it's not possible to boot from the
> installation USB anymore.

I'd like you to try the latest snapshot.  The boot loader had some
problems on handling 4K sector disks and they were resolved.

--yasuoka



Re: BL460c G1 issues

2016-08-03 Thread YASUOKA Masahiko
On Tue, 24 May 2016 16:02:21 -0400
Steve Shockley  wrote:
> I have an HP BL460c blade I'm using with OpenBSD.  I was able to get
> 5.8 to install by disabling ACPI; since I'm lazy I didn't submit a bug
> report.  I tried to upgrade to 5.9 (and -current), but booting from

I hit a similar problem on NEC Express5800/R110h-1.  On that machine,
X2APIC is enabled on boot and this seems to cause the panic following.

> cpu0 at mainbus0panic: cpu at apic id 0 already attached?

So the diff disables the X2APIC.  Can you try the diff attached?


Index: sys/arch/amd64/amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.102
diff -u -p -r1.102 cpu.c
--- sys/arch/amd64/amd64/cpu.c  28 Jul 2016 21:57:57 -  1.102
+++ sys/arch/amd64/amd64/cpu.c  4 Aug 2016 02:51:08 -
@@ -683,6 +683,8 @@ cpu_hatch(void *v)
 
ci->ci_flags |= CPUF_PRESENT;
 
+   if (ci->ci_flags & CPUF_AP)
+   lapic_ap_init();
lapic_enable();
lapic_startclock();
 
Index: sys/arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.44
diff -u -p -r1.44 lapic.c
--- sys/arch/amd64/amd64/lapic.c22 Jun 2016 01:12:38 -  1.44
+++ sys/arch/amd64/amd64/lapic.c4 Aug 2016 02:51:08 -
@@ -155,6 +155,19 @@ x2apic_writeicr(u_int32_t hi, u_int32_t 
__asm volatile("wrmsr" : : "a" (lo), "d" (hi), "c" (msr));
 }
 
+void
+x2apic_disable(void)
+{
+   uint64_t msr;
+
+   msr = rdmsr(MSR_APICBASE);
+   if (msr & APICBASE_ENABLE_X2APIC) {
+   wrmsr(MSR_APICBASE,
+   (msr & ~(APICBASE_GLOBAL_ENABLE|APICBASE_ENABLE_X2APIC)));
+   wrmsr(MSR_APICBASE, (msr & ~APICBASE_ENABLE_X2APIC));
+   }
+}
+
 u_int32_t
 lapic_cpu_number(void)
 {
@@ -204,6 +217,8 @@ lapic_map(paddr_t lapic_base)
return;
}
 
+   x2apic_disable();
+
va = (vaddr_t)_apic;
 
disable_intr();
@@ -370,6 +385,13 @@ lapic_boot_init(paddr_t lapic_base)
 #ifdef MULTIPROCESSOR
evcount_attach(_count, "ipi", _irq);
 #endif
+}
+
+void
+lapic_ap_init(void)
+{
+   if (!x2apic_enabled)
+   x2apic_disable();
 }
 
 static __inline u_int32_t
Index: sys/arch/amd64/amd64/mptramp.S
===
RCS file: /cvs/src/sys/arch/amd64/amd64/mptramp.S,v
retrieving revision 1.13
diff -u -p -r1.13 mptramp.S
--- sys/arch/amd64/amd64/mptramp.S  16 May 2016 01:54:15 -  1.13
+++ sys/arch/amd64/amd64/mptramp.S  4 Aug 2016 02:51:08 -
@@ -188,30 +188,35 @@ _TRMP_LABEL(mptramp_longmode)

 _C_LABEL(cpu_spinup_trampoline_end):   #end of code copied to MP_TRAMPOLINE
.globl  _C_LABEL(x2apic_enabled)
-   movlx2apic_enabled,%eax
-   testl   %eax,%eax
-   jz  1f
-
mov $MSR_APICBASE,%ecx
mov $0,%edx
rdmsr
+   mov %eax,%edi
+   andl$APICBASE_ENABLE_X2APIC,%eax
+   testl   %eax,%eax
+   jnz 1f
+   movlx2apic_enabled,%eax
+   testl   %eax,%eax
+   jz  2f
+   mov %edi,%eax
orl $APICBASE_ENABLE_X2APIC,%eax
wrmsr
+1:
mov $MSR_X2APIC_ID,%ecx
rdmsr
andl$X2APIC_ID_MASK,%eax
-   jmp 2f
-1:
+   jmp 3f
+2:
movl_C_LABEL(local_apic)+LAPIC_ID,%eax
shrl$LAPIC_ID_SHIFT,%eax
-2:
-   xorq%rcx,%rcx
 3:
+   xorq%rcx,%rcx
+4:
movq_C_LABEL(cpu_info)(,%rcx,8),%rdi
incq%rcx
movlCPU_INFO_APICID(%rdi),%edx
cmpl%eax,%edx
-   jne 3b
+   jne 4b
 
movqCPU_INFO_IDLE_PCB(%rdi),%rsi
 
Index: sys/arch/amd64/include/i82489var.h
===
RCS file: /cvs/src/sys/arch/amd64/include/i82489var.h,v
retrieving revision 1.17
diff -u -p -r1.17 i82489var.h
--- sys/arch/amd64/include/i82489var.h  22 Jun 2016 01:12:38 -  1.17
+++ sys/arch/amd64/include/i82489var.h  4 Aug 2016 02:51:08 -
@@ -118,6 +118,7 @@ extern void Xrecurse_hyperv_upcall(void)
 struct cpu_info;
 
 extern void lapic_boot_init(paddr_t);
+extern void lapic_ap_init(void);
 extern void lapic_set_lvt(void);
 extern void lapic_enable(void);
 extern void lapic_disable(void);



Re: uefi boot

2016-07-12 Thread YASUOKA Masahiko
Hi,

On Tue, 12 Jul 2016 21:17:20 -0300
Friedrich Locke  wrote:
> I wonder if that's possible to boot obsd amd64 5.9 CD on a computer whose
> bios is setted to boot UEFI secure mode off.

5.9 CD doesn't support UEFI boot.  If the computer doesn't have legacy
mode BIOS, you need to use an USB memory stick and install59.fs for
this moment.

--yasuoka



Re: uefi

2016-07-01 Thread YASUOKA Masahiko
On Thu, 30 Jun 2016 10:41:39 -0300
Friedrich Locke  wrote:
> i would like to know if there is anyone in this list that is running
> Windows and OBSD 5.9 amd 64 on the same machine with UEFI and doing,
> naturally, multiboot.

Both my vaio laptops and dell desktop boot both OpenBSD and Windows.

As for the boot program, I think many ways exist.  But my favoite way
is following:

  1. Set the first boot priority to OpenBSD
 Set the next to Windows
  2. Enter "machine exit" on OpenBSD efiboot when you want to use
 Windows.  Just wait when you use OpenBSD.

--yasuoka



Re: L2TP/IPSec via npppd won't work with Android 6.0.1

2016-03-30 Thread YASUOKA Masahiko
On Tue, 29 Mar 2016 11:37:14 +0200
Mattieu Baptiste  wrote:
> On Tue, Mar 29, 2016 at 5:43 AM, Sly Midnight  wrote:
>> I don't mean to bring up an old thread, but I was wondering if anyone
>> else was experiencing issues with OpenBSD 5.8 and Android 6.0.1
>> (preferably the version on the Nexus line of devices) connecting to
>> ipsec/l2tp.
>>
>> I had this working late last year some time and hadn't used it in a few
>> months.  When I went to use it again a few days ago it didn't work at
>> all.  After rebooting my phone and even trying it on my tablet that
>> coincidentally runs the exact same version of stock Android 6.0.1, it
>> too didn't work there.
> 
> I have the very same problem.
> To me, It's caused by some Android updates. I saw this since 6.0, but
> some security updates near 5.1.1 seems to trigger the same behavior.
> I've tried to tweak ipsec.conf like you without luck. Unfortunately, I
> did not have the time to dig further...

My colleague and I also hit this issue.

This issue is caused by Android, it sends ESP packets with wrong
padding size when SHA2-256 is selected for HMAC.  It seems that
Android is using an old ietf draft for SHA2-256, but OpenBSD is using
RFC 4868.

When the issue occurs,

  XXX packets with bad payload size or padding received

counter in "netstat -sp esp" will be incremented.

We can force using MD5 or SHA for HMAC to workaround this issue.  To
do this, put the text below to /etc/isakmpd/isakmpd.policy and remove
"-K" from isakmpd_flags.

  Authorizer: "POLICY"
  Comment: This is test
  Licensees: "passphrase:PASSPHRASE"
  conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present == 
"yes" && (esp_auth_alg == "hmac-md5" || esp_auth_alg == "hmac-sha") -> "true";

--yasuoka



Re: L2TP/IPSec via npppd won't work with Android 5.x

2016-02-21 Thread YASUOKA Masahiko
Hi,

On Mon, 22 Feb 2016 00:26:11 +0800
Jiahao Dai  wrote:
> I am a new openBSD user and I found it's extramly difficult to setup a
> L2TP/IPSec(IKEv1) Road Warrior server to getting work with Android devices.
> 
> I followed the tutorial here Configuring L2TP Over IPSec on OpenBSD for Mac
> OS X
> Clients [1], deployed on fresh openBSD 5.8 and found out that iOS9.x ipad
> works like a
> charm.
> 
> But the android devices I had won't work by all means. I found out that
> Android 5.x
> L2TP/IPSec VPN client works in:
> hash algorithm: hmac-sha2-256
> encrypt method: aes_cbc
> life time: 28800
> 
> The ipsec.conf with:
> ``
> ike passive esp tunnel \
>  from "IP_ADDRESS" to any \
>  main auth "hmac-sha2-256" enc "aes" group "modp1024" lifetime 2880\
>  quick group "modp1024" \
>  psk "SECRET_KEY"
> '' didn't make a chage.(after `ipsecctl -f /etc/ipsec.conf`)
> 
> The /var/log/messages didn't report anything as the VPN connection failed
> on
> Android device.
> 
> When debugging at the foreground with `isakmpd -v -K -d`

In this case, you should do "ipsecctl -f /etc/ipsec.conf" again after
start the isakmpd.

> It still reported that:
> ``
> 002212.657833 Default isakmpd: starting [priv]
> 002219.561051 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561236 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561386 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561546 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561664 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561746 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> AES_CBC, expected 3DES_CBC
> 002219.561832 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.561916 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.562003 Default attribute_unacceptable: AUTHENTICATION_METHOD: got
> PRE_SHARED, expected RSA_SIG
> 002219.562085 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562189 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562308 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got
> DES_CBC, expected 3DES_CBC
> 002219.562385 Default message_negotiate_sa: no compatible proposal found
> 002219.562459 Default dropped message from 139.227.237.86 port 500 due to
> notification type NO_PROPOSAL_CHOSEN
> ^C002221.748476 Default isakmpd: shutting down...
> 002221.748562 Default isakmpd: exit
> 
> ""
> 
> I am trying to use aes and encryption algorithm but it seems that it keep
> using 3des, what can I do?

This seems that the "ike" line in ipsec.conf wasn't appied to the
received packets.

I think you should:

  - make sure to do "ipsectl" after iksampd starts
(ipsec=YES in rc.conf.local does this)
  - check the "ike" line (especially the IP address of "from")

> Please help. I have spent all my weekends on it, still no idea. Other idea
> on VPN
> type with setup (except OpenVPN which needs additional software implement)
> are
> welcome.
> Jiahao Dai



Re: npppd pppx0 VPN Client can access wan but cannot access lan

2015-12-18 Thread YASUOKA Masahiko
Hi,

On Sat, 19 Dec 2015 01:11:40 -
"torsten"  wrote:
> I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and 5.3.
> npppd is works fine and clients can connect using windows pptp client.
> The Client has the pptp connection set as default gateway and can access the
> internet through the vpn gateway but cannot access the LAN network.
> Traffic arrives on the pppx0 interface but never get forwarded to the LAN ip
> address.

Can you see the traffic for the LAN on $int_if or the other physical
interfaces?

>   ## vpn
> pass quick log on pppx
> match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
> match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
> match out log on $int_if from $vpn_net nat-to ($int_if)

Fist line, "pass quick", becomes the last rule for traffic in/out on
the pppx interface since it is "quick".  So subsequent rules
(including nat) are not applied.

--yasuoka



Re: "panic: ipintr no HDR" when attempting to connect OpenBSD running l2tp/IPsec

2015-12-03 Thread YASUOKA Masahiko
Can you check "net.pipex.enable"?

pppxwrite() is not used if "net.pipex.enable=1".

--yasuoka



Re: Failure to boot install media using bootia32.efi

2015-12-02 Thread YASUOKA Masahiko
On Tue, 1 Dec 2015 20:41:15 +
Callum Davies  wrote:
> I have two "devices" using IA32 UEFI firmware with 64-bit
> hardware.  An Asus EeeBook X502TA and qemu-system-x86_64 with
> an IA32 TianoCore firmware.  Neither of these will boot from
> snapshots/amd64/install58.fs.
> 
> Attempting to run bootia32.efi from the UEFI shell of the qemu system
> simply tells me "Command Error Status: Not Found".
> 
> The EeeBook is deficient, and doesn't provide an UEFI shell, but I
> suspect it fails for the same reason.

Fixed some issues on ia32 on the CVS tree.  Can you try that by
replacing BOOTIA32.EFI in install58.fs?

I put compiled one on http://yasuoka.net/~yasuoka/BOOTIA32.EFI .

(On qemu, the video hangs after the boot loader switches the video
 mode.  But this seems to be a problem of qemu or my environment.)

--yasuoka



Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

2015-11-26 Thread YASUOKA Masahiko
On Wed, 11 Nov 2015 15:33:06 -0500
"Joe Gidi"  wrote:
> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in one
> of my systems and tried to boot the November 11th amd64 miniroot58.fs
> image to test UEFI booting. I get to the bootloader, but it appears to
> fail while loading the kernel and goes into a reboot loop. Here's
> everything I see on screen before it reboots:
> 
> probing: pc0 mem[640K 2984M 4M 48K 5103M]
> disk: hd0 hd1 hd2*
>>> OpenBSD/amd64 EFIBOOT 3.29
> boot>
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238

I'd like to figure out where the efiboot is stopping.  Can you replace
the BOOTX64.EFI in the miniroot58.fs and check the output?

compiled version:

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

diff:

Index: efiboot/efiboot.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.9
diff -u -p -r1.9 efiboot.c
--- efiboot/efiboot.c   8 Nov 2015 00:17:29 -   1.9
+++ efiboot/efiboot.c   26 Nov 2015 09:15:17 -
@@ -569,7 +569,7 @@ efi_makebootargs(void)
 void
 _rtt(void)
 {
-#ifdef EFI_DEBUG
+#if defined(EFI_DEBUG) || 1
printf("Hit any key to reboot\n");
efi_cons_getc(0);
 #endif
Index: libsa/exec_i386.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.15
diff -u -p -r1.15 exec_i386.c
--- libsa/exec_i386.c   5 Oct 2015 22:59:39 -   1.15
+++ libsa/exec_i386.c   26 Nov 2015 09:15:17 -
@@ -123,6 +123,7 @@ run_loadfile(u_long *marks, int howto)
 * This code may be used both for 64bit and 32bit.  Make sure the
 * bootarg is 32bit always on even on amd64.
 */
+   printf("%s() calling makebootargs32()\n", __func__);
 #ifdef __amd64__
makebootargs32(av, );
 #else
@@ -134,6 +135,10 @@ run_loadfile(u_long *marks, int howto)
printf("entry point at 0x%lx [%x, %x, %x, %x]\n", entry,
((int *)entry)[0], ((int *)entry)[1],
((int *)entry)[2], ((int *)entry)[3]);
+
+   printf("Hit any key to continue\n");
+   efi_cons_getc(0);
+
 #ifndef EFIBOOT
/* stack and the gung is ok at this point, so, no need for asm setup */
(*(startfuncp)entry)(howto, bootdev, BOOTARG_APIVER, marks[MARK_END],



Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

2015-11-26 Thread YASUOKA Masahiko
Hi,

On Thu, 26 Nov 2015 09:57:12 -0500
"Joe Gidi" <j...@entropicblur.com> wrote:
> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
>> On Wed, 11 Nov 2015 15:33:06 -0500
>> "Joe Gidi" <j...@entropicblur.com> wrote:
>>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in
>>> one
>>> of my systems and tried to boot the November 11th amd64 miniroot58.fs
>>> image to test UEFI booting. I get to the bootloader, but it appears to
>>> fail while loading the kernel and goes into a reboot loop. Here's
>>> everything I see on screen before it reboots:
>>>
>>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>>> disk: hd0 hd1 hd2*
>>>>> OpenBSD/amd64 EFIBOOT 3.29
>>> boot>
>>> cannot open hd0a:/etc/random.seed: No such file or directory
>>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>>
>> I'd like to figure out where the efiboot is stopping.  Can you replace
>> the BOOTX64.EFI in the miniroot58.fs and check the output?
> 
> Sure, I now get these two lines after the 'booting' line:
> 
> GOP setmode failed(7)
> Hit any key to reboot

The bootloader changs the video resolution before start the kernel.
It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
7 means EFI_DEVICE_ERROR.

> Please let me know if I can do any further testing, and thank you for
> looking into this.

Can you provide the result of "machine video" and try to change the
video mode to the best and some others.


And also please try the diff below.

compiled:

  http://yasuoka.net/~yasuoka/BOOTX64.EFI (updated)

diff:

Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.9
diff -u -p -r1.9 efiboot.c
--- efiboot/efiboot.c   8 Nov 2015 00:17:29 -   1.9
+++ efiboot/efiboot.c   26 Nov 2015 15:57:56 -
@@ -528,8 +528,10 @@ efi_makebootargs(void)
}
if (bestmode >= 0) {
status = EFI_CALL(gop->SetMode, gop, bestmode);
+#if 0
if (EFI_ERROR(status))
panic("GOP setmode failed(%d)", status);
+#endif
}
 
gopi = gop->Mode->Info;
@@ -569,7 +571,7 @@ efi_makebootargs(void)
 void
 _rtt(void)
 {
-#ifdef EFI_DEBUG
+#if defined(EFI_DEBUG) || 1
printf("Hit any key to reboot\n");
efi_cons_getc(0);
 #endif
Index: libsa/exec_i386.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.16
diff -u -p -r1.16 exec_i386.c
--- libsa/exec_i386.c   26 Nov 2015 10:52:40 -  1.16
+++ libsa/exec_i386.c   26 Nov 2015 15:57:56 -
@@ -123,6 +123,7 @@ run_loadfile(u_long *marks, int howto)
 * This code may be used both for 64bit and 32bit.  Make sure the
 * bootarg is 32bit always on even on amd64.
 */
+   printf("%s() calling makebootargs32()\n", __func__);
 #ifdef __amd64__
makebootargs32(av, );
 #else
@@ -134,6 +135,10 @@ run_loadfile(u_long *marks, int howto)
printf("entry point at 0x%lx [%x, %x, %x, %x]\n", entry,
((int *)entry)[0], ((int *)entry)[1],
((int *)entry)[2], ((int *)entry)[3]);
+
+   printf("Hit any key to continue\n");
+   efi_cons_getc(0);
+
 #ifndef EFIBOOT
/* stack and the gung is ok at this point, so, no need for asm setup */
(*(startfuncp)entry)(howto, bootdev, BOOTARG_APIVER, marks[MARK_END],



Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

2015-11-26 Thread YASUOKA Masahiko
On Thu, 26 Nov 2015 11:10:33 -0500
"Joe Gidi" <j...@entropicblur.com> wrote:
> On Thu, November 26, 2015 10:59 am, YASUOKA Masahiko wrote:
>> On Thu, 26 Nov 2015 09:57:12 -0500
>> "Joe Gidi" <j...@entropicblur.com> wrote:
>>> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
>>>> On Wed, 11 Nov 2015 15:33:06 -0500
>>>> "Joe Gidi" <j...@entropicblur.com> wrote:
>>>>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard in
>>>>> one
>>>>> of my systems and tried to boot the November 11th amd64 miniroot58.fs
>>>>> image to test UEFI booting. I get to the bootloader, but it appears to
>>>>> fail while loading the kernel and goes into a reboot loop. Here's
>>>>> everything I see on screen before it reboots:
>>>>>
>>>>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>>>>> disk: hd0 hd1 hd2*
>>>>>>> OpenBSD/amd64 EFIBOOT 3.29
>>>>> boot>
>>>>> cannot open hd0a:/etc/random.seed: No such file or directory
>>>>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>>>>
>>>> I'd like to figure out where the efiboot is stopping.  Can you replace
>>>> the BOOTX64.EFI in the miniroot58.fs and check the output?
>>>
>>> Sure, I now get these two lines after the 'booting' line:
>>>
>>> GOP setmode failed(7)
>>> Hit any key to reboot
>>
>> The bootloader changs the video resolution before start the kernel.
>> It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
>> 7 means EFI_DEVICE_ERROR.
>>
>>> Please let me know if I can do any further testing, and thank you for
>>> looking into this.
>>
>> Can you provide the result of "machine video" and try to change the
>> video mode to the best and some others.
>>
>>
>> And also please try the diff below.
> 
> This appears to fix it. I did not have to change the video mode. Output
> from the bootloader:

UEFI seems to have refused changing the video mode since it
isn't to change.

Can you try this again?  (I'd like to verify whether the assumption
above is correct).

compiled:

  http://yasuoka.net/~yasuoka/BOOTX64.EFI (updated)

diff:

Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.9
diff -u -p -r1.9 efiboot.c
--- efiboot/efiboot.c   8 Nov 2015 00:17:29 -   1.9
+++ efiboot/efiboot.c   26 Nov 2015 16:21:23 -
@@ -526,10 +526,10 @@ efi_makebootargs(void)
bestsiz = gopsiz;
}
}
-   if (bestmode >= 0) {
+   if (bestmode >= 0 && conout->Mode->Mode != bestmode) {
status = EFI_CALL(gop->SetMode, gop, bestmode);
if (EFI_ERROR(status))
-   panic("GOP setmode failed(%d)", status);
+   printf("GOP setmode failed(%d)\n", status);
}
 
gopi = gop->Mode->Info;

--yasuoka



Re: UEFI boot-looping on Asus M5A97 LE R2.0 motherboard

2015-11-26 Thread YASUOKA Masahiko
On Thu, 26 Nov 2015 11:51:03 -0500
"Joe Gidi" <j...@entropicblur.com> wrote:
> On Thu, November 26, 2015 11:27 am, YASUOKA Masahiko wrote:
>> On Thu, 26 Nov 2015 11:10:33 -0500
>> "Joe Gidi" <j...@entropicblur.com> wrote:
>>> On Thu, November 26, 2015 10:59 am, YASUOKA Masahiko wrote:
>>>> On Thu, 26 Nov 2015 09:57:12 -0500
>>>> "Joe Gidi" <j...@entropicblur.com> wrote:
>>>>> On Thu, November 26, 2015 5:20 am, YASUOKA Masahiko wrote:
>>>>>> On Wed, 11 Nov 2015 15:33:06 -0500
>>>>>> "Joe Gidi" <j...@entropicblur.com> wrote:
>>>>>>> I recently installed a UEFI-capable Asus M5A97 LE R2.0 motherboard
>>>>>>> in
>>>>>>> one
>>>>>>> of my systems and tried to boot the November 11th amd64
>>>>>>> miniroot58.fs
>>>>>>> image to test UEFI booting. I get to the bootloader, but it appears
>>>>>>> to
>>>>>>> fail while loading the kernel and goes into a reboot loop. Here's
>>>>>>> everything I see on screen before it reboots:
>>>>>>>
>>>>>>> probing: pc0 mem[640K 2984M 4M 48K 5103M]
>>>>>>> disk: hd0 hd1 hd2*
>>>>>>>>> OpenBSD/amd64 EFIBOOT 3.29
>>>>>>> boot>
>>>>>>> cannot open hd0a:/etc/random.seed: No such file or directory
>>>>>>> booting hd0a:/bsd:3273216+1394144+2409472+0+569344=0x74d238
>>>>>>
>>>>>> I'd like to figure out where the efiboot is stopping.  Can you
>>>>>> replace
>>>>>> the BOOTX64.EFI in the miniroot58.fs and check the output?
>>>>>
>>>>> Sure, I now get these two lines after the 'booting' line:
>>>>>
>>>>> GOP setmode failed(7)
>>>>> Hit any key to reboot
>>>>
>>>> The bootloader changs the video resolution before start the kernel.
>>>> It seems to fail.  "GOP", Graphic Output Protocol, returns an error.
>>>> 7 means EFI_DEVICE_ERROR.
>>>>
>>>>> Please let me know if I can do any further testing, and thank you for
>>>>> looking into this.
>>>>
>>>> Can you provide the result of "machine video" and try to change the
>>>> video mode to the best and some others.
>>>>
>>>>
>>>> And also please try the diff below.
>>>
>>> This appears to fix it. I did not have to change the video mode. Output
>>> from the bootloader:
>>
>> UEFI seems to have refused changing the video mode since it
>> isn't to change.
>>
>> Can you try this again?  (I'd like to verify whether the assumption
>> above is correct).
> 
> Is there something specific you want me to test?

I had wanted to know the latest one can boot successfuly.
Since I'd like to fix it on the tree.  Thanks for your reports.

> With the latest bootloader you provided, the 'machine video' output is
> still the same:
> 
> boot> machine video
> Mode 0: 80 x 25
> Mode 1: 80 x 50
> Mode 2: 100 x 31
> 
> Current Mode = 2
> 
> I am able to boot successfully from miniroot.fs and run through a UEFI
> install as described by jasper@ here:
> https://blog.jasper.la/openbsd-uefi-bootloader-howto/
> 
> The only thing I did differently from his blog post was to use the
> bootloader you provided, rather than copying in the one from
> /mnt/usr/mdec.
> 
> The newly installed system boots successfully, but then it seems to fail
> to initialize video properly at the end of the boot process. My monitor
> goes into an endless cycle of trying to sync up. I can ssh in and see this
> in /var/log/messages:
> 
> Nov 26 11:45:55 opteron /bsd: root on sd0a (ef051b8fc18f2fbe.a) swap on
> sd0b dump on sd0b
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: drm:pid0:evergreen_init *ERROR* disabling
> GPU acceleration
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: drm:pid0:radeon_bo_unpin *WARNING*
> 0x802922c0 unpin not necessary
> Nov 26 11:45:55 opteron /bsd: ttm_bo_ioremap bus_space_map failed
> Nov 26 11:45:55 opteron /bsd: error: [drm:pid0:radeonfb_create] *ERROR*
> failed to create fbcon object -12
> Nov 26 11:45:55 opteron ntpd[27846]: /var/db/ntpd.drift is empty
> Nov 26 11:45:55 opteron savecore: no core dump
> 
> My video card is:
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> 
> And the radeondrm-firmware-20150927 package is installed.
> 
> Thanks again for all your help.
> 
> --
> Joe Gidi
> j...@entropicblur.com
> 
> "You cannot buy skill." -- Ross Seyfried



Re: installboot with amd64 root on softraid crypto, NOT 'a' partition

2015-11-09 Thread YASUOKA Masahiko
On Sun, 8 Nov 2015 21:22:04 -0800
Nathan Wheeler  wrote:
> I ran into this exact same issue when I was trying to create a
> rollback install with CRYPTO for a sort of appliance I develop/manage
> for my company. We only have remote access with console and remote
> hands aren't easy to get so when upgrading it'd be nice to have a
> rollback in case something happens.
> 
> You can definitely boot a kernel off a different partition, but the
> kernel still assumes the root disk is 'a'. You have to tell the kernel
> to ask you for the root partition with "boot -a". Or you can compile
> your own kernel with the root disk hardcoded as it mentions in this
> post: http://www.undeadly.org/cgi?action=article=20110530221728

Isn't a story of the kernel configuration file?
It doesn't seem 'a' is hard coded (cannot change) since actually -a
can override that value.

> But I've come to the same conclusion that most people would say on
> this list that its just not a good idea. I definitely don't plan to
> put that practice in production. But if its just a personal use
> laptop, maybe it'll be OK, up to you.

I understand that story.

I'm not complaining but just wondering why "boot hd0j:/bsd" works but
"boot sr0j:/bsd" doesn't work.

--yasuoka



Re: installboot with amd64 root on softraid crypto, NOT 'a' partition

2015-11-08 Thread YASUOKA Masahiko
On Sun, 8 Nov 2015 11:52:48 +0100
Stefan Sperling  wrote:
> On Sat, Nov 07, 2015 at 07:57:05PM -0500, Jonathan Thornburg wrote:
>> At this point the machine can boot and run sd1[aeg] fine.  *But* if I
>> enter "boot sr1d:/bsd" at the "boot>" prompt, the machine boots sd1[aeg],
>> not the desired sd1[dfh].  In other words, at this point my "backup"
>> sd1[dfh] partitions aren't usefully bootable :(.
> 
> You cannot boot a kernel from a non-'a' partition.
> The bootloader won't look elsewhere.

As far as I know The boot loader itself should be located on 'a'
partition at least on i386 or amd64 BIOS boot loader, but kernel seems
to be able to be booted from non-'a' parition partition.  This
actually works at least on hd?? on amd64.

When starting the kernel, the boot loaders pass the 'bootdev'
parameter to the kernel.   Below is the definition of 'bootdev' in
sys/reboot.h.

/*
 * Constants for converting boot-style device number to type,
 * adaptor (uba, mba, etc), unit number and partition number.
 * Type (== major device number) is in the low byte
 * for backward compatibility.  Except for that of the "magic
 * number", each mask applies to the shifted value.
 * Format:
 *   (4) (4) (4) (4)  (8) (8)
 *  
 *  |MA | AD| CT| UN| PART  | TYPE |
 *  
 */

it includes the parition number.  So booting from non-'a' partition
seems to be intended.

--yasuoka



Re: (U)EFI install and boot not finding hd0a:/bsd

2015-11-03 Thread YASUOKA Masahiko
On Sun, 01 Nov 2015 10:09:37 -0800
Bryan Vyhmeister  wrote:
> Perhaps this is related to something else but on my 2013 MacBook Air
> with an OpenBSD-only EFI install, boot fails to attempt booting from
> hd0a:/bsd but instead tries fd0a:/bsd several times. I tried adding
> /etc/boot.conf with boot hd0a:/bsd in both sd0i (the EFI boot partition)
> and sd0a.

I fixed the problem with the booted device on cvs repository.
Thank for your report.

> Is this something unique to Apple hardware or is this something that
> all (U)EFI installs have trouble with?

efiboot had used a protocol of UEFI which macbook doesn't support.

--yasuoka



Re: (U)EFI install and boot not finding hd0a:/bsd

2015-11-03 Thread YASUOKA Masahiko
On Tue, 03 Nov 2015 10:14:08 -0800
Bryan Vyhmeister <br...@bsdjournal.net> wrote:
> On Tue, Nov 3, 2015, at 03:23 AM, YASUOKA Masahiko wrote:
>> I fixed the problem with the booted device on cvs repository.
>> Thank for your report.
>> 
>> > Is this something unique to Apple hardware or is this something that
>> > all (U)EFI installs have trouble with?
>> 
>> efiboot had used a protocol of UEFI which macbook doesn't support.
> 
> Wonderful! I rebuilt my BOOTX64.EFI and installed it to the EFI boot
> partition and the MacBook Air finds the kernel perfectly. The EFI boot
> no longer shows anything other than hd0 as I would expect. No more fd0
> or errors about it. Should a softraid(4) crypto root also work fine with
> EFI boot? Thank you so much!

Yes, softraid will work with efiboot.



Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

2015-10-05 Thread YASUOKA Masahiko
ci1: USB revision 1.0
> uhub4 at usb4 "AMD OHCI root hub" rev 1.00/1.00 addr 1
> isa0 at mainbus0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: probed fifo depth: 15 bytes
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> efifb0 at mainbus0
> wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
> uhidev0 at uhub0 port 4 configuration 1 interface 0 "Microsoft Comfort
> Curve Keyboard 3000" rev 2.00/1.70 addr 2
> uhidev0: iclass 3/1
> ukbd0 at uhidev0
> wskbd1 at ukbd0 mux 1
> wskbd1: connecting to wsdisplay0
> uhidev1 at uhub0 port 4 configuration 1 interface 1 "Microsoft Comfort
> Curve Keyboard 3000" rev 2.00/1.70 addr 2
> uhidev1: iclass 3/0, 1 report id
> uhid at uhidev1 reportid 1 not configured
> umass0 at uhub2 port 2 configuration 1 interface 0 " Patriot Memory"
> rev 2.00/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus1 at umass0: 2 targets, initiator 0
> sd2 at scsibus1 targ 1 lun 0: <, Patriot Memory, PMAP> SCSI2 0/direct
> removable serial.13fe3e002446EDB2A631
> sd2: 30544MB, 512 bytes/sector, 62554112 sectors
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> sd3 at scsibus2 targ 1 lun 0: <OPENBSD, SR RAID 1, 005> SCSI2 0/direct fixed
> sd3: 1907724MB, 512 bytes/sector, 3907020272 sectors
> root on rd0a swap on rd0b dump on rd0b
> 
> On Sun, Oct 4, 2015 at 11:45 PM, YASUOKA Masahiko <yasu...@openbsd.org> wrote:
>> It seems I could fix the problem.
>>
>>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>>   (updated)
>>
>> This diff avoids conflicting address space kernel and UEFI OS loader.
>>
>> I'll commit this to OpenBSD repository soon, but please try if you
>> can.
>>
>> Index: sys//arch/amd64/include/loadfile_machdep.h
>> ===
>> RCS file: /cvs/src/sys/arch/amd64/include/loadfile_machdep.h,v
>> retrieving revision 1.5
>> diff -u -p -r1.5 loadfile_machdep.h
>> --- sys//arch/amd64/include/loadfile_machdep.h  17 Jul 2015 20:44:38 -   
>>1.5
>> +++ sys//arch/amd64/include/loadfile_machdep.h  5 Oct 2015 04:42:04 -
>> @@ -41,7 +41,13 @@
>>  #define LOAD_KERNELLOAD_ALL
>>  #define COUNT_KERNEL   COUNT_ALL
>>
>> +#ifdef EFIBOOT
>> +extern u_long  efi_loadaddr;
>> +#define LOADADDR(a)(u_long)(a)) + offset)&0xfff) + \
>> +   efi_loadaddr)
>> +#else
>>  #define LOADADDR(a)u_long)(a)) + offset)&0xfff)
>> +#endif
>>  #define ALIGNENTRY(a)  ((u_long)(a))
>>  #define READ(f, b, c)  read((f), (void *)LOADADDR(b), (c))
>>  #define BCOPY(s, d, c) memcpy((void *)LOADADDR(d), (void *)(s), (c))
>> Index: sys//arch/amd64/stand/efiboot/efiboot.c
>> ===
>> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
>> retrieving revision 1.5
>> diff -u -p -r1.5 efiboot.c
>> --- sys//arch/amd64/stand/efiboot/efiboot.c 23 Sep 2015 03:29:26 -   
>>1.5
>> +++ sys//arch/amd64/stand/efiboot/efiboot.c 5 Oct 2015 04:42:04 -
>> @@ -36,6 +36,8 @@
>>  #include "eficall.h"
>>  #include "run_i386.h"
>>
>> +#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024)
>> +
>>  EFI_SYSTEM_TABLE   *ST;
>>  EFI_BOOT_SERVICES  *BS;
>>  EFI_RUNTIME_SERVICES   *RS;
>> @@ -46,6 +48,7 @@ UINTN  heapsiz = 1 * 1024 * 1024;
>>  UINTN   mmap_key;
>>  static EFI_GUID imgdp_guid = { 0xbc62157e, 0x3e33, 0x4fec,
>> { 0x99, 0x20, 0x2d, 0x3b, 0x36, 0xd7, 0x50, 0xdf 
>> }};
>> +u_long  efi_loadaddr;
>>
>>  static void efi_heap_init(void);
>>  static void efi_memprobe_internal(void);
>> @@ -61,9 +64,10 @@ extern int bios_bootdev;
>>  EFI_STATUS
>>  efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)
>>  {
>> -   extern char *progname;
>> -   EFI_DEVICE_PATH *dp0 = NULL, *dp;
>> -   EFI_STATUS   status;
>> +   extern char *progname;
>> +   EFI_DEVICE_PATH *dp0 = NULL, *dp;
>> +   EFI_STATUS   status;
>> +   EFI_PHYSICAL_ADDRESS stack;
>>
>> ST = systab;
>> BS = ST->BootServices;
>> @@ -101,8 +105,27 @@ efi_main(EFI_HANDLE image, EFI_

Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

2015-09-23 Thread YASUOKA Masahiko
On Wed, 23 Sep 2015 14:40:52 -0500
Brian Conway  wrote:
>> This picture shows
>>
>>   Load address: Loader Data (2) 0xd0 for 4096KB FATAL
>>
>> This is what I want to know.  0xd0 + 4M is overlapping the kernel
>> area.
>>
>> I think the following diff or
>>
>>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>>   (updated)
>>
>> will fix the problem.
> 
> Great, thanks. I grabbed the updated binary. `machine memory` is
> looking better,

Thanks.  The test code for `machine memory' was removed from that
binary.. Sorry.

> but no improvement on the boot situation, yet.

Umm.  I reverted the test code.  Can you try "machine memory" with

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

again?  This will not fix the problem, but I'd like to verify my
assumption is correct.

--yasuoka



Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

2015-09-22 Thread YASUOKA Masahiko
On Tue, 22 Sep 2015 14:20:22 -0500
Brian Conway  wrote:
>> Can you try the diff following or
>>
>>   http://yasuoka.net/~yasuoka/BOOTX64.EFI
>>
>> ?  Then enter "machine memory" on "boot> " prompt and check the last line.
>> It shows whether the memory area for kernel is free or not.  Like
>>
>>   Load address: Conventional(7) 0x for KB
>>
>> is good sign.
> 
> Great, thanks. I grabbed the binary.

Thanks,

> machine memory:
> 
> http://i.imgur.com/gtiAIxc.jpg

This picture shows

  Load address: Loader Data (2) 0xd0 for 4096KB FATAL

This is what I want to know.  0xd0 + 4M is overlapping the kernel
area.

I think the following diff or

  http://yasuoka.net/~yasuoka/BOOTX64.EFI
  (updated)

will fix the problem.

Index: sys/arch/amd64/stand/efiboot/Makefile.common
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/Makefile.common,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 Makefile.common
--- sys/arch/amd64/stand/efiboot/Makefile.common2 Sep 2015 01:52:25 
-   1.1
+++ sys/arch/amd64/stand/efiboot/Makefile.common23 Sep 2015 02:45:52 
-
@@ -7,6 +7,8 @@ EFIDIR= ${.CURDIR}/../../efi
 OBJCOPY?=  objcopy
 OBJDUMP?=  objdump
 
+EFI_HEAP_LIMIT=0xc0
+
 LDFLAGS+=  -nostdlib -T${.CURDIR}/../${LDSCRIPT} -Bsymbolic -shared
 
 COPTS+=-DEFIBOOT -DNEEDS_HEAP_H -DLINKADDR=${LINKADDR} 
-I${.CURDIR}/..
@@ -65,6 +67,7 @@ ${PROG}: ${PROG.so}
 .include 
 CFLAGS+=   -Wno-pointer-sign
 CPPFLAGS+= -DSMALL -DSLOW -DNOBYFOUR -D__INTERNAL_LIBSA_CREAD
+CPPFLAGS+= -DHEAP_LIMIT=${EFI_HEAP_LIMIT}
 
 ${PROG.so}: ${OBJS}
${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} ${LDADD}
Index: sys/arch/amd64/stand/efiboot/efiboot.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 efiboot.c
--- sys/arch/amd64/stand/efiboot/efiboot.c  3 Sep 2015 09:22:40 -   
1.3
+++ sys/arch/amd64/stand/efiboot/efiboot.c  23 Sep 2015 02:45:53 -
@@ -42,7 +42,7 @@ EFI_RUNTIME_SERVICES  *RS;
 EFI_HANDLE  IH, efi_bootdp = NULL;
 EFI_PHYSICAL_ADDRESSheap;
 EFI_LOADED_IMAGE   *loadedImage;
-UINTN   heapsiz = 3 * 1024 * 1024;
+UINTN   heapsiz = 1 * 1024 * 1024;
 UINTN   mmap_key;
 static EFI_GUID imgdp_guid = { 0xbc62157e, 0x3e33, 0x4fec,
  { 0x99, 0x20, 0x2d, 0x3b, 0x36, 0xd7, 0x50, 0xdf }};
@@ -199,7 +199,7 @@ efi_heap_init(void)
 {
EFI_STATUS   status;
 
-   heap = 0x100;   /* Below kernel base address */
+   heap = HEAP_LIMIT;
status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData,
EFI_SIZE_TO_PAGES(heapsiz), );
if (status != EFI_SUCCESS)



Re: UEFI boot attempt on AM1 platform with logs (9/16 snapshot)

2015-09-22 Thread YASUOKA Masahiko
Hi,

On Thu, 17 Sep 2015 20:47:22 -0500
Brian Conway  wrote:
> The NUC 2820 I was previously testing snapshots with has moved on to a
> better place (and lacked any meaningful serial console support), but
> here are some logs from an MSI AM1I motherboard, both the attempted
> UEFI boot and the successful BIOS boot. It also appears to hang during
> kernel load. Let me know if I can provide any more info.

Can you try the diff following or

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

?  Then enter "machine memory" on "boot> " prompt and check the last line.
It shows whether the memory area for kernel is free or not.  Like

  Load address: Conventional(7) 0x for KB

is good sign.

> Side note: Is com0 console not yet support by EFIBOOT? I got an error
> along those lines when attempting 'set tty com0', I assume this is
> already known.

No, it's not supported yet.

> boot> machine disk
> DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
> hd0 0x80label   956 64  32  0x2 0xe4afa028
> hd1 0x81label   1023255 63  0x0 0x0
> boot>

Isn't this a result of BIOS boot?

Index: sys/arch/amd64/stand/efiboot/efiboot.c
===
RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 efiboot.c
--- sys/arch/amd64/stand/efiboot/efiboot.c  3 Sep 2015 09:22:40 -   
1.3
+++ sys/arch/amd64/stand/efiboot/efiboot.c  22 Sep 2015 10:35:40 -
@@ -193,6 +193,7 @@ next:
  * Memory
  ***/
 bios_memmap_t   bios_memmap[64];
+static int  efi_badloadaddr = 0;
 
 static void
 efi_heap_init(void)
@@ -224,6 +225,8 @@ efi_memprobe(void)
printf("%uK", bm->size / 1024);
}
}
+   if (efi_badloadaddr)
+   printf(" BAD");
printf("]");
 }
 
@@ -233,9 +236,10 @@ efi_memprobe_internal(void)
EFI_STATUS   status;
UINTNmapkey, mmsiz, siz;
UINT32   mmver;
+   UINT64   pend;
EFI_MEMORY_DESCRIPTOR   *mm0, *mm;
int  i, n;
-   bios_memmap_t*bm, bm0;
+   bios_memmap_t   *bm, bm0;
 
cnvmem = extmem = 0;
bios_memmap[0].type = BIOS_MAP_END;
@@ -255,6 +259,11 @@ efi_memprobe_internal(void)
bm0.type = BIOS_MAP_END;
bm0.addr = mm->PhysicalStart;
bm0.size = mm->NumberOfPages * EFI_PAGE_SIZE;
+   pend = mm->PhysicalStart + mm->NumberOfPages * EFI_PAGE_SIZE;
+   if (!(pend <= 0x100 || 0x200 < mm->PhysicalStart) &&
+   mm->Type != EfiConventionalMemory)
+   efi_badloadaddr = 1;
+
if (mm->Type == EfiReservedMemoryType ||
mm->Type == EfiUnusableMemory ||
mm->Type == EfiRuntimeServicesCode ||
@@ -614,5 +623,49 @@ int
 Xpoweroff_efi(void)
 {
EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);
+   return (0);
+}
+
+int
+Xmemory_efi(void)
+{
+   EFI_STATUS   status;
+   UINTNmapkey, mmsiz, siz;
+   UINT32   mmver;
+   UINT64   pend;
+   EFI_MEMORY_DESCRIPTOR   *mm0, *mm;
+   int  i, n;
+   const char  *typestr;
+
+   siz = 0;
+   status = EFI_CALL(BS->GetMemoryMap, , NULL, , ,
+   );
+   if (status != EFI_BUFFER_TOO_SMALL)
+   panic("cannot get the size of memory map");
+   mm0 = alloc(siz);
+   status = EFI_CALL(BS->GetMemoryMap, , mm0, , , );
+   if (status != EFI_SUCCESS)
+   panic("cannot get the memory map");
+   n = siz / mmsiz;
+   mmap_key = mapkey;
+
+   for (i = 0, mm = mm0; i < n; i++, mm = NextMemoryDescriptor(mm, mmsiz)){
+   pend = mm->PhysicalStart + mm->NumberOfPages * EFI_PAGE_SIZE;
+   if (pend <= 0x100 || 0x200 < mm->PhysicalStart)
+   continue;
+   typestr = 
+   (mm->Type == EfiLoaderCode)? "Loader Code " :
+   (mm->Type == EfiLoaderData)? "Loader Data " :
+   (mm->Type == EfiBootServicesCode)? "BS Code " :
+   (mm->Type == EfiBootServicesData)? "BS Data " :
+   (mm->Type == EfiConventionalMemory)? "Conventional" :
+   "Other";
+   printf("Load address: %s(%d) 0x%llx for %uKB%s\n",
+   typestr, mm->Type, mm->PhysicalStart,
+   (unsigned)((mm->NumberOfPages * EFI_PAGE_SIZE) / 1024),
+   (mm->Type != EfiConventionalMemory)? " FATAL" : "");
+   }
+   free(mm0, siz);
+
   

Re: Native EFI Bootloader Support

2015-09-15 Thread YASUOKA Masahiko
On Tue, 15 Sep 2015 23:35:16 +0100
Toby Slight  wrote:
> On 15 September 2015 at 18:09, Chris Cappuccio  wrote:
>> Sounds like a bug in the brand new EFI boot blocks which affects your uefi
>> firmware and not some others. It seems all of your tests are pointing in
>> the
>> same direction, they are not a result of differences in the kernels,
>> rather,
>> they are a result of some bug or bugs in the efiblocks.
> 
> Do you think it's a efiblock bug for both issues (the usb installer kernel
> not loading 90% of the time AND an encrypted install not fully booting)?
> Why do you think the un-encrypted install and bsd.rd from an encrypted
> install boot without issue? Aren't the same efiblocks used in each case?

I'm not sure but I'm thinking the efi boot cannot load the kernel
properly from the disk.  There may be a bug in reading disk or
handling memory.  Differences of bsd, bsd.rd or softraid is changing
the broken part in the kernel.

Can you try

  http://yasuoka.net/~yasuoka/BOOTX64.EFI

this and "machine test" on boot prompt?  It will show

 0 blocksize=512

like this.  Disk number and blocksize.

Can you also try gzipped kernels (gzip /bsd, then "boot bsd.gz")?  I
suspect loading the kernel will always fail because the gzipped file
has a checksum.

--yasuoka



Re: Native EFI Bootloader Support

2015-09-13 Thread YASUOKA Masahiko
Hi,

Thank you for your report.  Can you provide a result of

  machine memory
  machine disk

on boot prompt?

>>> Also, is it normal that the resolution is a tiny cropped box in
>>> the middle of the screen?

The resolution is limitted to 100x31 or 80x25 since efifb was too slow
at least on my target machine.  The limit will be removed when it
becomes fast.  Currently efifb is getting better, it is very fast
after attaching efifb driver but it is still slow until attaching the
driver.

On Sun, 13 Sep 2015 23:14:55 +0100
Toby Slight  wrote:
> On 13 September 2015 at 19:26, Toby Slight  wrote:
> 
>> On 13 September 2015 at 18:34, Toby Slight  wrote:
>>
>>> OK, so I finally managed to boot the 12th's snapshot on an EFI only T430.
>>> Weirdly enough one time it just worked, but when I tried again I got the
>>> same results as the 9th's snapshot installer.
>>>
>>> It seems that sometime the bootblocks get loaded, sometimes not, 9 times
>>> out of 10 I get http://i.imgur.com/Apfoe8r.jpg, then suddenly it will
>>> just work. Any idea why a successful boot appears to be so random? Also,
> is
>>> it normal that the resolution is a tiny cropped box in the middle of the
>>> screen?
>>>
>>> Anyway, once I'd apparently (and very much obliviously) cast the right
>>> mystical invocations to successfully boot the installer, I followed Chris'
>>> very clear and useful instructions, with some slight alterations, to do my
>>> usual encrypted softraid0 setup on one disk.
>>>
>>> One point I should note is that the newfs_msdos command was not available
>>> in the installer's path, I had to wait until after install and then call
>>> the binary from the installed sets - ie) /mnt/sbin/newfs_mkdos.
>>>
>>> Anyway, apart from that tiny hiccup, everything else worked as expected.
>>> However when I tried to boot the new install I ended up almost immediately
>>> at the ddb prompt, as pictured below:
>>>
>>> http://i.imgur.com/1sfqYQ8.jpg
>>>
>>> http://i.imgur.com/OcRNUyI.jpg
>>>
>>> I'm not a developer and don't know how to use ddb, so is there anything
>>> else I could do to provide you guys information and help debug the issue?
>>>
>>> When I rebooted again it seemed the process hung in a slightly different
>>> way:
>>>
>>> http://i.imgur.com/1Am1qNB.jpg
>>>
>>> Hope some of that might be helpful to some of you EFI wizards, and if
>>> not, I haven't nuked the disk yet, so if there's any ddb poking you'd like
>>> me to do, let me know. Cheers!
>>>
>>
>> Perhaps this may also be of interest - I get yet again different results
>> when booting the sp kernel from the bootloader prompt (the boot process got
>> a lot further this time strangely enough):
>>
>> http://i.imgur.com/bAE0qWp.jpg
>>
>> http://i.imgur.com/sg7Rxgv.jpg
>>
>>
> 
> Again, in case it helps - managed to boot the ramdisk from my install
> successfully and get a dmesg:
> 
> OpenBSD 5.8-current (RAMDISK_CD) #1245: Sat Sep 12 15:04:54 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 8384425984 (7996MB)
> avail mem = 8128602112 (7752MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (68 entries)
> bios0: vendor LENOVO version "G1ETA8WW (2.68 )" date 03/06/2015
> bios0: LENOVO 2349VFV
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT
> ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.56 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X
> SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus -1 (EXP3)
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
> "Intel HD Graphics 4000" rev 0x09 at pci0 dev 2 function 0 not configured
> xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
> "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
> em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address
> 28:d2:44:44:38:e9
> ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 

Re: npppd and vpn connections on the same network

2014-12-01 Thread YASUOKA Masahiko
Yes.  But there is a bug with Windows clients.  See

  http://marc.info/?l=openbsd-miscm=141627574522930w=2

On Mon, 1 Dec 2014 12:42:41 +0100
Christer Solskogen christer.solsko...@gmail.com wrote:
 Hi!
 
 Is it possible to setup  npppd so that the clients are on the same
 network as the local network behind the router/firewall?
 
 The only setups I've seen have the clients on a seperate network.
 
 -- 
 chs



Re: npppd and vpn connections on the same network

2014-12-01 Thread YASUOKA Masahiko
On Mon, 1 Dec 2014 11:38:31 -0500
trondd tro...@gmail.com wrote:
 I had this set up for an Android and an OSX client.  Ignore the networks
 part and configure the connections for the end points.  I took the npppd
 assigned IPs out of my DHCP range.

I think I misunderstood your question.  You want to make two clients
be connected in the same network by PPP links.  right?

 My problems, though:
 Needed a specific npppd config for each client.  Username, assigned IP,
 whatever else goes along with it.
 I could only get one device talking at a time.  I think this was because
 npppd had the pppx0 interface hard coded in the config and the second
 device tried to create pppx1.

Though it's not related with your question, npppd can use tun0,
instead of pppx, which handles multiple PPP sessions at the same
time.

--yasuoka



Re: Concurrent L2TP/IPSEC connections for Windows Clients behind a shared NAT

2014-11-18 Thread YASUOKA Masahiko
On Sat, 15 Nov 2014 00:48:44 +
James McGoodwin jmcgood...@kobo.com wrote:
 However Windows clients are limited to only one connection at a
 time.  Subsequent connections cause the current session to die and
 be replaced by the new one.
(snip)
 In short, many security associations (for each windows client) but only one
 actual flow.
 
 Isakmpd doesn’t have a way to distinguish between the connections as it
 renegotiates their keys.

I could repeat the problem.  When rekeying, only one of the
connections can keep the IPsec session and others are dropped.  It
seems isakmpd NAT-T has an issue.

I also would like to fix it.  But I need to learn the isakmpd code.
It may take time.

--yasuoka



Re: npppd Ipsec L2TP mtu issues.

2014-09-16 Thread YASUOKA Masahiko
On Mon, 15 Sep 2014 20:22:25 +0200
Jens Hansen jensh...@gmail.com wrote:
 Thank you for your response. I've investegated a little further, I see the
 following in /var/log/messages on the l2tp npppd server:
 l2tpd ctrl=1 timeout waiting ack for hello packets.
 l2tpd ctrl=1 call=28732 logtype=PPPUnbind
 
 The client reports that the tunnel went down.. does this indidacte an
 mss/mtu issue? I've tried scrub on pppx and to set mru i npppd.conf ...no
 luck...

That log message indicates L2TP keepalive is failed.  The client
didn't respond for long time.

--yasuoka



Re: npppd Ipsec L2TP mtu issues.

2014-09-13 Thread YASUOKA Masahiko
Hi,

On Sun, 7 Sep 2014 21:00:31 +0200
Jens Hansen jensh...@gmail.com wrote:
 I can successfully connect to my opensbsd 5.5. isakmpd / npppd IPSEC L2TP
 vpn setup.
 But (not knowing too much about netwoking) i think i'm having a mtu
 problem. I can do low volume traffic fine, but transmitting larger files
 stalls. I've tried as per suggested by others around the  web the
 following.
 Added scrub on enc0 with an max mss of the pppx0 mtu.

scrub should be used for the VPN tunnel internal packets.  They pass
through on pppx0, pppx1,...pppxN.  (pppx creates a new clone for each
VPN session.)  pppx interface group should be used.

  match on pppx scrub ( max-mss 1410 )

 Tried with and without tcp-mss-adjust set to yes in npppd.conf.

At first, I think you should set mru not to fragment L2TP/IPsec
packets on your network and it also is used to fragment properly for
the packets inside the VPN links.  Also tcp-mss-adjust yes may be
useful if you want to avoid the PMTU-D blackhole problem.

--yasuoka



Re: Custom kernel with PIPEX without IPSEC failed to compile

2014-06-22 Thread YASUOKA Masahiko
On Sun, 22 Jun 2014 15:06:59 +0600
Ivan Solonin iss...@gmail.com wrote:
 I tried to compile custom kernel in the 5.5 release of OpenBSD on
 landisk platform with PIPEX, but found requirment of IPSEC by PIPEX.
 As I've found in file /sys/netinet/udp_usrreq.c it uses IPSEC only
 with L2TP to distinguish IPsec packets against non-IPsec.
 Is PIPEX so strong require IPSEC?

No, it isn't.

 Is it possible to compile custom kernel with PIPEX enabled, but
 without IPSEC?

Below diff will fix compile without IPSEC.  Also I sent the diff to
tech@ to ask for fixing it in the cvs tree.

Index: sys/netinet/udp_usrreq.c
===
RCS file: /disk/cvs/openbsd/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.184
diff -u -p -r1.184 udp_usrreq.c
--- sys/netinet/udp_usrreq.c23 Apr 2014 12:25:35 -  1.184
+++ sys/netinet/udp_usrreq.c23 Jun 2014 02:17:06 -
@@ -186,9 +186,9 @@ udp_input(struct mbuf *m, ...)
struct m_tag *mtag;
struct tdb_ident *tdbi;
struct tdb *tdb;
+#endif /* IPSEC */
int error;
u_int32_t ipsecflowinfo = 0;
-#endif /* IPSEC */
 
va_start(ap, m);
iphlen = va_arg(ap, int);



Re: npppd security

2014-05-29 Thread YASUOKA Masahiko
On Wed, 28 May 2014 22:04:34 +0300
Mike Jackson m...@netauth.com wrote:
  If npppd tunnel listen address can't be changed and l2tp-ipsec-require
  isn't supported,

You can change the listen address by npppd.conf:

  tunnel L2TP protocol l2tp {
listen on xxx.xxx.xxx.xxx
  }

l2tp-ipsec-require isn't supported yet, but we can refuse L2TP without
IPsec packerts by pf.

  then how is one supposed to secure the npppd service from
  dictionary attacks from the entire world?

When RADIUS is used for authentication, the RADIUS authentication
server may provide something against the dictonary attacks.

Also if npppd supports EAP-RADIUS in the future, some authentication
methods including EAP-TLS (certificate authentication) will become
available.

  Ideal would be to do certificate authentication to isakmpd and then
  password authentication to npppd that is running on an internal
  IP. Is this ever going to be possible?

Sorry, I'm not sure.

--yasuoka



Re: pipex and npppd syslog

2014-05-28 Thread YASUOKA Masahiko
On Tue, 27 May 2014 20:03:54 +0200
Marko Cupać marko.cu...@mimar.rs wrote:
 I have relatively busy npppd pptp server, and it logs a lot of output
 into /var/log/messages.
 
 How can I move npppd and pipex log messages into separate file?

As far as syslog.conf(5), you can use !!npppd for that purpose.

Currently npppd or pipex itself doesn't have any configuration which
controls the log output.

npppd should be more silence?  I myself feel the pipex log in dmesg is
noisy.  But almost all logs of /var/log/daemon are useful for me to
debug the problem.

--yasuoka



Re: PPTP after removing of userland ppp(8)

2014-03-19 Thread YASUOKA Masahiko
On Thu, 20 Mar 2014 00:39:50 +0200
Атанас Владимиров don.na...@gmail.com wrote:
 I was running PPTP client pptp-1.7.2p4 with userland ppp(8). It was a basic
 setup from pptp(8) manual page and specifically PPTP on a router example.
 What are my alternatives to run PPTP to connect to Microsoft VPN server?
 May I use ppp(4) and pppd(8) and if so can you point me to the right
 direction.

I think having good ppp client implementation and l2tp client in base
is the good direction.  I myself will try to do my best for that
direction.

--yasuoka



Re: npppd with two pppx interfaces causes kernel panic

2014-03-19 Thread YASUOKA Masahiko
On Wed, 19 Mar 2014 16:45:46 -0700
Paul B. Henson hen...@acm.org wrote:
 After successfully setting up an L2TP VPN with npppd and pppx, I tried
 to add a second VPN subnet with a different authentication base. I was
 working remotely, and after starting npppd in debug mode:

pppx will be fixed.

You can use tun(4) instead if you want to use multiple interfaces for
that purpose.

--yasuoka



Re: npppd with two pppx interfaces causes kernel panic

2014-03-19 Thread YASUOKA Masahiko
On Wed, 19 Mar 2014 21:05:35 -0700
Paul B. Henson hen...@acm.org wrote:
 On Thu, Mar 20, 2014 at 10:22:51AM +0900, YASUOKA Masahiko wrote:
 pppx will be fixed.
 
 Great :). This is a known bug then?

It's new for me.  I had not even try MAKEDEV pppx1 yet.

 Should I just keep an eye on the changelog for mention of pppx
 changes to tell when it's safe to try again?

Sorry I cannot understand the point of this question.

 You can use tun(4) instead if you want to use multiple interfaces for
 that purpose.
 
 Yes, I switched to tun for now pending the ability to have multiple pppx
 interfaces defined. It was a rather big surprise for the box to
 disappear on me while I was working with it, I don't have any out of
 band access to it so it was offline until I got to it sigh.

Sorry too.  I cannot see the problem you entered.

--yasuoka



Re: ospfd and L2VPN routes

2014-03-05 Thread YASUOKA Masahiko
On Sat, 1 Mar 2014 18:23:08 -0800
Paul B. Henson hen...@acm.org wrote:
 On Sat, Mar 01, 2014 at 01:48:06PM +0900, YASUOKA Masahiko wrote:
  on the other side? Right now it looks like the client is setting a
  route to 10.0.0.0/8 across the tunnel, that should actually be
  10.128.0.0/16, would setting the netmask in npppd-users fix that remote
  route? Can I set the netmask but still let the client get a dynamic IP?
 
 My answer was wrong.  Assigning statically or netmask to the client is
 not related the ospf problem, I'm sorry.
 
 No worries, I appreciate the help :). I tried setting the netmask in
 npppd-users, that didn't change the /8 route the iPhone client set. From
 a little investigation, it doesn't look like there's any way to set the
 client netmask for the l2tp vpn route? The client just does whatever it
 wants it seems, whether to just assume a class based route (/8 in the
 case of my 10.128 address) or some seem to just assume a /24 8-/. You'd
 think defining the client netmask would be part of the protocol, but
 unless I'm missing something, I guess it's not.

framed-ip-netmask in npppd-user to set the netmask of the route to
the PPP link.  But it is not to set the client netmask (on iPhone).

AFAIK to set the client netmask, DHCP inform can be used.

Also I found some bugs around framed-ip-netmask.  I will fix them
soon.

--yasuoka



Re: ospfd and L2VPN routes

2014-03-05 Thread YASUOKA Masahiko
On Sat, 1 Mar 2014 18:42:11 -0800
Paul B. Henson hen...@acm.org wrote:
 On Sat, Mar 01, 2014 at 07:41:10PM +0900, YASUOKA Masahiko wrote:
 I could repeat the problem.  ospfd seems not to be able to use routes
 set by npppd.  The problem seems to be come from pppx(4)'s behavior of
 its link state.
 
 Using tun(4) instead of pppx(4) avoid the problem.
 
 If I switch npppd to use tun, after startup (before any clients even
 connect) ospfd shows three routes:
 
 # ospfctl show fib | grep 120
 *56 10.128.120.0/24  127.0.0.1
   4 10.128.120.1/32  10.128.120.1
 *56 10.128.120.1/32  127.0.0.1
 
 Kind of odd ones though, routing the whole /24 to localhost?  After a
 client connects, it adds another /32 to it:
 
 # ospfctl show fib | grep 120
 *56 10.128.120.0/24  127.0.0.1
   4 10.128.120.1/32  10.128.120.1
 *56 10.128.120.1/32  127.0.0.1
  56 10.128.120.12/32 10.128.120.1
 
 And after the client disconnects, it goes away:
 
 # ospfctl show fib | grep 120
 *56 10.128.120.0/24  127.0.0.1
   4 10.128.120.1/32  10.128.120.1
 *56 10.128.120.1/32  127.0.0.1
 
 However, it's still not advertised by ospfd to other routers, so the
 client still can't communicate with the network beyond the openbsd
 router terminating the vpn connection.

I see the problem of /32 route.  But it doesn't occur on my
environment (OpenBSD 5.5-beta/amd64)..

  % ospfctl show fib | grep 128
  *56 10.128.120.0/24  127.0.0.1
  *56 10.128.120.213/3210.0.0.1
  % 

And do you know why the ospfd doesn't use the whole /24?

 So while tun seems to avoid the pppx problem of dangling routes, it
 still doesn't solve the issue of ospfd not advertising them sigh.
 
 pppx is more efficient than tun, right? It keeps packets in the kernel
 rather than bouncing them through userspace?

Even if tun(4) is used, packets are processed in-kernel.

--yasuoka



Re: ospfd and L2VPN routes

2014-03-05 Thread YASUOKA Masahiko
On Wed, 5 Mar 2014 10:50:10 -0800
Paul B. Henson hen...@acm.org wrote:
 From: YASUOKA Masahiko
 Sent: Wednesday, March 05, 2014 1:48 AM

 framed-ip-netmask in npppd-user to set the netmask of the route to
 the PPP link.  But it is not to set the client netmask (on iPhone).
 
 AFAIK to set the client netmask, DHCP inform can be used.
 
 Hmm, I thought the VPN client picked up its IP address from IPCP?

Of cource it does.  But netmask is not supported by IPCP.

 How would you get DHCP involved?

Some clients (AFAIK Windows, MacOS and iPhone) are waiting a DHCP
inform on their PPP link.  If we can send the DHCP inform, the clients
will receive that.  (Though I have not tried that with our dhcpd yet.)

--yasuoka



Re: ospfd and L2VPN routes

2014-03-05 Thread YASUOKA Masahiko
On Wed, 5 Mar 2014 10:55:51 -0800
Paul B. Henson hen...@acm.org wrote:
 From: YASUOKA Masahiko
 Sent: Wednesday, March 05, 2014 3:20 AM

   % ospfctl show fib | grep 128
   *56 10.128.120.0/24  127.0.0.1
   *56 10.128.120.213/3210.0.0.1
 
 Interesting, not only does it show a /24 route, it looks like it has it
 marked as valid. Is this with pppx or tun? IIRC, when I tested tun ospfd
 found a /24 route, but still didn't propagate it.

That was with tun.

 Even if tun(4) is used, packets are processed in-kernel.
 
 Ah, I had thought  pipex was just for pppx, but now I see in the man page it
 says pipex is used with tun(4) and pppx. What's the difference between tun
 and pppx in the context of npppd then? Is there any particular reason to use
 one versus the other for an L2TP VPN?

pppx(4) creates a interface for each PPP session.  tun(4) doesn't
create any interface and uses only one interface for all PPP
sessions.

Generally pppx's way is thought to be natural and tun's way is tricky.
Old system had had some problems if it has a lot of interfaces.  tun's
way had been used to avoid those problems.  So I think pppx should be
used.

--yasuoka



Re: ospfd and L2VPN routes

2014-03-01 Thread YASUOKA Masahiko
On Fri, 28 Feb 2014 12:41:16 -0800
Paul B. Henson hen...@acm.org wrote:
 I'm currently setting up an L2TP VPN with npppd. I've got the VPN piece
 working, and can send packets between the client and the openbsd box
 running the vpn. However, I'm currently using ospfd for routing between
 the rest of the network and the openbsd box, and it doesn't seem to be
 pushing routes for the IP addresses in use by the clients.

I could repeat the problem.  ospfd seems not to be able to use routes
set by npppd.  The problem seems to be come from pppx(4)'s behavior of
its link state.

Using tun(4) instead of pppx(4) avoid the problem.

--yasuoka



Re: ospfd and L2VPN routes

2014-02-28 Thread YASUOKA Masahiko
On Fri, 28 Feb 2014 12:41:16 -0800
Paul B. Henson hen...@acm.org wrote:
 I'm currently setting up an L2TP VPN with npppd. I've got the VPN piece
 working, and can send packets between the client and the openbsd box
 running the vpn. However, I'm currently using ospfd for routing between
 the rest of the network and the openbsd box, and it doesn't seem to be
 pushing routes for the IP addresses in use by the clients.

I'm not sure whether it works.  Can you try it by static route?

Also, if there is a network behind the vpn, you can assign a static ip
address and netmask instead of assigning /32 dynamic address.  See
npppd-users(5) and use framed-ip-address and framed-ip-netmask.

 So, after a couple VPN clients connect, there are pppx interfaces:
 
 pppx0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1360
 description: henson
 priority: 0
 groups: pppx
 inet 10.128.120.1 -- 10.128.120.82 netmask 0x
 
 pppx1: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1360
 description: henson
 priority: 0
 groups: pppx
 inet 10.128.120.1 -- 10.128.120.121 netmask 0x
 
 and the local routing tables know how to get to them:
 
 DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
 10.128.120.82  10.128.120.1   UH 0   10 - 4 pppx0
 10.128.120.121 10.128.120.1   UH 0   63 - 4 pppx1
 
 ospfd seems to know *something* about the /24 I've allocated to the VPN:

npppd setup the routes for configured pool addresses to reserve them.
I think this is the reason why ospfd seems to know something.

But

 flags: * = valid, O = OSPF, C = Connected, S = Static
 Flags  Prio Destination  Nexthop  
 *C4 10.128.110.0/24  link#7
   4 10.128.120.43/32 10.128.120.1
   4 10.128.120.45/32 10.128.120.1
   4 10.128.120.82/32 10.128.120.1

many /32 routes show something wrong.

--yasuoka



Re: npppd ipcp pool address configuration

2014-02-28 Thread YASUOKA Masahiko
Hi,

On Fri, 28 Feb 2014 11:54:07 -0800
Paul B. Henson hen...@acm.org wrote:
 According to the npppd.conf man page:
 
  pool-address address-range | address-mask [for dynamic | static]
  Specify the IP address space that is pooled for this IPCP
  setting.  The address space can be specified by address-range
  (e.g. 192.168.0.2-192.168.0.254) or address-mask (e.g.
  192.168.0.0/24) .  dynamic means the address space is reserved
  for dynamic allocation; static means the address space is
  reserved for static allocation.  The default is dynamic.  This
  option can be used multiple times.
 
 However, if I try to specify an address-mask:
 
 ipcp IPCP {
 pool-address 10.128.120.0/24
 dns-servers 10.128.0.4
 allow-user-selected-address no
 }
 
 It says there's a syntax error:
 
 2014-02-28 11:48:24:NOTICE: Starting npppd pid=31351 version=5.0.0
 2014-02-28 11:48:24:WARNING: pptpd GRE protocol not allowed
 2014-02-28 11:48:24:CRIT: /etc/npppd/npppd.conf:12: syntax error
 2014-02-28 11:48:24:CRIT: /etc/npppd/npppd.conf:17: ipcp IPCP is not found
 2014-02-28 11:48:24:CRIT: /etc/npppd/npppd.conf:18: interface pppx0 is not 
 found

Currently the parser needs to surrounding the address-mask with double
quote like below:

  pool-address 10.128.120.0/24

I will try to fix this.

And also we can use

  pool-address 10.128.120.0:255.255.255.0

format.  I will add mention this to the man page.

 I had originally specified an address range:
 
 ipcp IPCP {
 pool-address 10.128.120.2-10.128.120.254
 dns-servers 10.128.0.4
 allow-user-selected-address no
 }
 
 This works, but it's rather confusing in that it shows a whole bunch of tiny
 allocations rather than a contiguous one:
 
 2014-02-28 11:53:08:INFO: ipcp=IPCP pool 
 dyn_pool=[10.128.120.2/31,10.128.120.4/30,10.128.120.8/29,10.128.120.16/28,10.128.120.32/27,10.128.120.64/26,10.128.120.128/26,10.128.120.192/27,10.128.120.224/28,10.128.120.240/29,10.128.120.248/30,10.128.120.252/31,10.128.120.254/32]
  
 pool=[10.128.120.2/31,10.128.120.4/30,10.128.120.8/29,10.128.120.16/28,10.128.120.32/27,10.128.120.64/26,10.128.120.128/26,10.128.120.192/27,10.128.120.224/28,10.128.120.240/29,10.128.120.248/30,10.128.120.252/31,10.128.120.254/32]
 
 I thought maybe if I used the address-mask rather than a range this would
 be cleaner.
 
 Is the man page incorrect or am I specifying the CIDR address wrong?

The parser is not good enough.

 Assuming I want to allocate 10.128.120.1 as the local tunnel
 endpoint, and the rest of that /24 as VPN addresses, what's the best
 way to configure it?

As the default, npppd doesn't use the local tunnel endpoint address
and broadcast addresses in class network (10.0.0.0 and 10.255.255.255)
for the clients.  Do you worry about 10.128.120.0 or 10.128.120.255 in
this case?

--yasuoka



Re: ospfd and L2VPN routes

2014-02-28 Thread YASUOKA Masahiko
On Fri, 28 Feb 2014 19:42:26 -0800
Paul B. Henson hen...@acm.org wrote:
 On Sat, Mar 01, 2014 at 11:23:01AM +0900, YASUOKA Masahiko wrote:
 I'm not sure whether it works.  Can you try it by static route?
 
 A static route on the network on the other side of the openbsd box? I'm
 sure that would work; when I try to ping a box out in the network from
 the vpn client, I can see the outbound pings traversing the link from
 the openbsd box to the router on the other side:
 
 19:24:43.669307 10.128.120.163  10.128.130.1: icmp: echo request
 19:24:44.646823 10.128.120.163  10.128.130.1: icmp: echo request
 19:24:45.644309 10.128.120.163  10.128.130.1: icmp: echo request
 19:24:46.666878 10.128.120.163  10.128.130.1: icmp: echo request
 
 The return packets are getting dropped due to the lack of a route, so if
 I had a static route on the other side it would work, but I'd rather not
 use static routes, ideally I can make ospfd dynamically advertise routes
 as necessary.

Sorry I thought you were trying to add additional routes though the
PPP client.  Now I understand what you are trying.

 Also, if there is a network behind the vpn, you can assign a static ip
 address and netmask instead of assigning /32 dynamic address.  See
 npppd-users(5) and use framed-ip-address and framed-ip-netmask.
 
 I'd prefer not to assign a static IP per user, I like the concept of
 just having a dynamic pool and users just get whatever address out of
 it. I'm not sure how the netmask would work for a point-to-point link?
 How could it be anything but a /32? Or would the netmask be for the route
 on the other side? Right now it looks like the client is setting a
 route to 10.0.0.0/8 across the tunnel, that should actually be
 10.128.0.0/16, would setting the netmask in npppd-users fix that remote
 route? Can I set the netmask but still let the client get a dynamic IP?

My answer was wrong.  Assigning statically or netmask to the client is
not related the ospf problem, I'm sorry.

 many /32 routes show something wrong.
 
 Why?

npppd set a /32 route for a VPN client and delete it when the link
down.

 Isn't each instance of pppx for the VPN a /32 route to the remote
 IP?

You had 16 /32 routes.  Don't you mean you had 32 VPN clients
actually, right?


Sorry, I'm not good at ospfd, so I could not anwer other questions
soon.

--yasuoka



Re: L2TP VPN / pf

2014-02-27 Thread YASUOKA Masahiko
On Thu, 27 Feb 2014 13:51:10 -0800
Paul B. Henson hen...@acm.org wrote:
 From: YASUOKA Masahiko
 Sent: Wednesday, February 26, 2014 8:46 PM
   sysctl net.pipex.enable=1
 
 Hmm, yeah, that... I had updated my /etc/sysctl.conf with that change, but
 the system had not been rebooted since I did that; and it does appear I
 forgot to run it by hand 8-/. I could have sworn I manually tweaked it when
 I updated the config, but when I double checked, it was not set, so clearly
 I did not sigh. After enabling that setting, I can ping the client from
 the server and vice versa, yay! It looks like ospfd isn't propagating the
 route for the VPN addresses, so I can't talk to anything past the router,
 presumably I need to update that config next.

I'm glad to hear that.

 In L2TP/IPsec, transport mode IPsec is used instead of tunnel mode.
 This means enc(4) is not used.  And de-capsulated L2TP packets are
 received on the same interface which receives IPsec packet.
 
 Hmm, that's not what I'm seeing. On the regular WAN interface (em1), when a
 connection is established, I see some initial isakmp packets, and after
 that, the only packets on that interface are the esp protocol:

You're right.  I was confused, sorry.

 For the purpose of writing pf rules, I'd like to understand exactly what
 interfaces the packets are traversing. It looks like initially there are
 isakmp packets from the remote client to the server on the external WAN
 interface, followed by encapsulated esp packets. At that point, it looks
 like the packets are flowing through the enc0 interface, from the remote
 client to the l2tp server. Once that tunnel is established, it looks like
 the tunneled packets flow through the pppx0 interface.

Exactly.

 Thanks much for helping point out my obvious mistake with pipex :). I wish I
 would have thought to double check that yesterday when I was beating my head
 against the wall trying to figure out why it wasn't working...

Not at all.  I'll fix npppd to warn in the log when the pipex sysctl
is not set.

--yasuoka



Re: L2TP VPN / pf

2014-02-26 Thread YASUOKA Masahiko
Hi,

On Wed, 26 Feb 2014 16:32:34 -0800
Paul B. Henson hen...@acm.org wrote:
 I currently have the following in pf.conf:
 
 -
 pass quick proto { esp, ah } from any to any
 pass in quick on em1 proto udp from any to 96.251.22.154 port {500, 4500,
 1701} keep state
 set skip on enc0
 set skip on pppx0
 -

set skip on pppx0 needs to be improved because npppd may use pppx1,
or pppx2 ...

 I'm pretty sure I have the ipsec/npppd pieces correct, as I am successfully
 able to connect to the VPN:
 
 -
 2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
 from=134.71.203.230:644
(snip)
 2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base logtype=TUNNELSTART
 user=henson duration
 =4sec layer2=L2TP_ipv4 layer2from=134.71.203.230:64468 auth=MS-CHAP-V2
 ip=10.128.120.160 
 iface=pppx0

L2TP/IPsec seems to be established successfully.  This means your
ipsec.conf, npppd.conf and pf.conf are ok.

 However, from the VPN client I cannot ping 10.128.120.1, the server
 endpoint, and from the server I cannot ping 10.128.120.160, the client
 endpoint. When I try to ping the client, I can see traffic on the ethernet
 interface:
(snip)
 Am I missing something in either the ipsec, npppd, or pf configuration?

Did you do

  sysctl net.pipex.enable=1

?  This is required to pass packets through the VPN tunnel.

 For this rule pass quick proto { esp, ah } from any to any, does it really
 need to be any to any with no interface defined?

I think it is required only from/to the listening address of L2TP.

 Wouldn't all of the ipsec traffic be on the WAN interface to/from
 the WAN IP? While I think this piece is working, I'd rather have the
 rule exactly match what is needed than be extra generic.
 
 Regarding this rule pass in quick on em1 proto udp from any to
 96.251.22.154 port {500, 4500, 1701} keep state, it looks like the
 connection to the l2tp port is over the ipsec tunnel and hence via enc0, not
 em1? So it doesn't seem 1701 needs to be allowed in on this rule, I removed
 it and it continued to work, at least as far as successfully connecting but
 not passing traffic over the VPN link sigh.

In L2TP/IPsec, transport mode IPsec is used instead of tunnel mode.
This means enc(4) is not used.  And de-capsulated L2TP packets are
received on the same interface which receives IPsec packet.

--yasuoka



Re: VPN Between OpenBSD and iOS

2013-12-30 Thread YASUOKA Masahiko
Hi,

On Sun, 29 Dec 2013 20:58:03 -0500
Matt Carlson obsda0...@mpcarlson.com wrote:
 # grep -v ^# /etc/ipsec.conf
 
 
 ike passive esp transport \
proto udp \
from any to any port 1701 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes-256 \
psk 1

AFAIK, fixed IP address should be used for the source address.

Does changing

from any to any port 1701 \

to

from 69.g.h.i to any port 1701 \

fix the problem?

--yasuoka



Re: NPPPD and IPSec

2013-12-16 Thread YASUOKA Masahiko
Hi,

On Mon, 2 Dec 2013 19:34:57 +0200 (IST)
Or Elimelech o...@xwise.com wrote:
 I'm having trouble configuring Windows clients with l2tp over ipsec, 
 This config works great on OSX/iOS/Android/Linux 
 
 I do not know which type of auth/enc/group I should use for Windows clients 
 
 I currently use OpenBSD 5.4 with the following 
 
 ike passive esp transport \ 
 proto udp from 1.2.3.4 to any port 1701 \ 
 main auth hmac-sha1 enc aes group modp1024 \ 
 quick auth hmac-sha1 enc aes group modp1024 \ 
 psk secret 

As far as my test with Windows 7, changing the main mode config to

  main auth hmac-sha1 enc aes group modp2048

or

  main auth hmac-sha1 enc 3des group modp1024

will fix the problem.

--yasuoka



Re: NPPPD and IPSec

2013-12-16 Thread YASUOKA Masahiko
The mail I replied to was too old..  sorry.

On Mon, 16 Dec 2013 18:52:25 +0900 (JST)
YASUOKA Masahiko yasu...@yasuoka.net wrote:
 On Mon, 2 Dec 2013 19:34:57 +0200 (IST)
 Or Elimelech o...@xwise.com wrote:
 I'm having trouble configuring Windows clients with l2tp over ipsec, 
 This config works great on OSX/iOS/Android/Linux 
 
 I do not know which type of auth/enc/group I should use for Windows clients 
 
 I currently use OpenBSD 5.4 with the following 
 
 ike passive esp transport \ 
 proto udp from 1.2.3.4 to any port 1701 \ 
 main auth hmac-sha1 enc aes group modp1024 \ 
 quick auth hmac-sha1 enc aes group modp1024 \ 
 psk secret 
 
 As far as my test with Windows 7, changing the main mode config to
 
   main auth hmac-sha1 enc aes group modp2048
 
 or
 
   main auth hmac-sha1 enc 3des group modp1024
 
 will fix the problem.
 
 --yasuoka



Re: NPPPD

2013-12-09 Thread YASUOKA Masahiko
On Mon, 9 Dec 2013 09:38:50 +0200 (IST)
Or Elimelech o...@xwise.com wrote:
 I've configured nppd server and clients for Linux, Android, iOS, OSX
 and Windows.  This works on all platforms when routing all traffic
 through VPN except for Windows clients.

Usually npppd can work with Windows client without problem.

 I can connect to the vpn and I get a route for 0.0.0.0 mask 0.0.0.0
 vpn interface but ipconfig shows me 10.0.0.50 with 255.255.255.255
 and 0.0.0.0 GW

I think this is usual behavior of Windows.  ipconfig doesn't show the
remote gateway's address.

Did you alter the Use default gateway on remote network checkbox in
Advanced TCP/IP settings of the Windows client's VPN connection
entry?

Does ping to 10.0.0.1 from the Windows success?

How about npppctl session all?

--yasuoka



Re: VPN suggestions

2013-11-11 Thread YASUOKA Masahiko
On Sun, 10 Nov 2013 02:31:39 +0200
Kapetanakis Giannis bil...@edu.physics.uoc.gr wrote:
 On 08/11/13 17:50, YASUOKA Masahiko wrote:
 What I'm wondering is what you guys do to setup the ipsec path of the
 tunnel.

 One option is to use a unique pre-shared key for all clients. But this
 is probably insecure since
 it opens MITM attacks. Isn't it?
 Yes.  I think IKEv2 or SSTP will help that situation.
 
 Can IKEv2 be combined with npppd without problems?

IKEv2 will be used without npppd, since IKEv2 itself can be used for
remote access vpn.  It supports EAP for the authentication and
configures IP address and DNS and so on.

--yasuoka



Re: VPN suggestions

2013-11-08 Thread YASUOKA Masahiko
On Fri, 08 Nov 2013 14:38:33 +0200
Kapetanakis Giannis bil...@edu.physics.uoc.gr wrote:
 Playing around with npppd was straight forward and I was quite
 impressed with it. Good job.

Thanks.

 EAP-TLS would also be a very nice feature to have.

Do you mean npppd should *directly* authenticate the clients with the
TLS (certificates)?

I think it is a bad idea.  Npppd should support `EAP via RADIUS'.
After it supports the `EAP via RADIUS', it will be able to use all
EAP-??? which is supported by RADIUS.

 What I'm wondering is what you guys do to setup the ipsec path of the
 tunnel.
 
 One option is to use a unique pre-shared key for all clients. But this
 is probably insecure since
 it opens MITM attacks. Isn't it?

Yes.  I think IKEv2 or SSTP will help that situation.

--yasuoka



Re: npppd / pppoe server troubles

2013-10-17 Thread YASUOKA Masahiko
Hi,

On Wed, 16 Oct 2013 21:10:25 +0200
Gruel Bruno b.gr...@sdnet.info wrote:
 As i thought that it's doesn't read my users file i changed the
 username  password but nothing else.

Yes, the log shows the session is terminated because the passwords are
mismatched.

I checked by below snapshots, but I could not repeat the problem.

  OpenBSD 5.4-current (GENERIC) #77: Sun Oct 13 17:27:52 MDT 2013
  dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

  OpenBSD 5.4-current (GENERIC) #66: Sun Oct 13 15:54:12 MDT 2013
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Can you try again with below patch?  I'd like to get log for debug.

Index: npppd/pap.c
===
RCS file: /cvs/openbsd/src/usr.sbin/npppd/npppd/pap.c,v
retrieving revision 1.7
diff -u -p -r1.7 pap.c
--- npppd/pap.c 18 Sep 2012 13:14:08 -  1.7
+++ npppd/pap.c 18 Oct 2013 04:06:27 -
@@ -341,7 +341,11 @@ pap_local_authenticate(pap *_this, const
pap_response(_this, 1, DEFAULT_SUCCESS_MESSAGE);
return;
}
-   }
+   pap_log(_this, LOG_INFO, password mismatch %s%s,
+   password, password0);
+   } else
+   pap_log(_this, LOG_INFO, could not get password for %s,
+   username);
pap_response(_this, 0, DEFAULT_FAILURE_MESSAGE);
 }



Re: npppd / pppoe server troubles

2013-10-16 Thread YASUOKA Masahiko
Hi,

On Wed, 16 Oct 2013 13:39:31 +0200
Gruel Bruno b.gr...@sdnet.info wrote:
 ### On OBSD 5.3 release :
(snip)
 Segmentation fault
 
 After de DISCOVERY message the server crash with Segmentation fault

This bug had been fixed on April 16.  PPPoE server (by npppd) on 5.3
is completely broken.

 ### On OBSD 5.3 snapshot (2weeks ago version) :
 I'm doing some tests last night and got other problems. I don't have
 my snapshots stations here but the symptom is :

I believe this will work.

 npppd logs side  somthings like that :
 ...unable to agree auth proto...

As your config, CHAP or MS-CHAP-V2 must be accepted,

 Network side :
 request.reject when client propose pap or chap or whatever.
 
 I 'll give you full log tonight.
 
 Is someone have some idea ?

The log will help me.

Adding

  authentication-method pap chap

to the tunnel block on npppd.conf may avoid the problem.

--yasuoka



Re: Hang possibly related to pipex

2013-07-08 Thread YASUOKA Masahiko
Hi,

On Wed, 3 Jul 2013 13:55:45 +0200
Marko Cupać marko.cu...@mimar.rs wrote:
 In last 10 days machine hanged twice. I do not have hang message from
 the first time, but this time i read this:
 
 uvm_fault(0xd8f5f680, 0x0, 0, 3) - e
 kernel: page fault trap, code=0
 Stopped at   pipex_close_session+0xc4:   movl   %eax,0x6c(%exc)
 ddb{3}

This panic is fixed after 5.3.

 Below is my dmesg:
 OpenBSD 5.3 (GENERIC.MP) #58: Tue Mar 12 18:43:53 MDT 2013
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

Can you try latest snapshot or below patch?


CVSROOT:/cvs
Module name:src
Changes by: yasu...@cvs.openbsd.org 2013/04/16 01:36:55

Modified files:
sys/net: pipex.c pipex_local.h 

Log message:
When pipex session is terminated by idle timer, there was a problem that
the session is removed from the pipex_closed_wait_list twice, fixed it.
It always causes panic because QUEUE_MACRO_DEBUG is enabled by default.
Also remove some needless (struct pipex_session *) casts.

Index: src/sys/net/pipex.c
diff -u src/sys/net/pipex.c:1.40 src/sys/net/pipex.c:1.41
--- src/sys/net/pipex.c:1.40Thu Mar 28 17:10:05 2013
+++ src/sys/net/pipex.c Tue Apr 16 01:36:55 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: pipex.c,v 1.40 2013/03/28 23:10:05 tedu Exp $ */
+/* $OpenBSD: pipex.c,v 1.41 2013/04/16 07:36:55 yasuoka Exp $  */
 
 /*-
  * Copyright (c) 2009 Internet Initiative Japan Inc.
@@ -520,7 +520,7 @@
 
/* remove from close_wait list */
if (session-state == PIPEX_STATE_CLOSE_WAIT)
-   LIST_REMOVE((struct pipex_session *)session, state_list);
+   LIST_REMOVE(session, state_list);
 
/* get statistics before destroy the session */
req-pcr_stat = session-stat;
@@ -579,9 +579,10 @@
while (!LIST_EMPTY(pipex_close_wait_list)) {
session = LIST_FIRST(pipex_close_wait_list);
req-plr_ppp_id[req-plr_ppp_id_count++] = session-ppp_id;
-   LIST_REMOVE((struct pipex_session *)session, state_list);
+   LIST_REMOVE(session, state_list);
+   session-state = PIPEX_STATE_CLOSE_WAIT2;
if (req-plr_ppp_id_count = PIPEX_MAX_LISTREQ) {
-   if (LIST_NEXT(session, state_list))
+   if (!LIST_EMPTY(pipex_close_wait_list))
req-plr_flags |= PIPEX_LISTREQ_MORE;
break;
}
@@ -607,18 +608,16 @@
KASSERT(rn != NULL);
}
 
-   LIST_REMOVE((struct pipex_session *)session, id_chain);
-   LIST_REMOVE((struct pipex_session *)session, session_list);
+   LIST_REMOVE(session, id_chain);
+   LIST_REMOVE(session, session_list);
 #ifdef PIPEX_PPTP
if (session-protocol == PIPEX_PROTO_PPTP) {
-   LIST_REMOVE((struct pipex_session *)session,
-   peer_addr_chain);
+   LIST_REMOVE(session, peer_addr_chain);
}
 #endif
 #ifdef PIPEX_L2TP
if (session-protocol == PIPEX_PROTO_L2TP) {
-   LIST_REMOVE((struct pipex_session *)session,
-   peer_addr_chain);
+   LIST_REMOVE(session, peer_addr_chain);
}
 #endif
/* if final session is destroyed, stop timer */
@@ -850,6 +849,7 @@
break;
 
case PIPEX_STATE_CLOSE_WAIT:
+   case PIPEX_STATE_CLOSE_WAIT2:
session-stat.idle_time++;
if (session-stat.idle_time  PIPEX_CLOSE_TIMEOUT)
continue;
Index: src/sys/net/pipex_local.h
diff -u src/sys/net/pipex_local.h:1.17 src/sys/net/pipex_local.h:1.18
--- src/sys/net/pipex_local.h:1.17  Wed Sep 19 11:50:17 2012
+++ src/sys/net/pipex_local.h   Tue Apr 16 01:36:55 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: pipex_local.h,v 1.17 2012/09/19 17:50:17 yasuoka Exp $
*/
+/* $OpenBSD: pipex_local.h,v 1.18 2013/04/16 07:36:55 yasuoka Exp $
*/
 
 /*
  * Copyright (c) 2009 Internet Initiative Japan Inc.
@@ -162,7 +162,8 @@
 #define PIPEX_STATE_INITIAL0x
 #define PIPEX_STATE_OPENED 0x0001
 #define PIPEX_STATE_CLOSE_WAIT 0x0002
-#define PIPEX_STATE_CLOSED 0x0003
+#define PIPEX_STATE_CLOSE_WAIT20x0003
+#define PIPEX_STATE_CLOSED 0x0004
 
uint16_tip_forward:1,   /* {en|dis}ableIP forwarding */
ip6_forward:1,  /* {en|dis}able IPv6 forwarding 
*/



Re: npppd, L2TP to Iphone, eap?

2013-07-02 Thread YASUOKA Masahiko
Hi,

On Sun, 30 Jun 2013 15:03:58 +
Brad Brad braddeic...@hotmail.com wrote:
 Hi, setting up npppd I get the following in the logs when connecting from 
 Iphone 5
 
 Jun 30 22:23:43 fire53 npppd[17905]: ppp id=0 layer=lcp No authentication 
 protocols are agreeable.  peer's auth proto=eap

If you just want to connect from iPhone 5, I think you could use other
authentication methods.  MS-CHAP-V2, for example.

 I saw a message saying eap was removed and will be re-added later, and Iphone 
 isn't particularly configurable. Can I suggest a different proto from the 
 server side or just keep an eye out for eap? (or run 5.2)

Are you talking about EAP with RADIUS?  Supporting it will not so
far.

--yasuoka



Re: NPPPD with intermediate LTS

2013-05-14 Thread YASUOKA Masahiko
Hi,

On Mon, 13 May 2013 15:28:38 +0100
Joe Holden li...@rewt.org.uk wrote:
 YASUOKA Masahiko wrote:
 On Wed, 08 May 2013 12:32:16 +0100
 Joe Holden li...@rewt.org.uk wrote:
 YASUOKA Masahiko wrote:
 On Tue, 07 May 2013 22:38:46 +0100
 Joe Holden li...@rewt.org.uk wrote:
 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received
 chap packet.  But chap is not started
 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received
 chap packet.  But chap is not started
 Do you have the dialin-proxy message before these messages?  If you
 have, I would like to see it.

 The only message ppp related prior to those is:

 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN
 session_id=5644 calling_number= tx_conn_speed=1000 framing=sync
 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind
 ppp=0
 Those AVPs don't seem to be requested by the LAC.
 
 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started
 tunnel=L2TP_ipv4(172.16.10.57:54189)
 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB
 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd
 broken frame.  ACFC is not accepted, but received ppp frame that has
 no address.
 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received
 chap packet.  But chap is not started
 The LAC seems to be starting CHAP without LCP.  The problem seems to
 be come from the LAC.
 If mpd has settings about proxy LCP and authentication, I would like
 you to try them.
 
 mpd doesn't have the ability to generate Proxy auth AVPs, I currently
 use both mpd and others without proxied avps, afaic it isn't breaking
 rfc to restart lcp at every point (which is how I work things
 currently)

npppd itself is in Link Establishment Phase.  As RFC 1661 section
3.4.,

|   Any non-LCP packets received during this phase MUST be silently
|   discarded.

so discarding CHAP packets from mpd should not be a problem.

But npppd doesn't start LCP actively.  I think this causes the problem
in this case.  The peer is in Authentication Phase, it must be able
to receive the LCP packets from npppd.  I attached the diff which
makes npppd start LCP actively.  Could you try the diff?

 How difficult would it be to add a config option to always restart
 lcp, or maybe just if proxied avps aren't there?

If my understanding is correct and the diff will fix the problem, it's
easy.

--yasuoka

Index: usr.sbin/npppd/npppd/lcp.c
===
RCS file: /cvs/openbsd/src/usr.sbin/npppd/npppd/lcp.c,v
retrieving revision 1.8
diff -u -p -r1.8 lcp.c
--- usr.sbin/npppd/npppd/lcp.c  18 Sep 2012 13:14:08 -  1.8
+++ usr.sbin/npppd/npppd/lcp.c  15 May 2013 02:46:28 -
@@ -122,7 +122,9 @@ lcp_init(lcp *_this, npppd_ppp *ppp)
_this-fsm.ppp = ppp;
_this-fsm.callbacks = lcp_callbacks;
_this-fsm.protocol = PPP_PROTO_LCP;
+   /*
_this-fsm.flags |= OPT_SILENT;
+*/
_this-timerctx.ctx = _this;
 
_this-recv_ress = 0;



Re: NPPPD with intermediate LTS

2013-05-09 Thread YASUOKA Masahiko
On Wed, 08 May 2013 12:32:16 +0100
Joe Holden li...@rewt.org.uk wrote:
 YASUOKA Masahiko wrote:
 On Tue, 07 May 2013 22:38:46 +0100
 Joe Holden li...@rewt.org.uk wrote:
 I'm testing out npppd as a termination device which is being fed from
 existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC
 begins LCP to challenge the client for it's username in order to
 lookup the destination LNS, npppd just repeats the following until it
 gives up:

In this case, npppd assumes the LAC is using Proxy LCP and
Authentication AVP in RFC 2661.

 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received
 chap packet.  But chap is not started
 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received
 chap packet.  But chap is not started
 Do you have the dialin-proxy message before these messages?  If you
 have, I would like to see it.
 
 The only message ppp related prior to those is:
 
 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN
 session_id=5644 calling_number= tx_conn_speed=1000 framing=sync
 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind
 ppp=0

Those AVPs don't seem to be requested by the LAC.

 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started
 tunnel=L2TP_ipv4(172.16.10.57:54189)
 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB
 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd
 broken frame.  ACFC is not accepted, but received ppp frame that has
 no address.
 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received
 chap packet.  But chap is not started

The LAC seems to be starting CHAP without LCP.  The problem seems to
be come from the LAC.

If mpd has settings about proxy LCP and authentication, I would like
you to try them.

--yasuoka



Re: NPPPD with intermediate LTS

2013-05-07 Thread YASUOKA Masahiko
Hi,

On Tue, 07 May 2013 22:38:46 +0100
Joe Holden li...@rewt.org.uk wrote:
 I'm testing out npppd as a termination device which is being fed from
 existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC
 begins LCP to challenge the client for it's username in order to
 lookup the destination LNS, npppd just repeats the following until it
 gives up:
 
 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received
 chap packet.  But chap is not started
 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received
 chap packet.  But chap is not started

Do you have the dialin-proxy message before these messages?  If you
have, I would like to see it.

 This is on a test setup currently, but mirrors the behaviour as it
 would see on a real network.
 
 If I blindly switch to npppd all is well, I've got l2tp-lcp-reneg
 enabled but it doesn't seem to make any difference, likewise with
 force.
 
 Is this known behaviour or am I missing something?

Does the config

  l2tp-accept-dialin yes

line in the `tunnel' config?

--yasuoka



Re: OpenBSD 5.3 npppd pppoe segmantation fault

2013-04-21 Thread YASUOKA Masahiko
Hi,

Thank you for your feedbacks.

On Sun, 21 Apr 2013 16:09:36 +0900
trick star freeu...@inbox.com wrote:
 I have question. npppd pppx session need the inet6?

No, it doesn't matter the inet6.

 I usually kill the interface's inet6.
 npppd pppoe connection for tun0 work.
 but, pppx0's didn't work!

I don't think it matters for this kind of problem whether npppd uses
tun or pppx.

 #server
 npppd -df /etc/npppd/npppd.conf
 2013-04-21 14:57:16:NOTICE: Starting npppd pid=21302 version=5.0.0
 2013-04-21 14:57:16:NOTICE: Load configuration
 from='/etc/npppd/npppd.conf' successfully.
 2013-04-21 14:57:16:INFO: pppx0 Started pppx
 2013-04-21 14:57:16:INFO: Listening /var/run/npppd_ctl (npppd_ctl)
 2013-04-21 14:57:16:INFO: ipcp=IPCP pool
 dyn_pool=[10.0.0.2/31,10.0.0.4/30,10.0.0.8/29,10.0.0.16/28,10.0.0.32/27,10.0.0.64/26,10.0.0.128/26,10.0.0.192/27,10.0.0.224/28,10.0.0.240/29,10.0.0.248/30,10.0.0.252/31,10.0.0.254/32]
 pool=[10.0.0.2/31,10.0.0.4/30,10.0.0.8/29,10.0.0.16/28,10.0.0.32/27,10.0.0.64/26,10.0.0.128/26,10.0.0.192/27,10.0.0.224/28,10.0.0.240/29,10.0.0.248/30,10.0.0.252/31,10.0.0.254/32]
 2013-04-21 14:57:16:INFO: Loading pool config successfully.
 2013-04-21 14:57:16:INFO: pppoed Listening on bge0 (PPPoE) [PPPOE]
 using=/dev/bpf0 address=00:11:22:33:44:55
 2013-04-21 14:57:42:INFO: pppoed RecvPADI from=aa:bb:cc:dd:ee:ff
 service-name= host-uniq=7446772e if=bge0
 2013-04-21 14:57:42:INFO: pppoed SendPADO to=aa:bb:cc:dd:ee:ff
 serviceName= acName=00:11:22:33:44:55 hostUniq=7446772e eol if=bge0
 2013-04-21 14:57:42:INFO: pppoed if=bge0 session=43717 SendPADS
 serviceName= hostUniq=7446772e
 2013-04-21 14:57:42:NOTICE: pppoed if=bge0 session=43717
 logtype=PPPBind ppp=0
 2013-04-21 14:57:42:ERR: ppp id=0 layer=base getnameinfo() failed at
 ppp_set_tunnel_label
 2013-04-21 14:57:42:INFO: ppp id=0 layer=base logtype=Started
 tunnel=PPPOE(0.0.0.0)
 2013-04-21 14:57:42:INFO: ppp id=0 layer=lcp logtype=Opened
 mru=1400/1492 auth=PAP magic=dea55c97/0632d896
 2013-04-21 14:57:42:DEBUG: ppp id=0 layer=pap pap_start
 2013-04-21 14:57:42:INFO: ppp id=0 layer=pap logtype=Success
 username=taro realm=LOCAL
 2013-04-21 14:57:42:INFO: ppp id=0 layer=base unhandled protocol
 ipv6cp, 32855(8057)
 2013-04-21 14:57:42:INFO: ppp id=0 layer=ipcp IP Address peer=0.0.0.0
 our=10.0.0.101.
 2013-04-21 14:58:15:WARNING: ppp id=0 layer=ipcp timeout sending
 Config-Requests

ppp id=0 failed to open the IPCP because npppd could not get the
response from the client.

 2013-04-21 14:58:15:INFO: ppp id=0 layer=ipcp IPCP is stopped
 2013-04-21 14:58:21:INFO: pppoed if=bge0 session=43717 SendPADT
 2013-04-21 14:58:21:ERR: ppp id=0 layer=base getnameinfo() failed at
 ppp_set_tunnel_label
 2013-04-21 14:58:21:NOTICE: ppp id=0 layer=base logtype=TUNNELUSAGE
 user=taro duration=39sec layer2=PPPOE layer2from=0.0.0.0 auth=PAP
 data_in=98bytes,7packets data_out=265bytes,20packets error_in=1
 error_out=0 mppe=no iface=pppx0

its duration was 39sec

 ^C
 2013-04-21 14:59:34:INFO: ppp id=1 layer=base unhandled protocol
 ipv6cp, 32855(8057)

The logs seem to be snipped.  ppp id=1 appeared suddenly.

 2013-04-21 14:59:34:INFO: ppp id=1 layer=base unhandled protocol
 ipv6cp, 32855(8057)
 2013-04-21 14:59:34:INFO: ppp id=1 layer=lcp terminated by peer

it was stopped by LCP terminate request from the peer.

 2013-04-21 14:59:34:INFO: pppoed if=bge0 session=48751 RecvPADT
 2013-04-21 14:59:34:INFO: pppoed if=bge0 session=48751 SendPADT
 2013-04-21 14:59:34:ERR: ppp id=1 layer=base getnameinfo() failed at
 ppp_set_tunnel_label
 2013-04-21 14:59:34:NOTICE: ppp id=1 layer=base logtype=TUNNELUSAGE
 user=taro duration=64sec layer2=PPPOE layer2from=0.0.0.0 auth=PAP
 data_in=242bytes,20packets data_out=509bytes,32packets error_in=11
 error_out=0 mppe=no iface=pppx0

its duration was 64sec.

The behavior of ppp id=0 and ppp id=1 seem to be different.  And logs
don't show any problem which can relate to the problem.  So I suspect
the problem is not caused by npppd.

If you can repeat the problem, I'd like you to get the result of the
command below

  tcpdump -pni bge0 ether proto 0x8863 or 0x8864

--yasuoka



Re: OpenBSD 5.3 npppd pppoe segmantation fault

2013-04-20 Thread YASUOKA Masahiko
Hi,

On Sat, 20 Apr 2013 01:00:14 +0900
trick star freeu...@inbox.com wrote:
 hi, I have problem in the OpenBSD -snapshots 5.3 npppd pppoe setting!
 server's npppd was down for segmantation fault. when client to attache
 the server.
 before -current version was fine. but new -snapshots is suck.
 if anyone could help my problem. please suggest for me.

npppd pppoe server has been broken since September.  I fixed the
problem on cvs and I attached the diff below.  I'd like you to apply
the diff and let me know if the diff doesn't fix your problem.

Thank you your report.

Index: pppoe/pppoed.c
===
RCS file: /cvs/src/usr.sbin/npppd/pppoe/pppoed.c,v
retrieving revision 1.11
diff -u -p -r1.11 pppoed.c
--- pppoe/pppoed.c  18 Sep 2012 13:14:08 -  1.11
+++ pppoe/pppoed.c  6 Apr 2013 01:56:29 -
@@ -470,8 +470,9 @@ pppoed_reload(pppoed *_this, struct pppo
struct ifaddrs*ifa0;
slist  rmlist, newlist;
struct {
-   char   ifname[IF_NAMESIZE];
-   char   name[PPPOED_PHY_LABEL_SIZE];
+   char ifname[IF_NAMESIZE];
+   char name[PPPOED_PHY_LABEL_SIZE];
+   struct pppoe_conf   *conf;
} listeners[PPPOE_NLISTENER];
pppoed_listener   *l;
pppoe_session *session;
@@ -493,6 +494,7 @@ pppoed_reload(pppoed *_this, struct pppo
sizeof(listeners[count].ifname));
strlcpy(listeners[count].name, conf-name,
sizeof(listeners[count].name));
+   listeners[count].conf = conf;
count++;
}
 
@@ -520,6 +522,7 @@ pppoed_reload(pppoed *_this, struct pppo
strlcpy(l-tun_name, listeners[i].name, sizeof(l-tun_name));
strlcpy(l-listen_ifname, listeners[i].ifname,
sizeof(l-listen_ifname));
+   l-conf = listeners[i].conf;
if (slist_add(newlist, l) == NULL) {
pppoed_log(_this, LOG_ERR,
slist_add() failed in %s(): %m, __func__);

Index: l2tp/l2tpd.c
===
RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tpd.c,v
retrieving revision 1.11
diff -u -p -r1.11 l2tpd.c
--- l2tp/l2tpd.c18 Sep 2012 13:14:08 -  1.11
+++ l2tp/l2tpd.c19 Apr 2013 03:19:17 -
@@ -573,8 +573,6 @@ l2tpd_reload(l2tpd *_this, struct l2tp_c
return 0;
}
 
-   if (l2tpd_init(_this) != 0)
-   return -1;
i = 0;
TAILQ_FOREACH(conf, l2tp_conf, entry)
l2tpd_add_listener(_this, i++, conf);
Index: npppd/npppd.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
retrieving revision 1.28
diff -u -p -r1.28 npppd.c
--- npppd/npppd.c   16 Apr 2013 07:42:27 -  1.28
+++ npppd/npppd.c   19 Apr 2013 03:19:20 -
@@ -286,6 +286,18 @@ npppd_init(npppd *_this, const char *con
 
_this-boot_id = (uint32_t)random();
 
+#ifdef USE_NPPPD_L2TP
+   if (l2tpd_init(_this-l2tpd) != 0)
+   return (-1);
+#endif
+#ifdef USE_NPPPD_PPTP
+   if (pptpd_init(_this-pptpd) != 0)
+   return (-1);
+#endif
+#ifdef USE_NPPPD_PPPOE
+   if (pppoed_init(_this-pppoed) != 0)
+   return (-1);
+#endif
/* load configuration */
if ((status = npppd_reload_config(_this)) != 0)
return status;
Index: pptp/pptpd.c
===
RCS file: /cvs/src/usr.sbin/npppd/pptp/pptpd.c,v
retrieving revision 1.16
diff -u -p -r1.16 pptpd.c
--- pptp/pptpd.c6 Apr 2013 17:03:51 -   1.16
+++ pptp/pptpd.c19 Apr 2013 03:19:22 -
@@ -589,8 +589,6 @@ pptpd_reload(pptpd *_this, struct pptp_c
return 0;
}
 
-   if (pptpd_init(_this) != 0)
-   return -1;
i = 0;
TAILQ_FOREACH(conf, pptp_conf, entry)
pptpd_add_listener(_this, i++, conf);



Re: npppd not communicating in 5.2

2013-03-06 Thread YASUOKA Masahiko
Hi,

On Tue, 5 Mar 2013 16:35:51 -0500
Jason Markowitz jma...@gmail.com wrote:
 I'm receiving the following errors when attempting to establish a vpn
 session via l2tp, the ipsec side works fine and phase 1 authenticates
 perfectly, i dont see pf blocking anything in pf log (egress wide
 open, inbound is set to block in log all, with holes opened for the
 appropriate ports for vpn and ssh)
 
 2013-03-05 16:26:10:NOTICE: Starting npppd pid=5729 version=5.0.0
...
 2013-03-05 16:26:19:INFO: l2tpd ctrl=1 SendSCCRP
 2013-03-05 16:26:21:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
 from=x.x.x.252.247:65028/udp tunnel_id=2/15 protocol=1.0 winsize=4
 hostname=Jasons-MacBook-Air.local vendor=(no vendorname) firm=
 2013-03-05 16:26:21:INFO: l2tpd ctrl=2 SendSCCRP

The client seems it could not receive any L2TP reply packets from
npppd.

Is there a NAT between the client and the npppd?  npppd on 5.2 doesn't
support L2TP/IPsec over NAT.  5.3 will support that.

--yasuoka



Re: current snapshot pipex kernel panic

2013-02-13 Thread YASUOKA Masahiko
On Wed, 26 Sep 2012 14:44:58 +0900 (JST)
YASUOKA Masahiko yasu...@yasuoka.net wrote:
 On Tue, 25 Sep 2012 16:16:12 +0200
 csszep css...@gmail.com wrote:
 I wanted to try a simple npppd setup and i got a panic.
 
 I'm looking into this problem and fixing it.  But it will take more
 days.

oops, I forgot about this bug

 To workaround the problem, please add
 
   mppe no
 
 to the tunnel configuration.

Can you try below diff instead of the above workaround?

Index: sys/net/pipex.c
===
RCS file: /cvs/src/sys/net/pipex.c,v
retrieving revision 1.37
diff -u -p -r1.37 pipex.c
--- sys/net/pipex.c 14 Dec 2012 01:19:26 -  1.37
+++ sys/net/pipex.c 13 Feb 2013 14:55:16 -
@@ -396,14 +396,24 @@ pipex_add_session(struct pipex_session_r
}
 #endif
 #ifdef PIPEX_MPPE
-   if ((req-pr_ppp_flags  PIPEX_PPP_MPPE_ACCEPTED) != 0)
+   if ((req-pr_ppp_flags  PIPEX_PPP_MPPE_ACCEPTED) != 0) {
+   if (req-pr_mppe_recv.keylenbits = 0) {
+   free(session, M_TEMP);
+   return (EINVAL);
+   }
pipex_session_init_mppe_recv(session,
req-pr_mppe_recv.stateless, req-pr_mppe_recv.keylenbits,
req-pr_mppe_recv.master_key);
-   if ((req-pr_ppp_flags  PIPEX_PPP_MPPE_ENABLED) != 0)
+   }
+   if ((req-pr_ppp_flags  PIPEX_PPP_MPPE_ENABLED) != 0) {
+   if (req-pr_mppe_send.keylenbits = 0) {
+   free(session, M_TEMP);
+   return (EINVAL);
+   }
pipex_session_init_mppe_send(session,
req-pr_mppe_send.stateless, req-pr_mppe_send.keylenbits,
req-pr_mppe_send.master_key);
+   }
 
if (pipex_session_is_mppe_required(session)) {
if (!pipex_session_is_mppe_enabled(session) ||
Index: usr.sbin/npppd/npppd/mppe.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/mppe.c,v
retrieving revision 1.9
diff -u -p -r1.9 mppe.c
--- usr.sbin/npppd/npppd/mppe.c 19 Dec 2012 09:23:54 -  1.9
+++ usr.sbin/npppd/npppd/mppe.c 13 Feb 2013 14:55:16 -
@@ -119,9 +119,6 @@ mppe_init(mppe *_this, npppd_ppp *ppp)
 
_this-required = conf-mppe_required;
 
-   if (_this-required == 0)
-   goto mppe_config_done;
-
if (conf-mppe_keystate == (NPPPD_MPPE_STATEFUL|NPPPD_MPPE_STATELESS)) {
/* no need to change from default. */
} else if (conf-mppe_keystate == NPPPD_MPPE_STATELESS) {
@@ -230,21 +227,21 @@ mppe_start(mppe *_this)
_this-recv.keybits = 128;
}
 
-   mppe_rc4_init(_this, _this-send, 0);
-   mppe_rc4_init(_this, _this-recv, _this-recv.stateless);
-
-   GetNewKeyFromSHA(_this-recv.master_key, _this-recv.master_key,
-   _this-recv.keylen, _this-recv.session_key);
-   GetNewKeyFromSHA(_this-send.master_key, _this-send.master_key,
-   _this-send.keylen, _this-send.session_key);
-
-   mppe_reduce_key(_this-recv);
-   mppe_reduce_key(_this-send);
-
-   mppe_rc4_setkey(_this, _this-recv);
-   mppe_rc4_setkey(_this, _this-send);
+   if (_this-send.keybits  0) {
+   mppe_rc4_init(_this, _this-send, 0);
+   GetNewKeyFromSHA(_this-send.master_key, _this-send.master_key,
+   _this-send.keylen, _this-send.session_key);
+   mppe_reduce_key(_this-send);
+   mppe_rc4_setkey(_this, _this-send);
+   }
+   if (_this-recv.keybits  0) {
+   mppe_rc4_init(_this, _this-recv, _this-recv.stateless);
+   GetNewKeyFromSHA(_this-recv.master_key, _this-recv.master_key,
+   _this-recv.keylen, _this-recv.session_key);
+   mppe_reduce_key(_this-recv);
+   mppe_rc4_setkey(_this, _this-recv);
+   }
 }
-
 
 /**
  * creating the mppe bits. In case of first proposal, it specifies the
Index: usr.sbin/npppd/npppd/npppd.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
retrieving revision 1.26
diff -u -p -r1.26 npppd.c
--- usr.sbin/npppd/npppd/npppd.c5 Dec 2012 23:20:26 -   1.26
+++ usr.sbin/npppd/npppd/npppd.c13 Feb 2013 14:55:17 -
@@ -899,19 +899,21 @@ pipex_setup_common(npppd_ppp *ppp, struc
 
 #ifdef USE_NPPPD_MPPE
req-pr_ccp_id = ppp-ccp.fsm.id;
-   memcpy(req-pr_mppe_send.master_key,
-   ppp-mppe.send.master_key, sizeof(req-pr_mppe_send.master_key));
-   req-pr_mppe_send.stateless = ppp-mppe.send.stateless;
-   req-pr_mppe_send.keylenbits = ppp-mppe.send.keybits;
-
-   memcpy(req-pr_mppe_recv.master_key,
-   ppp-mppe.recv.master_key, sizeof(req-pr_mppe_recv.master_key));
-   req-pr_mppe_recv.stateless = ppp-mppe.recv.stateless;
-   req-pr_mppe_recv.keylenbits = ppp

Re: npppd radius on current jan 21

2013-01-31 Thread YASUOKA Masahiko
On Wed, 30 Jan 2013 12:07:05 +0100
mxb m...@alumni.chalmers.se wrote:
 Yasuoka forgot to commit his fix.
 I have it working.

Oops, I forgot about that fix...

I've commited.  Also here is the diff.  Thanks,

Index: npppd_auth.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd_auth.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- npppd_auth.c22 Sep 2012 20:22:48 -  1.11
+++ npppd_auth.c31 Jan 2013 09:44:21 -  1.12
@@ -1,4 +1,4 @@
-/* $OpenBSD: npppd_auth.c,v 1.11 2012/09/22 20:22:48 espie Exp $ */
+/* $OpenBSD: npppd_auth.c,v 1.12 2013/01/31 09:44:21 yasuoka Exp $ */
 
 /*-
  * Copyright (c) 2009 Internet Initiative Japan Inc.
@@ -26,7 +26,7 @@
  * SUCH DAMAGE.
  */
 /**@file authentication realm */
-/* $Id: npppd_auth.c,v 1.11 2012/09/22 20:22:48 espie Exp $ */
+/* $Id: npppd_auth.c,v 1.12 2013/01/31 09:44:21 yasuoka Exp $ */
 #include sys/types.h
 #include sys/stat.h
 #include sys/socket.h
@@ -561,6 +561,10 @@ npppd_auth_radius_reload(npppd_auth_base
break;
memcpy(rad-server[i].peer, server-address,
server-address.ss_len);
+   if (((struct sockaddr_in *)rad-server[i].peer)-sin_port
+   == 0)
+   ((struct sockaddr_in *)rad-server[i].peer)-sin_port
+   = htons(DEFAULT_RADIUS_AUTH_PORT);
strlcpy(rad-server[i].secret, server-secret,
sizeof(rad-server[i].secret));
rad-server[i].enabled = 1;
@@ -578,6 +582,10 @@ npppd_auth_radius_reload(npppd_auth_base
break;
memcpy(rad-server[i].peer, server-address,
server-address.ss_len);
+   if (((struct sockaddr_in *)rad-server[i].peer)-sin_port
+   == 0)
+   ((struct sockaddr_in *)rad-server[i].peer)-sin_port
+   = htons(DEFAULT_RADIUS_ACCT_PORT);
strlcpy(rad-server[i].secret, server-secret,
sizeof(rad-server[i].secret));
rad-server[i].enabled = 1;
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/parse.y,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- parse.y 13 Nov 2012 17:10:40 -  1.3
+++ parse.y 31 Jan 2013 09:44:21 -  1.4
@@ -1,4 +1,4 @@
-/* $OpenBSD: parse.y,v 1.3 2012/11/13 17:10:40 yasuoka Exp $ */
+/* $OpenBSD: parse.y,v 1.4 2013/01/31 09:44:21 yasuoka Exp $ */
 
 /*
  * Copyright (c) 2002, 2003, 2004 Henning Brauer henn...@openbsd.org
@@ -677,7 +677,8 @@ radopt  : ADDRESS address optport SECRET
YYERROR;
}
n-address = $2;
-   ((struct sockaddr_in *)n-address)-sin_port = $3;
+   ((struct sockaddr_in *)n-address)-sin_port =
+   htons($3);
n-secret = $5;
TAILQ_INSERT_TAIL(curr_radconf-servers, n, entry);
}



Re: npppd with tun interface not work on i386?

2013-01-30 Thread YASUOKA Masahiko
Hi,

On Tue, 29 Jan 2013 20:20:24 +0100
csszep css...@gmail.com wrote:
 I tried to start npppd with the default config with tun0 interface on
 my Alix board:
 
 I get the following error message:
 
 # npppd -d
 2013-01-29 19:54:38:NOTICE: Starting npppd pid=13464 version=5.0.0
 2013-01-29 19:54:38:NOTICE: Load configuration
 from='/etc/npppd/npppd.conf' successfully.
 2013-01-29 19:54:38:ERR: tun0 delete ipaddress tun0 failed: Device not
 configured

This was from a bug.  I fixed it on cvs.  Please update your source
code from cvs or apply a patch below.

Thank you for your report.

Index: privsep.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/privsep.c,v
retrieving revision 1.7
diff -u -p -r1.7 privsep.c
--- privsep.c   28 Sep 2012 23:46:00 -  1.7
+++ privsep.c   31 Jan 2013 02:03:36 -
@@ -463,7 +463,7 @@ priv_get_if_addr(const char *ifname, str
struct PRIVSEP_GET_IF_ADDR_RESP  r;
 
a.cmd = PRIVSEP_GET_IF_ADDR;
-   strlcpy(a.ifname, ifname, sizeof(ifname));
+   strlcpy(a.ifname, ifname, sizeof(a.ifname));
if ((retval = send(privsep_sock, a, sizeof(a), 0))  0)
return retval;
if ((retval = recv(privsep_sock, r, sizeof(r), 0))  0) {
@@ -488,7 +488,7 @@ priv_delete_if_addr(const char *ifname)
struct PRIVSEP_DEL_IF_ADDR_ARG   a;
 
a.cmd = PRIVSEP_DEL_IF_ADDR;
-   strlcpy(a.ifname, ifname, sizeof(ifname));
+   strlcpy(a.ifname, ifname, sizeof(a.ifname));
if ((retval = send(privsep_sock, a, sizeof(a), 0))  0)
return retval;
retval = privsep_common_resp();
@@ -503,7 +503,7 @@ priv_set_if_addr(const char *ifname, str
struct PRIVSEP_SET_IF_ADDR_ARG   a;
 
a.cmd = PRIVSEP_SET_IF_ADDR;
-   strlcpy(a.ifname, ifname, sizeof(ifname));
+   strlcpy(a.ifname, ifname, sizeof(a.ifname));
a.addr = *addr;
if ((retval = send(privsep_sock, a, sizeof(a), 0))  0)
return retval;
@@ -519,7 +519,7 @@ priv_get_if_flags(const char *ifname, in
struct PRIVSEP_GET_IF_FLAGS_RESP  r;
 
a.cmd = PRIVSEP_GET_IF_FLAGS;
-   strlcpy(a.ifname, ifname, sizeof(ifname));
+   strlcpy(a.ifname, ifname, sizeof(a.ifname));
if ((retval = send(privsep_sock, a, sizeof(a), 0))  0)
return retval;
if ((retval = recv(privsep_sock, r, sizeof(r), 0))  0) {
@@ -543,7 +543,7 @@ priv_set_if_flags(const char *ifname, in
struct PRIVSEP_SET_IF_FLAGS_ARG   a;
 
a.cmd = PRIVSEP_SET_IF_FLAGS;
-   strlcpy(a.ifname, ifname, sizeof(ifname));
+   strlcpy(a.ifname, ifname, sizeof(a.ifname));
a.flags = flags;
if ((retval = send(privsep_sock, a, sizeof(a), 0))  0)
return retval;



Re: npppd as pptpdserver

2012-10-17 Thread YASUOKA Masahiko
Hi,

On Tue, 16 Oct 2012 22:29:44 +0400
pavel pocheptsov lilit-aibo...@mail.ru wrote:
 http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/npppd/Attic/HOWTO_PIPEX_NPPPD.txt?rev=1.3;content-type=text%2Fplain
(snip)
 # uname -vrp
 5.1 GENERIC.MP#188 i386

HOWTO_PIPEX_NPPPD.txt revsion 1.3 is too old for 5.1.

Did you do

 # sysctl net.pipex.enable=1

?

Please refer

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/npppd/Attic/HOWTO_PIPEX_NPPPD.txt?rev=1.8;content-type=text%2Fplain

revision 1.8 or upgrade to the latest snapshot.

--yasuoka



Re: npppd, framed_ip_address

2012-10-01 Thread YASUOKA Masahiko
On Sat, 29 Sep 2012 02:27:07 -0400
Andrew Ngo andrew@gmail.com wrote:
 On 28 September 2012 03:17, YASUOKA Masahiko
 yasu...@yasuoka.netjavascript:;
 wrote:
 On Thu, 27 Sep 2012 13:41:52 -0400
 Andrew Ngo andrew@gmail.com javascript:; wrote:
 (By the way, the daemon goes absolutely bananas if you use a
 framed-ip-address on a different subnet than those in the pool.
 Bananas! I don't recommend this error. ^^)

 npppd will assign ip address dynamically on that case.
 Can you explain your recommendation?
 
 I only managed to replicate the error using pool-address [ip4] [ip4] for
 static in the pre-patched npppd, so it's probably a result of the same
 bug. (When I said bananas, I was just talking about the deluge of
 unhandled option messages. :) Anyway, I've attached the output -- it
 looks like a consequence of npppd thinking it has no addresses to allocate.

I see,

 10:15:34:NOTICE: ppp id=0 layer=base No free address in the pool.
 10:15:34:NOTICE: ppp id=0 layer=base No free address in the pool.
 10:15:35:INFO: ppp id=0 layer=base unhandled protocol ipv6cp, 32855(8057)
 10:15:35:INFO: ppp id=0 layer=ccp CCP is stopped
 10:15:35:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10
 10:15:36:DEBUG: ppp id=0 layer=ipcp Unhandled Option 01 10

Because npppd could not allocate any ip address, iOS fallbacked to use
old options of IPCP.  The messages are to complain for the old
options.

Thank you for your report.

--yasuoka



Re: npppd, framed_ip_address

2012-09-28 Thread YASUOKA Masahiko
Hi,

On Thu, 27 Sep 2012 13:41:52 -0400
Andrew Ngo andrew@gmail.com wrote:
 Hm. I can't seem to get npppd to map users to static addresses in the
 npppd-users file, after trying various permutations of pool-address
 ##-## for static and such. The client is an iPhone running iOS 6.0,
 and is definitely able to set up a working vpn over l2tp/ipsec with
 the npppd server (many thx, btw), but the client is then always
 assigned a random address from the pool (and never the static one,
 incidentally... but that could just be chance).
 
 Did I screw something up in the configuration or has this particular
 feature not been implemented yet? Has anyone else had troubles with
 this?

The feature was broken by the my configuration syntax change work.
Thank you for your report.  Attached diff will fix the problem.

 (By the way, the daemon goes absolutely bananas if you use a
 framed-ip-address on a different subnet than those in the pool.
 Bananas! I don't recommend this error. ^^)

npppd will assign ip address dynamically on that case.
Can you explain your recommendation?

Index: npppd.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
retrieving revision 1.23
diff -u -p -r1.23 npppd.c
--- npppd.c 20 Sep 2012 20:28:09 -  1.23
+++ npppd.c 28 Sep 2012 07:01:14 -
@@ -1545,6 +1545,7 @@ npppd_assign_ip_addr(npppd *_this, npppd
goto dyna_assign;
return 1;
}
+   ppp-assigned_pool = pool;
 
ppp-ppp_framed_ip_address.s_addr = htonl(ip4);
ppp-ppp_framed_ip_netmask.s_addr = htonl(ip4mask);
Index: privsep.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/privsep.c,v
retrieving revision 1.6
diff -u -p -r1.6 privsep.c
--- privsep.c   18 Sep 2012 13:14:08 -  1.6
+++ privsep.c   28 Sep 2012 07:01:14 -
@@ -447,6 +447,9 @@ priv_get_user_info(const char *path, con
n = strlcpy(cp, r.calling_number, sz);
cp += ++n; sz -= n;
 
+   u-framed_ip_address = r.framed_ip_address;
+   u-framed_ip_netmask = r.framed_ip_netmask;
+
*puser = u;
 
return 0;
@@ -731,6 +734,8 @@ privsep_priv_on_sockio(int sock, short e
 
a = (struct PRIVSEP_GET_USER_INFO_ARG *)rbuf;
memset(r, 0, sizeof(r));
+   r.framed_ip_address.s_addr = INADDR_NAS_SELECT;
+   r.framed_ip_netmask.s_addr = INADDR_NONE;
db[0] = a-path;
 
if (privsep_npppd_check_get_user_info(a)) {



Re: current snapshot pipex kernel panic

2012-09-25 Thread YASUOKA Masahiko
Hello,

On Tue, 25 Sep 2012 16:16:12 +0200
csszep css...@gmail.com wrote:
 I wanted to try a simple npppd setup and i got a panic.

I'm looking into this problem and fixing it.  But it will take more
days.

To workaround the problem, please add

  mppe no

to the tunnel configuration.

--yasuoka



Re: Microsoft Wireless Mobile Mouse 3500

2012-09-24 Thread YASUOKA Masahiko
On Mon, 24 Sep 2012 15:45:15 -0700
Justin Lindberg justin.lindb...@gmail.com wrote:
 I recently bought a Microsoft Wireless Mobile Mouse 3500, and I assumed
 it would work like most any other mouse on OpenBSD.  Unfortunately it
 did not.  After googling, I found a patch on the following page,
 which again unfortunately seems down at the moment, and moreover it's in
 Japanese, of which I don't understand a word:
 
 http://yasuoka.net/~yasuoka/hack-2012.html
 
 At first I thought the patch was working perfectly in an amd64 otherwise
 generic MP kernel, but the mouse has a tendency to slow down and
 become unresponsive over time, and then I have to power-cycle the mouse
 itself in order to get it to work again.
 
 I'm inclined to think it's just a piece of junk, but is there any hope
 to support this mouse, or should I simply avoid all Microsoft mice?

The patch is for myself.  It fixes the problem of my laptop.

I already sent the patch to yuo@.  I heard from him the mouse doesn't
work because openbsd cannot read the usb hid descriptors properly and
it is not easy to fix.  He is trying to fix that.

--yasuoka



Re: npppd and iOS 5.1.1 on OpenBSD 5.1

2012-08-15 Thread YASUOKA Masahiko
Hi,

 real.local.concentrate: tun0

this should be 

  realm.local.concentrate: tun0

I hope this will help you.

--yasuoka

On Wed, 15 Aug 2012 09:11:06 -0700
Johan Beisser j...@caustic.org wrote:
 I've hit a bit of a wall digging around getting L2TP working with OpenBSD 5.1.
 
 I've enabled pipex in kernel:
 # sysctl -a | grep -E '(pipex|gre)'
 net.inet.gre.allow=0
 net.inet.gre.wccp=0
 net.pipex.enable=1
 
 Before anyone asks, yes, I had GRE enabled as well. But, I'm not
 looking to run PPTP via npppd, only L2TP. I've tested with it
 activated, and the config with pptpd.enabled: false
 
 I've configured a very basic npppd.conf, per the instructions in
 http://www.undeadly.org/cgi?action=articlesid=20120427125048 and
 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/npppd/HOWTO_PIPEX_NPPPD.txt?rev=1.8
 
 Everything connects, it appears to authenticate fine, but after that
 iOS attempts to negotiate ppp. I'm assuming this is the relevant part
 of the npppd debugging output (for my own privacy, I've replaced
 non-RFC addresses with A.B.C.D for the client and E.F.G.H for the
 server, respectively):
 
 2012-08-15 08:37:03:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
 from=A.B.C.D:50002/udp tunnel_id=2/21 protocol=1.0 winsize=4
 hostname=users-thing vendor=(no vendorname) firm=
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 SendSCCRP
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 RecvSCCN
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 SendZLB
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 call=9490 RecvICRQ session_id=948
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 call=9490 SendICRP session_id=9490
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 call=9490 RecvICCN
 session_id=948 calling_number= tx_conn_speed=100 framing=async
 2012-08-15 08:37:03:NOTICE: l2tpd ctrl=2 call=9490 logtype=PPPBind ppp=1
 2012-08-15 08:37:03:INFO: ppp id=1 layer=base logtype=Started
 tunnel=L2TP(A.B.C.D:50002)
 2012-08-15 08:37:03:INFO: l2tpd ctrl=2 call=9490 SendZLB
 2012-08-15 08:37:22:INFO: ppp id=1 layer=lcp logtype=Opened
 mru=1400/1400 auth=MS-CHAP-V2 magic=3adadd39/37d59f4b
 2012-08-15 08:37:22:INFO: ppp id=1 layer=chap proto=mschap_v2
 logtype=Success username=user realm=local
 2012-08-15 08:37:22:WARNING: ppp id=1 layer=base No interface binding.
 2012-08-15 08:37:22:INFO: ppp id=1 layer=base unhandled protocol
 ip6cp, 32855(8057)
 2012-08-15 08:37:22:INFO: l2tpd ctrl=2 call=9490 SendCDN
 result=ERROR_CODE/2 error=GENERIC_ERROR/6 messsage=Disconnected by
 local PPP
 2012-08-15 08:37:22:NOTICE: l2tpd ctrl=2 call=9490 logtype=PPPUnbind
 2012-08-15 08:37:22:NOTICE: ppp id=1 layer=base logtype=TUNNELUSAGE
 user=user duration=19sec layer2=L2TP layer2from=A.B.C.D:50002
 auth=MS-CHAP-V2 data_in=271bytes,12packets data_out=333bytes,15packets
 error_in=1 error_out=0 mppe=no iface=(not binding)
 2012-08-15 08:37:22:INFO: l2tpd ctrl=2 call=9490 Received CDN in
 unexpected state=cleanup-wait
 2012-08-15 08:37:22:INFO: l2tpd ctrl=2 RecvStopCCN result=UNKNOWN/256
 error=UNKNOWN/28261 tunnel_id=21 message=cted
 2012-08-15 08:37:22:DEBUG: l2tpd ctrl=2 SendZLB
 2012-08-15 08:37:22:NOTICE: l2tpd ctrl=2 logtype=Finished
 2012-08-15 08:37:23:INFO: l2tpd Received from=A.B.C.D:42138: bad
 control message: tunnelId=2 is not found.  mestype=CDN
 
 
 Isakmpd does throw some errors, but they don't seem to be related to
 anything except protocol negotiation.
 
 Aug 15 08:37:00 soekris isakmpd[1079]: attribute_unacceptable:
 ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
 Aug 15 08:37:02 soekris isakmpd[1079]: isakmpd: phase 1 done (as
 responder): initiator id 10.70.108.213, responder id E.F.G.H, src:
 A.B.C.D dst: A.B.C.D
 Aug 15 08:37:02 soekris isakmpd[1079]: isakmpd: quick mode done (as
 responder): src: E.F.G.H dst: A.B.C.D
 
 
 It acts the same if pf is enabled or disabled. I'm debating if I
 should update to a snapshot or not, at this point. Due to the hardware
 being weak, and kind of old, I'd rather not have the debugging flags,
 etc, running a snapshot would entail.
 
 Any pointers on where to look would be appreciated.
 
 -jb
 
 
 npppd.conf:
 
 interface_list: tun0
 interface.tun0.ip4addr: 172.23.0.1
 
 # IP Address Pool
 pool.dyna_pool: 172.23.0.0/25
 pool.pool:  172.23.0.128/25
 
 # local file auth
 auth.local.realm_list:  local
 auth.local.realm.acctlist:  /etc/npppd/npppd-users.csv
 real.local.concentrate: tun0
 
 lcp.mru:1400
 lcp.timeout:18
 auth.method:mschapv2
 # auth.method:  mschapv2 chap pap
 ipcp.assign_fixed: true
 ipcp.assign_userselect:true
 
 pptpd.enabled:  false
 pptpd.ip4_allow:0.0.0.0/0
 #pptpd.listener_in: PPTP 192.168.0.1
 
 # L2TP daemon
 l2tpd.enabled:  true
 l2tpd.ip4_allow:0.0.0.0/0
 #l2tpd.listener_in: L2TP 192.168.0.1
 l2tpd.purge_ipsec_sa:   false
 l2tpd.require_ipsec:true
 l2tpd.accept_dialin:   

Re: npppd with EAP-TLS for PPTP

2012-03-01 Thread YASUOKA Masahiko
Hi,

On Wed, 29 Feb 2012 12:52:40 +0100
Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote:
 since there is the limitation in npppd that it doesn't support multiple 
 clients behind the same NAT host for IPSec/L2TP, I'm looking 
 into using PPTP with EAP-TLS authentication. But I'm wondering, whether this 
 is supported by npppd.
 The examples in the HOWTO_PIPEX_NPPPD.txt only use mschapv2 and chap with the 
 local authentication.
 When I'd use radius authentication, would it be possible to use EAP-TLS then?
 
EAP support of npppd was deleted.

  http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/npppd/npppd/Attic/eap.c

I want to write eap.c again, but it is a later item in my TODOs.

--yasuoka



Re: linux stronswan/xl2tpd client to IPSec/npppd

2012-01-19 Thread YASUOKA Masahiko
On Thu, 19 Jan 2012 14:10:03 +0100
Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote:
 On Thursday, January 19, 2012 02:23 CET, YASUOKA Masahiko 
 yasu...@yasuoka.net wrote: 
 On Thu, 19 Jan 2012 02:14:48 +0900 (JST)
 YASUOKA Masahiko yasu...@yasuoka.net wrote:
  To enable 'pppx mode', add
  
pppx_mode: true
  
  to /etc/npppd/npppd.conf. 
 
 Sorry, above example was wrong.  To test `pppx mode'
 
 (1) create /dev/pppx0
 % cd /dev
 % sudo sh MAKEDEV pppx
 (2) replace from `tun0' to `pppx0' in /etc/npppd/npppd.conf
 (3) add interface.pppx0.pppx_mode: true to /etc/npppd/npppd.conf
 
 I tried this pppx mode on my OBSD VM, together with the Linux client, but it 
 doesn't establish the connection:
 
 - I created the pppx device as explained above
 - edited npppd.conf:
 
 #interface_list: tun0
 #interface.tun0.ip4addr: 10.66.66.1
 interface_list: pppx0
 interface.pppx0.ip4addr: 10.66.66.1
 interface.pppx0.pppx_mode:   true
 ...

Do you have

  realm.local.concentrate:pppx0

line correctly?

 2012-01-19 13:39:03:INFO: ppp id=0 layer=chap proto=mschap_v2
   logtype=Success username=user1 realm=local
 2012-01-19 13:39:03:WARNING: ppp id=0 layer=base No interface binding.

npppd failed to find a interface for the user of the realm.

--yasuoka



Re: linux stronswan/xl2tpd client to IPSec/npppd

2012-01-18 Thread YASUOKA Masahiko
Hello,

On Tue, 17 Jan 2012 11:57:07 +0100
Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote:
 npppd doesn't implement AVP38, but reading the RFC, it seems, since
 its not mandatory, that should not be a problem.
 xl2tpd is wrong, requiring AVP 38 as mandatory.

I belive this is a bug of xl2tpd, but I think npppd should continue to
establish a L2TP session in this case.  I'll fix this soon.

 After the client got its IP address, it can access the VPN server
 via the tunnel.  But how to access hosts behind the tunnel endpoint?
 I wonder how to tell the client about routes?

If you want to setup a route to an address/mask automaticaly on
establish PPP link, you can use Framed-IP-Address and
Framed-IP-Network attribute to /etc/npppd/npppd-users.csv or setup
them your RADIUS server.

In usr.sbin/npppd/HOWTO_PIPEX_NPPPD.txt:
|[npppd-users.csv]
|  - First line of the CSV is *IGNORED*.  It is treated as a title line.
|---
|Username,Password,Framed-IP-Address,Framed-IP-Netmask,Description,Calling-Id
|user1,user1's secret,10.0.0.129,,memo for user1
|---

If you want more routes, npppd cannot setup them automatically.  But
if npppd will support Framed-Route attribute, it will help this issue.

In addition to, as the default, npppd concentrates a lot of PPP
sessions to one interface.  Because of this design, you can not add
extra routes by hand using route(8) command.

If you don't like this limitation, you can use 'pppx mode'.  In 'pppx
mode' npppd will create a pppx interface for each PPP session.  You
can add any routes to the interface.  To enable 'pppx mode', add

  pppx_mode: true

to /etc/npppd/npppd.conf. 

 Is the isakmpd responsible to set this up prior the L2TP
 authentication, and this has to be configured in the ipsec.conf?

No, IKE and IPsec are used only for outer of the PPP tunnel.

 have routes to be pushed via npppd when it gives the IP to the
 client, like OpenVPN is doing it?
 Or something else, i.e. the client must know what to access behind
 the VPN and setup routes on its own?

As I mentioned above, I think npppd can do the same things that
OpenVPN can do by the way we go.

--yasuoka



Re: linux stronswan/xl2tpd client to IPSec/npppd

2012-01-18 Thread YASUOKA Masahiko
Hi,

On Thu, 19 Jan 2012 02:14:48 +0900 (JST)
YASUOKA Masahiko yasu...@yasuoka.net wrote:
 On Tue, 17 Jan 2012 11:57:07 +0100
 Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote:
 If you don't like this limitation, you can use 'pppx mode'.  In 'pppx
 mode' npppd will create a pppx interface for each PPP session.  You
 can add any routes to the interface.

Unfortunately the ingress filter of `pipex' drops all these packets.
It's always on by default and not configurable.  It should be
configurable, but it is not implemented yet.

 To enable 'pppx mode', add
 
   pppx_mode: true
 
 to /etc/npppd/npppd.conf. 

Sorry, above example was wrong.  To test `pppx mode'

(1) create /dev/pppx0
% cd /dev
% sudo sh MAKEDEV pppx
(2) replace from `tun0' to `pppx0' in /etc/npppd/npppd.conf
(3) add interface.pppx0.pppx_mode: true to /etc/npppd/npppd.conf

--yasuoka



Re: NPPPD/L2TP IPsec problems

2011-12-18 Thread YASUOKA Masahiko
Hi,

On Fri, 16 Dec 2011 15:38:14 +0200
lilit-aibolit lilit-aibo...@mail.ru wrote:
 29.09.2011 16:30, YASUOKA Masahiko P?P8QP5Q:
 On Mon, 26 Sep 2011 15:20:50 +0200
 Martin Poulsenmar...@dividebyzero.dk  wrote:
 This is my setup:

 client (Windows XP)  NAT - internet - OpenBSD (public IP)

 npppd L2TP/IPsec with NAT-T is not supported yet.

 We need 3 more hacks.

1. support FQDN identifier type on isakmpd
2. ignore UDP checksum to pass L2TP messages.  (checksums is broken
   by IPsec transport mode)
3. npppd must be able to send a L2TP message to different peer
   behind NAT by socket API.  (API is not fixed yet.)

 1. and 2. are `just do it' task.  But 3. may take time.
 I'll start to discuss this on tech@.
 
 Do you have any progress in that?

1. and 2. are fixed in -current.  Now *one* Windows box from behind a
NAT box can connect npppd.

Please wait about 3.  (Multiple clients still can not connect npppd
from behind the same NAT box.)

--yasuoka



Re: NPPPD/L2TP IPsec problems

2011-09-29 Thread YASUOKA Masahiko
On Mon, 26 Sep 2011 15:20:50 +0200
Martin Poulsen mar...@dividebyzero.dk wrote:
 I have been playing around a little with the npppd daemon having setup a
 L2TP server for test and learning purposes. The connection is running in
 an IPsec tunnel and it works great and runs very fine when used on a
 local network.
 
 But I'm having problems when it comes to NAT.
 
 This is my setup:
 
 client (Windows XP)  NAT - internet - OpenBSD (public IP)

npppd L2TP/IPsec with NAT-T is not supported yet.

We need 3 more hacks.

  1. support FQDN identifier type on isakmpd
  2. ignore UDP checksum to pass L2TP messages.  (checksums is broken
 by IPsec transport mode)
  3. npppd must be able to send a L2TP message to different peer
 behind NAT by socket API.  (API is not fixed yet.)

1. and 2. are `just do it' task.  But 3. may take time.
I'll start to discuss this on tech@.

Thanks,

--yasuoka



Re: npppd as L2TP client

2011-09-27 Thread YASUOKA Masahiko
On Mon, 26 Sep 2011 22:22:13 -0700 (PDT)
Matt S maschwa...@yahoo.com wrote:
 Is it possible to use npppd as an L2TP client or in a configuration
 where both vpn endpoints are OpenBSD based? Thank you in advance.

No, currently npppd supports server side only.

--yasuoka



Re: npppd OpenBSD 5.0

2011-09-20 Thread YASUOKA Masahiko
Hello,

I'm a maintainer of npppd.

On Tue, 20 Sep 2011 14:51:52 +0200
wessels wessels...@gmail.com wrote:
 I did a test install of OpenBSD 5.0 and noticed that npppd is present
 in the source tree but isn't compiled nor installed.
 I rebuild everything using yesterdays sources from CVS. A manual build
 and installation as described in HOWTO_PIPEX_NPPPD.txt does build and
 install npppd.
 Is npppd not included by design? If so, why?

There are 2 things to do for npppd.

  1. rewrite configuration parser.
  2. write man pages.

I hope to do these tasks before 5.1.

 Second I noticed that only the man page for npppdctl is present. The
 npppd and npppd.conf man pages are not present yet.Hmm, is this the
 anwer to my first question??

Yes, that is one of reasons.

--yasuoka



Re: LAC LNS server with OpenBSD

2011-08-18 Thread YASUOKA Masahiko
Hi,

On Thu, 18 Aug 2011 13:11:19 +0200
Andre Keller a...@list.ak.cx wrote:
 Am 18.08.2011 07:51, schrieb YASUOKA Masahiko:
 npppd supports `LNS' only and it supports `compulsory tunnel' (or
 `accept dialin').  So currently npppd can become `R3' on above picture
 but it can not become `R2'.

 To enable `accept-dialin' on npppd, please add below line to
 npppd.conf.

   l2tp.accept_dialin: true
 
 is there radius support for npppd? (looking in the sourcecode shows that
 a least some radius parts are implemented)

Yes.  Latest version of usr.sbin/npppd/HOWTO_PIPEX_NPPPD.txt includes
sample setting of radius like below:

  # RADIUS authentication / accounting
  #auth.radius.realm_list:radius
  #auth.radius.realm.server.address:  127.0.0.1:1812
  #auth.radius.realm.server.secret:   hogehoge
  #auth.radius.realm.acct_server.address: 127.0.0.1:1813
  #auth.radius.realm.acct_server.secret:  hogehoge
  #realm.radius.concentrate:  tun0

 If there is support can some documentation about usage be found anywhere?

Not yet.

The configuration part of `npppd' will be re-written with OpenBSD
parse.y style.  Then npppd.conf(7) will be provided after that.

Thanks, 

--yasuoka



  1   2   >