Re: Can't set 'from' address in .mailrc
On Thu, Jan 28, 2021 at 09:51:57PM +, Stuart Henderson wrote: Not 100% sure but I think you can just edit it in the template file. But unless you've got a properly configured mail setup on the machine saving it as a text file is probably easier. Editing it in the template file did the trick. Thanks!
Re: Can't set 'from' address in .mailrc
On Thu, Jan 28, 2021 at 05:30:47PM +0100, Marcus MERIGHI wrote: 2. Where can I find the message that 'sendbug' composed? 'ls /var/spool/smtpd/queue/*' does not show any messages in any of the subfolders, did smtpd delete it because it couldn't be delivered? Do you see smtpd[30872]: warn: queue: no return path! in /var/log/maillog? Do you have a file named "dead.letter"? 'doas find / -iname dead.letter' produces no results. there is nothing matching "no return path" in /var/log/maillog.
Re: Can't set 'from' address in .mailrc
On Thu, Jan 28, 2021 at 05:30:07PM -, Stuart Henderson wrote: You could use "sendbug -P > sendbug.out" to get your report in a file and send that from a different host. Or edit the file and $ cat sendbug.out | mail -s "my bug report" -r my_lap...@domain.com \ -c my_lap...@domain.com b...@openbsd.org unless you do this, sendbug doesn't use mail(1), it uses /usr/sbin/sendmail directly. Okay, how do I specify that sendbug sets a specific from address when sending mail? Or do I have to save it as a text file as discussed above
Re: OpenSMTPD is not sending e-mail.
On Thu, Jan 28, 2021 at 08:41:46PM +0100, Radek wrote: > Hi, > a few days ago all my boxes using the same ISP stopped to send me emails from > local users and daemons (daily outputs and any other cronjob reports) to > @gmail.com. > I have tried to send email to a few not_gmail mailboxes - the same problem. > If i send emails from other boxes (using other ISP), they are received > correctly. > > Telnet test doesn't show the "220 mx.google." line. Does is mean that > port 25 is blocked by the ISP? > I would guess not since it shows you connected. > $ telnet gmail-smtp-in.l.google.com 25 > Trying 173.194.220.26... > Connected to gmail-smtp-in.l.google.com. > Escape character is '^]'. > Connection closed by foreign host. > > > $ smtpctl remove all > 14 envelopes removed > $ echo test-123 | mail -s test-123 a...@gmail.com > $ tail -n 30 /var/log/maillog > Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp connected > address=local host=fw66-krz.krz > Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp message > msgid=ba93721b size=331 nrcpt=1 proto=ESMTP > Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp envelope > evpid=ba93721b7de7a76f from= to= > Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp disconnected > reason=quit > Jan 28 20:06:57 fw66-krz smtpd[69953]: 717b8138ac37b4db mta error > reason=Connection closed unexpectedly > Jan 28 20:06:57 fw66-krz smtpd[69953]: smtp-out: Disabling route [] <-> > 142.250.96.27 (142.250.96.27) for 15s > Jan 28 20:07:12 fw66-krz smtpd[69953]: smtp-out: Enabling route [] <-> > 142.250.96.27 (142.250.96.27) > Jan 28 20:07:14 fw66-krz smtpd[69953]: 717b8139462f1927 mta error > reason=Connection closed unexpectedly > Jan 28 20:07:14 fw66-krz smtpd[69953]: smtp-out: Disabling route [] <-> > 108.177.112.27 (108.177.112.27) for 15s > Jan 28 20:07:14 fw66-krz smtpd[69953]: 717b813c3c64b02d mta connecting > address=smtp://142.250.96.27:25 host=142.250.96.27 > Jan 28 20:07:14 fw66-krz smtpd[69953]: 717b813c3c64b02d mta connected > Jan 28 20:07:29 fw66-krz smtpd[69953]: smtp-out: Enabling route [] <-> > 108.177.112.27 (108.177.112.27) > Jan 28 20:07:30 fw66-krz smtpd[69953]: 717b813ddb20a2c5 mta connecting > address=smtp://108.177.112.27:25 host=108.177.112.27 > Jan 28 20:07:30 fw66-krz smtpd[69953]: 717b813ddb20a2c5 mta connected > > > > > On Tue, 26 Jan 2021 11:26:17 - (UTC) > Stuart Henderson wrote: > > > On 2021-01-25, latincom wrote: > > > It had worked for many years; but this time OpenBSD 6.8; server and > > > Laptop, are not working as the man page says. > > > > > > I did an empiric test, because i am not qualified for a real test. > > > > > > Both are not able to send messages (e-mails), to other machines. > > > The message at maillog is the same: > > > > > > result="TempFail" stat="Network error on destination MXs" > > > > Perhaps your ISP blocks port 25. What do you get if you type > > "telnet gmail-smtp-in.l.google.com 25"? It should go something > > like this: > > > > $ telnet gmail-smtp-in.l.google.com 25 > > Trying 66.102.1.27... > > Connected to gmail-smtp-in.l.google.com. > > Escape character is '^]'. > > 220 mx.google.com ESMTP k2si3832128wrm.242 - gsmtpquit > > 221 2.0.0 closing > > connection k2si3832128wrm.242 - gsmtp > > Connection closed by foreign host. > > > > > > > > -- > Radek >
Re: Can't set 'from' address in .mailrc
On 2021/01/28 18:55, tetrahe...@danwin1210.me wrote: > On Thu, Jan 28, 2021 at 05:30:07PM -, Stuart Henderson wrote: > > > You could use "sendbug -P > sendbug.out" to get your report in a file > > > and send that from a different host. Or edit the file and > > > > > > $ cat sendbug.out | mail -s "my bug report" -r my_lap...@domain.com \ > > > -c my_lap...@domain.com b...@openbsd.org > > > > unless you do this, sendbug doesn't use mail(1), it uses /usr/sbin/sendmail > > directly. > > Okay, how do I specify that sendbug sets a specific from address when > sending mail? Or do I have to save it as a text file as discussed above Not 100% sure but I think you can just edit it in the template file. But unless you've got a properly configured mail setup on the machine saving it as a text file is probably easier.
Re: OpenSMTPD is not sending e-mail.
Hi, a few days ago all my boxes using the same ISP stopped to send me emails from local users and daemons (daily outputs and any other cronjob reports) to @gmail.com. I have tried to send email to a few not_gmail mailboxes - the same problem. If i send emails from other boxes (using other ISP), they are received correctly. Telnet test doesn't show the "220 mx.google." line. Does is mean that port 25 is blocked by the ISP? $ telnet gmail-smtp-in.l.google.com 25 Trying 173.194.220.26... Connected to gmail-smtp-in.l.google.com. Escape character is '^]'. Connection closed by foreign host. $ smtpctl remove all 14 envelopes removed $ echo test-123 | mail -s test-123 a...@gmail.com $ tail -n 30 /var/log/maillog Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp connected address=local host=fw66-krz.krz Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp message msgid=ba93721b size=331 nrcpt=1 proto=ESMTP Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp envelope evpid=ba93721b7de7a76f from= to= Jan 28 20:06:43 fw66-krz smtpd[69953]: 717b813accae5132 smtp disconnected reason=quit Jan 28 20:06:57 fw66-krz smtpd[69953]: 717b8138ac37b4db mta error reason=Connection closed unexpectedly Jan 28 20:06:57 fw66-krz smtpd[69953]: smtp-out: Disabling route [] <-> 142.250.96.27 (142.250.96.27) for 15s Jan 28 20:07:12 fw66-krz smtpd[69953]: smtp-out: Enabling route [] <-> 142.250.96.27 (142.250.96.27) Jan 28 20:07:14 fw66-krz smtpd[69953]: 717b8139462f1927 mta error reason=Connection closed unexpectedly Jan 28 20:07:14 fw66-krz smtpd[69953]: smtp-out: Disabling route [] <-> 108.177.112.27 (108.177.112.27) for 15s Jan 28 20:07:14 fw66-krz smtpd[69953]: 717b813c3c64b02d mta connecting address=smtp://142.250.96.27:25 host=142.250.96.27 Jan 28 20:07:14 fw66-krz smtpd[69953]: 717b813c3c64b02d mta connected Jan 28 20:07:29 fw66-krz smtpd[69953]: smtp-out: Enabling route [] <-> 108.177.112.27 (108.177.112.27) Jan 28 20:07:30 fw66-krz smtpd[69953]: 717b813ddb20a2c5 mta connecting address=smtp://108.177.112.27:25 host=108.177.112.27 Jan 28 20:07:30 fw66-krz smtpd[69953]: 717b813ddb20a2c5 mta connected On Tue, 26 Jan 2021 11:26:17 - (UTC) Stuart Henderson wrote: > On 2021-01-25, latincom wrote: > > It had worked for many years; but this time OpenBSD 6.8; server and > > Laptop, are not working as the man page says. > > > > I did an empiric test, because i am not qualified for a real test. > > > > Both are not able to send messages (e-mails), to other machines. > > The message at maillog is the same: > > > > result="TempFail" stat="Network error on destination MXs" > > Perhaps your ISP blocks port 25. What do you get if you type > "telnet gmail-smtp-in.l.google.com 25"? It should go something > like this: > > $ telnet gmail-smtp-in.l.google.com 25 > Trying 66.102.1.27... > Connected to gmail-smtp-in.l.google.com. > Escape character is '^]'. > 220 mx.google.com ESMTP k2si3832128wrm.242 - gsmtpquit > 221 2.0.0 closing > connection k2si3832128wrm.242 - gsmtp > Connection closed by foreign host. > > -- Radek
Re: OpenBSD (memory management) performance issues
On Thu, Jan 28, 2021 at 03:25:46PM +, Marek Klein wrote:
> > On Wed, Jan 27, 2021 at 08:39:46AM +0100, Otto Moerbeek wrote:
> >
> > > On Tue, Jan 26, 2021 at 04:08:40PM +, Marek Klein wrote:
> > >
> > > > Hi,
> > > >
> > > > We are working on an appliance like product that is based on OpenBSD.
> > > > Recently we found out that our performance critical C++ program is
> > > > ~2.5 times slower on OpenBSD compared to Ubuntu 20.04.
> > > >
> > > > The program basically just reads data from stdin, does some
> > > > transformation of the data, and returns the result on stdout, thus
> > > > the program does not perform any further I/O operations nor interacts
> > > > with other programs. We extensively use the C++ standard library string
> > > > class for manipulation of data.
> > > >
> > > > We started searching for the reason, and eliminated I/O as a factor.
> > > > During some experiments we found out that one, perhaps not the only
> > > > one, factor is OpenBSD's memory management. To test this assumption we
> > > > wrote a simple program that allocates and frees memory in a loop.
> > > > Something like:
> > > >
> > > > for (...) {
> > > > void *buffer = malloc(...);
> > > > ...
> > > > free(buffer);
> > > > }
> > > >
> > > > We compiled it on OpenBSD with clang
> > > > $ /usr/bin/c++ --version
> > > > OpenBSD clang version 10.0.1
> > > > Target: amd64-unknown-openbsd6.8
> > > > Thread model: posix
> > > > InstalledDir: /usr/bin
> > > >
> > > > using options '-O3 -DNDEBUG -std=gnu++11' and ran it without memory
> > > > junking.
> > > >
> > > > $ time MALLOC_OPTIONS=jj ./memory_allocs --cycles 123456789 --size
> > 1024
> > > >
> > > > real0m27.218s
> > > > user0m27.220s
> > > > sys 0m0.020s
> > > >
> > > > We compiled the same program on Ubuntu 20.04 with g++
> > > > $ /usr/bin/c++ --version
> > > > c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> > > >
> > > > using the same options '-O3 -DNDEBUG -std=gnu++11'
> > > >
> > > > $ time ./memory_allocs --cycles 123456789 --size 1024
> > > >
> > > > real0m1,920s
> > > > user0m1,915s
> > > > sys 0m0,004s
> > > >
> > > > Both systems were tested in the same virtualized environment (VSphere),
> > > > thus we can assume the "hardware" is the same.
> > > >
> > > > Given the virtual environment, the tests might not be scientifically
> > > > the best choice, but they serve the observation well enough. We
> > > > actually ruled out virtualization as a cause in other tests.
> > >
> > > Short story: the slowness is because you get more security.
> > >
> > > Somewhat longer story: depending on the size if the allocation actual
> > > unmaps take place on free. This will catch use-after-free always. For
> > > smaller allocations, caching takes place, sadly you did not tell us
> > > how big the total of your allocations are. So I cannot predict if
> > > enlargering the cache will help you.
> > >
> > > Now the differnence is quite big so I like to know what you are doing
> > > exactly in your test program. Please provide the full test porogram
> > > so I can take a look.
> > >
> > > >
> > > > What other options are there we could try in order to speed the memory
> > > > management up?
> > >
> > > Some hintss: allocate/free less, use better algorithms that do not
> > > allocate as much. With C++ make sure your code uses moves of objects
> > > instead of copies whenever possible. Use reserve() wisely. If all else
> > > fails you might go for custom allocaters, but you will loose security
> > > features.
> > >
> > > -Otto
> > >
> > > >
> > > > Also are there any other known areas, for CPU bound processing, where
> > > > OpenBSD performs worse than other "common" platforms?
> > > >
> > > > Cheers,
> > > > Marek
> > > >
> > >
> >
> > To reply to myself.
> >
> > Be VERY careful when drawing conclusions from these kinds of test
> > programs. To demonstrate, the loop in the test program below gets
> > compiled out by some compilers with some settings.
> >
> > So again, please provide your test program.
> >
> > -Otto
> >
> > #include
> > #include
> > #include
> > #include
> >
> > int
> > main(int argc, char *argv[])
> > {
> > size_t count, sz, i;
> > char *p;
> > const char *errstr;
> >
> > count = strtonum(argv[1], 0, LONG_MAX, &errstr);
> > if (errstr)
> > errx(1, "%s: %s", argv[1], errstr);
> > sz = strtonum(argv[2], 0, LONG_MAX, &errstr);
> > if (errstr)
> > errx(1, "%s: %s", argv[2], errstr);
> >
> > printf("Run with %zu %zu\n", count, sz);
> >
> > for (i = 0; i < count; i++) {
> > p = malloc(sz);
> > if (p == NULL)
> > err(1, NULL);
> > *p = 1;
> > free(p);
> > }
> > }
> >
> >
>
> Hi Otto,
>
> My test program does something very similar.
>
> As stated before I compile with
> 1. OpenBSD: clang version 10.0.1 and
> 2. Ubuntu: g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> with the same options '-O3
Can't set 'from' address in .mailrc
I'm trying to set up my system so I can use 'sendbug' to send in a bug report for a kernel panic, and a number of issues have cropped up. 1. My mail provider won't let me send email from but only from . Therefore I tried adding to ~/.mailrc: set from "my_lap...@domain.com" Unfortunately, this didn't fix the issue, and /var/log/maillog is still showing "Sender address rejected" messages. According to the mail manpage 'from' is a binary option, but this makes no sense to me, where does one set the default from address? 2. Where can I find the message that 'sendbug' composed? 'ls /var/spool/smtpd/queue/*' does not show any messages in any of the subfolders, did smtpd delete it because it couldn't be delivered?
Re: Can't set 'from' address in .mailrc
On 2021-01-28, Marcus MERIGHI wrote: > Hello, > > tetrahe...@danwin1210.me (tetrahe...@danwin1210.me), 2021.01.28 (Thu) 16:00 > (CET): >> I'm trying to set up my system so I can use 'sendbug' to send in a bug >> report for a kernel panic, and a number of issues have cropped up. >> >> 1. My mail provider won't let me send email from but only >> from . Therefore I tried adding to ~/.mailrc: >> set from "my_lap...@domain.com" >> Unfortunately, this didn't fix the issue, and /var/log/maillog is still >> showing "Sender address rejected" messages. >> According to the mail manpage 'from' is a binary option, but this makes no >> sense to me, where does one set the default from address? > > I have nothing to say on mail(1) interactive usage :-) and got confused > reading the man page, just as you. Looks like when "from" was added, the text about binary options at the top of the list was missed. > You could use "sendbug -P > sendbug.out" to get your report in a file > and send that from a different host. Or edit the file and > > $ cat sendbug.out | mail -s "my bug report" -r my_lap...@domain.com \ > -c my_lap...@domain.com b...@openbsd.org unless you do this, sendbug doesn't use mail(1), it uses /usr/sbin/sendmail directly.
Re: Can't set 'from' address in .mailrc
Hello, tetrahe...@danwin1210.me (tetrahe...@danwin1210.me), 2021.01.28 (Thu) 16:00 (CET): > I'm trying to set up my system so I can use 'sendbug' to send in a bug > report for a kernel panic, and a number of issues have cropped up. > > 1. My mail provider won't let me send email from but only > from . Therefore I tried adding to ~/.mailrc: > set from "my_lap...@domain.com" > Unfortunately, this didn't fix the issue, and /var/log/maillog is still > showing "Sender address rejected" messages. > According to the mail manpage 'from' is a binary option, but this makes no > sense to me, where does one set the default from address? I have nothing to say on mail(1) interactive usage :-) and got confused reading the man page, just as you. You could use "sendbug -P > sendbug.out" to get your report in a file and send that from a different host. Or edit the file and $ cat sendbug.out | mail -s "my bug report" -r my_lap...@domain.com \ -c my_lap...@domain.com b...@openbsd.org > 2. Where can I find the message that 'sendbug' composed? 'ls > /var/spool/smtpd/queue/*' does not show any messages in any of the > subfolders, did smtpd delete it because it couldn't be delivered? Do you see smtpd[30872]: warn: queue: no return path! in /var/log/maillog? Do you have a file named "dead.letter"? Marcus
Re: bgpd not including MED attribute on updates
On Thu, Jan 28, 2021 at 02:51:33PM +0100, open...@kene.nu wrote:
> In my case MED is changed with + on every eBGP hop. I use it to
> calculate the total MED over several hops to decide the best path from a
> latency point of view.
>
> My intention with listing the advertised prefix from R1 was to show that
> there is a MED present. As per the tcpdump I did, the MED attribute is not
> included in the BGP update packets. This I have confirmed is the case for
> all prefixes on R1 that has an iBGP nexthop. Any prefixes that in R1 has an
> eBGP nexthop advertises MED as expected.
>
> The "bgpd -vn" for R1:
>
> AS 64660
> router-id 172.30.37.1
> socket "/var/run/bgpd.sock.0"
> holdtime 9
> rde med compare always
> nexthop qualify via bgp
>
> prefix-set "internal" {
>
> }
>
> rde rib Adj-RIB-In no evaluate
> rde rib Loc-RIB rtable 0 fib-update yes
>
> neighbor 172.30.1.54 {
> descr "R2"
> remote-as 64840
> enforce neighbor-as yes
> enforce local-as yes
> announce IPv4 unicast
> }
>
> group "rr" {
> neighbor 172.30.37.25 {
> descr "rr1"
> remote-as 64660
> local-address 172.30.37.1
> enforce neighbor-as no
> enforce local-as yes
> announce IPv4 unicast
> }
> neighbor 172.30.37.39 {
> descr "rr2"
> remote-as 64660
> local-address 172.30.37.1
> enforce neighbor-as no
> enforce local-as yes
> announce IPv4 unicast
> }
> }
>
> deny from any
> deny to any
> allow to ebgp prefix-set "internal"
> allow to ibgp prefix-set "internal"
> allow from ebgp prefix-set "internal"
> allow from group "rr" prefix-set "internal"
> match to ibgp set { nexthop self }
> match from 172.30.1.54 set { metric +23 }
Any route learned via rr1 or rr2 will not pass the MED on to R2 because
the system does not touch the MED and therefor bgpd considers the received
MED from rr1 and rr2 to have originated from outside and so it is excluded
from UPDATES to EBGP peers.
You should add a 'maych from ibgp set med +0' rule which makes MED learned
via IBGP to be considered to be sent out.
> On Thu, Jan 28, 2021 at 2:01 PM Claudio Jeker
> wrote:
>
> > On Thu, Jan 28, 2021 at 12:41:29PM +0100, open...@kene.nu wrote:
> > > Hello,
> > >
> > > I am experiencing this on 6.8, fully syspatched.
> > >
> > > root@R1():~ # uname -a
> > > OpenBSD R1 6.8 GENERIC.MP#4 amd64
> > >
> > > The problem is that R1 sends updates with MED set to 0 even though I
> > expect
> > > it not to be. Upon reviewing a tcpdump pcap taken at R2, the MED
> > attribute
> > > is not even included in said update sent from R1.
> > >
> > > This only applies to some, not all updates, in my case it seems to affect
> > > routes where R1 has an ospf discovered nexthop. (172.30.37.2)
> > >
> > > root@R1():~ # route -n get 172.30.37.2 | grep priority
> > >priority: 32 (ospf)
> > >
> > > root@R1():~ # route -n get 172.30.1.110 | grep priority
> > >priority: 8 (static)
> > >
> > > root@R1():~ # bgpctl sh ip bgp neigh R2 out | egrep "172.30.194.[1234]"
> > > * N 172.30.194.1/32 172.30.1.110 100 210 64750 i
> > > * N 172.30.194.2/32 172.30.37.2 100 251 64750 i
> > > * N 172.30.194.3/32 172.30.1.110 100 210 64750 i
> > > * N 172.30.194.4/32 172.30.1.110 100 210 64750 i
> > >
> > > root@R2():~ $ bgpctl sh ip bgp neigh R1 in | egrep "172.30.194.[1234]"
> > > * N 172.30.194.1/32 172.30.1.55100 210 64660 64750
> > i
> > > * N 172.30.194.2/32 172.30.1.55100 0 64660 64750
> > i
> > > * N 172.30.194.3/32 172.30.1.55100 210 64660 64750
> > i
> > > * N 172.30.194.4/32 172.30.1.55100 210 64660 64750
> > i
> >
> > Please remember that MED is not really a transitive attribute. It only
> > hops into an AS but not accross it. So a MED recv from an EBGP session is
> > not forwarded. If the MED is changed (e.g. set med +1 -- maybe set med +0
> > works as well, don't remember) then the MED will be passed on.
> > From the output the session between R1 and R2 is EBGP so it very much
> > depends on your filter rules. If the MED was changed by the ruleset it
> > will be sent if not it will be filtered.
> >
> > With the limited information it is not really possible to know. Note, the
> > adj-rib-out output on R1 shows the prefix before the attribute is stripped.
> > Also the ASPATH prepend happens then.
> >
> > --
> > :wq Claudio
> >
--
:wq Claudio
Re: bgpd not including MED attribute on updates
In my case MED is changed with + on every eBGP hop. I use it to
calculate the total MED over several hops to decide the best path from a
latency point of view.
My intention with listing the advertised prefix from R1 was to show that
there is a MED present. As per the tcpdump I did, the MED attribute is not
included in the BGP update packets. This I have confirmed is the case for
all prefixes on R1 that has an iBGP nexthop. Any prefixes that in R1 has an
eBGP nexthop advertises MED as expected.
The "bgpd -vn" for R1:
AS 64660
router-id 172.30.37.1
socket "/var/run/bgpd.sock.0"
holdtime 9
rde med compare always
nexthop qualify via bgp
prefix-set "internal" {
}
rde rib Adj-RIB-In no evaluate
rde rib Loc-RIB rtable 0 fib-update yes
neighbor 172.30.1.54 {
descr "R2"
remote-as 64840
enforce neighbor-as yes
enforce local-as yes
announce IPv4 unicast
}
group "rr" {
neighbor 172.30.37.25 {
descr "rr1"
remote-as 64660
local-address 172.30.37.1
enforce neighbor-as no
enforce local-as yes
announce IPv4 unicast
}
neighbor 172.30.37.39 {
descr "rr2"
remote-as 64660
local-address 172.30.37.1
enforce neighbor-as no
enforce local-as yes
announce IPv4 unicast
}
}
deny from any
deny to any
allow to ebgp prefix-set "internal"
allow to ibgp prefix-set "internal"
allow from ebgp prefix-set "internal"
allow from group "rr" prefix-set "internal"
match to ibgp set { nexthop self }
match from 172.30.1.54 set { metric +23 }
On Thu, Jan 28, 2021 at 2:01 PM Claudio Jeker
wrote:
> On Thu, Jan 28, 2021 at 12:41:29PM +0100, open...@kene.nu wrote:
> > Hello,
> >
> > I am experiencing this on 6.8, fully syspatched.
> >
> > root@R1():~ # uname -a
> > OpenBSD R1 6.8 GENERIC.MP#4 amd64
> >
> > The problem is that R1 sends updates with MED set to 0 even though I
> expect
> > it not to be. Upon reviewing a tcpdump pcap taken at R2, the MED
> attribute
> > is not even included in said update sent from R1.
> >
> > This only applies to some, not all updates, in my case it seems to affect
> > routes where R1 has an ospf discovered nexthop. (172.30.37.2)
> >
> > root@R1():~ # route -n get 172.30.37.2 | grep priority
> >priority: 32 (ospf)
> >
> > root@R1():~ # route -n get 172.30.1.110 | grep priority
> >priority: 8 (static)
> >
> > root@R1():~ # bgpctl sh ip bgp neigh R2 out | egrep "172.30.194.[1234]"
> > * N 172.30.194.1/32 172.30.1.110 100 210 64750 i
> > * N 172.30.194.2/32 172.30.37.2 100 251 64750 i
> > * N 172.30.194.3/32 172.30.1.110 100 210 64750 i
> > * N 172.30.194.4/32 172.30.1.110 100 210 64750 i
> >
> > root@R2():~ $ bgpctl sh ip bgp neigh R1 in | egrep "172.30.194.[1234]"
> > * N 172.30.194.1/32 172.30.1.55100 210 64660 64750
> i
> > * N 172.30.194.2/32 172.30.1.55100 0 64660 64750
> i
> > * N 172.30.194.3/32 172.30.1.55100 210 64660 64750
> i
> > * N 172.30.194.4/32 172.30.1.55100 210 64660 64750
> i
>
> Please remember that MED is not really a transitive attribute. It only
> hops into an AS but not accross it. So a MED recv from an EBGP session is
> not forwarded. If the MED is changed (e.g. set med +1 -- maybe set med +0
> works as well, don't remember) then the MED will be passed on.
> From the output the session between R1 and R2 is EBGP so it very much
> depends on your filter rules. If the MED was changed by the ruleset it
> will be sent if not it will be filtered.
>
> With the limited information it is not really possible to know. Note, the
> adj-rib-out output on R1 shows the prefix before the attribute is stripped.
> Also the ASPATH prepend happens then.
>
> --
> :wq Claudio
>
Re: bgpd not including MED attribute on updates
On Thu, Jan 28, 2021 at 12:41:29PM +0100, open...@kene.nu wrote: > Hello, > > I am experiencing this on 6.8, fully syspatched. > > root@R1():~ # uname -a > OpenBSD R1 6.8 GENERIC.MP#4 amd64 > > The problem is that R1 sends updates with MED set to 0 even though I expect > it not to be. Upon reviewing a tcpdump pcap taken at R2, the MED attribute > is not even included in said update sent from R1. > > This only applies to some, not all updates, in my case it seems to affect > routes where R1 has an ospf discovered nexthop. (172.30.37.2) > > root@R1():~ # route -n get 172.30.37.2 | grep priority >priority: 32 (ospf) > > root@R1():~ # route -n get 172.30.1.110 | grep priority >priority: 8 (static) > > root@R1():~ # bgpctl sh ip bgp neigh R2 out | egrep "172.30.194.[1234]" > * N 172.30.194.1/32 172.30.1.110 100 210 64750 i > * N 172.30.194.2/32 172.30.37.2 100 251 64750 i > * N 172.30.194.3/32 172.30.1.110 100 210 64750 i > * N 172.30.194.4/32 172.30.1.110 100 210 64750 i > > root@R2():~ $ bgpctl sh ip bgp neigh R1 in | egrep "172.30.194.[1234]" > * N 172.30.194.1/32 172.30.1.55100 210 64660 64750 i > * N 172.30.194.2/32 172.30.1.55100 0 64660 64750 i > * N 172.30.194.3/32 172.30.1.55100 210 64660 64750 i > * N 172.30.194.4/32 172.30.1.55100 210 64660 64750 i Please remember that MED is not really a transitive attribute. It only hops into an AS but not accross it. So a MED recv from an EBGP session is not forwarded. If the MED is changed (e.g. set med +1 -- maybe set med +0 works as well, don't remember) then the MED will be passed on. >From the output the session between R1 and R2 is EBGP so it very much depends on your filter rules. If the MED was changed by the ruleset it will be sent if not it will be filtered. With the limited information it is not really possible to know. Note, the adj-rib-out output on R1 shows the prefix before the attribute is stripped. Also the ASPATH prepend happens then. -- :wq Claudio
bgpd not including MED attribute on updates
Hello, I am experiencing this on 6.8, fully syspatched. root@R1():~ # uname -a OpenBSD R1 6.8 GENERIC.MP#4 amd64 The problem is that R1 sends updates with MED set to 0 even though I expect it not to be. Upon reviewing a tcpdump pcap taken at R2, the MED attribute is not even included in said update sent from R1. This only applies to some, not all updates, in my case it seems to affect routes where R1 has an ospf discovered nexthop. (172.30.37.2) root@R1():~ # route -n get 172.30.37.2 | grep priority priority: 32 (ospf) root@R1():~ # route -n get 172.30.1.110 | grep priority priority: 8 (static) root@R1():~ # bgpctl sh ip bgp neigh R2 out | egrep "172.30.194.[1234]" * N 172.30.194.1/32 172.30.1.110 100 210 64750 i * N 172.30.194.2/32 172.30.37.2 100 251 64750 i * N 172.30.194.3/32 172.30.1.110 100 210 64750 i * N 172.30.194.4/32 172.30.1.110 100 210 64750 i root@R2():~ $ bgpctl sh ip bgp neigh R1 in | egrep "172.30.194.[1234]" * N 172.30.194.1/32 172.30.1.55100 210 64660 64750 i * N 172.30.194.2/32 172.30.1.55100 0 64660 64750 i * N 172.30.194.3/32 172.30.1.55100 210 64660 64750 i * N 172.30.194.4/32 172.30.1.55100 210 64660 64750 i
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, Jan 27, 2021 at 11:12 PM vejetaryenvampir wrote: > I think I was having the same problem when I changed the passphrase > of my disk. I managed to fix it with installboot(8). You can > access the bug report in here: > https://marc.info/?l=openbsd-bugs&m=161075212820257&w=2 > I had the panic with the 6.8-stable device, but the 6.8-current device > was booting just fine. In fact, I've used installboot(8) on that device > while it was running (booted by hand with sr0a:/bsd as you did). > > Sincerely, > vejetaryenvampir > Thank you so much! You made my day! So I used FuguIta (6.8 - stable) attached the encrypted partition (accessible as sd1 now) and 'installboot sd1', reboot and surprise - everything is working. I still have no idea why detaching the softraid determined this kind of behavior. Best regards, Samarul P.S. To tetrahedra --- maybe this solution will solve your problem also.
