Re: Mutt cannot sent mail in OpenBsd
On 2022-07-08, Stuart Henderson wrote: > You are missing the intermediate certificate on the server. visually: imap - presents an intermediate cert, providing a path to the trusted root cert --- Certificate chain 0 s:/CN=mail.thinkerwim.org i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- smtp - doesn't --- Certificate chain 0 s:/CN=mail.thinkerwim.org i:/C=US/O=Let's Encrypt/CN=R3 ---
Re: Mutt cannot sent mail in OpenBsd
Hi, Thanks Stuart, I figured it out. So silly my SMTP server was indeerd serving a different cert than my imap server (DOVECOT). I used the mail.thinkerwim.org.crt instead of mail.thinkerwim.org.fullchain.pem Thank bsd team for helping me :-). See you around Bye Wim Stockman On Sat, Jul 09, 2022 at 07:47:43AM -, Stuart Henderson wrote: > On 2022-07-08, Stuart Henderson wrote: > > You are missing the intermediate certificate on the server. > > visually: > > imap - presents an intermediate cert, providing a path to the trusted root > cert > > --- > Certificate chain > 0 s:/CN=mail.thinkerwim.org >i:/C=US/O=Let's Encrypt/CN=R3 > 1 s:/C=US/O=Let's Encrypt/CN=R3 >i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 > 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 >i:/O=Digital Signature Trust Co./CN=DST Root CA X3 > --- > > smtp - doesn't > > --- > Certificate chain > 0 s:/CN=mail.thinkerwim.org >i:/C=US/O=Let's Encrypt/CN=R3 > --- > >
Re: dhcpleased and ifstated
On 2022-07-06 21:05 +02, Christer Solskogen wrote: > On Wed, Jul 6, 2022 at 4:47 PM Florian Obser wrote: > >> >> Are you comparing the same thing? I.e. did dhcpleased get a lease before >> and does /var/db/dhcpleased/$IF exist? >> > > Both nodes have /var/db/dhcpleased/$IF. If I reboot both firewalls only the > master have gotten the lease, until I do a switch over. > During a switchover I get this with debug on: > > tugs# dhcpleased -d -v -v > changed iface: re2[3] > state_transition[re2] Down -> Down, timo: -1 > > (when doing the switchover) > > state_transition[re2] Down -> Down, timo: -1 > state_transition[re2] Down -> Rebooting, timo: 1 interface coming up, setting timeout to 1 second > DHCPREQUEST on re2 we are sending DHCPREQUEST > iface_timeout[3]: Rebooting we did not get a DHCPACK within 1 second > state_transition[re2] Rebooting -> Rebooting, timo: 2 setting timeout to 2 seconds > DHCPREQUEST on re2 send another DHCPREQUEST Note that we are sending the DHCPREQUEST immediately and then wait at most 2 seconds. > parse_dhcp, from: 00:02:00:01:00:01, to: ff:ff:ff:ff:ff:ff > parse_dhcp: 79.160.116.238:67 -> 255.255.255.255:68 > we probably get a DHCPACK. > > It looks to me that it's rebooting twice? yes, because it didn't get a DHCPACK for the first DHCPREQUEST. Maybe the DHCP server was busy. I'm seeing this with my ISP's CPE once in a while, too. > > What's the correct way of doing this with ifstated? run "ifconfig $IF down" > or "ifconfig $IF delete"? I have no idea, I've never used ifstated. -- I'm not entirely sure you are real.
Re: dhcpleased and ifstated
This happens every time with dhcpleased and my ISP and it didn't with dhclient, and what I do see now, that I didn't see with dhclient, is that during the negotiation ifconfig says that the interface has "status: no carrier" for 2-3 seconds. Which explains why I don't get a DHCPACK within 1 second.
