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

[Brett Lymn]

On Wed, Mar 02, 2016 at 12:40:30PM +0100, Frank Wille wrote:
> >
> > 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.
> 

Because racoon says that it didn't receive the ack from the lancom -
either it received the packet and didn't like it or racoon didn't see it
for some reason.  It is good that the packet made it all the way back,
it would be better if we could understand what, if anything, racoon did
with it.

> 
> >> [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.
> 

Right, that is the lancom losing patience and tearing down its side of
the connection.

> 
> > 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.
> 

Well, let's say packet loss from the point of view of racoon, ipsec can
be very sensitive to lossy networks so it is good the eliminate that as
a cause.  The test with the windows client is valuable, it shows that
ipsec can work from where you are.  As for the keep alives, the handling
of those depends on the client and/or its configuration - maybe the
windows client is configured to ignore the keep alives?

> 
> > 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.
> 

Good - another thing we can tick off as not being a cause.

> 
> > 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?
> 

Yes, I think you are correct... my flaky memory is probably throwing
that up because I was running a vpn server behind a NAT and had to do
the port forwarding.  As you have stated, NAT-T is supposed to work
around those issues.

> 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...
> 

Yes, at a network infrastructure level it seems so given that the
windows client just works.

> 
> 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.
> 

OK, that sounds like it eliminates a firewall issue.

> 
> > 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.
> 

Try dropping the esp_frag to, say, 352 just to see what happens.  I know
the man page says 552 should be safe but that seems a bit close to the
minimum mtu which is 576.  At least a very low frag value will eliminate
the possibility of the packet getting fragmented.  Also, does the NetBSD
client network interface have any tcp checksum offload turned on?

> My current racoon.conf:
> 

That all looks fairly sensible to me...

> 
> Unfortunately "log debug" doesn't work at all. I get no debug messages out
> of racoon.
> 

I do recall being able to get logging out of racoon.  Have you tried
running racoon in the foreground (i.e. using the -F flag along with
multiple -d) also have you used the -l flag to log to a file instead of
syslog?

> Also I'm getting doubt whether 

Re: Would Raspberry Pi 3's wifi be supported by NetBSD arm port?

[Christof Meerwald]

On Thu, Mar 03, 2016 at 11:39:55AM +, Nick Hudson wrote:
> On 03/03/16 05:33, Mayuresh wrote:
> >The specs say that pi 3 maintains a backward compatibility.
> >
> >https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/
> >
> >So I am hoping that arm port might work out of the box.
> Not quite... I have one and I'm getting close to making it work.

I am assuming you are "only" talking about 32 bit... Are there any
plans for 64 bit ARM support at all?


Christof

-- 

http://cmeerw.org  sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org   xmpp:cmeerw at cmeerw.org

Re: bta2dpd - advanced audio distribution profile bluetooth daemon IMPROVED

[Swift Griggs]

On Fri, 4 Mar 2016, Nathanial Sloss wrote:

Call for testers of the next installment of bta2dpd.


Yay! Nice one. I'll test it out this week. It looks fun.

It allows you to stream music or pad(4) output to bluetooth stereo 
headphones or speakers using the advanced audio distribution profile 
(a2dp).


Ahhh, that's going to rock, quite literally. I've got a SoundBlaster 
BlasterAxx and a new set of Sony BT headphones. I'll try it with both.


NEW!!! bta2dpd can be used also as an audio sink, so you can stream 
music from your phone/computer etc. to a file or audioplay to hear it on 
your computer speakers.  See below.


Hmm, does it have any noticeable delay? Ie.. could it be used to send 
output to a recording monitor without any significant delay (for live 
monitoring while playing music) ? If you don't know off hand, it's not big 
deal. I'll just try it.


I have a two mixers hooked up to my main NetBSD workstation (though I 
sometimes move them to an SGI workstation). One for input, one for output. 
I'd love to be able to add a high bitrate BT DAC on a channel for both 
sides (know of any good ones you like?).


To use this deamon requires 44100Hz stereo signed 16 bit little endian 
wav files or the pad(4) device.


Just like a CDDA converted to PCM WAV would be, right?

Most of the options change the way audio is encoded and are not 
necessary however if you have skipping audio or no audio try the 
following:


Does that buffering result in more jitter or delays? Again, I'll fiddle, 
but just curious about your experience.


What fun!  Great work.

-Swift

bta2dpd - advanced audio distribution profile bluetooth daemon IMPROVED

[Nathanial Sloss]

Hi,

Call for testers of the next installment of bta2dpd.

It allows you to stream music or pad(4) output to bluetooth stereo headphones 
or speakers using the advanced audio distribution profile (a2dp).

NEW!!! bta2dpd can be used also as an audio sink, so you can stream music from 
your phone/computer etc. to a file or audioplay to hear it on your computer 
speakers.  See below.

This program will work on NetBSD-current, 7 and 6.

To compile:
extract the archive from 
ftp://ftp.NetBSD.org/pub/NetBSD/misc/nat/bta2dpd-v62.tgz

change to the extracted directory and make(1).
ie. 
$cd bta2dp-bsd-v62
$make.

pair up your bluetooth headphones/speakers:
#btpin -P  -a bluetooth-device-address

And your ready to go...


To use this deamon requires 44100Hz stereo signed 16 bit little endian wav 
files or the pad(4) device.

$./bta2dpd -a bluetooth-device-address my.wav
or 
$./bta2dpd -a bluetooth-device-address /dev/pad0

Most of the options change the way audio is encoded and are not necessary 
however if you have skipping audio or no audio try the following:

./bta2dpd -a bluetooth-device-address -M 300 my.wav
or 
./bta2dpd -a bluetooth-device-address -M 300 -B 36 my.wav

The -M option limits the maximum amount of data sent to the bluetooth device 
per transaction, if you still have problems try an MTU of 700 (-M 700) and 
work your way down by hundreds.

The -B option limits the bitpool value used for encoding the stream and 
although the daemon calculates the bitpool value it might not work in all 
cases.

NEW!!! It can also be used as an audio sink:
./bta2dpd -K -r 44100 | audioplay -f -e linear -P 16 -c 2 -s 44100 --

As an audio sink it is possible to specify an address to receive connections 
from with -a. i.e:

./bta2dpd -K -r 44100 -a myphone | audioplay -f -e linear -P 16 -c 2 -s 44100 
--

I found in order for my phone to connect to bta2dpd as an audio sink I needed 
the most recent version of sdpd(1) and had to set a pin code for my phone (see 
btpin(1)) and had to start bta2dpd as a sink with -K before pairing.


Best regards,

Nat.

Re: ZFS

[Swift Griggs]

On Thu, 3 Mar 2016, co...@sdf.org wrote:
Someone on IRC implied that he is using ZFS. Still struggling to 
believe, so I gotta ask - is there anyone out there using it?


I'm not. I never knew it got past the idea stage for NetBSD. It's listed 
on the projects page here:


https://wiki.netbsd.org/projects/project/zfs/

Did it ever get to the point where it was usable? The last note on the 
project page says "It is not finished. Ask on tech-kern for more 
information about the current state." but it's dated 2014.


Like you, I wonder about ZFS in general. Didn't the NetBSD project pay 
someone to complete it or am I wrong and it was a purely volunteer effort? 
Was it part of a Google SoC project? Can it ever be pulled into the 
mainline code (ie.. isn't the CDDL incompatible with the BSD license?) ?


ZFS has some great features. I've used it quite a bit under Solaris and 
FreeBSD. However, it's also proven to be a source of a lot of crashes I've 
seen under both (but especially FreeBSD).


I'm guessing it'd be a really big challenge to re-implement things like 
deduplication or other key ZFS features, but then again I look at HAMMER 
and wonder... Since HAMMER is BSD-focused (and BSD licensed) maybe that's 
a better choice to want to throw in with ? Then again, I don't know the 
politics of that, either.


A few tidbits about ZFS:

* Solaris never has had LVM. Sun had a history of making spectacularly
  bad choices before ZFS came along. Those of you who have tried to
  recover a mis-matched SDS/SVM rig know what I mean. They had a chance to
  get VxVM on the cheap in the 90's and pooched it (while HP-UX, Tru64,
  and UnixWare snatched it up). So, NetBSD has RAIDframe which works
  nicely, and now a very sweet LVM. The urgency to have something like ZFS
  in NetBSD shouldn't be quite as acute as it was in Slowlaris.

* I don't consider having block storage commands separated from file
  system commands a weakness. Ie.. LVM + FS == ZFS && ! ZFS > everything.
  I think that puts me on the outs with the cool kids.

* If you put all the storage features in NetBSD up against ZFS, the main
  things you come up missing on are:

  - Huge sizes on all the upper limits. The "zettabyte" part is real.
  - Deduplication
  - online fsck (scrub)
  - An unprecedented level of paranoia about data integrity

However, of those only deduplication is all that exciting. Other ZFS-like 
features we have (if you consider the full NetBSD toolset):


  - Block device encryption
  - Ability to grow a file system (don't think UFS in NetBSD can shrink)
  - Block device abstraction, aggregation / RAID (LVM / RAIDframe)
  - File system snapshots
  - Root disk mirroring

Other stuff I'm not sure about:

  - Can NetBSD do RAID6 / RAID-DP in software ?
  - What about the ZIL and L2ARC, are there already NetBSD equals?
  - Does NetBSD's LVM support multiple copies of an LV on physical PVs
ala ZFS ditto blocks ?
  - Does anyone care that ZFS is now closed source and the CDDL forks are
now going to drift significantly from the parent core ? I don't
really, but I'm just wondering if that's a concern.
  - Do we have anything against HAMMER ? I personally think it's cool.

It's an interesting topic to me.

-Swift

Re: Would Raspberry Pi 3's wifi be supported by NetBSD arm port?

[Nick Hudson]

On 03/03/16 05:33, Mayuresh wrote:

The specs say that pi 3 maintains a backward compatibility.

https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/

So I am hoping that arm port might work out of the box.


Not quite... I have one and I'm getting close to making it work.



Just curious about the new bits - wifi and bluetooth. Above link says the
chip is BCM43438.



I don't know anything about support for these right now.



[I haven't yet ordered a pi 3, and I am content with pi 2 for my needs
right now, though just curious.]

Mayuresh


Nick

Re: DRM issues with Xorg and intel

[BERTRAND Joël]

Riccardo Mottola a écrit :

Hi,

BERTRAND Joël wrote:

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).


I don't see an interrapt flood (do you see it in the console).


	No. I only see when screen is blanking a cpu totally busy. There is a 
command to investigate ant I have seen that cpu stalled due to an 
interrupt flood.



But more
than once I notice the laptop freeze. Actually.. starve, for a little
there is disk activity, the mouse may update once after a couple of
minutes and then freeze totoally, not even the power button or a remote
shell are active.
The Network card continues to blink though.
Perhaps this happens due to interrupt flood?


Maybe. In my case, it remains seven other CPU's...

Regards,

JKB

Re: Would Raspberry Pi 3's wifi be supported by NetBSD arm port?

[Stephan]

The first question is if the device itself will work. As with its
predecessor, I´m not able to find a datasheet of the BCM2837.

I wonder what has changed, e.g. with respect to timers and the
interrupt controller. Anyone having a clue?

2016-03-03 6:33 GMT+01:00 Mayuresh :
> The specs say that pi 3 maintains a backward compatibility.
>
> https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/
>
> So I am hoping that arm port might work out of the box.
>
> Just curious about the new bits - wifi and bluetooth. Above link says the
> chip is BCM43438.
>
> [I haven't yet ordered a pi 3, and I am content with pi 2 for my needs
> right now, though just curious.]
>
> Mayuresh