reg:Contribution

[Amrutanshu Tripathy]

I am willing t contribute in development.

Kindly guide.

Re: Last version of of citrix Client core dumps (Was Re: How to run Microsoft Internet Explorer on NetBSD?)

[Patrick Welche]

On Fri, Feb 26, 2016 at 04:11:53PM +, Christos Zoulas wrote:
> In article <20160226154046.ga1...@quark.internal.precedence.co.uk>,
> Patrick Welche   wrote:
> >On Fri, Feb 26, 2016 at 02:30:21PM +0100, Stephan wrote:
> >> The assembly looks like junk and considering the adresses, you have
> >> tried to disassemble some memory on the stack. Is this a 64-bit wfica
> >> binary?
> >
> 
> I commented out the x86_64 restriction and it runs on amd64/current.
> At least it brings up a window saying it needs me to specify application
> servers which I don't have any...

Indeed - it runs, but once you actually start using a connected socket
recvmsg ends up returning errno 35 Resource temporarily unavailable
until the timer SEGVs it.

P

Re: "No route to host" in Alpine

[Swift Griggs]

On Wed, 2 Mar 2016, Marco Beishuizen wrote:

Could be I don't know. Is there a way to make try NetBSD IPv4 first?


I'm not sure there is any way to change that. Something like
"ifconfig  inet6 down" might be cool, but doesn't work. It'll take 
down the whole interface (including ipv4).


What you could do, just to be sure, is compile a custom kernel without any 
ipv6 support in it.


-Swift

Re: Netbsd xenserver

[Stephen Borrill]

On Mon, 29 Feb 2016, Siyar Erdemli wrote:

29 ??ub 2016 11:08 tarihinde "Stephen Borrill" 
yazd??:


On Sat, 27 Feb 2016, Siyar Erdemli wrote:


Hi. I want to use NetBSD7 on xenserver 6.5. But , ffs journaling not
working. When journaling turned off performance degrades dramatically



Are you doing this paravirtualised, i.e. with XEN3_DOMU as a kernel?

--
Stephen


Hi. Yes stephen.  We use a XEN3_DOMU kernel. And pf firewall support. But i
use the ffs,log for root partition ,
*xbd0**: WARNING: cache flush not supported by backend*

And i use ffs without log , its working. But performance is very poor.


What's the underlying storage for the XenServer storage repository? I get 
good performance on all of our PV VMs on XenServer.


Can you run benchmarks/bonnie on it?

--
Stephen

Re: DRM issues with Xorg and intel

[BERTRAND Joël]

Riccardo Mottola a écrit :

Hi,

I am running 7.0 (full dmesg below) and I noticed that my video card has
bad performance and often worden its performance when e.g. browsing. I
noticed these errors in the console:

DRM error in intel_pipe_set_base: pin & fence failed
DRM error in intel_pipe_set_base: pin & fence failed
DRM error in intel_pipe_set_base: pin & fence failed
DRM error in i8xx_irq_handler: pipe B underrun
DRM error in i8xx_irq_handler: pipe B underrun


Hello,

	I have seen some issues with netbsd-7 and intel drm. I have opened a PR 
a long time ago without any answer. In my case, when DPMS blanks screen, 
CPU receives interrupt flood (40k by second if I remember).


Regards,

JKB

Re: Simple IPSEC client with certificate - phase 1 time out

[Frank Wille]

Thor Lancelot Simon wrote:

> Consider disabling dead peer detection?

Yes, tried that. The only difference is that "racoonctl vc 1.2.3.4" does not
return, as it never realizes that the VPN server is dead.

Otherwise the Lancom still terminates my connection after 30s.

-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

[Frank Wille]

Brett Lymn wrote:

> Well, there is a chance that the negotiation was failing due to packets
> not going where you expect.  That doesn't appear to be happening but
> checking the simple things can't hurt and can save a lot of grief :)

Sure. I will do what I can. Thanks for your detailed analyzation, BTW.


>> [VPN-Status] 2016/03/01 11:52:07,121
>> IKE info: Phase-1 [responder] for peer VPNCLIENT15EF90 initiator id
>> [...]
>
> This is good - we have a phase 1 done here, note the initiator and
> responder cookies match the SPI numbers from the NetBSD side.  Looking
> good at this point.

Besides that IKE mode config is not requested by the NetBSD client, although
explicitely stated in the racoon.conf.


>> [VPN-Status] 2016/03/01 11:52:27,223
>> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer
>> VPNCLIENT15EF90 Seq-Nr 0xe8, expected 0xe8
>
>> 
>> [VPN-Status] 2016/03/01 11:52:27,224
>> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer
>> VPNCLIENT15EF90, sequence nr 0xe8
>
>
> OK and here is where things fall apart.  The client sends an "are you
> there" request and vpn server sends a reply but it seems like the
> packet did not get through and then things go bad from there...

What makes you think so? Looking at the tcpdump directly from the NetBSD
client shows that the ACK from the Lancom router arrived (those were the
only packets at 11:52:27):

11:52:27.567012 IP 192.168.1.5.4500 > 1.2.3.4.4500: NONESP-encap: isakmp:
phase 2/others I inf[E]
11:52:27.609318 IP 1.2.3.4.4500 > 192.168.1.5.4500: NONESP-encap: isakmp:
phase 2/others R inf[E]

IMHO, DPD works fine.


>> [VPN-Status] 2016/03/01 11:52:37,096
>> VPN: connection for VPNCLIENT15EF90 (91.56.237.127) timed out: no
>> response

BTW, this timeout is always 30 seconds after phase1 has been established. No
matter what I do. With of without DPD. With or without mode_cfg.


> OK so what we can see here is that there seems to be some packet loss
> that is causing the NetBSD client to wait for an answer but during that
> time the vpn server decides nothing is happening and tears the
> connection down.  So, some things to consider:

I'm not so sure about that packet loss. The only possible packet loss, which
Greg already noticed in a parallel thread on tech-net, seems to be with
NAT-T keepalive. But a test with a working Windows client using the same
certificate on the same LAN showed that those keepalive messages are not
replied either.


> 0) How reliable is the internet connection on the client side?  It
> seems these days there is an assumption the connection is fast.

ADSL with approx. 6 MBit down and 1 MBit up. But our DSLAM is already
capable of 50 or 100 MBit, and only 30m away.

I do not remember having any reliability problems.


> 1) Since one side is doing NAT-T, do you have port forwarding on the
> router so that the IKE packets (udp 500 and 4500) are forwarded back to
> the vpn client?  Though it seems you must already have this right to
> get the phase 1 done...

That's an interesting question. No, I don't have port forwarding enabled. Do
I really need that? I thought one of the reasons for using NAT-T is to work
around such problems?

But, as you said, I see UDP 500 and 4500 packets coming through on both
sides, and the Windows client is working over the same router. So I guess
everything is fine...


> 2) any firewall rules blocking the incoming traffic?  Again, just check
> though it doesn't make much sense give you have managed to get so far
> along.

My home router is a Soekris running NetBSD. A few days ago I added the
following ipf rules:

pass in quick proto 4 from any to any  
pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto udp from any port = 500 to any port = 500  
pass in quick proto udp from any port = 4500 to any port = 4500
pass out quick proto 4 from any to any  
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto udp from any port = 500 to any port = 500  
pass out quick proto udp from any port = 4500 to any port = 4500

But I don't think they are required, as the Windows VPN-client worked
without. Now I did:

pass in from any to any
pass out from any to any

...for a test. But it didn't change anything. So I don't think there is a
firewall problem.


> 3) some firewalls/routers don't like large udp packets, there are some
> racoon settings for fragmenting packets - perhaps you need those.

I already had "ike_frag on" in my config. Now I also added "esp_frag 552",
without making any difference.

My current racoon.conf:

path include "/etc/racoon";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

# "log" specifies logging level.  It is followed by either "notify", "debug"
# or "debug2".
log debug;

#timer
#{
#   natt_keepalive 15 seconds;
#}

remote "wpsd"
{
remote_address 1.2.3.4;
exchange_mode main,base;

my_identifier asn1dn;

Re: nVidia vs NetBSD v7 resolving issue.

[Mike]

On Wed, Mar 02, 2016 at 08:35:42AM +0330, Mohammad Badie Zadegan wrote:
BTW, I'm also using OpenBSD, as my second OS on "main" computer)) It
is good system, of course but there is no framebuffer at all in
openbsd(((
> Hi Mike,
> First of all I tried with default config of last release but it did not 
> worked!
> At now I switched to OpenBSD with no issue and run X with vesa good.
> Thanks for your Help too.
> Regards.
> 
> Sent from my iPhone
> 
> > On Mar 2, 2016, at 3:02 AM, Mike  wrote:
> > 
> >> On Fri, Feb 26, 2016 at 05:54:49PM +0330, Mohammad Badie Zadegan wrote:
> >> I set vesa 0x118 mode in boot prompt and I saw the boot process was change 
> >> visiblity to new mode but still errored me (EE) No Device detected.
> >> BTW, I didn't use current version.
> >> Is that I must use current version for vesa?
> >> 
>  On Feb 26, 2016, at 3:23 PM, Roy Bixler  wrote:
>  
>  On Fri, Feb 26, 2016 at 06:56:17AM +0330, Mohammad BadieZadegan wrote:
>  Yes, the main reason is that nVidia did not handle its source code.
>  How i can try booting from vesa framebuffer?
>  Which NetBSD image produce with vesa framebuffer defaultly?
>  Thanks for your attention.
> >>> 
> >>> From the boot prompt.  Try a "man boot" to see the commands.  One of the
> >>> commands is "vesa" and you can do "vesa list" to see which modes are
> >>> available.
> >>> 
> >>> -- 
> >>> Roy Bixler 
> >>> "The fundamental principle of science, the definition almost, is this: the
> >>> sole test of the validity of any idea is experiment."
> >>> -- Richard P. Feynman
> > Hi Mohammad... I guess you don't need current... First of all - did you
> > try to start X without config at all?? Most probably you just have to
> > specify the right BUSID in xorg.conf I'm using similar configuration
> > - framebuffer mode+nvidia cards+Xorg... It works with both nv and
> >  vesa(I'm not sure about vesa... I do not remember exactly) and wsfb
> > drivers! But when using your own xorg.conf you should specify slightly
> > different BusID's with different drivers...) Can you send your
> > Xorg.0.log, then running X --configure/ startx with config( pls also attach
> > your video device section of config)/ startx w/out config / Xorg
> > -logverbose 4 /)??
> > I've had 1680x1050 resolution in both console and X(using nv driver -
> > it's better... but before I've had to use wsfb, because I couldn't
> > understand for a long time, how to make this works "right"... finnaly
> > i've found running X with wsfb driver had too many flaws...and figured
> > out about this part of configuration...)
> > So I think I can help you, if you will still have problems, after the
> > above actions...)
> > 

-- 
Cool signature, or maybe script, fortune, etc...