Re: Unbound Notice: "sendto failed: No buffer space available"
On Thu, Apr 16, 2020 at 10:28:55AM +0200, Ben wrote: > > AFAIU, ENOBUFS happens when the NIC transmit queue is full. Have you looked > > at the interface statistics to see if there are many dropped packets? Try, > > e.g., > > > > $ netstat -ni > > NameMtu Network Address Ipkts IfailOpkts > Ofail Colls > em0 150000:30:48:92:24:b0 711639121 168364 838861401 > 1124769 0 > em0 1500 192.168.0/2 192.168.0.1 711639121 168364 838861401 > 1124769 0 0.13% failure rate. > pppoe0 1492 329558645 0 188975582 > 180546 0 > pppoe0 1492 81.12.67.201 81.12.67.12 329558645 0 188975582 > 180546 0 0.10% failure rate. > vlan4 150000:30:48:92:24:b0 109009001 0 167250501 > 4757578 0 > vlan4 1500 192.168.4/2 192.168.4.1 109009001 0 167250501 > 4757578 0 2.8% failure rate. I'm no network administrator, but a 3% failure rate would be very high on a physical interface. vlan4 is presumably the interface your Apple device passes through, right? Investigate why all the dropped packets. Start with your queuing rules: examine/enable PF statistics, examine/enable PF logs, or just disable queueing to rule it out entirely.
Re: Regarding randomized times in crontab
On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote: > That is a lot of words to cover a simple concept: > > The specific random values are selected when cron(5) loads > the crontab file. New numbers are chosen when crontab -e is used. > > If you understand that, the conclusions are obvious. Ah. Good. Then I know the restrictions. The random times are random, but fixed for the lifetime of the cron daemon (or until the crontab is reloaded due to being edited). And for Raul, yes I'm aware that randomly picked value can be the same as the last randomly picked value, but for most types of house keeping tasks, the quality of "random" is less interesting. You are however correct in that my question wasn't totally coherent, but at least Theo got my drift. Cheers, > > > Raul Miller wrote: > > > That's a poorly phrased question, to be honest. > > > > In one sense the point in time where the job is scheduled has to be > > different -- it's a point in time in a different 24 hour period. > > > > But in another sense (a sense closer to what you probably intended) > > the point in time can't be guaranteed to be different. There's a > > finite number of minutes in a day and picking one pseudo-randomly > > would occasionally collide. Consider, as an extreme example, a system > > which reboots often and is only up for 1 minute every 24 hour period. > > > > But, such collisions should be rare, and that specific extreme case > > example was ludicrous. > > > > Anyways, on a normally operating machine, you should expect the same > > minute to be used slightly more often than once every four years. And, > > a difference less than 2 minutes would happen more often (around once > > a year, depending on exactly where you draw the line). > > > > But, if you don't trust what I have said here (and maybe you should > > not) what you really want to understand is the algorithm being used, > > and the best way to discover that is to look at the implementation. > > https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to > > look at the implementation of get_range() in usr.sbin/cron/entry.c > > > > FYI, > > > > > > -- > > Raul > > > > On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri > > wrote: > > > > > > Thanks for that! > > > > > > Also, considering a job scheduled like > > > > > > ~ ~ * * * somecommand > > > > > > I'm assuming, provided that the cron daemon is not restarted, this would > > > run the job at a single random point in each 24h period, right? A > > > *different* point in time, each 24 period? > > > > > > > > > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > > > Yes. > > > > > > > > But that problem already existed with the minutes field being >close to > > > > the moment cron was restarted. > > > > > > > > Only difference is now you don't know the minute. > > > > > > > > > > > > Andreas Kusalananda Kähäri wrote: > > > > > > > > > Thanks for the ~ crontab(5) feature! > > > > > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > > > interval during which a cron job may be randomly triggered, is there a > > > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Andreas (Kusalananda) Kähäri > > > > > SciLifeLab, NBIS, ICM > > > > > Uppsala University, Sweden > > > > > > > > > > . > > > > > > > > > > > -- > > > Andreas (Kusalananda) Kähäri > > > SciLifeLab, NBIS, ICM > > > Uppsala University, Sweden > > > > > > . > > > > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: mount dir over another dir
NFS did the trick. Although this made me to apply some unusual pf rules to
make portmapper work
pass in inet proto { tcp udp } from self to self port { 111 2049 }
pass out inet proto { tcp udp } from self to self port { 111 2049 }
without it nfsd[70598]: can't register with udp portmap
Thank you.
чт, 16 апр. 2020 г. в 16:16, Adam Thompson :
> On 2020-04-16 02:13, Ono Caritofilaxy wrote:
> > Hello.
> >
> > I want to mount /usr/local/srcdir /usr/local/dstdir/subdir
> >
> > answer was "no" 3 years ago
> > https://marc.info/?l=openbsd-misc=149743861203607=2
> >
> > Can I do this now?
> > If not - why? Is it dangerous?
>
> You should be able to do this as an NFS mount. With all the nastiness
> that NFS mounts come with, but it's an option. (I'm doing it in
> production on 6.6-STABLE.)
> -Adam
>
Re: Regarding randomized times in crontab
That is a lot of words to cover a simple concept: The specific random values are selected when cron(5) loads the crontab file. New numbers are chosen when crontab -e is used. If you understand that, the conclusions are obvious. Raul Miller wrote: > That's a poorly phrased question, to be honest. > > In one sense the point in time where the job is scheduled has to be > different -- it's a point in time in a different 24 hour period. > > But in another sense (a sense closer to what you probably intended) > the point in time can't be guaranteed to be different. There's a > finite number of minutes in a day and picking one pseudo-randomly > would occasionally collide. Consider, as an extreme example, a system > which reboots often and is only up for 1 minute every 24 hour period. > > But, such collisions should be rare, and that specific extreme case > example was ludicrous. > > Anyways, on a normally operating machine, you should expect the same > minute to be used slightly more often than once every four years. And, > a difference less than 2 minutes would happen more often (around once > a year, depending on exactly where you draw the line). > > But, if you don't trust what I have said here (and maybe you should > not) what you really want to understand is the algorithm being used, > and the best way to discover that is to look at the implementation. > https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to > look at the implementation of get_range() in usr.sbin/cron/entry.c > > FYI, > > > -- > Raul > > On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri > wrote: > > > > Thanks for that! > > > > Also, considering a job scheduled like > > > > ~ ~ * * * somecommand > > > > I'm assuming, provided that the cron daemon is not restarted, this would > > run the job at a single random point in each 24h period, right? A > > *different* point in time, each 24 period? > > > > > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > > Yes. > > > > > > But that problem already existed with the minutes field being >close to > > > the moment cron was restarted. > > > > > > Only difference is now you don't know the minute. > > > > > > > > > Andreas Kusalananda Kähäri wrote: > > > > > > > Thanks for the ~ crontab(5) feature! > > > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > > interval during which a cron job may be randomly triggered, is there a > > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > > > > Regards, > > > > > > > > -- > > > > Andreas (Kusalananda) Kähäri > > > > SciLifeLab, NBIS, ICM > > > > Uppsala University, Sweden > > > > > > > > . > > > > > > > > -- > > Andreas (Kusalananda) Kähäri > > SciLifeLab, NBIS, ICM > > Uppsala University, Sweden > > > > . > > >
Re: Regarding randomized times in crontab
That's a poorly phrased question, to be honest. In one sense the point in time where the job is scheduled has to be different -- it's a point in time in a different 24 hour period. But in another sense (a sense closer to what you probably intended) the point in time can't be guaranteed to be different. There's a finite number of minutes in a day and picking one pseudo-randomly would occasionally collide. Consider, as an extreme example, a system which reboots often and is only up for 1 minute every 24 hour period. But, such collisions should be rare, and that specific extreme case example was ludicrous. Anyways, on a normally operating machine, you should expect the same minute to be used slightly more often than once every four years. And, a difference less than 2 minutes would happen more often (around once a year, depending on exactly where you draw the line). But, if you don't trust what I have said here (and maybe you should not) what you really want to understand is the algorithm being used, and the best way to discover that is to look at the implementation. https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to look at the implementation of get_range() in usr.sbin/cron/entry.c FYI, -- Raul On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri wrote: > > Thanks for that! > > Also, considering a job scheduled like > > ~ ~ * * * somecommand > > I'm assuming, provided that the cron daemon is not restarted, this would > run the job at a single random point in each 24h period, right? A > *different* point in time, each 24 period? > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > Yes. > > > > But that problem already existed with the minutes field being >close to > > the moment cron was restarted. > > > > Only difference is now you don't know the minute. > > > > > > Andreas Kusalananda Kähäri wrote: > > > > > Thanks for the ~ crontab(5) feature! > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > interval during which a cron job may be randomly triggered, is there a > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > Regards, > > > > > > -- > > > Andreas (Kusalananda) Kähäri > > > SciLifeLab, NBIS, ICM > > > Uppsala University, Sweden > > > > > > . > > > > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . >
Re: Regarding randomized times in crontab
Thanks for that! Also, considering a job scheduled like ~ ~ * * * somecommand I'm assuming, provided that the cron daemon is not restarted, this would run the job at a single random point in each 24h period, right? A *different* point in time, each 24 period? On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > Yes. > > But that problem already existed with the minutes field being >close to > the moment cron was restarted. > > Only difference is now you don't know the minute. > > > Andreas Kusalananda Kähäri wrote: > > > Thanks for the ~ crontab(5) feature! > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > interval during which a cron job may be randomly triggered, is there a > > risk (or even guarantee) that the job may run a second time? > > > > > > Regards, > > > > -- > > Andreas (Kusalananda) Kähäri > > SciLifeLab, NBIS, ICM > > Uppsala University, Sweden > > > > . > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Regarding randomized times in crontab
Yes. But that problem already existed with the minutes field being >close to the moment cron was restarted. Only difference is now you don't know the minute. Andreas Kusalananda Kähäri wrote: > Thanks for the ~ crontab(5) feature! > > Question: If the cron daemon is restarted (e.g. via reboot) during the > interval during which a cron job may be randomly triggered, is there a > risk (or even guarantee) that the job may run a second time? > > > Regards, > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . >
Re: Traffic inspection with relayd
Here are some helpful links that have information about TLS inspection
with relayd in case you haven't already seen them:
https://www.openbsd.org/papers/relayd-asiabsdcon2013.pdf
https://www.openbsd.org/papers/relayd-slides-asiabsdcon2013.pdf
https://reykfloeter.com/posts/relayd-ssl-interception
https://man.openbsd.org/relayd.conf.5
Since you didn't say what IoT devices you're using, I'll mention that
this won't work if you can't configure them somehow. You need them to
point to/proxy through your router or trust your CA certificate. If
your router could inspect TLS packets without doing that, TLS would be
broken or the device would have a security issue. I don't think many
commercial IoT devices will let you do this kind of inspection.
If you're using devices that are open source or that allow you to
access the OS, another option is to monitor them or inspect what
they're doing on the devices or in the source code instead. The
downside is that you can't monitor all of them in one place, but it
might be your only option.
Tim
On Wed, Apr 15, 2020 at 2:31 PM Cornelius Jubjub
wrote:
>
> Hello all,
>
> First off, I hope everyone is staying happy, healthy and sane in these
> difficult times.
>
> I've been working on a little side project involving some IoT devices
> and I'm in the need of a HTTPS MITM proxy so I can do some traffic
> analysis. I'm running OpenBSD 6.6 as my firewall at home doing NAT and
> providing some other network plumbing (great term btw!). I have been
> exploring relayd to do this intercept on the firewall. Currently I have
> this config for a tls proxy:
>
> log connection
>
> http protocol httpfilter {
> return error
> pass
> match url log
>
> tls ca key "/etc/ssl/private/ca.key" password "stinkbutt"
> tls ca cert "/etc/ssl/ca.crt"
> }
>
> relay tlsmitm {
> listen on 127.0.0.1 port 8443 tls
> protocol httpfilter
> forward with tls to destination
> }
>
> EOF
>
> The issues I'm having are two fold, first off I can't, for the life of
> me get anything to appear in the log (/var/log/daemon) except for the
> usual daemon start and stops. Secondly, I'd really like to dump all of
> the traffic al la tcpdump but I don't really see a place to do so (no
> unencrypted data passes through an interface AFAIK).
>
> I'm hoping someone might be able to steer me in the right direction
> and maybe let me know if I'm using the wrong tool for the job.
>
> Thank you,
>
> CJ
>
Re: S3 Virge support on IBM T23 for 6.6
Thanks Janne for the tech insight. So, but for routerboards/CLI boxen, considering that this recent move hinders GUI for most P3s, the really viable ones remain P3s/K7s with different graphics boards (mostly desktop/tower) and early P4s without em64t. For all the following stuff there's no reason not to run amd64. Quite obsoleting and now few machines in order to support a full architecture on the long run, like VAX has recently shown. Pity, because best laptop keyboards still belong to this arch. Il gio 16 apr 2020, 08:44 Janne Johansson ha scritto: > Den ons 15 apr. 2020 kl 23:29 skrev Paolo Aglialoro : > >> Is this a hint that soon i386 architecture will be deprecated? >> Considering that supported hw (at least graphics) is going more and more >> to >> overlap with amd64, at the very end i386 would remain only for some >> routerboards. >> > > i386 has seen a fair share of deprecations, from the actual 386 CPUs and > 486s without FPU, to machines with 8,16,32,64M ram for whom reordering libs > and kernel isn't really doable with recent OpenBSD releases. > > -- > May the most significant bit of your life be positive. >
Regarding randomized times in crontab
Thanks for the ~ crontab(5) feature! Question: If the cron daemon is restarted (e.g. via reboot) during the interval during which a cron job may be randomly triggered, is there a risk (or even guarantee) that the job may run a second time? Regards, -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: mount dir over another dir
On 2020-04-16 02:13, Ono Caritofilaxy wrote: Hello. I want to mount /usr/local/srcdir /usr/local/dstdir/subdir answer was "no" 3 years ago https://marc.info/?l=openbsd-misc=149743861203607=2 Can I do this now? If not - why? Is it dangerous? You should be able to do this as an NFS mount. With all the nastiness that NFS mounts come with, but it's an option. (I'm doing it in production on 6.6-STABLE.) -Adam
Re: mount dir over another dir
On 2020-04-16, Ono Caritofilaxy wrote: > Hello. > > I want to mount /usr/local/srcdir /usr/local/dstdir/subdir > > answer was "no" 3 years ago > https://marc.info/?l=openbsd-misc=149743861203607=2 > > Can I do this now? Same as was mentioned in the earlier thread, you can do this by mounting over NFS from 127.0.0.1. If that isn't enough then you will need to rearrange partitions/mountpoints or you could try porting https://bindfs.org/ (using FUSE, which OpenBSD supports to some degree...) > If not - why? Is it dangerous? We used to have NULLFS but it was really always just meant as demonstration code, I don't recall the original reason for removing it but it has been gone for 15 years and since then nobody saw enough need to write non-demonstration code to replace it.
Re: Traffic inspection with relayd
"Cornelius Jubjub" writes:
> Hello all,
>
> First off, I hope everyone is staying happy, healthy and sane in these
> difficult times.
>
> I've been working on a little side project involving some IoT devices
> and I'm in the need of a HTTPS MITM proxy so I can do some traffic
> analysis. I'm running OpenBSD 6.6 as my firewall at home doing NAT and
> providing some other network plumbing (great term btw!). I have been
> exploring relayd to do this intercept on the firewall. Currently I have
> this config for a tls proxy:
>
> log connection
>
> http protocol httpfilter {
> return error
> pass
> match url log
>
> tls ca key "/etc/ssl/private/ca.key" password "stinkbutt"
> tls ca cert "/etc/ssl/ca.crt"
> }
>
> relay tlsmitm {
> listen on 127.0.0.1 port 8443 tls
> protocol httpfilter
> forward with tls to destination
> }
>
> EOF
>
> The issues I'm having are two fold, first off I can't, for the life of
> me get anything to appear in the log (/var/log/daemon) except for the
> usual daemon start and stops.
The default log level doesn't log anything besides starts and stops.
Try "relayctl log verbose". You also need to configure syslogd(8)
properly, for that and for things like log connection to work.
You also might try "relayctl monitor".
If you expect to see something but don't, the relayd configuration
isn't doing what you think it's doing. Here's one potential issue:
you might want to have your relay listening on the router's LAN
IP, to listen for incoming connections. I think that listening on
localhost will only catch stuff being sent within the router box, but I
could be wrong.
Make sure you've got the relayd anchor set up for pf, see relayd(8).
> Secondly, I'd really like to dump all of
> the traffic al la tcpdump but I don't really see a place to do so (no
> unencrypted data passes through an interface AFAIK).
> I'm hoping someone might be able to steer me in the right direction
> and maybe let me know if I'm using the wrong tool for the job.
>
> Thank you,
>
> CJ
Re: MultiPath / ADD_PATH for bgpd
On Wed, Apr 15, 2020 at 08:16:14PM +0100, Richard Chivers wrote: > Hi, > > Just wondering if anyone can help. > > I saw back in late 2018 that there were some initial plans for ADD_PATH and > Multipath in bgpd, it was in a list on a slide right after the portable > version. https://youtu.be/4gOoPxGKKjA?t=1500 > > Does anyone know if there are still plans in this area, or if there has > been any progress, we are really interested to explore using this in a > project we are working on, and just keen to understand if it may be coming? > The plan still holds but the timeline got a bit mixed up. Unless someone steps up ADD_PATH will not show up in the 6.8 release but probably in 6.9. -- :wq Claudio
Re: Unbound Notice: "sendto failed: No buffer space available"
> AFAIU, ENOBUFS happens when the NIC transmit queue is full. Have you looked > at the interface statistics to see if there are many dropped packets? Try, > e.g., > > $ netstat -ni NameMtu Network Address Ipkts IfailOpkts Ofail Colls lo0 3276851863 051863 0 0 lo0 32768 ::1/128 ::1 51863 051863 0 0 lo0 32768 fe80::%lo0/ fe80::1%lo0 51863 051863 0 0 lo0 32768 127/8 127.0.0.151863 051863 0 0 em0 150000:30:48:92:24:b0 711639121 168364 838861401 1124769 0 em0 1500 192.168.0/2 192.168.0.1 711639121 168364 838861401 1124769 0 em1 150000:30:48:92:24:b1 329783577 113371 188872522 2 0 em1 1500 172.16.0/24 172.16.0.1329783577 113371 188872522 2 0 em2 150090:e2:ba:c9:22:1c0 01 1 0 em2 1500 192.168.100 192.168.100.10 01 1 0 enc0* 00 00 0 0 pppoe0 1492 329558645 0 188975582 180546 0 pppoe0 1492 81.12.67.201 81.12.67.12 329558645 0 188975582 180546 0 tun01500 16995 029189 0 0 tun01500 192.168.2/2 192.168.2.1 16995 029189 0 0 vlan1 150000:30:48:92:24:b0 763387 0 72 1871 0 vlan1 1500 192.168.1/2 192.168.1.1 763387 0 72 1871 0 vlan2 150000:30:48:92:24:b0 474476153 0 15182811 0 0 vlan2 1500 192.168.3/2 192.168.3.1 474476153 0 15182811 0 0 vlan4 150000:30:48:92:24:b0 109009001 0 167250501 4757578 0 vlan4 1500 192.168.4/2 192.168.4.1 109009001 0 167250501 4757578 0 pflog0 331360 071617 0 0
Re: mount dir over another dir
Hi, From: Ono Caritofilaxy Date: Thu, 16 Apr 2020 10:13:51 +0300 > Hello. > > I want to mount /usr/local/srcdir /usr/local/dstdir/subdir > > answer was "no" 3 years ago > https://marc.info/?l=openbsd-misc=149743861203607=2 > > Can I do this now? > If not - why? Is it dangerous? I have no solution about your question. Maybe FUSE (Filesystem in Userspace) can solve your question. SSHFS is useing FUSE. SSHFS can mount remote file system. https://github.com/libfuse/libfuse https://github.com/libfuse/sshfs Oh, I just realized: $ sshfs localhost:/usr/local/srcdir /usr/local/dstdir/subdir How about it? -- ASOU Masato
mount dir over another dir
Hello. I want to mount /usr/local/srcdir /usr/local/dstdir/subdir answer was "no" 3 years ago https://marc.info/?l=openbsd-misc=149743861203607=2 Can I do this now? If not - why? Is it dangerous?
Re: S3 Virge support on IBM T23 for 6.6
Den ons 15 apr. 2020 kl 23:29 skrev Paolo Aglialoro : > Is this a hint that soon i386 architecture will be deprecated? > Considering that supported hw (at least graphics) is going more and more to > overlap with amd64, at the very end i386 would remain only for some > routerboards. > i386 has seen a fair share of deprecations, from the actual 386 CPUs and 486s without FPU, to machines with 8,16,32,64M ram for whom reordering libs and kernel isn't really doable with recent OpenBSD releases. -- May the most significant bit of your life be positive.
