Re: Best testcases for SSHD when fuzzing with afl?

[Darren Tucker]

On 5 May 2018 at 21:50, Hess THR  wrote:
[...]
> But the question: does anybody have more? Or better? Any idea how to have 
> more and better quality testcases?

https://anongit.mindrot.org/openssh-fuzz-cases.git/

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: video(1): Xv adaptor unable to display yuy2?

[Stuart Henderson]

On 2018/05/06 18:08, Leonid Bobrov wrote:
> Thank you!
> 
> So the problem is in driver...

Not really.

Re: nsd does not stop

[Dimitris Papastamos]

On Thu, May 03, 2018 at 07:57:45PM +0530, Vivek Vinod wrote:
> Dear Misc,
> 
> on stopping nsd from command line, nsd does not stop at all
> 
> Config:
> OpenBSD 6.3
> nsd remote control is disabled

enable remote control

Re: tap+bridge: arp reply not forwarded

[Xavier Guerin]

On Sun, 2018-05-06 at 17:51 -0400, Xavier Guerin wrote:
> On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> > On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > > Hello list,
> > > > 
> > > > Working with a user-space TCP-IP, I tried to setup a local
> > > > bridge
> > > > between two taps, each tap being driver by a user-space client
> > > > and
> > > > server.
> > > > 
> > > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > > > 
> > > > I am interestingly stuck at the ARP discovery phase. When the
> > > > client
> > > > send its ARP request, the server receives it and replies.
> > > > However,
> > > > the
> > > > client never gets the reply back.
> > > > 
> > > > Some research indicated that since the client is getting an
> > > > echoed
> > > > version of its request, the bridge learns its address
> > > > preventing
> > > > the reply from being forwared.
> > > > 
> > > > Would my understanding be correct? If so, is there any way to
> > > > correct
> > > > this behavior?
> > > > 
> > > > Thanks,
> > > > xavier
> > > > 
> > > 
> > > What version are you running?
> > > 
> > > I ask because of the following:
> > > https://www.openbsd.org/errata63.html
> > > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.pa
> > > tc
> > > h.
> > > sig
> > > 
> > > +--+
> > > Carlos
> > > 
> > 
> > I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> > long time). I just applied the patch and tried again, but no cigar.
> > 
> > Here is exactly what is happening:
> > 
> > 1. On TAP0, the server waits for any request on 10.1.0.1 (user-
> > space
> > stack address)
> > 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> > (also
> > user-space address)
> > 3. The ARP table of the client is empty, so it sends a broadcast
> > ARP
> > request.
> > 4. Both the server AND the client receive that request, the client
> > ignores it
> > 5. The server responds to the client but the client never receives
> > the
> > reply
> > 
> > I can see the reply packet leaving TAP0 and passing through
> > BRIDGE0.
> > It
> > just simply never show up on TAP1.
> > 
> > /x
> > 
> 
> Looking at the source code for the bridge and doing some debugging in
> VMM, it looks like the reply gets dropped at that point:
> 
> sys/net/if_bridge.c:1182
> 
>   if (bridge_ourether(ifl, eh->ether_shost)) {
>   m_freem(m);
>   return;
>   }
> 
> In my case, ifl is the sending address and, of course, the source
> ethernet is ours.
> 
> Doing some barbaric massaging of the inner FOREACH got me to the
> point
> where my ARP reply was received by my stack. I also was able to get a
> S/SA/A sequence but eventually the stack failed after its first P.
> 
> I'll investigate the TCP misbehaving using static ARP routes as Edgar
> suggested.
> 
> /x
> 

I'm running out of luck apparently... Now that ARP is out of the way,
the user-space client sends an S frame to the user-space server through
tap2. The server uses tap1, which sees the frame (per tcpdump).
However, the read() function on tap1 never returns any data.

Re: tap+bridge: arp reply not forwarded

[Xavier Guerin]

On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > Hello list,
> > > 
> > > Working with a user-space TCP-IP, I tried to setup a local bridge
> > > between two taps, each tap being driver by a user-space client
> > > and
> > > server.
> > > 
> > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > > 
> > > I am interestingly stuck at the ARP discovery phase. When the
> > > client
> > > send its ARP request, the server receives it and replies.
> > > However,
> > > the
> > > client never gets the reply back.
> > > 
> > > Some research indicated that since the client is getting an
> > > echoed
> > > version of its request, the bridge learns its address preventing
> > > the reply from being forwared.
> > > 
> > > Would my understanding be correct? If so, is there any way to
> > > correct
> > > this behavior?
> > > 
> > > Thanks,
> > > xavier
> > > 
> > 
> > What version are you running?
> > 
> > I ask because of the following:
> > https://www.openbsd.org/errata63.html
> > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patc
> > h.
> > sig
> > 
> > +--+
> > Carlos
> > 
> 
> I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> long time). I just applied the patch and tried again, but no cigar.
> 
> Here is exactly what is happening:
> 
> 1. On TAP0, the server waits for any request on 10.1.0.1 (user-space
> stack address)
> 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> (also
> user-space address)
> 3. The ARP table of the client is empty, so it sends a broadcast ARP
> request.
> 4. Both the server AND the client receive that request, the client
> ignores it
> 5. The server responds to the client but the client never receives
> the
> reply
> 
> I can see the reply packet leaving TAP0 and passing through BRIDGE0.
> It
> just simply never show up on TAP1.
> 
> /x
> 

Looking at the source code for the bridge and doing some debugging in
VMM, it looks like the reply gets dropped at that point:

sys/net/if_bridge.c:1182

if (bridge_ourether(ifl, eh->ether_shost)) {
m_freem(m);
return;
}

In my case, ifl is the sending address and, of course, the source
ethernet is ours.

Doing some barbaric massaging of the inner FOREACH got me to the point
where my ARP reply was received by my stack. I also was able to get a
S/SA/A sequence but eventually the stack failed after its first P.

I'll investigate the TCP misbehaving using static ARP routes as Edgar
suggested.

/x

Re: tap+bridge: arp reply not forwarded

[Xavier Guerin]

On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > Hello list,
> > > 
> > > Working with a user-space TCP-IP, I tried to setup a local bridge
> > > between two taps, each tap being driver by a user-space client
> > > and
> > > server.
> > > 
> > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > > 
> > > I am interestingly stuck at the ARP discovery phase. When the
> > > client
> > > send its ARP request, the server receives it and replies.
> > > However,
> > > the
> > > client never gets the reply back.
> > > 
> > > Some research indicated that since the client is getting an
> > > echoed
> > > version of its request, the bridge learns its address preventing
> > > the reply from being forwared.
> > > 
> > > Would my understanding be correct? If so, is there any way to
> > > correct
> > > this behavior?
> > > 
> > > Thanks,
> > > xavier
> > > 
> > 
> > What version are you running?
> > 
> > I ask because of the following:
> > https://www.openbsd.org/errata63.html
> > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patc
> > h.
> > sig
> > 
> > +--+
> > Carlos
> > 
> 
> I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> long time). I just applied the patch and tried again, but no cigar.
> 
> Here is exactly what is happening:
> 
> 1. On TAP0, the server waits for any request on 10.1.0.1 (user-space
> stack address)
> 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> (also
> user-space address)
> 3. The ARP table of the client is empty, so it sends a broadcast ARP
> request.
> 4. Both the server AND the client receive that request, the client
> ignores it
> 5. The server responds to the client but the client never receives
> the
> reply
> 
> I can see the reply packet leaving TAP0 and passing through BRIDGE0.
> It
> just simply never show up on TAP1.
> 
> /x
> 

Looking at the source code for the bridge and doing some debugging in
VMM, it looks like the reply gets dropped at that point:

sys/net/if_bridge.c:1182

if (bridge_ourether(ifl, eh->ether_shost)) {
m_freem(m);
return;
}

In my case, ifl is the sending address and, of course, the source
ethernet is ours.

Doing some barbaric massaging of the inner FOREACH got me to the point
where my ARP reply was received by my stack. I also was able to get a
S/SA/A sequence but eventually the stack failed after its first P.

I'll investigate the TCP misbehaving using static ARP routes as Edgar
suggested.

/x

Re: nsd does not stop

[Maxim Bourmistrov]

Is nsd.conf broken?

shell# nsd-checkconf /var/nsd/etc/nsd.conf



> 3 maj 2018 kl. 16:27 skrev Vivek Vinod :
> 
> Dear Misc,
> 
> on stopping nsd from command line, nsd does not stop at all
> 
> Config:
> OpenBSD 6.3
> nsd remote control is disabled
> nsd ipv6 is disabled
> 
> $doas rcctl restart nsd
> (failed)
> 
> $doas rcctl stop nsd
> $echo $?
> 0
> 
> $doas rcctl start nsd
> (failed)
> 
> $doas tail -f /var/log/nsd.log
> error: can't bind udp socket: Address already in use
> error: server initialization failed, nsd could not be started
> 
> $ps aux | grep nsd
> shows running processes
> 
> if I kill the processes, I can start nsd. However, it is just that nsd does
> not stop if I want it to
> 
> even
> $doas /etc/rc.d/nsd stop | restart
> does not work.
> 
> What am I doing wrong here? Pooped. Any help would be appreciated.
> 
> regards,
> Vivek

Re: Intel X-550T 10 GbE Adapter cards

[Maxim Bourmistrov]

> 6 maj 2018 kl. 22:43 skrev Sebastian Benoit :
> 
> Peter J. Philipp(p...@centroid.eu) on 2018.05.06 21:47:02 +0200:
>> Hi,
>> 
>> The ix(4) manpage mentions there is support:
>> 
>> o Intel X550-T 10GbE Adapter (10GbaseT/1000baseT/100baseTX)
>> 
>> However there is a X550-T1 and a X550-T2 model are both supported or
>> 
>> just the X550-T1?
> 
> its the same card, just with 1 port ort 2 ports.
> 

Exactly.
For instance, I have X540, both T1 and T2, working.

Re: Intel X-550T 10 GbE Adapter cards

[Sebastian Benoit]

Peter J. Philipp(p...@centroid.eu) on 2018.05.06 21:47:02 +0200:
> Hi,
> 
> The ix(4) manpage mentions there is support:
> 
> o Intel X550-T 10GbE Adapter (10GbaseT/1000baseT/100baseTX)
> 
> However there is a X550-T1 and a X550-T2 model are both supported or
> 
> just the X550-T1?

its the same card, just with 1 port ort 2 ports.

frequent SeaMonkey crashes

[Riccardo Mottola]

Hi,

after 6.3 upgade (with associated packages) I experience very frequent 
crashes of the SeaMonkey browser.
I checked RAM consumption and it crashes even if it is not very hight, 
around 400MB, for example.


I tried starting it from a terminal and see this message after a crash:

seamonkey: Fatal IO error 12 (Cannot allocate memory) on X server :0.

Is it a bug perhaps_ or some limit i can extend?

I tried FireFox and it seems a little bit better: strange though, 
because usually it is has always been the other way and I am a long-time 
seamonkey fan.


Riccardo

Intel X-550T 10 GbE Adapter cards

[Peter J. Philipp]

Hi,

The ix(4) manpage mentions there is support:

o   Intel X550-T 10GbE Adapter (10GbaseT/1000baseT/100baseTX)

However there is a X550-T1 and a X550-T2 model are both supported or

just the X550-T1?

Please clarify this for me.

Also is there any comparable products that you'd recommend that I might

have overlooked (non-ix for example?).

Regards,

-peter

Re: compiling ardour -lexecinfo issues

[Ken M]

I will move further iteration of this to there after this reply. Sorry.

OK I will try to figure out getting this to use cc c++ instead. I tried setting
the flag and it says not found. It is setup to compile with waf and that might
be part of the darn problem.

Ken

On Sun, May 06, 2018 at 02:15:52PM +, Stuart Henderson wrote:
> On 2018-05-06, Ken M  wrote:
> > Maybe this should go to ports@ but not sure I am near there yet.
> 
> ports@ is a much better place for this type of question.
> 
> > So I am trying to compile the latest ardour on 6.3, got through compiling
> > rubberband and aubio and now well I am stuck here:
> >
> > [200~./waf configure --boost-include=/usr/local/include
> > Setting top to   : /home/superfly/git/ardour 
> > Setting out to   : /home/superfly/git/ardour/build 
> > Checking for 'gcc' (c compiler)  : /usr/bin/gcc 
> > Checking for 'g++' (c++ compiler): /usr/bin/g++ 
> 
> This should be using cc/c++ rather than gcc/g++
> 
> > Global Configuration 
> >  * Install prefix: /usr/local 
> >   * Debuggable build  : True 
> >* Build documentation   : False 
> >
> >Ardour Configuration 
> > * Will build against private GTK dependency stack   : no 
> >  * Will rely on libintl built into libc  : yes 
> >   * Will build against private Ardour dependency stack : no 
> >   Checking for boost library >= 1.39   : ok 
> >   Checking for program pkg-config  : 
> > /usr/bin/pkg-config 
> >   Checking for 'glib-2.0' >= 2.28  : yes 
> >   Checking for 'gthread-2.0' >= 2.2: yes 
> >   Checking for 'glibmm-2.4' >= 2.32.0  : yes 
> >   Checking for 'sndfile' >= 1.0.18 : yes 
> >   Checking for 'giomm-2.4' >= 2.2  : yes 
> >   Checking for 'libcurl' >= 7.0.0  : yes 
> >   Checking for 'libarchive' >= 3.0.0   : yes 
> >   Checking for 'liblo' >= 0.26 : yes 
> >   Checking for 'taglib' >= 1.6 : yes 
> >   Checking for 'vamp-sdk' >= 2.1   : yes 
> >   Checking for 'vamp-hostsdk' >= 2.1   : yes 
> >   Checking for 'rubberband': yes 
> >   Checking for  sndfile RF64=>RIFF support : Found 
> >   Checking for clang   : no 
> >
> >   Warning: you are building Ardour with SSE support even though your 
> > system
> >   does not support these instructions. (This may not be an error, 
> > especially
> >   if you are a package maintainer)
> >   hidapi is not yet available for the given system
> >   Checking for 'fftw3f': yes 
> >   Checking for 'aubio' >= 0.3.2: yes 
> >   Checking for 'aubio' >= 0.4.0: yes 
> >   Checking for 'libxml-2.0': yes 
> >   Checking for 'sigc++-2.0' >= 2.0 : yes 
> >   Checking for function getmntent  : not found 
> >   Checking for header execinfo.h   : not found 
> >   Checking for header unistd.h : not found 
> >   Checking for function posix_memalign : no 
> 
> That's weird because we do have posix_memalign
> 
> >   Checking for function localtime_r: not found 
> >   Checking for header boost/shared_ptr.hpp : not found 
> >   The configuration failed
> >   (complete log in /home/superfly/git/ardour/build/config.log)
> >
> > Tail form the config.log
> >
> > [2/2] cxxprogram: 
> > build/.conf_check_c02c9165785b1b8132b54a498262d87b/testbuild/test.cpp.1.o 
> > -> build/.conf_check_c02c9165785b1b8132b54a498262d87b/testbuild/testprog
> >
> > ['/usr/bin/g++', '-lexecinfo', 'test.cpp.1.o', '-o', 
> > '/home/superfly/git/ardour/build/.conf_check_c02c9165785b1b8132b54a498262d87b/testbuild/testprog',
> >  '-Wl,-Bstatic', '-Wl,-Bdynamic']
> > err: /usr/bin/ld: cannot find -lexecinfo
> > collect2: ld returned 1 exit status
> 
> The reason it's failing is because it doesn't specify -L/usr/local/lib,
> however in the case of libexecinfo the best option here is to figure out
> how to disable it from being picked up at all.
> 
> 

Re: video(1): Xv adaptor unable to display yuy2?

[Leonid Bobrov]

Thank you!

So the problem is in driver...

Re: compiling ardour -lexecinfo issues

[Stuart Henderson]

On 2018-05-06, Ken M  wrote:
> Maybe this should go to ports@ but not sure I am near there yet.

ports@ is a much better place for this type of question.

> So I am trying to compile the latest ardour on 6.3, got through compiling
> rubberband and aubio and now well I am stuck here:
>
> [200~./waf configure --boost-include=/usr/local/include
> Setting top to   : /home/superfly/git/ardour 
> Setting out to   : /home/superfly/git/ardour/build 
> Checking for 'gcc' (c compiler)  : /usr/bin/gcc 
> Checking for 'g++' (c++ compiler): /usr/bin/g++ 

This should be using cc/c++ rather than gcc/g++

> Global Configuration 
>  * Install prefix: /usr/local 
>   * Debuggable build  : True 
>* Build documentation   : False 
>
>Ardour Configuration 
> * Will build against private GTK dependency stack   : no 
>* Will rely on libintl built into libc  : yes 
> * Will build against private Ardour dependency stack : no 
> Checking for boost library >= 1.39   : ok 
> Checking for program pkg-config  : 
> /usr/bin/pkg-config 
> Checking for 'glib-2.0' >= 2.28  : yes 
> Checking for 'gthread-2.0' >= 2.2: yes 
> Checking for 'glibmm-2.4' >= 2.32.0  : yes 
> Checking for 'sndfile' >= 1.0.18 : yes 
> Checking for 'giomm-2.4' >= 2.2  : yes 
> Checking for 'libcurl' >= 7.0.0  : yes 
> Checking for 'libarchive' >= 3.0.0   : yes 
> Checking for 'liblo' >= 0.26 : yes 
> Checking for 'taglib' >= 1.6 : yes 
> Checking for 'vamp-sdk' >= 2.1   : yes 
> Checking for 'vamp-hostsdk' >= 2.1   : yes 
> Checking for 'rubberband': yes 
> Checking for  sndfile RF64=>RIFF support : Found 
> Checking for clang   : no 
>
> Warning: you are building Ardour with SSE support even though your 
> system
> does not support these instructions. (This may not be an error, 
> especially
> if you are a package maintainer)
> hidapi is not yet available for the given system
> Checking for 'fftw3f': yes 
> Checking for 'aubio' >= 0.3.2: yes 
> Checking for 'aubio' >= 0.4.0: yes 
> Checking for 'libxml-2.0': yes 
> Checking for 'sigc++-2.0' >= 2.0 : yes 
> Checking for function getmntent  : not found 
> Checking for header execinfo.h   : not found 
> Checking for header unistd.h : not found 
> Checking for function posix_memalign : no 

That's weird because we do have posix_memalign

> Checking for function localtime_r: not found 
> Checking for header boost/shared_ptr.hpp : not found 
> The configuration failed
> (complete log in /home/superfly/git/ardour/build/config.log)
>
> Tail form the config.log
>
> [2/2] cxxprogram: 
> build/.conf_check_c02c9165785b1b8132b54a498262d87b/testbuild/test.cpp.1.o -> 
> build/.conf_check_c02c9165785b1b8132b54a498262d87b/testbuild/testprog
>
> ['/usr/bin/g++', '-lexecinfo', 'test.cpp.1.o', '-o', 
> '/home/superfly/git/ardour/build/.conf_check_c02c9165785b1b8132b54a498262d87b/testbuild/testprog',
>  '-Wl,-Bstatic', '-Wl,-Bdynamic']
> err: /usr/bin/ld: cannot find -lexecinfo
> collect2: ld returned 1 exit status

The reason it's failing is because it doesn't specify -L/usr/local/lib,
however in the case of libexecinfo the best option here is to figure out
how to disable it from being picked up at all.

Re: video(1): Xv adaptor unable to display yuy2?

[Stuart Henderson]

On 2018-05-06, mazoc...@disroot.org  wrote:
> I don't understand how to use video(1), what is
> wrong with Xv(3)? My webcam works fine with other
> applications (uTox, Toxic).

Until/unless video(1) is changed to cope, you'll need to use the intel
driver rather than the modesetting driver.

$ cat /etc/X11/xorg.conf
Section "Device"
   Identifier  "Intel Graphics"
   Driver  "intel"
EndSection

Re: tap+bridge: arp reply not forwarded

[Xavier Guerin]

On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > Hello list,
> > 
> > Working with a user-space TCP-IP, I tried to setup a local bridge
> > between two taps, each tap being driver by a user-space client and
> > server.
> > 
> > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > 
> > I am interestingly stuck at the ARP discovery phase. When the
> > client
> > send its ARP request, the server receives it and replies. However,
> > the
> > client never gets the reply back.
> > 
> > Some research indicated that since the client is getting an echoed
> > version of its request, the bridge learns its address preventing
> > the reply from being forwared.
> > 
> > Would my understanding be correct? If so, is there any way to
> > correct
> > this behavior?
> > 
> > Thanks,
> > xavier
> > 
> 
> What version are you running?
> 
> I ask because of the following:
> https://www.openbsd.org/errata63.html
> https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patch.
> sig
> 
> +--+
> Carlos
> 

I am running 6.3 but was missing that patch (hadn't syspatch'd in a
long time). I just applied the patch and tried again, but no cigar.

Here is exactly what is happening:

1. On TAP0, the server waits for any request on 10.1.0.1 (user-space
stack address)
2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2 (also
user-space address)
3. The ARP table of the client is empty, so it sends a broadcast ARP
request.
4. Both the server AND the client receive that request, the client
ignores it
5. The server responds to the client but the client never receives the
reply

I can see the reply packet leaving TAP0 and passing through BRIDGE0. It
just simply never show up on TAP1.

/x

video(1): Xv adaptor unable to display yuy2?

[mazocomp]

Hi!

I don't understand how to use video(1), what is
wrong with Xv(3)? My webcam works fine with other
applications (uTox, Toxic).

P.S. To make my webcam work I disabled xhci(4),
now my USB is handled by ehci(4).

mazocomp$ video
video: could not find a usable encoding
mazocomp$ video -q
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
160x120: 30
176x144: 30
320x240: 30
352x288: 30
640x480: 30
  controls: brightness, contrast, saturation, gamma, sharpness
mazocomp$ video -e yuy2
video: Xv adaptor 0 can't display yuy2
mazocomp$ video -e yuy2 -s 640x480 -r 30
video: Xv adaptor 0 can't display yuy2
mazocomp$ video -
video: adaptor 0 has no usable encodings
video: could not find a usable encoding
mazocomp$ video - -e yuy2
video: adaptor 0 has no usable encodings
video: Xv adaptor 0 can't display yuy2
mazocomp$ dmesg
sibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.50014ee6b16cb4fa
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 9 Series SMBus" rev 0x03: apic 2 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
Unclaimed register detected before reading register 0x23a0
uhidev0 at uhub0 port 2 configuration 1 interface 0 "A4Tech USB Mouse" rev 
1.10/3.14 addr 2
uhidev0: iclass 3/1, 4 report ids
ums0 at uhidev0 reportid 1: 8 buttons, Z dir
wsmouse1 at ums0 mux 0
uhid0 at uhidev0 reportid 4: input=5, output=0, feature=0
ugen0 at uhub0 port 4 "Generic USB2.0-CRW" rev 2.00/39.60 addr 3
uvideo0 at uhub0 port 6 configuration 1 interface 0 "Chicony Electronics 
Co.,Ltd. Lenovo EasyCamera" rev 2.00/95.60 addr 4
video0 at uvideo0
uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 
2.00/0.03 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (3c4038c4be3c16ce.a) swap on sd0b dump on sd0b
error: [drm:pid28732:intel_pipe_update_start] *ERROR* Potential atomic update 
failure on pipe A
error: [drm:pid28732:intel_pipe_update_start] *ERROR* Potential atomic update 
failure on pipe A
error: [drm:pid28732:intel_pipe_update_start] *ERROR* Potential atomic update 
failure on pipe A
error: [drm:pid28732:intel_pipe_update_start] *ERROR* Potential atomic update 
failure on pipe A
error: [drm:pid28732:intel_pipe_update_start] *ERROR* Potential atomic update 
failure on pipe A
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 addr 5
umodem0: data interface 0, has CM over data, has break
umodem0: could not set data multiplex mode
umodem0 detached
umodem0 at uhub0 port 1 configuration 1 interface 1 "Nokia product 0x069c" rev 
1.10/1.00 

Re: 6.3 - dhclient not working on wireless

[Stefan Sperling]

On Sat, May 05, 2018 at 11:03:52PM +0200, Riccardo Mottola wrote:
> Hi,
> 
> I upgraded to 6.3 and I cannot connect to a certain WiFi network anymore,
> or, better, ifconfig says it is connected and the LED says it is too, but
> then dhclient fails to get a lease from it.
> I can connect to the same network through wired ethernet and dhclient
> correctly gets an address from the same router.
> 
> What is going wrong? can I enable some further information?
> 
> Here you can see ifconfig "active":
> wpi0: flags=8843 mtu 1500
>     lladdr 00:13:02:9a:52:1b
>     index 2 priority 4 llprio 3
>     groups: wlan
>     media: IEEE802.11 autoselect (DS1 mode 11g)
>     status: active
>     ieee80211: nwid westernesse chan 10 bssid f8:d1:11:b9:07:2a -16dBm
> nwkey

The keyword 'nwkey' indicates you are using WEP. Is that correct?

A commit of mine accidentally broke WEP support back in August 2017.
This was eventually fixed in -current 2 weeks ago. Nobody noticed
that WEP was broken for 8 months...

I'd suggest switching this wifi network to WPA2, or just leaving it open
since WEP is no better than leaving your wifi open in the first place.

We provide WEP only for interop with legacy networks outside your control.

Re: HTTPD and php-cgi

[Martijn van Duren]

On 05/06/18 06:31, Duncan Patton a Campbell wrote:
> On Sat, 5 May 2018 12:19:59 +0200
> Martijn van Duren  wrote:
> 
> On Sat, 5 May 2018 08:48:23 +0200
> Mischa Peters  wrote:
> 
> Hi Martijn, Mischa.  Thanks for you replies, from which 
> I've figured out that the problem is I'm running sparc64
> and the packages you refer to are not extant...  I guess
> I'll have a go with ports and hopefully report back...

sparc64 currently misses php-7.0, because of segfaults during the
generation of phar, but php-5.6 is available. So if you
`pkg_add php` you'll get the php-5.6 package which contains php-fpm.
After that's installed you can run `rcctl start php56-fpm`.

I have a patch in the pipeline that can disable the extensions based on
architecture during compile-time which should allow us to have php-7.0
on sparc64 (without phar), but I don't have the hardware to test it.
> 
> Thanks again.
> 
> Dhu
> 

Re: relayd as websocket proxy?

[Ajitabh Pandey]

Hello,

I am facing issues with running Jupyter notebook behind relayd. This is
most probably because of websockets proxy.

When I open a notebook, its not able to connect to the kernel.


Searching on the net pointed me to this issue -
https://github.com/jupyter/notebook/issues/2664

The solution there is with an nginx configuration. I am not able to figure
out equivalent relayd config.

Any help here would be appreciated.

Here is my relayd config -
-
-

relayd_addr="0.0.0.0"
relayd_port="80"

jupyter_port="5000"
table  { 127.0.0.1 }

httpd_port="8000"
table  { 127.0.0.1 }

log all

http protocol "httpfilter" {
match header append "X-Forwarded-For" \
value "$REMOTE_ADDR"
match header append "X-Forwarded-By" \
value "$REMOTE_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"

### TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 100 }

### Return HTTP/HTML error pages
return error

match request path "/ipython/*" forward to 
match request path "/" forward to 
}

relay http {
listen on $relayd_addr port $relayd_port
protocol "httpfilter"
forward to  port $jupyter_port mode loadbalance
forward to  port $httpd_port check tcp interval 60
}
-
-


Regards.
-- 
Ajitabh Pandey

On Mon, Apr 30, 2018 at 9:24 PM, Andre Ruppert  wrote:

> Hello @misc,
>
> is it possible to configure relayd to act as a websocket proxy with
> v6.2/v6.3?
>
> I set up relayd as ssl accelerator:
>
> excerpt from relayd.conf:
>
> 
> http protocol "httpfilter2" {
>
> tcp { nodelay, sack, socket buffer 65536, backlog 100 }
>
> return error
> match request header set "Connection" value "close"
> match header set "Keep-Alive" value "$TIMEOUT"
> match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
> match request header append "X-Forwarded-By" value \
>   "$SERVER_ADDR:$SERVER_PORT"
>
> tls { tlsv1, ciphers "HIGH:!ADH:!NULL:!RC4:-ECDH:ECDHE" }
> }
> ...
>
> relay webrtc_wsc {
> listen on $webrtc_wsc_relayd_addr \
> port $webrtc_wsc_relayd_port tls
> protocol "httpfilter2"
> transparent forward to  port $webrtc_wsc_web_port \
> mode loadbalance http “/” code 200
> }
> ...
>
> valid .key and .crt-files are placed in /etc/ssl/private and /etc/ssl.
>
>
> First: "standard" SSL acceleration works fine without problems.
>
> Second: websocket connections don't  :-(
>
> As far I can see websocket upgrade messages (decoded in wireshark as
> "HTTP/1.1 101 Switching Protocols" packets) from the internal server are
> replaced by relayd with packets with the RST-flag set directed to the WAN
> client and the connection is closed.
>
>
> My head-scratching question:
> is this possible at all with relayd?
>
> Or do I have to switch to nginx?
>
>
> Regards
> Andre Ruppert
>
>
>
>


-- 
Ajitabh Pandey
http://ajitabhpandey.info/ | http://unixclinic.net/ |
http://buddingthoughts.info
ICQ - 150615062
Registered Linux User - 240748

Re: Troubleshooting rl instability on OpenBSD 6.1

[Stuart Longland]

On 01/05/18 21:30, Stuart Longland wrote:
> No corresponding log messages from the switch.
> 
> In any case, I've asked PC Engines about the voltage range of the APU2,
> having priced one for under the AU$600 mark.

Right, so a further update… I observed the errors came in bursts,
sometimes at particular times of the day.  During these times, nothing
else has connectivity issues, just the border router.

I wondered if it might be bursts of network activity on the main switch.
 The 240-12V 1.35A switchmode PSU in it was replaced with a Micrel
MIC29750 LDO which is set to regulate to 11.8V (within 3%), and is
capable of supplying 7.5A.

The mainboard of the Linksys LGS326AU features two switchmode PSUs that
regulate to 3.3V and 5V, everything in the switch runs off those two
power rails.  On paper, that *should* work fine, and for everything
else, it does.  Just this border router misbehaves with it.

As an experiment, I grabbed an old 10/100Mbps switch, hooked the main
switch and rl0 on the border router up to it.  I also hooked up a
TS-7670 to that same 10/100 switch.  If it's the main switch, I
shouldn't be able to ping either machine.

About 45 minutes later, I got a burst of errors from my cron job.
Pinging the border router yielded no reply, but I could still ping the
TS-7670.  I think that confirms hardware.

Disappointingly, I've not heard from PC Engines regarding the APU2 and
its power supply tolerance, but I've placed an order with Yawarra
Computers anyway, as it *looks* as if all the expensive bits that touch
12V can take 24V+.

If a 12V capacitor blows, well I have the schematics and a soldering
iron to replace that part.  Plus, the old border router is still there
even if not the most reliable.

When that arrives, I can look at getting OpenBSD 6.3 onto that, and
migrating my old config across.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.