Re: non-checksummed UDP packets

2020-07-20 Thread David Gwynne



> On 20 Jul 2020, at 05:30, Stuart Henderson  wrote:
> 
> On 2020-07-19, obs...@loopw.com  wrote:
>> 
>>> Is this normal?  
>> 
>> Checksum is OPTIONAL in UDP, not required.  This is covered in RFC 768.
> 
> For IPv4, anyway. It's required for v6.

Or is it?

https://tools.ietf.org/html/rfc6935



Re: iked wrongly processes traffic selectors

2020-07-20 Thread Tobias Heider
On Mon, Jul 20, 2020 at 12:03:57PM +0300, Антон Касимов wrote:
> I am using OpenBSD 6.7
> iked does not respect mixing ports in the source and the destination of
> traffic selectors.
> 
> Such policy in iked.conf
> ikev2 "epsilon" active \
> proto tcp \
> from ::::30 to :::10::2 port 8000 \
> from ::::30 port postgresql to ::::/48 \
> from ::::30 port postgresql to ::::/48 \
> peer d.d.d
> 
> Produces wrong flows (specifying only destination port from first selector):
> 
> flow esp in proto tcp from ::::/48 port 8000 to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp in proto tcp from ::::/48 *port 8000* to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp in proto tcp from ::::2 *port 8000* to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from ::::30 to ::::/48 port
> 8000  peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d::/48 *port
> 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d:10::2 *port
> 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> 
> -- 
> Антон Касимов / Anton Kasimov

Hi Anton,

thanks for the report.
Below is a diff that should fix your problem.

Index: parse.y
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/parse.y,v
retrieving revision 1.102
diff -u -p -r1.102 parse.y
--- parse.y 25 Jun 2020 13:05:58 -  1.102
+++ parse.y 20 Jul 2020 20:06:53 -
@@ -344,6 +344,7 @@ struct ipsec_addr_wrap {
sa_family_t  af;
unsigned int type;
unsigned int action;
+   uint16_t port;
char*name;
struct ipsec_addr_wrap  *next;
struct ipsec_addr_wrap  *tail;
@@ -353,8 +354,6 @@ struct ipsec_addr_wrap {
 struct ipsec_hosts {
struct ipsec_addr_wrap  *src;
struct ipsec_addr_wrap  *dst;
-   uint16_t sport;
-   uint16_t dport;
 };
 
 struct ipsec_filters {
@@ -649,9 +648,9 @@ hosts   : FROM host port TO host port   
{
err(1, "hosts: calloc");
 
$$->src = $2;
-   $$->sport = $3;
+   $$->src->port = $3;
$$->dst = $5;
-   $$->dport = $6;
+   $$->dst->port = $6;
}
| TO host port FROM host port   {
struct ipsec_addr_wrap *ipa;
@@ -667,9 +666,9 @@ hosts   : FROM host port TO host port   
{
err(1, "hosts: calloc");
 
$$->src = $5;
-   $$->sport = $6;
+   $$->src->port = $6;
$$->dst = $2;
-   $$->dport = $3;
+   $$->dst->port = $3;
}
;
 
@@ -2936,14 +2935,14 @@ create_ike(char *name, int af, uint8_t i
flow->flow_src.addr_af = ipa->af;
flow->flow_src.addr_mask = ipa->mask;
flow->flow_src.addr_net = ipa->netaddress;
-   flow->flow_src.addr_port = hosts->sport;
+   flow->flow_src.addr_port = ipa->port;
 
memcpy(>flow_dst.addr, >address,
sizeof(ipb->address));
flow->flow_dst.addr_af = ipb->af;
flow->flow_dst.addr_mask = ipb->mask;
flow->flow_dst.addr_net = ipb->netaddress;
-   flow->flow_dst.addr_port = hosts->dport;
+   flow->flow_dst.addr_port = ipb->port;
 
ippn = ipa->srcnat;
if (ippn) {



l2ip + ipsec question

2020-07-20 Thread kasak

Hello misc.
Recently, i needed to setup l2tp-ipsec for some ip phones to reach my 
network.


so, the l2tp part is not trouble at all with npppd, but, the ipsec part 
is harder to understand.


after reading ipsec and ipsec.conf man,

i tryed to add just one line:

ike passive from my.ga.te.ip to any psk "mykey"

but this didn't work.

after some googling, i have found this line:

ike passive esp transport \
proto udp from 1.2.3.4 to any port 1701 \
main auth "hmac-sha1" enc "3des" group modp1024 \
quick auth "hmac-sha1" enc "aes" \
psk "password"

it was found on undeadly.org

I need help to understand how it even works.

1) why does somebody use "transport" here and somebody use "tunnel"? I 
myself tryed "transport" and it works. than, what is the difference for 
l2tp?


2) ipsec.conf man, says that "esp" is default. But if I omit this 
option, it stops working with error like: PAYLOAD_MALFORMED.


3) and the most difficult for me to understand: Why does all howto's use 
this fragment:


proto udp from my.ga.te.ip to any port 1701 ??

the ipsec.conf man says: from src [port sport] [(srcnat)] to dst [port 
dport]


so, this line declare a tunnel, where our gate use any port, and our 
expected remote client use port 1701?? why does this even work?


Thank you in advance for help!




Re: athn(4): hidenwid?

2020-07-20 Thread Mogens Jensen
‐‐‐ Original Message ‐‐‐
On Thursday, July 16, 2020 9:33 AM, Stefan Sperling  wrote:

> Nevermind, I have found the problem.

Thanks.

BTW some time ago I watched your EuroBSDcon 2017 talk on device driver
development. I found this introduction very clear and interesting.


Regards,
Mogens Jensen



Re: gdb in uninterruptible wait

2020-07-20 Thread Julian Smith
On Mon, 20 Jul 2020 15:26:11 +
Visa Hankala  wrote:

> On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote:
> > On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote:  
> > > I've been finding egdb and gdb rather easily get stuck in an
> > > uninterruptible wait, e.g. when running the 'next' command after
> > > hitting a breakpoint.

[...]

> > The single-thread check done by wait4() is non-interruptible.
> > When the debugger gets stuck, is it blocked in "suspend" state?

ps reports it to be in state 'D'.

> > 
> > However, I think there is a bug in the single-thread switch code.
> > It looks that ps_singlecount can be decremented too much. This
> > probably is a regression of making ps_singlecount unsigned and
> > letting single_thread_check() run without the kernel lock.
> > 
> > The bug might go away if single_thread_check() made sure that
> > P_SUSPSINGLE is set before the thread suspends.   
> 
> Below is an updated patch for testing. It extends the scope of
> SCHED_LOCK() so that there are fewer chances of interleaving of
> single_thread_set() and single_thread_check().

Many thanks for these patches. I'll try to test in the next couple of
days. Though the last time i built an OpenBSD kernel was well over a
decade ago, so it might take me a little longer.

Thanks,

- Jules


> 
> One problem is that once single_thread_set() sets ps_single, the other
> threads can enter the suspension code in single_thread_check(). The
> extended lock scope prevents the threads from taking action before
> single_thread_set() has finished with the state updates.
> 
> Index: kern/kern_sig.c
> ===
> RCS file: src/sys/kern/kern_sig.c,v
> retrieving revision 1.258
> diff -u -p -r1.258 kern_sig.c
> --- kern/kern_sig.c   15 Jun 2020 13:18:33 -  1.258
> +++ kern/kern_sig.c   20 Jul 2020 13:29:50 -
> @@ -1915,16 +1915,17 @@ single_thread_check(struct proc *p, int 
>   return (EINTR);
>   }
>  
> + SCHED_LOCK(s);
>   if (atomic_dec_int_nv(>ps_singlecount)
> == 0) wakeup(>ps_singlecount);
>   if (pr->ps_flags & PS_SINGLEEXIT) {
> + SCHED_UNLOCK(s);
>   KERNEL_LOCK();
>   exit1(p, 0, 0, EXIT_THREAD_NOCHECK);
> - KERNEL_UNLOCK();
> + /* NOTREACHED */
>   }
>  
>   /* not exiting and don't need to unwind, so
> suspend */
> - SCHED_LOCK(s);
>   p->p_stat = SSTOP;
>   mi_switch();
>   SCHED_UNLOCK(s);
> @@ -1950,7 +1951,7 @@ single_thread_set(struct proc *p, enum s
>  {
>   struct process *pr = p->p_p;
>   struct proc *q;
> - int error;
> + int error, s;
>  
>   KERNEL_ASSERT_LOCKED();
>   KASSERT(curproc == p);
> @@ -1974,26 +1975,22 @@ single_thread_set(struct proc *p, enum s
>   panic("single_thread_mode = %d", mode);
>  #endif
>   }
> + SCHED_LOCK(s);
>   pr->ps_singlecount = 0;
>   membar_producer();
>   pr->ps_single = p;
>   TAILQ_FOREACH(q, >ps_threads, p_thr_link) {
> - int s;
> -
>   if (q == p)
>   continue;
>   if (q->p_flag & P_WEXIT) {
>   if (mode == SINGLE_EXIT) {
> - SCHED_LOCK(s);
>   if (q->p_stat == SSTOP) {
>   setrunnable(q);
>   atomic_inc_int(>ps_singlecount);
>   }
> - SCHED_UNLOCK(s);
>   }
>   continue;
>   }
> - SCHED_LOCK(s);
>   atomic_setbits_int(>p_flag, P_SUSPSINGLE);
>   switch (q->p_stat) {
>   case SIDL:
> @@ -2027,8 +2024,8 @@ single_thread_set(struct proc *p, enum s
>   signotify(q);
>   break;
>   }
> - SCHED_UNLOCK(s);
>   }
> + SCHED_UNLOCK(s);
>  
>   if (mode != SINGLE_PTRACE)
>   single_thread_wait(pr, 1);
> 
> 



-- 
http://op59.net



Re: DHCPD issue

2020-07-20 Thread Kenneth Gober
On Mon, Jul 20, 2020 at 3:06 AM Charlie Burnett  wrote:

> 1. I cannot connect to the internet properly unless only em0 (which is the
> ethernet port I have connected to the external network) has a hostname
> file- I have to either add back the hostname files after boot and run
> /etc/netsetup or manually set up the internal network ports through
> ifconfig.
>

I am guessing (due to lack of details) that your issue is that you are
running
a DHCP client on multiple interfaces, and as a result you are ending up with
multiple default routes.  It is normal when getting an IP address with DHCP
to be provided with a default route, so if you're using DHCP to get an IP
address
from your upstream provider you should not also use DHCP on any internal
interfaces (unless you want to server DHCP as a DHCP server).  Static IP
address assignments on your internal interfaces will work fine.

2. Even once the box is connected properly to the network, its' seemingly
> unable to assign leases to other clients, attempting to connect to it
> through another OpenBSD machine results in it timing out while getting a
> lease.
>

I cannot guess the issue here without seeing your dhcpd.conf.


> 3. Using the same exact config, I ran it behind a standard proprietary
> router (linksys) that connects fine externally. Using that, the box
> functions as expected.
> 4. Using an openwrt router I get similar errors.


Are the Linksys and Openwrt routers serving the same IP address ranges
to DHCP clients?  If not, it's possible that the one that's not working is
using the same subnet as you have assigned to an internal interface on
the APU2.

5. I'm using both config that I've used on external networks as well as
>
subnetworks on a corporate network that worked, and the default config from
> the setting up a router page for a sanity check.
>

It is unclear what the outcome was here, and without knowing how those
external and corporate networks were set up, I'm not able to guess what
those configs might have been.  In terms of useful information you could
just as well have said "I tried something random but I'm not going to tell
you the result."


> 6. I assumed it was DHCP, but nonetheless as a sanity check I had pf pass
> through anything and everything, worked internally as well as externally.
> I'm at a complete loss- seeing as it occurs on openwrt I assume that its'
> probably because of however the hell my landlord set up the network, but
> anyone remotely have an idea how to begin debugging this? I don't like
> particularly having a proprietary router running especially without a
> firewall I trust.
>

The way you debug this is to first establish that you have Internet
connectivity
as an endpoint.  Don't worry about routing at all.  Once that is confirmed
working
then you can enable your internal interfaces and turn on forwarding.  Once
you're
sure that routing is working, you can then start offering internal services
like DHCP
and DNS.

If you use a default deny/deny PF policy (both block in and block out by
default)
keep in mind that you may need to explicitly add pass out rules to allow
things like
the DHCP client to work.  Remember that a default block out rule will block
both
forwarded traffic trying to go out the egress interface, as well as
non-forwarded
traffic that originates from the router itself (like DHCP requests, DNS
requests,
NTP requests, etc.)  I used to use a "pass out from (self)" rule to cover
these but
have since switched to explicit rules so that I can have more certainty
about what
exactly my router is sending.

-ken


Re: gdb in uninterruptible wait

2020-07-20 Thread Visa Hankala
On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote:
> On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote:
> > I've been finding egdb and gdb rather easily get stuck in an
> > uninterruptible wait, e.g. when running the 'next' command after
> > hitting a breakpoint.
> > 
> > So it's not possible to kill the debuggee or gdb and the only way to
> > kill the debuggee process and free up its listening sockets seems to be
> > to reboot the entire system.
> > 
> > Perhaps unsurprisingly one cannot attach a second invocation of gdb to
> > the uninterruptible gdb, so i don't know for sure what syscall is being
> > run that is getting stuck.
> > 
> > The debuggee is a local build of the flightgear flight simulator.
> > 
> > Here's the output of ps for the debugger and debuggee:
> > 
> > 12419 p0  D0:34.37 egdb -ex handle SIGPIPE noprint nostop -ex set 
> > print thread-events off -ex set print pretty on -ex run --args 
> > build-walk/fgfs,clang,debug,opt,co
> > 63921 p0  TX+  0:42.45 
> > /home/jules/flightgear/build-walk/fgfs,clang,debug,opt,compositor,osg.exe 
> > --airport=egtk (fgfs,clang,debug)
> > 
> > I've tried using ktrace on egdb, and the kdump output ends like this:
> > 
> >  53950 egdb CALL  wait4(WAIT_ANY,0x7f7e8efc,0<>,0)
> >  53950 egdb RET   wait4 97562/0x17d1a
> >  53950 egdb CALL  ptrace(PT_GET_PROCESS_STATE,97562,0x7f7e8ef0,12)
> >  53950 egdb RET   ptrace 0
> >  53950 egdb CALL  ptrace(PT_GETREGS,161560,0x7f7e8b40,0)
> >  53950 egdb RET   ptrace 0
> >  53950 egdb CALL  
> > futex(0x6444e37c490,0x82,1,0,0)
> >  53950 egdb RET   futex 0
> >  53950 egdb CALL  
> > futex(0x644bef12740,0x82,1,0,0)
> >  53950 egdb RET   futex 0
> >  53950 egdb CALL  ptrace(PT_IO,97562,0x7f7e8a30,0)
> >  53950 egdb RET   ptrace 0
> >  53950 egdb CALL  ptrace(PT_IO,97562,0x7f7e8a30,0)
> >  53950 egdb RET   ptrace 0
> >  53950 egdb CALL  ptrace(PT_STEP,97562,0x1,0)
> >  53950 egdb RET   ptrace 0
> >  53950 egdb CALL  read(6,0x7f7e9187,0x1)
> >  53950 egdb RET   read -1 errno 35 Resource temporarily unavailable
> >  53950 egdb CALL  poll(0x6441581e720,3,0)
> >  53950 egdb STRU  struct pollfd [3] { fd=4, events=0x1, 
> > revents=0<> } { fd=6, events=0x1, revents=0<> } { fd=10, 
> > events=0x1, revents=0<> }
> >  53950 egdb RET   poll 0
> >  53950 egdb CALL  wait4(WAIT_ANY,0x7f7e8efc,0<>,0)
> > 
> > Assuming that this is the actual end of the ktrace output and there
> > isn't some missing ktrace output in a buffer somewhere, this looks
> > like egdb is simply blocked in wait4(), which should be harmless and
> > certainly not uninterruptable?
> 
> The single-thread check done by wait4() is non-interruptible.
> When the debugger gets stuck, is it blocked in "suspend" state?
> 
> However, I think there is a bug in the single-thread switch code.
> It looks that ps_singlecount can be decremented too much. This probably
> is a regression of making ps_singlecount unsigned and letting
> single_thread_check() run without the kernel lock.
> 
> The bug might go away if single_thread_check() made sure that
> P_SUSPSINGLE is set before the thread suspends. 

Below is an updated patch for testing. It extends the scope of
SCHED_LOCK() so that there are fewer chances of interleaving of
single_thread_set() and single_thread_check().

One problem is that once single_thread_set() sets ps_single, the other
threads can enter the suspension code in single_thread_check(). The
extended lock scope prevents the threads from taking action before
single_thread_set() has finished with the state updates.

Index: kern/kern_sig.c
===
RCS file: src/sys/kern/kern_sig.c,v
retrieving revision 1.258
diff -u -p -r1.258 kern_sig.c
--- kern/kern_sig.c 15 Jun 2020 13:18:33 -  1.258
+++ kern/kern_sig.c 20 Jul 2020 13:29:50 -
@@ -1915,16 +1915,17 @@ single_thread_check(struct proc *p, int 
return (EINTR);
}
 
+   SCHED_LOCK(s);
if (atomic_dec_int_nv(>ps_singlecount) == 0)
wakeup(>ps_singlecount);
if (pr->ps_flags & PS_SINGLEEXIT) {
+   SCHED_UNLOCK(s);
KERNEL_LOCK();
exit1(p, 0, 0, EXIT_THREAD_NOCHECK);
-   KERNEL_UNLOCK();
+   /* NOTREACHED */
}
 
/* not exiting and don't need to unwind, so suspend */
-   SCHED_LOCK(s);
p->p_stat = SSTOP;
mi_switch();
SCHED_UNLOCK(s);
@@ -1950,7 +1951,7 @@ single_thread_set(struct proc *p, enum s
 {
struct process *pr = p->p_p;
struct proc *q;
- 

Re: iked wrongly processes traffic selectors

2020-07-20 Thread Stuart Henderson
Moving to bugs@:

In gmane.os.openbsd.misc, Anton Kasmov wrote:
> I am using OpenBSD 6.7
> iked does not respect mixing ports in the source and the destination of
> traffic selectors.
>
> Such policy in iked.conf
> ikev2 "epsilon" active \
> proto tcp \
> from ::::30 to :::10::2 port 8000 \
> from ::::30 port postgresql to ::::/48 \
> from ::::30 port postgresql to ::::/48 \
> peer d.d.d
>
> Produces wrong flows (specifying only destination port from first selector):
>
> flow esp in proto tcp from ::::/48 port 8000 to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp in proto tcp from ::::/48 *port 8000* to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp in proto tcp from ::::2 *port 8000* to
> ::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from ::::30 to ::::/48 port
> 8000  peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d::/48 *port
> 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
> flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d:10::2 *port
> 8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require

Actually whatever is used as "port" on the first selector is used for all
other selectors; if there is no port on the first selector, no port is used
for any others.

I had a look but I think it's beyond my yacc skills.



Re: DHCPD issue

2020-07-20 Thread Zé Loff



On Mon, Jul 20, 2020 at 02:06:37AM -0500, Charlie Burnett wrote:
> Hi,
> I've set up a good deal of openbsd firewalls in a professional environment
> before with little to no issue. I'm trying to set one up for me personally
> though, and am having some bizarre issues, with no clue where to begin
> trying to fix them. This is on an APU unit from PC Engines. I've managed to
> figure out a couple things when trying to debug this:
> 1. I cannot connect to the internet properly unless only em0 (which is the
> ethernet port I have connected to the external network) has a hostname
> file- I have to either add back the hostname files after boot and run
> /etc/netsetup or manually set up the internal network ports through
> ifconfig.
> 2. Even once the box is connected properly to the network, its' seemingly
> unable to assign leases to other clients, attempting to connect to it
> through another OpenBSD machine results in it timing out while getting a
> lease.
> 3. Using the same exact config, I ran it behind a standard proprietary
> router (linksys) that connects fine externally. Using that, the box
> functions as expected.
> 4. Using an openwrt router I get similar errors.
> 5. I'm using both config that I've used on external networks as well as
> subnetworks on a corporate network that worked, and the default config from
> the setting up a router page for a sanity check.
> 6. I assumed it was DHCP, but nonetheless as a sanity check I had pf pass
> through anything and everything, worked internally as well as externally.
> I'm at a complete loss- seeing as it occurs on openwrt I assume that its'
> probably because of however the hell my landlord set up the network, but
> anyone remotely have an idea how to begin debugging this? I don't like
> particularly having a proprietary router running especially without a
> firewall I trust.
> Best,
> Charlie

As has been posted, without config files nor ifconfig outputs it's hard
to figure out what might be going wrong.  Are you by any chance serving
DHCP internally on the same network segment (e.g. 192.168.0.0/24) that
you get from your landlord?

-- 
 



iked wrongly processes traffic selectors

2020-07-20 Thread Антон Касимов
I am using OpenBSD 6.7
iked does not respect mixing ports in the source and the destination of
traffic selectors.

Such policy in iked.conf
ikev2 "epsilon" active \
proto tcp \
from ::::30 to :::10::2 port 8000 \
from ::::30 port postgresql to ::::/48 \
from ::::30 port postgresql to ::::/48 \
peer d.d.d

Produces wrong flows (specifying only destination port from first selector):

flow esp in proto tcp from ::::/48 port 8000 to
::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
flow esp in proto tcp from ::::/48 *port 8000* to
::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
flow esp in proto tcp from ::::2 *port 8000* to
::::30 peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
flow esp out proto tcp from ::::30 to ::::/48 port
8000  peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d::/48 *port
8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require
flow esp out proto tcp from 2a04:5200:fff5::30 to fdd3:d128:dc2d:10::2 *port
8000* peer d.d.d srcid FQDN/a.a.a dstid FQDN/d.d.d type require

-- 
Антон Касимов / Anton Kasimov


Re: OpenBSD Hangs On

2020-07-20 Thread jin
Hi

As suggested earlier, i've upgrade system to 6.7 and my problem solved.

Thanks

On Mon, Jun 22, 2020, 16:20 jin 
wrote:

> Hello
>
> I've a virtual appliance on kvm and it hangs on every 3 days
> period approximately. The problem been there since its installation which
> was in March. When it happens, I can only make hard shutdown/reboot to
> recover my system from this issue because the system doesn't respond me.
> I'm using version 6.6 of OpenBSD and i already applied the all syspatches.
> I'm not certain but it looks like the problem could be related with syslog
> deamon.  May be it is too early to make an assumption but log messages
> (/var/log/messages) show that syslog daemon keeps restarting itself in 4
> hours periods.
>
> Could someone please point me to how to increase verbosity of the logs ?
> I'ld like to dig myself as much as possible.
>
> Fatih
> Sincerely
>
> dmesg output
>
> OpenBSD 6.6 (GENERIC) #7: Thu Mar 12 10:32:29 MDT 2020
> r...@syspatch-66-amd64.openbsd.org:
> /usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 1056817152 (1007MB)
> avail mem = 1012228096 (965MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5940 (9 entries)
> bios0: vendor SeaBIOS version "
> rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Westmere E56xx/L56xx/X56xx (Nehalem-C), 2295.15 MHz, 06-2c-01
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,HV,NXE,LONG,LAHF,ARAT,MELTDOWN
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpihpet0 at acpi0: 1 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> "ACPI0006" at acpi0 not configured
> acpipci0 at acpi0 PCI0: _OSC failed
> acpicmos0 at acpi0
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "QEMU0002" at acpi0 not configured
> "ACPI0010" at acpi0 not configured
> cpu0: using IvyBridge MDS workaround
> pvbus0 at mainbus0: KVM
> pvclock0 at pvbus0
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> pciide0: channel 1 disabled (no drives)
> uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
> piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0
> int 9
> iic0 at piixpm0
> vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio0: address 52:54:00:a5:1f:57
> virtio0: msix shared
> eap0 at pci0 dev 4 function 0 "Ensoniq AudioPCI" rev 0x00: apic 0 int 11
> audio0 at eap0
> midi0 at eap0: 
> virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio1
> scsibus1 at vioblk0: 2 targets
> sd0 at scsibus1 targ 0 lun 0: 
> sd0: 51200MB, 512 bytes/sector, 104857600 sectors
> virtio1: msix shared
> virtio2 at pci0 dev 6 function 0 "Qumranet Virtio Memory Balloon" rev 0x00
> viomb0 at virtio2
> virtio2: apic 0 int 10
> isa0 at pcib0
> isadma0 at isa0
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> 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
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev
> 1.00/1.00 addr 1
> uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet"
> rev 2.00/0.00 addr 2
> uhidev0: iclass 3/0
> ums0 at uhidev0: 3 buttons, Z dir
> wsmouse1 at ums0 mux 0
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on sd0a (496659ef9c4468e2.a) swap on sd0b dump on sd0b
> WARNING: / was not properly unmounted
> fd0 at fdc0 drive 1: density unknown
> 

Re: backtrace_symbols() not showing line numbers, and small patch for backtrace.3 manpage.

2020-07-20 Thread Stuart Henderson
On 2020-07-17, Julian Smith  wrote:
> For me, backtrace_symbols() does not show line-numbers. Is this the
> intended behaviour?

It is working as shown in upstream's example:

https://github.com/conformal/backtrace/wiki

So I'd say this is as expected.

> I'm using:
> OpenBSD jules-obsd 6.7 GENERIC.MP#182 amd64
> libexecinfo-0.3p2v0
>
> With 'cc -g -Wl,--export-dynamic', i'm getting backtraces like:
>
> 0x69854ee369  at ./foo.c.exe
> 0x69854ee477  at ./foo.c.exe
> 0x69854ee4be  at ./foo.c.exe
> 0x69854ee13b <__start+315> at ./foo.c.exe
>
> [gdb can show line numbers on the same executable, so the information
> is definitely in the executable somewhere.]
>
> I'm testing with this code:
>
>
> #include 
> #include 
> #include 
> #include 
>
> void bar()
> {
> void*   bt[20];
> char**  strings;
> int i;
> int d;
> 
> d = backtrace(bt, sizeof(bt) / sizeof(bt[0]));
> if (d == -1)
> errx(1, "backtrace");
>
> strings = backtrace_symbols(bt, d);
>
> if (strings == NULL)
> errx(1, "backtrace_symbols");
>
> for (i = 0; i < d; i++)
> printf("%s\n", strings[i]);
>
> free(strings);
> }
>
> void foo(void)
> {
> bar();
> }
>
> int main(void)
> {
> foo();
> return 0;
> }
>===
>
> Build with:
> cc -g -o foo.c.exe foo.c -I /usr/local/include -g -L /usr/local/lib
> -lexecinfo -Wl,--export-dynamic
>
> Run:
> ./foo.c.exe
>
> Output:
> 0x69854ee369  at ./foo.c.exe
> 0x69854ee477  at ./foo.c.exe
> 0x69854ee4be  at ./foo.c.exe
> 0x69854ee13b <__start+315> at ./foo.c.exe
>
>
>
>
> Also, here's a small diff for /usr/local/man/man3/backtrace.3, which
> makes the code example more directly usable and fixes a misprint of
> '\n':
>
> --- /usr/local/man/man3/backtrace.3 Fri May  8 19:49:25 2020
> +++ backtrace.3 Fri Jul 17 11:09:15 2020
> @@ -63,14 +63,17 @@
>  The following code fragment illustrates the use of the backtrace
>  functionality:
>  .Bd -literal -offset indent
> +#include 
> +#include 
> +
>  void
>  print_backtrace(void)
>  {
> -   void*bt[BT_MAX_DEPTH];
> +   void*bt[20];
> char**strings;
> int i, d;
>  
> -d = backtrace(bt, BT_MAX_DEPTH);
> +d = backtrace(bt, sizeof(bt) / sizeof(bt[0]));
> if (d == -1)
> errx(1, "backtrace");
>  
> @@ -80,7 +83,7 @@
> errx(1, "backtrace_symbols");
>  
> for (i = 0; i < d; i++)
> -   printf("%s\n", strings[i]);
> +   printf("%s\\n", strings[i]);
>  
> free(strings);
>  }
>
> Thanks,
>
> - Jules
>



Re: DHCPD issue

2020-07-20 Thread Stuart Henderson
Many people are using OpenBSD on APUs as routers and DHCP servers with
no problems. Maybe someone can help if you show the configuration you
are trying to use (hostname.* files, rc.conf.local, dhcpd.conf,
etc.)


On 2020-07-20, Charlie Burnett  wrote:
> Hi,
> I've set up a good deal of openbsd firewalls in a professional environment
> before with little to no issue. I'm trying to set one up for me personally
> though, and am having some bizarre issues, with no clue where to begin
> trying to fix them. This is on an APU unit from PC Engines. I've managed to
> figure out a couple things when trying to debug this:
> 1. I cannot connect to the internet properly unless only em0 (which is the
> ethernet port I have connected to the external network) has a hostname
> file- I have to either add back the hostname files after boot and run
> /etc/netsetup or manually set up the internal network ports through
> ifconfig.
> 2. Even once the box is connected properly to the network, its' seemingly
> unable to assign leases to other clients, attempting to connect to it
> through another OpenBSD machine results in it timing out while getting a
> lease.
> 3. Using the same exact config, I ran it behind a standard proprietary
> router (linksys) that connects fine externally. Using that, the box
> functions as expected.
> 4. Using an openwrt router I get similar errors.
> 5. I'm using both config that I've used on external networks as well as
> subnetworks on a corporate network that worked, and the default config from
> the setting up a router page for a sanity check.
> 6. I assumed it was DHCP, but nonetheless as a sanity check I had pf pass
> through anything and everything, worked internally as well as externally.
> I'm at a complete loss- seeing as it occurs on openwrt I assume that its'
> probably because of however the hell my landlord set up the network, but
> anyone remotely have an idea how to begin debugging this? I don't like
> particularly having a proprietary router running especially without a
> firewall I trust.
> Best,
> Charlie
>



Re: OpenBSD and HP ProBook 445 G7

2020-07-20 Thread Stefan Sperling
On Mon, Jul 20, 2020 at 02:14:17PM +0800, Tito Mari Francis Escaño wrote:
> Good day to everyone at misc.
> Has anybody tried tried checking how OpenBSD worked with HP ProBook 445 G7
> with Ryzen 5 or 7 4000 and Intel AX200 WLAN card?

AX200 wifi will work. I would recommend -current for best results.



DHCPD issue

2020-07-20 Thread Charlie Burnett
Hi,
I've set up a good deal of openbsd firewalls in a professional environment
before with little to no issue. I'm trying to set one up for me personally
though, and am having some bizarre issues, with no clue where to begin
trying to fix them. This is on an APU unit from PC Engines. I've managed to
figure out a couple things when trying to debug this:
1. I cannot connect to the internet properly unless only em0 (which is the
ethernet port I have connected to the external network) has a hostname
file- I have to either add back the hostname files after boot and run
/etc/netsetup or manually set up the internal network ports through
ifconfig.
2. Even once the box is connected properly to the network, its' seemingly
unable to assign leases to other clients, attempting to connect to it
through another OpenBSD machine results in it timing out while getting a
lease.
3. Using the same exact config, I ran it behind a standard proprietary
router (linksys) that connects fine externally. Using that, the box
functions as expected.
4. Using an openwrt router I get similar errors.
5. I'm using both config that I've used on external networks as well as
subnetworks on a corporate network that worked, and the default config from
the setting up a router page for a sanity check.
6. I assumed it was DHCP, but nonetheless as a sanity check I had pf pass
through anything and everything, worked internally as well as externally.
I'm at a complete loss- seeing as it occurs on openwrt I assume that its'
probably because of however the hell my landlord set up the network, but
anyone remotely have an idea how to begin debugging this? I don't like
particularly having a proprietary router running especially without a
firewall I trust.
Best,
Charlie


OpenBSD and HP ProBook 445 G7

2020-07-20 Thread Tito Mari Francis Escaño
Good day to everyone at misc.
Has anybody tried tried checking how OpenBSD worked with HP ProBook 445 G7
with Ryzen 5 or 7 4000 and Intel AX200 WLAN card?
Unfortunately, being in the Philippines, I can't yet check because it's not
yet available here, and I was hoping someone in the community can verify if
it work well or not.
Hope somebody can advise me and the community on this. Thanks so much.