Re: Bridged vether interfaces can't talk to each other (multiple routing tables)

[Edgar Pettijohn]

On 04/21/17 20:49, Anders Andersson wrote:

=== BACKGROUND ===

I'm trying to set up an OpenBSD 6.1 server having two externally visible
IP numbers through one physical network port, each IP mapping to a
unique MAC address[1]. I have it mostly working, but my interfaces can't
talk to each other.

All traffic should use the primary IP, and most services should listen
on that. The secondary IP should only be used on-demand for one or two
services.

Thinking that separate routing tables can solve this, I have configured
my network like this[2][3]:

 # cat hostname.em2
 up

 # cat hostname.vether0
 lladdr 00:00:00:00:00:02

 # cat hostname.vether1
 lladdr 00:00:00:00:00:03 rdomain 1

 # cat hostname.bridge0
 add em2 add vether0 add vether1 up
 !dhclient vether0
 !dhclient vether1

 # cat sysctl.conf
 net.inet.ip.forwarding=1

Leading to something like this[4]:
(full post in monospace: http://paste.debian.net/928811 )

..-.  10.0.0.1  .-,(  ),-.
| bridge0|   em2   |dhcp server  .-(  )-.
|| (no ip) |--->  gateway   --->(internet)
|'-' __  '-(  ).-'
|  |[_...__...°] '-.( ).-'
.---.  .---.
|  vether0  |  |  vether1  |
| rdomain 0 |  | rdomain 1 |
|   dhcp|  |   dhcp|
| 10.0.0.2  |  | 10.0.0.3  |
'---'--'---'


Love the ascii art!



Everything else should be the default, this is on a clean 6.1 install.

This configuration works great, vether0 and vether1 both gets an IP
number from my DHCP server, all traffic goes out on vether0 by default,
but I can select vether1 manually:

 # traceroute -nvq1 10.0.0.1
 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
  1  10.0.0.1 48 bytes to 10.0.0.2  0.994 ms

 # route -T1 exec traceroute -nvq1 10.0.0.1
 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
  1  10.0.0.1 48 bytes to 10.0.0.3  0.984 ms

I can also reach each IP from outside the box. They are going in on em2,
through the bridge, and in to vether0 or vether1 respectively.




=== PROBLEM ===

Now to my problem: I have no connection between vether0<->vether1.

 # traceroute -nvq1 10.0.0.3
 traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40 byte...
  1  *
  2  *
 ^C

If I listen with tcpdump on the bridge, I see lots of unanswered arp
who-has:

 # tcpdump -nti bridge0
 tcpdump: listening on bridge0, link-type EN10MB
 arp who-has 10.0.0.3 tell 10.0.0.2
 arp who-has 10.0.0.3 tell 10.0.0.2
 ^C


Never done this, but maybe you need an arp proxy.  Not sure which $iface 
to put it on, but something like:

# arp -s 10.0.0.2 00:00:00:00:00:02 pub

may or may not help depending on if my understanding of what I read in 
the manual actually does what I think it will.




These packets even go out on em2 to my LAN, but no one ever answers. The
same thing happens in reverse.

I have experimented with these bridge settings:
 'blocknonip' - adding or removing on members makes no difference
 'discover' - should be the default, adding makes no difference
 'learn' - should be the default, adding makes no difference



=== EXPECTATIONS ===

I expected that someone should answer those arp who-is requests, either
vether1 directly, or the bridge0 who should know which interfaces it
has. Is there something I must configure to make this work, or is my
plan flawed from the start?





=== INFORMATION ===

Various information that could help answer my question (trimmed
whitespace and boilerplate):

# route -n show -inet
Destination   Gateway   Flags Refs Use   Mtu Prio Iface
default   10.0.0.1  UGS  0   0 -8 vether0
224/4 127.0.0.1 URS  0   0 327688 lo0
10.0.0/24 10.0.0.2  UCn  1   0 -4 vether0
10.0.0.1  link#6UHLch1   1 -3 vether0
10.0.0.2  00:00:00:00:00:02 UHLl 0   0 -1 vether0
10.0.0.25510.0.0.2  UHb  0   0 -1 vether0
127/8 127.0.0.1 UGRS 0   0 327688 lo0
127.0.0.1 127.0.0.1 UHhl 1   2 327681 lo0

# route -T1 -n show -inet
Destination   Gateway   Flags Refs Use   Mtu Prio Iface
default   10.0.0.1  UGS  0  32 -8 vether1
10.0.0/24 10.0.0.3  UCn  1   4 -4 vether1
10.0.0.1  00:00:00:00:00:01 UHLch1   3 -3 vether1
10.0.0.3  00:00:00:00:00:03 UHLl 0   0 -1 vether1
10.0.0.25510.0.0.3  UHb  0   0 -1 vether1

# for if in bridge0 em2 vether{0,1}; do ifconfig $if; done
bridge0: flags=41
description: Bridge for external virtual NICs
index 9 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
designated: id 

Bridged vether interfaces can't talk to each other (multiple routing tables)

[Anders Andersson]

=== BACKGROUND ===

I'm trying to set up an OpenBSD 6.1 server having two externally visible
IP numbers through one physical network port, each IP mapping to a
unique MAC address[1]. I have it mostly working, but my interfaces can't
talk to each other.

All traffic should use the primary IP, and most services should listen
on that. The secondary IP should only be used on-demand for one or two
services.

Thinking that separate routing tables can solve this, I have configured
my network like this[2][3]:

# cat hostname.em2
up

# cat hostname.vether0
lladdr 00:00:00:00:00:02

# cat hostname.vether1
lladdr 00:00:00:00:00:03 rdomain 1

# cat hostname.bridge0
add em2 add vether0 add vether1 up
!dhclient vether0
!dhclient vether1

# cat sysctl.conf
net.inet.ip.forwarding=1

Leading to something like this[4]:
(full post in monospace: http://paste.debian.net/928811 )

..-.  10.0.0.1  .-,(  ),-.
| bridge0|   em2   |dhcp server  .-(  )-.
|| (no ip) |--->  gateway   --->(internet)
|'-' __  '-(  ).-'
|  |[_...__...°] '-.( ).-'
.---.  .---.
|  vether0  |  |  vether1  |
| rdomain 0 |  | rdomain 1 |
|   dhcp|  |   dhcp|
| 10.0.0.2  |  | 10.0.0.3  |
'---'--'---'

Everything else should be the default, this is on a clean 6.1 install.

This configuration works great, vether0 and vether1 both gets an IP
number from my DHCP server, all traffic goes out on vether0 by default,
but I can select vether1 manually:

# traceroute -nvq1 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
 1  10.0.0.1 48 bytes to 10.0.0.2  0.994 ms

# route -T1 exec traceroute -nvq1 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
 1  10.0.0.1 48 bytes to 10.0.0.3  0.984 ms

I can also reach each IP from outside the box. They are going in on em2,
through the bridge, and in to vether0 or vether1 respectively.




=== PROBLEM ===

Now to my problem: I have no connection between vether0<->vether1.

# traceroute -nvq1 10.0.0.3
traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40 byte...
 1  *
 2  *
^C

If I listen with tcpdump on the bridge, I see lots of unanswered arp
who-has:

# tcpdump -nti bridge0
tcpdump: listening on bridge0, link-type EN10MB
arp who-has 10.0.0.3 tell 10.0.0.2
arp who-has 10.0.0.3 tell 10.0.0.2
^C

These packets even go out on em2 to my LAN, but no one ever answers. The
same thing happens in reverse.

I have experimented with these bridge settings:
'blocknonip' - adding or removing on members makes no difference
'discover' - should be the default, adding makes no difference
'learn' - should be the default, adding makes no difference



=== EXPECTATIONS ===

I expected that someone should answer those arp who-is requests, either
vether1 directly, or the bridge0 who should know which interfaces it
has. Is there something I must configure to make this work, or is my
plan flawed from the start?





=== INFORMATION ===

Various information that could help answer my question (trimmed
whitespace and boilerplate):

# route -n show -inet
Destination   Gateway   Flags Refs Use   Mtu Prio Iface
default   10.0.0.1  UGS  0   0 -8 vether0
224/4 127.0.0.1 URS  0   0 327688 lo0
10.0.0/24 10.0.0.2  UCn  1   0 -4 vether0
10.0.0.1  link#6UHLch1   1 -3 vether0
10.0.0.2  00:00:00:00:00:02 UHLl 0   0 -1 vether0
10.0.0.25510.0.0.2  UHb  0   0 -1 vether0
127/8 127.0.0.1 UGRS 0   0 327688 lo0
127.0.0.1 127.0.0.1 UHhl 1   2 327681 lo0

# route -T1 -n show -inet
Destination   Gateway   Flags Refs Use   Mtu Prio Iface
default   10.0.0.1  UGS  0  32 -8 vether1
10.0.0/24 10.0.0.3  UCn  1   4 -4 vether1
10.0.0.1  00:00:00:00:00:01 UHLch1   3 -3 vether1
10.0.0.3  00:00:00:00:00:03 UHLl 0   0 -1 vether1
10.0.0.25510.0.0.3  UHb  0   0 -1 vether1

# for if in bridge0 em2 vether{0,1}; do ifconfig $if; done
bridge0: flags=41
   description: Bridge for external virtual NICs
   index 9 llprio 3
   groups: bridge
   priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
   designated: id 00:00:00:00:00:00 priority 0
   em2 flags=3
   port 3 ifpriority 0 ifcost 0
   vether0 flags=3
   port 6 ifpriority 0 ifcost 0
   vether1 flags=3
   port 7 ifpriority 0 ifcost 0
   Addresses (max cache: 100, timeout: 240):
   00:00:00:00:00:01 em2 1 flags=0<>
em2: 

Re: spamd and outlook.com

[Stuart Henderson]

On 2017-04-21, Kurt H Maier  wrote:
> What I don't do it set an outgoing voicemail greeting informing
> correspondents that my time is more valuable than theirs, and if they
> want to contact me I have a list of hoops through which they must jump.
>
> That would make me an asshole.

Heh. I do actually have asterisk play a "press  to talk to someone" message to callers who withhold caller id.

Re: spamd and outlook.com

[Kurt H Maier]

On Fri, Apr 21, 2017 at 10:40:42PM +0100, Kevin Chadwick wrote:
> On Fri, 21 Apr 2017 09:21:48 -0700
> Kurt H Maier  wrote:
> 
> > Greylisting is a hack, an abuse of a side-effect.  Most such
> > approaches have deleterious side effects.  This particular side
> > effect is why I don't like greylisting in general, even though it's
> > fairly effective.
> 
> Do you answer your phone before looking at the number/caller?

In fact, there are some numbers I will not respond to (and these do not
cause my phone to ring) and the rest I just answer.  Just like having a
blacklist I don't accept SMTP connections from at all, and the rest get
processed normally.

What I don't do it set an outgoing voicemail greeting informing
correspondents that my time is more valuable than theirs, and if they
want to contact me I have a list of hoops through which they must jump.

That would make me an asshole.

> It is not a hack at all. 

It is.  SMTP is mandated to retry as a reliability factor, in a world
with bad network connections and unreliable software.  It is not
mandated to retry so people can play cute games with the sending unit.
I personally have no burning desire to see greylisting expunged from the
internet, but I also have no sympathy for people who think it's a real
solution to anything.  If it works for someone, good for them, but I
will never be even a little surprised when it becomes a pain in
someone's ass.

khm

Re: spamd and outlook.com

[Kevin Chadwick]

On Fri, 21 Apr 2017 09:21:48 -0700
Kurt H Maier  wrote:

> Greylisting is a hack, an abuse of a side-effect.  Most such
> approaches have deleterious side effects.  This particular side
> effect is why I don't like greylisting in general, even though it's
> fairly effective.

Do you answer your phone before looking at the number/caller?

It is not a hack at all. The only problem that keeps coming up is large
MTAs that I have concluded, wish to discourage it as it increases their
costs (I am sure they know what IPS may send mail and could publish SPF
records much more usefully (they probably block windows boxes
etc. from connecting to port 25 to avoid being blacklisted)). It would
be nice if SPAMD/SMTPD/GREYSCANNER/SCRIPTS could be integrated/improved
to the point that checks could be completed whilst the connection is
still stuttering and then the connection speed back up once completed.
Unfortunately, it is often dumb spam bots that hang around and the
likes of hotmail that disconnect early. So I guess any efforts there
*may* be a waste of time anyway.

Re: iked/IKEv2 issue with 6.1

[Igor V. Gubenko]

Thanks again. The connections are all working.


On 4/20/17 8:54 PM, Igor V. Gubenko wrote:
> Thank you, the patch appears to work. I haven't fully tested
> connecting/establishing connections, so I'll send another update.
>
> Prior to the patch, iked also complained about lack of public keys for
> PSK connections 1 and 2 (in /etc/iked/pubkeys/fqdn/)
> It doesn't mind them being absent anymore though.
>
> - Igor
>
> On 4/20/17 5:44 PM, Reyk Floeter wrote:
>> --- sbin/iked/parse.y28 Mar 2017 16:56:39 -  1.64
>> +++ sbin/iked/parse.y20 Apr 2017 21:40:14 -
>> @@ -1807,7 +1807,7 @@ set_policy(char *idstr, int type, struct
>>  {
>>  char keyfile[PATH_MAX];
>>  const char  *prefix = NULL;
>> -EVP_PKEY*key;
>> +EVP_PKEY*key = NULL;
>>  
>>  switch (type) {
>>  case IKEV2_ID_IPV4:
>> @@ -1822,6 +1822,9 @@ set_policy(char *idstr, int type, struct
>>  case IKEV2_ID_UFQDN:
>>  prefix = "ufqdn";
>>  break;
>> +case IKEV2_ID_ASN1_DN:
>> +/* public key authentication is not supported with ASN.1 IDs */
>> +goto done;
>>  default:
>>  /* Unspecified ID or public key not supported for this type */
>>  log_debug("%s: unknown type = %d", __func__, type);
>> @@ -1841,6 +1844,7 @@ set_policy(char *idstr, int type, struct
>>  keyfile);
>>  }
>>  
>> + done:
>>  if (set_policy_auth_method(keyfile, key, pol) < 0) {
>>  EVP_PKEY_free(key);
>>  log_warnx("%s: failed to set policy auth method for %s",

Re: OpenBSD 6.1, spamd strange behavior

[Peter N. M. Hansteen]

On 04/21/17 10:44, Alex Shupikov wrote:

> spamd is working in the greylisting mode with "-v -G 2:4:864" options.
> For every trying of the delivery mail a remote host become TRAPPED for 24
> hours, and I don't understand why.

is there a very restrictive spamd.alloweddomains you're not showing us?
(see the GREYTRAPPING section of the man page)

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: WARNING: symbol(icudt58_dat) size mismatch, relink your program

[bian]

On 2017-04-21 19:09, bian wrote:

I did not try slappasswd but the message is triggered from other
places as well. From my ~/.xsession-errors (using 6.1 , xfce4):
firefox-esr:/usr/local/lib/libicuuc.so.12.0:
/usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size
mismatch, relink your program
soffice.bin:/usr/local/lib/libicuuc.so.12.0:
/usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size
mismatch, relink your program
vlc:/usr/local/lib/libicuuc.so.12.0: /usr/local/lib/libicudata.so.12.0
: WARNING: symbol(icudt58_dat) size mismatch, relink your program
Best regards
/Birger

On 2017-04-20 21:40, Predrag Punosevac wrote:

Sorry for the noise. Did anybody try to use slappasswd after upgrading
from 6.0 to 6.1 (amd64). I get

slappasswd:/usr/local/lib/libicuuc.so.12.0:
/usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size
mismatch, relink your program

I tried reinstalling openldap-server-2.4.44p3 which I only keep 
around.

I actually use ldapd from the base.

Best,
Predrag

Re: spamd and outlook.com

[Walter Alejandro Iglesias]

Stuart Henderson wrote:

> On 2017-04-21, Craig Skinner  wrote:
> > Email is not instant messaging.
> >
> > Customers need educated to that fact.
> 
> How do you educate them to that when they send to their gmail account
> and it shows up on their phone within seconds?

We, at school, used the pen as blowgun.

understanding ldapd log error messages

[Predrag Punosevac]

Hi misc,

ldapd on one of my two ldap servers stop working overnight

# uname -a  
OpenBSD atlas.int.autonlab.org 6.1 GENERIC.MP#20 amd64

I manually restarted it and it appears to work OK.  I started digging
little bit through the log files and I see the following in my
/var/log/message file before and after the upgrade. Can somebody help me
understand what I see and point me to some kind reading? Is my database
corrupted for some reason? The LDAP server overall has being working
really well for the past 3.5 years with Red Hat, FreeBSD, and OpenBSD
clients. I have being upgrading this server since the last database
format change (I think OpenBSD 5.3 or 5.4).

Best,
Predrag




Apr 17 04:03:39 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,]
doesn't exist!
Apr 17 04:03:39 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,]
doesn't exist!
Apr 17 04:03:44 atlas ldapd[83666]: error 0x24 on connection 17
Apr 17 04:04:20 atlas last message repeated 3 times
Apr 17 04:04:31 atlas ldapd[83666]: error 0x24 on connection 13
Apr 17 04:05:02 atlas last message repeated 3 times
Apr 17 04:05:12 atlas ldapd[83666]: error 0x24 on connection 13
Apr 17 04:05:24 atlas ldapd[83666]: error 0x24 on connection 18
Apr 17 04:05:57 atlas last message repeated 3 times
Apr 17 04:08:08 atlas last message repeated 12 times
Apr 17 04:08:41 atlas last message repeated 3 times
Apr 17 04:08:53 atlas ldapd[83666]: error 0x24 on connection 20
Apr 17 04:09:05 atlas ldapd[83666]: error 0x24 on connection 22
Apr 17 04:09:36 atlas last message repeated 3 times
Apr 17 04:09:57 atlas last message repeated 2 times
Apr 17 04:10:07 atlas ldapd[83666]: error 0x24 on connection 38
Apr 17 04:10:18 atlas ldapd[83666]: error 0x24 on connection 25
Apr 17 04:10:28 atlas ldapd[83666]: error 0x24 on connection 25
Apr 17 04:10:40 atlas ldapd[83666]: error 0x24 on connection 38
Apr 17 04:10:52 atlas ldapd[83666]: error 0x24 on connection 40
Apr 17 04:11:23 atlas last message repeated 3 times
Apr 17 04:11:34 atlas ldapd[83666]: error 0x24 on connection 26
Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=dwang,ou=users,]
doesn't exist!
Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,]
doesn't exist!
Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,]
doesn't exist!
Apr 17 04:11:44 atlas ldapd[83666]: error 0x24 on connection 40
Apr 17 04:11:56 atlas ldapd[83666]: error 0x24 on connection 41
Apr 17 04:12:29 atlas last message repeated 3 times
Apr 17 04:12:50 atlas last message repeated 2 times
Apr 17 04:13:00 atlas ldapd[83666]: error 0x24 on connection 28
Apr 17 04:13:36 atlas last message repeated 3 times
Apr 17 04:14:09 atlas last message repeated 3 times
Apr 17 04:14:21 atlas ldapd[83666]: error 0x24 on connection 14
Apr 17 04:14:44 atlas last message repeated 2 times
Apr 17 04:14:54 atlas ldapd[83666]: error 0x24 on connection 15
Apr 17 04:15:25 atlas last message repeated 3 times
Apr 17 04:16:10 atlas last message repeated 4 times
Apr 17 04:16:20 atlas ldapd[83666]: error 0x24 on connection 29
Apr 17 04:16:53 atlas last message repeated 3 times
Apr 17 04:17:05 atlas ldapd[83666]: error 0x24 on connection 29
Apr 17 04:17:17 atlas ldapd[83666]: error 0x24 on connection 32
Apr 17 04:17:50 atlas last message repeated 3 times
Apr 17 04:18:23 atlas last message repeated 3 times
Apr 17 04:18:33 atlas ldapd[83666]: error 0x24 on connection 16
Apr 17 04:19:06 atlas last message repeated 3 times
Apr 17 04:19:18 atlas ldapd[83666]: error 0x24 on connection 33
Apr 17 04:19:51 atlas last message repeated 3 times
Apr 17 04:20:01 atlas ldapd[83666]: error 0x24 on connection 33
Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=dwang,ou=users,]
doesn't exist!
Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,]
doesn't exist!
Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,]
doesn't exist!
Apr 17 04:20:12 atlas ldapd[83666]: error 0x24 on connection 34
Apr 17 04:20:22 atlas ldapd[83666]: error 0x24 on connection 13
Apr 17 04:20:33 atlas ldapd[83666]: error 0x24 on connection 34

and this is from today
Apr 21 12:04:41 atlas ldapd[78718]: error 0x24 on connection 19
Apr 21 12:04:52 atlas ldapd[78718]: error 0x24 on connection 19
Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,]
doesn't exist!
Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,]
doesn't exist!
Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=seohyuns,ou=users,]
doesn't exist!
Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,]
doesn't exist!
Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,]
doesn't exist!
Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=seohyuns,ou=users,]
doesn't exist!
Apr 21 12:05:01 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,]
doesn't exist!
Apr 21 12:05:01 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,]
doesn't exist!

Re: spamd and outlook.com

[Kurt H Maier]

On Fri, Apr 21, 2017 at 04:02:20PM +, Stuart Henderson wrote:
> On 2017-04-21, Craig Skinner  wrote:
> > Hi Markus,
> >
> > On Fri, 21 Apr 2017 11:25:14 +0200 Markus Rosjat wrote:
> >> so if you have spamd in place in greylisting mode and you have
> >> customers that work with people who use Office365 as a service you
> >> will get calls that emails are delayed for a freaking long time
> >
> > Email is not instant messaging.
> >
> > Customers need educated to that fact.
> 
> How do you educate them to that when they send to their gmail account
> and it shows up on their phone within seconds?
> 
> Sometimes there are delays but there's no reason for that to be the norm.
> 

There's no reason email can't be instant messaging.  Postmasters have
spent decades training users that email just sucks and is necessarily
unreliable.  All they did was corral users toward services where they
don't have to hear the administrators whining about how hard that job
is.  

Greylisting is a hack, an abuse of a side-effect.  Most such approaches
have deleterious side effects.  This particular side effect is why I
don't like greylisting in general, even though it's fairly effective.

khm

Re: spamd and outlook.com

[Kevin Chadwick]

On Fri, 21 Apr 2017 16:02:20 + (UTC)
Stuart Henderson  wrote:

> >
> > Email is not instant messaging.
> >
> > Customers need educated to that fact.  
> 
> How do you educate them to that when they send to their gmail account
> and it shows up on their phone within seconds?
> 
> Sometimes there are delays but there's no reason for that to be the
> norm.

Unfortunately, I disagree. Instant messaging has a friends/block
facility, email is for strangers too. The delay doesn't need to
be long however but your chances of receiving spam are far better with
the checks before accepting.

Hotmail users skip through the spam and pick valid messages out of their
spam folder. A colleague of mine commented on having a spam message as
if it was rare the other day.

Re: Is randomizing UID/GUID would make sense?

[Kevin Chadwick]

On Fri, 21 Apr 2017 22:39:39 +1000
 wrote:

> Thanks for the start points, Christian and Philip.
> I would have never thought about those use cases.
> I'll definitely look into this further.

I rewrote some code for key generation for particular memory
handling/protection reasons and it certainly provides some extra
confidence to yourself and/or other if you find your implementation and
four others all produce the same 1 outputs with the same repeatable
but random looking inputs. Usually specific and well chosen test vectors
are available, but not always.

I did have a cry/laugh at the function name of the deterministic
"random" generator in mbedtls though and reminding me of the OpenBSD
commentry on them. Unfortunately I forget the details of what was
particularly alarming/funny though.

Re: spamd and outlook.com

[Markus Rosjat]

Like I said I had one case where I had the same message send from 20 different 
outlook.com servers that's just stupid
Regards
Markus

 Ursprüngliche Nachricht 
Von: Edgar Pettijohn  
Datum: 21.04.17  15:20  (GMT+01:00) 
An: misc@openbsd.org 
Betreff: Re: spamd and outlook.com 



On 04/21/17 07:12, Reyk Floeter wrote:
> On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote:
>> Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter :
>>> On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote:
 On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:
>>> I use the attached script to fetch the SPF entries recursively, in a
>>> plain text format that can be fed into pfctl.
>> Have you tried mx3a.certifiedfactory.info ?  ;)
>>
> great
>
> I think you got something wrong:
>
> I don't use this simple script automatically or for "untrusted
> domains", I just use it _manually_ and for _well-known_ offenders like
> outlook.com that break greylisting.  SPF is not a security solution,
> but it is a band-aid that helps to handle these stupid cloud-based MTAs.
>
> The script below fixes it - or akpoff's slightly more complicated (and
> probably more correct) version.
>
> Reyk
>
> ---snip---
> #!/usr/bin/perl
>
> # Copyright (c) 2016, 2017 Reyk Floeter 
> #
> # Permission to use, copy, modify, and distribute this software for any
> # purpose with or without fee is hereby granted, provided that the above
> # copyright notice and this permission notice appear in all copies.
> #
> # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>
> $domain = shift @ARGV or die "usage: $0 domain";
> %seen = {};
>
> sub parsespf
> {
>   my $domain = shift;
>   my @foo = `nslookup -q=TXT $domain`;
>   my @results = ();
>
>   foreach (@foo) {
>   next if not /$domain\ttext/;
>   next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/;
>
>   @results = split /\s+/;
>   foreach (@results) {
>   next if /.all/;
>   if (s/^ip[46]://) {
>   print "$_\n";
>   } elsif (s/^(redirect|include)[:=]//) {
>   print "\n#$_\n";
>   if (!$seen{$_}) {
>   $seen{$_} = true;
>   parsespf($_);
>   }
>   }
>   }
>   }
> }
>
> parsespf($domain);
>
> 0;
I'm glad I'm not the only one with this problem.  I started off just 
adding individual ip's to my nospamd as needed, but they deliver mail so 
stupidly.  One message may get sent from in my experience 4 different 
ip's so they get trapped each time and I'm guessing they eventually give 
up.  Luckily https://home.nuug.no/~peter/nospamd came across my screen 
one day.  It seems to have cured my problem. Thanks Peter!

Re: spamd and outlook.com

[Stuart Henderson]

On 2017-04-21, Craig Skinner  wrote:
> Hi Markus,
>
> On Fri, 21 Apr 2017 11:25:14 +0200 Markus Rosjat wrote:
>> so if you have spamd in place in greylisting mode and you have
>> customers that work with people who use Office365 as a service you
>> will get calls that emails are delayed for a freaking long time
>
> Email is not instant messaging.
>
> Customers need educated to that fact.

How do you educate them to that when they send to their gmail account
and it shows up on their phone within seconds?

Sometimes there are delays but there's no reason for that to be the norm.

Re: spamd and outlook.com

[Stuart Henderson]

On 2017-04-21, Markus Rosjat  wrote:
> so if you have spamd in place in greylisting mode and you have customers 
> that work with people who use Office365 as a service you will get calls 
> that emails are delayed for a freaking long time and if you check the ip 
> range that outlook.com could send from you get scared.
>
> So  what are the strategies out there to handle this kind of situation?

I stopped simple spamd-style greylisting years ago, I was spending far
more time waiting for verification mails and figuring out the cause for
mail delays than it saved me in deleting spam (especially considering
a lot still gets past greylisting).

I switched to using postfix's "after-accept" checks (which drop the
first attempt from a new source, blacklisting if they make certain SMTP
errors, but don't have a timeout period - allows delivery immediately on
reconnect). And these days I exempt hosts on dnswl.org from this.

I now also do greylisting via rspamd for high-ish scoring mail, if it
suspects it's likely to be spam but isn't quite sure, it greylists for a
while; often the sender is added to enough RBL or RHSBLs by the time it
retries and is then detected as spam right away. There are still some
delays from legit-but-spammy-looking mail, but real "written by a human"
mail, and the majority of address verification mails, usually get through
without greylisting.

> Do you let them all pass and trust that microsoft is protecting there 
> service enough to stop spamming from hijacked machines that use office365 ?

Never mind spam, from what I can see Microsoft don't even kill off
actual malware hosted on their own domains (e.g. sharepoint.com) in a
timely fashion..

But they undoubtedly will have per-sender rate limits on email. I don't
see greylisting from the address space listed in their SPF records or
dnswl entries as doing much good.

> I'm a little reluctant to whitelist a shitload of ips just to get rid of 
> a 1 or 2 day delay in delivering the message and yes this was the case

And if you're unlucky they don't retry from the same IP before the
message gets too old and falls out of the sender's queue.

Re: spamd and outlook.com

[Boudewijn Dijkstra]

Op Fri, 21 Apr 2017 14:12:56 +0200 schreef Reyk Floeter :

On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote:
Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter  
:

> On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote:
> > On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:
> > >
>
> I use the attached script to fetch the SPF entries recursively, in a
> plain text format that can be fed into pfctl.

Have you tried mx3a.certifiedfactory.info ?  ;)



great

I think you got something wrong:

I don't use this simple script automatically or for "untrusted
domains", I just use it _manually_ and for _well-known_ offenders like
outlook.com that break greylisting.


I only pointed out a weakness. Infinite loops may happen regardless of  
trust or reputation, so the weakness should IMHO be either documented or  
fixed.



 SPF is not a security solution,
but it is a band-aid that helps to handle these stupid cloud-based MTAs.

The script below fixes it - or akpoff's slightly more complicated (and
probably more correct) version.


Thanks.

--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Re: spamd and outlook.com

[Boudewijn Dijkstra]

Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter :

On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote:

On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:
>


I use the attached script to fetch the SPF entries recursively, in a
plain text format that can be fed into pfctl.


Have you tried mx3a.certifiedfactory.info ?  ;)


--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

no network in bsd.rd when wifi card is present

[Jordon]

My main OpenBSD system is a Shuttle SH81R4 with a 4th Gen i5.  I run the latest 
snapshot on it and once or twice a week I will boot into bsd.rd and run update. 
 A week or two ago I put a mini-pcie wifi card in it (athn0) and after getting 
some help from this mailing list, I got this system running as an Access Point. 
 I have since noticed a strange issue.

Now, when I boot into bsd.rd, I have no network.  When i try to upgrade, I will 
see the DHCPDISCOVER, DHCPOFFER, etc go by and it is all right, but when get to 
the “lets upgrade the sets” part, i get the (Unable to get list from 
ftp.openbsd.org, but that is OK) message and any attempt to actually download 
the updated packages fails.

If I ctrl+c to a prompt, i can run ‘dhclient re0’ and it looks like it 
succeeds, but when I run ‘ifconfig’, re0 does not have an ip address.  I can’t 
even ping the ip address of my router.
If I actually remove the wifi adapter (as in, open the case and physically 
remove the mini-pcie card from its slot) and try it, it works fine (though 
entering a number for a different mirror doesn’t seem to work).

Removing the pcie card every time I want to install the latest build is very 
inconvenient.  Is there a workaround for this?

Jordon

Re: spamd and outlook.com

[Edgar Pettijohn]

On 04/21/17 07:12, Reyk Floeter wrote:

On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote:

Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter :

On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote:

On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:

I use the attached script to fetch the SPF entries recursively, in a
plain text format that can be fed into pfctl.

Have you tried mx3a.certifiedfactory.info ?  ;)


great

I think you got something wrong:

I don't use this simple script automatically or for "untrusted
domains", I just use it _manually_ and for _well-known_ offenders like
outlook.com that break greylisting.  SPF is not a security solution,
but it is a band-aid that helps to handle these stupid cloud-based MTAs.

The script below fixes it - or akpoff's slightly more complicated (and
probably more correct) version.

Reyk

---snip---
#!/usr/bin/perl

# Copyright (c) 2016, 2017 Reyk Floeter 
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

$domain = shift @ARGV or die "usage: $0 domain";
%seen = {};

sub parsespf
{
my $domain = shift;
my @foo = `nslookup -q=TXT $domain`;
my @results = ();

foreach (@foo) {
next if not /$domain\ttext/;
next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/;

@results = split /\s+/;
foreach (@results) {
next if /.all/;
if (s/^ip[46]://) {
print "$_\n";
} elsif (s/^(redirect|include)[:=]//) {
print "\n#$_\n";
if (!$seen{$_}) {
$seen{$_} = true;
parsespf($_);
}
}
}
}
}

parsespf($domain);

0;
I'm glad I'm not the only one with this problem.  I started off just 
adding individual ip's to my nospamd as needed, but they deliver mail so 
stupidly.  One message may get sent from in my experience 4 different 
ip's so they get trapped each time and I'm guessing they eventually give 
up.  Luckily https://home.nuug.no/~peter/nospamd came across my screen 
one day.  It seems to have cured my problem. Thanks Peter!

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Jeff]

On Fri, 21 Apr 2017, Stefan Sperling wrote:

> On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote:
> > Hi,
> >
> > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> > I attempted to update to OpenBSD 6.1 using the files first from:
> >
> > http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64
> >
> > Then from:
> >
> > https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64
> >
> > First I tried to copy bsd.rd to / and boot from it.  When I boot
> > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> > OpenBSD 6.0.
>
> Did you actually type '/boot bsd.rd'?
> When booting from softraid you need to pass the virtual 'sr' drive
> as part of the boot path. Try again with: boot sr0a:/bsd.rd
>
> >From the boot_sparc64(8) man page:
>
>  To boot from a softraid(4) volume by default, boot-device must be set to
>  a disk device hosting a chunk of the softraid volume:
>
>ok setenv boot-device disk0
>
>  and boot-file must contain the (sr) device name of the softraid volume
>  and optionally a partition letter and/or kernel:
>
>ok setenv boot-file sr0a:/bsd
>

Hi Stefan,

Thanks!

I must have missed that man page when I originally installed 6.0.
Booting with sr0a:/bsd* did work but it took a much longer time
loading the symbols with both bsd & bsd.rd.  I'll be sure to read
that man page and try again later today after I'm done working (in
case I muck it up again).

Using a non-standard name for the bsd.rd file seems to help clarify
things.

ok printenv boot-device
boot-device = disk1:a /pci@1f,0/pci@1/scsi@8/disk@1,0:a

ok boot disk1:a /bsd.rd.61
...
Executing last command: boot disk1:a /bsd.rd.61
Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
/bsd.rd.61
OpenBSD IEEE 1275 Bootblock 1.4
..>> OpenBSD BOOT 1.7
Can't read disk label.
Can't open disk label package
Drive not ready
Can't read disk label.
Can't open disk label package
sr0*
open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/etc/random.seed: No such file or 
directory
open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/bsd.rd.61: No such file or directory

Boot:

lom> reset

ok boot sr0a:/bsd.rd.61
Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
sr0a:/bsd.rd.61
OpenBSD IEEE 1275 Bootblock 1.4
..>> OpenBSD BOOT 1.7
Can't read disk label.
Can't open disk label package
Drive not ready
Can't read disk label.
Can't open disk label package
sr0*
Booting sr0:a/bsd.rd.61
4045496@0x100+1352@0x13dbab8+3251904@0x180+942400@0x1b19ec0
symbols @ 0xfff42300 120 start=0x100
console is /pci@1f,0/pci@1,1/isa@7/serial@0,3f8
Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.1 (RAMDISK) #55: Sat Apr  1 17:41:52 MDT 2017
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK

Re: Is randomizing UID/GUID would make sense?

[bytevolcano]

Thanks for the start points, Christian and Philip.
I would have never thought about those use cases.
I'll definitely look into this further.

On Wed, 19 Apr 2017 13:31:08 + (UTC)
Christian Weisgerber  wrote:

> On 2017-04-19, Philip Guenther  wrote:
> 
> > For a broader answer to the "why?", take a look at the patches under
> > /usr/ports/ which add uses of the *_deterministic() calls.  
> 
> For instance, take graphics/netpbm and look at its multitude of
> image manipulation tools that take a -randomseed=integer argument
> to ensure that the same result can be obtained on separate
> invocations.
> 

acme-client(1) and http_proxy

[Manuel Giraud]

Hi,

I'm trying to use the new acme-client on a server behind a corporate
proxy (i.e. I have to set a http_proxy to get out). It seems (from
reading the code) that acme-client(1) does not honor http_proxy.

Is this on purpose? If so, can someone point me to another acme client
that does this?
-- 
Manuel Giraud

Re: spamd and outlook.com

[Peter N. M. Hansteen]

And apropos of the subject, quite on-topic: 
https://home.nuug.no/~peter/dmarc-reject_openbsd-misc_spadm_and_spf.txt

- P (pats robot on virtual head)
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: spamd and outlook.com

[Reyk Floeter]

On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote:
> Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter :
> > On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote:
> > > On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:
> > > >
> > 
> > I use the attached script to fetch the SPF entries recursively, in a
> > plain text format that can be fed into pfctl.
> 
> Have you tried mx3a.certifiedfactory.info ?  ;)
> 

great

I think you got something wrong:

I don't use this simple script automatically or for "untrusted
domains", I just use it _manually_ and for _well-known_ offenders like
outlook.com that break greylisting.  SPF is not a security solution,
but it is a band-aid that helps to handle these stupid cloud-based MTAs.

The script below fixes it - or akpoff's slightly more complicated (and
probably more correct) version.

Reyk

---snip---
#!/usr/bin/perl

# Copyright (c) 2016, 2017 Reyk Floeter 
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

$domain = shift @ARGV or die "usage: $0 domain";
%seen = {};

sub parsespf
{
my $domain = shift;
my @foo = `nslookup -q=TXT $domain`;
my @results = ();

foreach (@foo) {
next if not /$domain\ttext/;
next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/;

@results = split /\s+/;
foreach (@results) {
next if /.all/;
if (s/^ip[46]://) {
print "$_\n";
} elsif (s/^(redirect|include)[:=]//) {
print "\n#$_\n";
if (!$seen{$_}) {
$seen{$_} = true;
parsespf($_);
}
}
} 
} 
}

parsespf($domain);

0;

Re: Strange PF behaviour after 6.0 -> 6.1 pgrade

[Sjöholm Per-Olov]

> On 21 Apr 2017, at 10:34, Stuart Henderson  wrote:
> 
> On 2017-04-20, Sjöholm Per-Olov  wrote:
>> Could it be any buffers that is causing this in 6.1 but not in 6.0 ?
> 
> There were changes that would allow larger TCP buffers in 6.1. This
> would not have made a difference to normal or natted connections from
> non-OpenBSD going through PF to non-OpenBSD but could possibly affect
> some configurations with proxies (though only if PF rules were already
> dodgy - you would have active states in "pfctl -ss|grep -A1 tcp"
> without wscale values if this was the case).
> 
> Might be worth bumping up the pf log level and seeing if system logs
> give you more clues. Default is "error", you need "notice" to get the
> ones which might give useful clues (loose state match warnings or
> state mismatch errors).  (On a busy machine, be ready to back-off on
> the debug level in case it causes too much load).
> 
> 

Another addition… This is what the problem actually looks like

## 1 ## When the problem is ongoing…. Telnet from internet to DMZ server FAIL
[sjoholmp@dewey ~]$ telnet mail.dyn.incedo.org 25
Trying 155.4.8.28...
^C

## 2 ## This looks like this
Apr 21 14:06:28.751796 rule 573/(match) pass in on em3: 168.235.89.110.42126 > 
192.168.1.12.25: S 2597688027:2597688027(0) win 29200  (DF)
Apr 21 14:06:28.751824 rule 63/(match) block out on em3: 155.4.8.28.25 > 
168.235.89.110.42126: R 0:0(0) ack 2597688028 win 0 (DF)


## 3 ## Reload PF
root@xanadu:/var/log#pfctl -f /etc/pf.conf
root@xanadu:/var/log#


## 4 ## Telnet from internet again WORKS
[sjoholmp@dewey ~]$ telnet mail.dyn.incedo.org 25
Trying 155.4.8.28...
Connected to mail.dyn.incedo.org.
Escape character is '^]'.
220 mail.dyn.incedo.org ESMTP Sendmail; Fri, 21 Apr 2017 14:08:16 +0200


## 5 ## Looks like this
Apr 21 14:08:16.239213 rule 573/(match) pass in on em3: 168.235.89.110.42168 > 
192.168.1.12.25: S 4285065753:4285065753(0) win 29200  (DF)
Apr 21 14:08:16.239267 rule 89/(match) pass out on vlan3: 168.235.89.110.42168 
> 192.168.1.12.25: S 4285065753:4285065753(0) win 29200  (DF)

## 6 ## After a few hours the same problem occurs again which requires a PF 
reload 

The dmesg extra output ater pfctl -x notice only shows..
pf: pf_map_addr: selected address 155.4.8.28


I have serious problems with 6.1. I will probably go back to 6.0. I will giveit 
 to the end of this day and check what I can…

Peo

Re: Strange PF behaviour after 6.0 -> 6.1 pgrade

[Sjöholm Per-Olov]

> On 21 Apr 2017, at 10:34, Stuart Henderson  wrote:
> 
> On 2017-04-20, Sjöholm Per-Olov  wrote:
>> Could it be any buffers that is causing this in 6.1 but not in 6.0 ?
> 
> There were changes that would allow larger TCP buffers in 6.1. This
> would not have made a difference to normal or natted connections from
> non-OpenBSD going through PF to non-OpenBSD but could possibly affect
> some configurations with proxies (though only if PF rules were already
> dodgy - you would have active states in "pfctl -ss|grep -A1 tcp"
> without wscale values if this was the case).
> 
> Might be worth bumping up the pf log level and seeing if system logs
> give you more clues. Default is "error", you need "notice" to get the
> ones which might give useful clues (loose state match warnings or
> state mismatch errors).  (On a busy machine, be ready to back-off on
> the debug level in case it causes too much load).
> 
> 

Tnx for the answer Stuart

I will check and do what you suggest. In the meanwhile some additions…

I have removed all tuning in sysctl.conf to make sure we have nothing that 
interfere.

When pf is reloaded it works perfect for hours. And then the kernel, just like 
that stops route some packages. when it works it could look like this in the 
logg…
Apr 21 10:32:14.734332 rule 573/(match) pass in on em3: 202.67.41.252.49461 > 
192.168.1.12.25: S 583218598:583218598(0) win 8192  (DF)
Apr 21 10:32:14.734356 rule 89/(match) pass out on vlan3: 202.67.41.252.49461 > 
192.168.1.12.25: S 583218598:583218598(0) win 8192  (DF)

Note that the problem appeared and started just between these above and below 
connections. When it happens I have permanent intermittent issues that is only 
solved by reloading pf.

When it stops working after a few hours it then looks like this where the 
kernel simply refuse to forward the incoming internet packet on em3 packet to 
the dmz1 (i.e vlan3)…
Apr 21 10:32:17.373591 rule 573/(match) pass in on em3: 122.200.1.158.55956 > 
192.168.1.12.25: S 1479648704:1479648704(0) win 8192  (DF)
Apr 21 10:32:17.373618 rule 63/(match) block out on em3: 155.4.8.28.25 > 
122.200.1.158.55956: R 0:0(0) ack 1479648705 win 0 (DF)


root@xanadu:/var/log#pfctl -g -sr|grep @573
@573 pass in log quick on em3 inet proto tcp from any to 192.168.1.12 port = 25 
flags S/FSRA keep state (source-track rule, max-src-states 90, max-src-conn 90, 
max-src-conn-rate 30/30, max-src-nodes 70, overload  flush global, 
src.track 30) label "MAIL"
root@xanadu:/var/log#pfctl -g -sr|grep @89
@89 pass out log quick on vlan3 inet proto tcp all flags S/SA
root@xanadu:/var/log#pfctl -g -sr|grep @63 
@63 block drop log all

So is it perhaps possible to give any more hints based on this extra info? Here 
I see wscale in both cases.

Note though that on 6.0 it worked flawlessly. I upgraded from 6.0 and just did 
what the upgrade guide said + did a sysmerge where I kept my pf.conf as is. 

Peo

Re: spamd and outlook.com

[Craig Skinner]

Hello Peter/all,

On Fri, 21 Apr 2017 11:59:20 +0200 "Peter N. M. Hansteen" wrote:
> 
> start with
> 
> $ host -ttxt outlook.com
> 
> and follow the includes to the very end. Then weep.
> 


In February 2015 Paul de Weerd calculated Google published 217,088 IPv4
addresses, and 29,710,560,942,849,126,597,578,981,376 IPv6 addresses as
valid SMTP servers. See:
http://marc.info/?l=openbsd-misc=142478407909186

It would be reasonable to state Google (and others) have populated SPF
with LIES.


Boudewijn Dijkstra wrote: "SPF was never meant for making accept/reject
decisions on arbitrary domains. If you don't trust the sending domain,
then SPF evaluation is pointless."
http://marc.info/?l=openbsd-misc=148232868408696


Regards,
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: spamd and outlook.com

[Craig Skinner]

Hi Markus,

On Fri, 21 Apr 2017 11:25:14 +0200 Markus Rosjat wrote:
> so if you have spamd in place in greylisting mode and you have
> customers that work with people who use Office365 as a service you
> will get calls that emails are delayed for a freaking long time

Email is not instant messaging.

Customers need educated to that fact.

> 
> So  what are the strategies out there to handle this kind of
> situation? Do you let them all pass and trust that microsoft is
> protecting there service enough to stop spamming from hijacked
> machines that use office365 ?
> 

http://web.britvault.co.uk/products/ungrey-robins/logs/outlook.txt

The ungrey-robins tool, with patterns for Outlook, Google, Amazon, etc:
http://web.britvault.co.uk/products/ungrey-robins/


> 
> Just curious here I had a case where you could dig the mx for a
> domain and it was a outlook.com server.

No. DNS MX records are used for sending mail _TO_ a domain.

Inbound mail routing doesn't apply to outbound mail.

Domains may relay out via other domains (e.g. their ISP's mail farm).

When sending, many domains SMTP HELO with google, outlook, etc...

The ungrey-robins tool looks at the HELO hostname, not the FROM domain.


See the misc@ thread "spamd and network whitelisting"
http://marc.info/?t=14818982922


Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: Van Jacobson network channels

[Martin Pieuchot]

On 03/04/17(Mon) 10:41, Hrvoje Popovski wrote:
> Hi all,
> 
> i'm reading some networking stuff and I saw Van Jacobson presentation
> about net channels concept.
> For me, as user that doesn't know net internals, this presentation seems
> quite reasonable.
> 
> Beside that it's about linux network stack, what net gurus think about
> VJ net channels ?
> 
> http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf

It's an interesting idea.  But you have to understand the context in
which it has been presented.  I doubt that replacing "mbuf queue" (see
mq_init(9)) by net channels will buy us anything for now.  We're still
in the phase of eliminating the 'softint' context and moving everything
to tasks, close to where the packets will be consumed, as explained in
the presentation.

Once that's done we might see if a lock-free FIFO helps to pass packets
between contexts.

Re: spamd and outlook.com

[Reyk Floeter]

On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote:
> On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:
> > 
> > so if you have spamd in place in greylisting mode and you have customers
> > that work with people who use Office365 as a service you will get calls that
> > emails are delayed for a freaking long time and if you check the ip range
> > that outlook.com could send from you get scared.
> 
> start with
> 
> $ host -ttxt outlook.com
> 
> and follow the includes to the very end. Then weep.
> 
> TL;DR: last time I looked that expanded to eighty-some *networks* of varying 
> sizes.
> 
> https://github.com/akpoff/spf_fetch fed the relevant domains is one solution,
> and in addition you will find my collection of manually maintained SPF 
> sedimentation 
> is available at https://home.nuug.no/~peter/nospamd 
> 

I use the attached script to fetch the SPF entries recursively, in a
plain text format that can be fed into pfctl.

outlook.com gives me 82 networks.

Reyk

---snip---
#!/usr/bin/perl

# Copyright (c) 2016 Reyk Floeter 
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

$domain = shift @ARGV or die "usage: $0 domain";

sub parsespf
{
my $domain = shift;
my @foo = `nslookup -q=TXT $domain`;
my @results = ();

foreach (@foo) {
next if not /$domain\ttext/;
next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/;

@results = split /\s+/;
foreach (@results) {
next if /.all/;
if (s/^ip[46]://) {
print "$_\n";
} elsif (s/^(redirect|include)[:=]//) {
print "\n#$_\n";
parsespf($_);
}
} 
} 
}

parsespf($domain);

0;

Re: spamd and outlook.com

[Markus Rosjat]

hey peter,

like your pf book very much helped me a lot to grasp some stuff  :)

fot the host solution I already did this but skiped the part with 
following the includes.


MS is providing a list of there possible ip ranges here

https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx

and thats just scary ...

Am 21.04.2017 um 11:59 schrieb Peter N. M. Hansteen:

On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:


so if you have spamd in place in greylisting mode and you have customers
that work with people who use Office365 as a service you will get calls that
emails are delayed for a freaking long time and if you check the ip range
that outlook.com could send from you get scared.


start with

$ host -ttxt outlook.com

and follow the includes to the very end. Then weep.

TL;DR: last time I looked that expanded to eighty-some *networks* of varying 
sizes.

https://github.com/akpoff/spf_fetch fed the relevant domains is one solution,
and in addition you will find my collection of manually maintained SPF 
sedimentation
is available at https://home.nuug.no/~peter/nospamd

The problem is that the 'architects' behind outlook.com and their ilk are really
not on board with the idea that having some tiny bit of control over where your 
mail
comes from is a good idea, but they were made to comply with the SPF/DKIM/DMARC 
scheme
(straight out of the Rube Goldberg school of engineering), which is one of 
those endless
and endlessly tiresome artifacts of the "something has to be done", "this is 
something"
'system architect' responses.



--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: spamd and outlook.com

[Peter N. M. Hansteen]

On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote:
> 
> so if you have spamd in place in greylisting mode and you have customers
> that work with people who use Office365 as a service you will get calls that
> emails are delayed for a freaking long time and if you check the ip range
> that outlook.com could send from you get scared.

start with

$ host -ttxt outlook.com

and follow the includes to the very end. Then weep.

TL;DR: last time I looked that expanded to eighty-some *networks* of varying 
sizes.

https://github.com/akpoff/spf_fetch fed the relevant domains is one solution,
and in addition you will find my collection of manually maintained SPF 
sedimentation 
is available at https://home.nuug.no/~peter/nospamd 

The problem is that the 'architects' behind outlook.com and their ilk are really
not on board with the idea that having some tiny bit of control over where your 
mail
comes from is a good idea, but they were made to comply with the SPF/DKIM/DMARC 
scheme
(straight out of the Rube Goldberg school of engineering), which is one of 
those endless
and endlessly tiresome artifacts of the "something has to be done", "this is 
something"
'system architect' responses.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Mickael Torres]

On 2017-04-21 10:50, Stefan Sperling wrote:

On Fri, Apr 21, 2017 at 09:04:07AM +0200, Mickael Torres wrote:

On 2017-04-21 02:13, Jeff wrote:
> I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> ...
> First I tried to copy bsd.rd to / and boot from it.  When I boot
> using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> OpenBSD 6.0.

Hi Jeff,

If you use softraid on sparc64, you should have a small ffs FS on your
first disk, containing the kernel and ofwboot.
That *is* where you should put the new bsd.rd, and copy the new 
kernel(s)

at the end of install.

The firmware doesn't know how to boot a softraid volume, hence the 
need

for this small FS.


A separate boot partition is not required.

The first stage boot loader is a Forth script which reads a second 
stage

(ofwboot) from the softraid meta data area. ofwboot will load a kernel
from RAID1 and CRYPTO volumes. See the last few slides in
https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf

The install/upgrade scripts run installboot(8) to set this up.

The only differences to i386/amd64 is that bootable sparc64 RAID 
partitions
must use the letter 'a' (the first stage does not try any other 
letters) and
that the boot-device and boot-file open firmware environment variables 
must

be set up correctly (see boot_sparc64(8)).


Wow, you've just made my day!
Thanks, Stefan.

Best regards,
Mickael.

spamd and outlook.com

[Markus Rosjat]

Hi there,

so if you have spamd in place in greylisting mode and you have customers 
that work with people who use Office365 as a service you will get calls 
that emails are delayed for a freaking long time and if you check the ip 
range that outlook.com could send from you get scared.


So  what are the strategies out there to handle this kind of situation?
Do you let them all pass and trust that microsoft is protecting there 
service enough to stop spamming from hijacked machines that use office365 ?


Do you gradually grand access to a new ip rang if you see its tring to 
reach your server and let the rest be?


Just curious here I had a case where you could dig the mx for a domain 
and it was a outlook.com server. It was whitelisted in my system but it 
seems MS is using this mx to retrieve mail and still send mails even 
from that domain with other mx in diffrent ranges. So you see 30 grey 
entries from diffent mx that trying to reach the customers mailbox.


I'm a little reluctant to whitelist a shitload of ips just to get rid of 
a 1 or 2 day delay in delivering the message and yes this was the case


regards

--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Stefan Sperling]

On Fri, Apr 21, 2017 at 09:04:07AM +0200, Mickael Torres wrote:
> On 2017-04-21 02:13, Jeff wrote:
> > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> > ...
> > First I tried to copy bsd.rd to / and boot from it.  When I boot
> > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> > OpenBSD 6.0.
> 
> Hi Jeff,
> 
> If you use softraid on sparc64, you should have a small ffs FS on your
> first disk, containing the kernel and ofwboot.
> That *is* where you should put the new bsd.rd, and copy the new kernel(s)
> at the end of install.
> 
> The firmware doesn't know how to boot a softraid volume, hence the need
> for this small FS.

A separate boot partition is not required.

The first stage boot loader is a Forth script which reads a second stage
(ofwboot) from the softraid meta data area. ofwboot will load a kernel
from RAID1 and CRYPTO volumes. See the last few slides in
https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf

The install/upgrade scripts run installboot(8) to set this up.

The only differences to i386/amd64 is that bootable sparc64 RAID partitions
must use the letter 'a' (the first stage does not try any other letters) and
that the boot-device and boot-file open firmware environment variables must
be set up correctly (see boot_sparc64(8)).

OpenBSD 6.1, spamd strange behavior

[Alex Shupikov]

Hello misc

I'm setting the small mail system and I don't investigate with the working
of spamd.

spamd is working in the greylisting mode with "-v -G 2:4:864" options.
For every trying of the delivery mail a remote host become TRAPPED for 24
hours, and I don't understand why.

Please help me change the situation.

And excuse my English, I'm still learning it.

-- 
/Alex

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Stefan Sperling]

On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote:
> Hi,
> 
> I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> I attempted to update to OpenBSD 6.1 using the files first from:
> 
> http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64
> 
> Then from:
> 
> https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64
> 
> First I tried to copy bsd.rd to / and boot from it.  When I boot
> using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> OpenBSD 6.0.

Did you actually type '/boot bsd.rd'?
When booting from softraid you need to pass the virtual 'sr' drive
as part of the boot path. Try again with: boot sr0a:/bsd.rd

>From the boot_sparc64(8) man page:

 To boot from a softraid(4) volume by default, boot-device must be set to
 a disk device hosting a chunk of the softraid volume:

   ok setenv boot-device disk0

 and boot-file must contain the (sr) device name of the softraid volume
 and optionally a partition letter and/or kernel:

   ok setenv boot-file sr0a:/bsd

Re: Strange PF behaviour after 6.0 -> 6.1 pgrade

[Stuart Henderson]

On 2017-04-20, Sjöholm Per-Olov  wrote:
> Could it be any buffers that is causing this in 6.1 but not in 6.0 ?

There were changes that would allow larger TCP buffers in 6.1. This
would not have made a difference to normal or natted connections from
non-OpenBSD going through PF to non-OpenBSD but could possibly affect
some configurations with proxies (though only if PF rules were already
dodgy - you would have active states in "pfctl -ss|grep -A1 tcp"
without wscale values if this was the case).

Might be worth bumping up the pf log level and seeing if system logs
give you more clues. Default is "error", you need "notice" to get the
ones which might give useful clues (loose state match warnings or
state mismatch errors).  (On a busy machine, be ready to back-off on
the debug level in case it causes too much load).

new groups

[Rafael adorman]

0
C Iran
P Tehran
T Tehran
F irregular
O Iranian meetBSD Group
I abdorrahman homaei
M d.orien...@gmail.com
U http://meetbsd.ir
N *BSD

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Mickael Torres]

On 2017-04-21 02:13, Jeff wrote:

I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
...
First I tried to copy bsd.rd to / and boot from it.  When I boot
using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
OpenBSD 6.0.


Hi Jeff,

If you use softraid on sparc64, you should have a small ffs FS on your
first disk, containing the kernel and ofwboot.
That *is* where you should put the new bsd.rd, and copy the new 
kernel(s)

at the end of install.

The firmware doesn't know how to boot a softraid volume, hence the need
for this small FS.

Best regards,
Mickael.

Re: Performance Clang

[Andreas Kusalananda Kähäri]

On Thu, Apr 20, 2017 at 07:31:47PM +, Christian Weisgerber wrote:
> On 2017-04-19, Heiko  wrote:
> 
> > I'm using current on amd64 (Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz,
> > 3411.91 MHz)
> >
> > I noticed that with clang it needs 109 minutes for "make build" and
> > before with gcc 32 minutes.
> 
> Not sure what you mean by "performance" in the subject.  We're not
> building anything with clang yet, apart from clang itself.  We have
> simply added clang.  The rest of the build is identical.
> 
> And yes, clang is a big C++ program and C++ code compiles s l o w l y.
> 
> > Is this a normal behavior?
> 
> The exact numbers are a bit odd, but generally speaking, yes, adding
> clang has substantially increased the build time.  I see about a
> doubling on Xeon E3-12xx-based machines for make -j4 build.


I'm happy as long as building the complete base system takes less than a
day.  I'm more concerned with the compiler generating good code, to be
honest.

Cheers,
Kusalananda

Re: Adding default IPv6 route fails on 6.1

[Stuart Henderson]

On 2017-04-19, Harald Dunkel  wrote:
>
> On 04/18/17 17:05, Stuart Henderson wrote:
>> 
>> Mine is in the pkg-readme.
>> 
>> 
>
> A pkg-readme? Is this included in the binary package?

Yes - pkg_add should have drawn your attention to it:

# pkg_add dhcpcd
dhcpcd-6.11.5: ok
The following new rcscripts were installed: /etc/rc.d/dhcpcd
See rcctl(8) for details.
Look in /usr/local/share/doc/pkg-readmes for extra documentation.