Re: IPv6 packets are not forwarded via IPsec tunnel
On Mon, Dec 07, 2020 at 01:00:05PM +0900, Yuichiro NAITO wrote:
> Hi.
>
> I have set up OpenBSD as a IPsec gateway and tried to forward IPv6 packets.
> But IPv6 packets are not forwarded via IPsec tunnel.
> IPv4 forwarding via IPsec works for me.
>
> Of course, I set following MIBs.
>
> net.inet.ip.forwarding=1
> net.inet6.ip6.forwarding=1
>
> I have confirmed ipsec policies by 'ipsecctl -sa'.
> Both SPD and SPA entries are good to me.
>
> In my investigation,
> IPv6 packets are forwarded by ip6_forward() function in ip6_forward.c.
> One of the arguments of ip6_forward() is "struct rtentry *rt" that will be
> NULL,
> if the packet is forwarded via IPsec tunnel.
> Because next hop information is written in SPD and not in the routing table.
>
> If rt is NULL, "rtisvalid(rt)" check is not satisfied,
> OpenBSD sends back network unreachable ICMP6 packet before
> ip6_output_ipsec_send().
>
> I have tried the following patch that makes dummy 'rt' to pass
> "rtisvalid(rt)” check
> and do the Scope check. It forwards IPv6 packets as I expected.
IPsec requires valid routing to work both for IPv6 and IPv4. At least you
need to have a default route that forwards the packet. The IPsec flow will
trigger on the output and "steal" the packets away.
Is there a reason why your IPv6 setup has no matching route that would
allow ip6_forward to work?
> diff --git a/sys/netinet6/ip6_forward.c b/sys/netinet6/ip6_forward.c
> index e47047e31f1..4dac045f243 100644
> --- a/sys/netinet6/ip6_forward.c
> +++ b/sys/netinet6/ip6_forward.c
> @@ -91,6 +91,7 @@ ip6_forward(struct mbuf *m, struct rtentry *rt, int srcrt)
> struct mbuf *mcopy = NULL;
> #ifdef IPSEC
> struct tdb *tdb = NULL;
> + struct rtentry rtent;
> #endif /* IPSEC */
> char src6[INET6_ADDRSTRLEN], dst6[INET6_ADDRSTRLEN];
>
> @@ -157,6 +158,17 @@ reroute:
> m_freem(m);
> goto freecopy;
> }
> + if (tdb != NULL && rt == NULL) {
> + /*
> + * If we try to forward via IPsec,
> + * create dummy rtent for scope check.
> + */
> + rt =
> + memset(rt, 0, sizeof(rtent));
> + SET(rt->rt_flags, RTF_UP);
> + /* Do not match any existing interface */
> + memset(>rt_ifidx, 0xff, sizeof(rt->rt_ifidx));
> + }
> }
> #endif /* IPSEC */
>
> @@ -302,6 +314,9 @@ reroute:
> /* tag as generated to skip over pf_test on rerun */
> m->m_pkthdr.pf.flags |= PF_TAG_GENERATED;
> srcrt = 1;
> +#ifdef IPSEC
> + if (rt != )
> +#endif /* IPSEC */
> rtfree(rt);
> rt = NULL;
> if_put(ifp);
> @@ -369,6 +384,9 @@ senderr:
> freecopy:
> m_freem(mcopy);
> out:
> +#ifdef IPSEC
> + if (rt != )
> +#endif /* IPSEC */
> rtfree(rt);
> if_put(ifp);
> }
>
> —
> Yuichiro NAITO
> naito.yuich...@gmail.com
>
>
>
>
--
:wq Claudio
Re: syspatch exit state
> > Returning a non-zero exit status is generally a sign of some sort of > failure. Not applying a patch due to already having the patch applied > is not really a failure. > The joys of running Solaris 2.x patches in the late 90s, where "ERROR 02" means the above, you already have the patch. And it took ages for the OS to figure this out for each one, taking longer and longer as recommended packs grew bigger over time. -- May the most significant bit of your life be positive.
IPv6 packets are not forwarded via IPsec tunnel
Hi.
I have set up OpenBSD as a IPsec gateway and tried to forward IPv6 packets.
But IPv6 packets are not forwarded via IPsec tunnel.
IPv4 forwarding via IPsec works for me.
Of course, I set following MIBs.
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
I have confirmed ipsec policies by 'ipsecctl -sa'.
Both SPD and SPA entries are good to me.
In my investigation,
IPv6 packets are forwarded by ip6_forward() function in ip6_forward.c.
One of the arguments of ip6_forward() is "struct rtentry *rt" that will be NULL,
if the packet is forwarded via IPsec tunnel.
Because next hop information is written in SPD and not in the routing table.
If rt is NULL, "rtisvalid(rt)" check is not satisfied,
OpenBSD sends back network unreachable ICMP6 packet before
ip6_output_ipsec_send().
I have tried the following patch that makes dummy 'rt' to pass "rtisvalid(rt)”
check
and do the Scope check. It forwards IPv6 packets as I expected.
diff --git a/sys/netinet6/ip6_forward.c b/sys/netinet6/ip6_forward.c
index e47047e31f1..4dac045f243 100644
--- a/sys/netinet6/ip6_forward.c
+++ b/sys/netinet6/ip6_forward.c
@@ -91,6 +91,7 @@ ip6_forward(struct mbuf *m, struct rtentry *rt, int srcrt)
struct mbuf *mcopy = NULL;
#ifdef IPSEC
struct tdb *tdb = NULL;
+ struct rtentry rtent;
#endif /* IPSEC */
char src6[INET6_ADDRSTRLEN], dst6[INET6_ADDRSTRLEN];
@@ -157,6 +158,17 @@ reroute:
m_freem(m);
goto freecopy;
}
+ if (tdb != NULL && rt == NULL) {
+ /*
+* If we try to forward via IPsec,
+* create dummy rtent for scope check.
+*/
+ rt =
+ memset(rt, 0, sizeof(rtent));
+ SET(rt->rt_flags, RTF_UP);
+ /* Do not match any existing interface */
+ memset(>rt_ifidx, 0xff, sizeof(rt->rt_ifidx));
+ }
}
#endif /* IPSEC */
@@ -302,6 +314,9 @@ reroute:
/* tag as generated to skip over pf_test on rerun */
m->m_pkthdr.pf.flags |= PF_TAG_GENERATED;
srcrt = 1;
+#ifdef IPSEC
+ if (rt != )
+#endif /* IPSEC */
rtfree(rt);
rt = NULL;
if_put(ifp);
@@ -369,6 +384,9 @@ senderr:
freecopy:
m_freem(mcopy);
out:
+#ifdef IPSEC
+ if (rt != )
+#endif /* IPSEC */
rtfree(rt);
if_put(ifp);
}
—
Yuichiro NAITO
naito.yuich...@gmail.com
Re: syspatch exit state
On December 6, 2020 8:13:26 PM GMT+01:00, Antoine Jacoutot wrote: >On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote: >> On 2020/12/06 16:39, Otto Moerbeek wrote: >> > On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote: >> > >> > > On 06/12/2020 14:32, Otto Moerbeek wrote: >> > > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: >> > > > >> > > >> Hi, >> > > >> I've been looking to have syspatch give me a quick indication >of whether >> > > >> a reboot is likely to be required. As a quick and dirty check, >I've just >> > > >> been treating "Were patches applied?" as the indicator. >> > > >> >> > > >> The following diff will cause syspatch to exit when applying >patches >> > > >> with status code 0 only if patches were actually applied. >> > > >> >> > > >> My biggest concern is that it does cause a change in >behaviour, so >> > > >> perhaps this either needs making into an option or a different >approach >> > > >> entirely? >> > > >> >> > > >> --- syspatch Sun Dec 6 14:11:12 2020 >> > > >> +++ syspatch Sun Dec 6 14:10:23 2020 >> > > >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then >> > > >> _PATCH_APPLIED=true >> > > >> done >> > > >> fi >> > > >> + >> > > >> +if [ "$_PATCH_APPLIED" = "true" ]; then >> > > >> + exit 0 >> > > >> +else >> > > >> + exit 1 >> > > >> +fi >> > > >> >> > > >> Thanks, >> > > >> S >> > > >> >> > > > I don't this is correct since it maks syspatch exit 1 on "no >patches applied". >> > > > >> > > >-Otto >> > > > . >> > > That's precisely the idea- from previous discussion with a couple >of >> > > people there didn't seem to be an easy (programmatic) way to >figure out >> > > whether syspatch had done anything or not. >> > >> > exit code 1 normally used for error conditions. A system being >> > up-to-date is not an error condition. >> > >> >-Otto >> > >> > >> > > >> > > Doing this would be a bit of a blunt way of handling things, and >perhaps >> > > it would be better gated behind a flag, but is there a better way >to >> > > make a scripted update work automatically (including rebooting as >> > > necessary)? >> > > >> > > Thanks, >> > > S >> > >> >> How about the same exit codes as acme-client? They seem fairly >> reasonable - 0=updated, 1=failure, 2=no change. > >I wouldn't object to that. So that'd boil down to $_PATCH_APPLIED || exit 4 or $_PATCH_APPLIED && exit exit 4 ...if the explicit exit feels better instead of just running to the end of the script. But maybe this script prefers some more verbosity... :-) /Alexander
Re: syspatch exit state
On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote: > On 2020/12/06 16:39, Otto Moerbeek wrote: > > On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote: > > > > > On 06/12/2020 14:32, Otto Moerbeek wrote: > > > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > > > > > > > >> Hi, > > > >> I've been looking to have syspatch give me a quick indication of > > > >> whether > > > >> a reboot is likely to be required. As a quick and dirty check, I've > > > >> just > > > >> been treating "Were patches applied?" as the indicator. > > > >> > > > >> The following diff will cause syspatch to exit when applying patches > > > >> with status code 0 only if patches were actually applied. > > > >> > > > >> My biggest concern is that it does cause a change in behaviour, so > > > >> perhaps this either needs making into an option or a different approach > > > >> entirely? > > > >> > > > >> --- syspatch Sun Dec 6 14:11:12 2020 > > > >> +++ syspatch Sun Dec 6 14:10:23 2020 > > > >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then > > > >> _PATCH_APPLIED=true > > > >> done > > > >> fi > > > >> + > > > >> +if [ "$_PATCH_APPLIED" = "true" ]; then > > > >> + exit 0 > > > >> +else > > > >> + exit 1 > > > >> +fi > > > >> > > > >> Thanks, > > > >> S > > > >> > > > > I don't this is correct since it maks syspatch exit 1 on "no patches > > > > applied". > > > > > > > > -Otto > > > > . > > > That's precisely the idea- from previous discussion with a couple of > > > people there didn't seem to be an easy (programmatic) way to figure out > > > whether syspatch had done anything or not. > > > > exit code 1 normally used for error conditions. A system being > > up-to-date is not an error condition. > > > > -Otto > > > > > > > > > > Doing this would be a bit of a blunt way of handling things, and perhaps > > > it would be better gated behind a flag, but is there a better way to > > > make a scripted update work automatically (including rebooting as > > > necessary)? > > > > > > Thanks, > > > S > > > > How about the same exit codes as acme-client? They seem fairly > reasonable - 0=updated, 1=failure, 2=no change. I wouldn't object to that. -- Antoine
Re: syspatch exit state
On 2020/12/06 16:39, Otto Moerbeek wrote: > On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote: > > > On 06/12/2020 14:32, Otto Moerbeek wrote: > > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > > > > > >> Hi, > > >> I've been looking to have syspatch give me a quick indication of whether > > >> a reboot is likely to be required. As a quick and dirty check, I've just > > >> been treating "Were patches applied?" as the indicator. > > >> > > >> The following diff will cause syspatch to exit when applying patches > > >> with status code 0 only if patches were actually applied. > > >> > > >> My biggest concern is that it does cause a change in behaviour, so > > >> perhaps this either needs making into an option or a different approach > > >> entirely? > > >> > > >> --- syspatch Sun Dec 6 14:11:12 2020 > > >> +++ syspatch Sun Dec 6 14:10:23 2020 > > >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then > > >> _PATCH_APPLIED=true > > >> done > > >> fi > > >> + > > >> +if [ "$_PATCH_APPLIED" = "true" ]; then > > >> + exit 0 > > >> +else > > >> + exit 1 > > >> +fi > > >> > > >> Thanks, > > >> S > > >> > > > I don't this is correct since it maks syspatch exit 1 on "no patches > > > applied". > > > > > > -Otto > > > . > > That's precisely the idea- from previous discussion with a couple of > > people there didn't seem to be an easy (programmatic) way to figure out > > whether syspatch had done anything or not. > > exit code 1 normally used for error conditions. A system being > up-to-date is not an error condition. > > -Otto > > > > > > Doing this would be a bit of a blunt way of handling things, and perhaps > > it would be better gated behind a flag, but is there a better way to > > make a scripted update work automatically (including rebooting as > > necessary)? > > > > Thanks, > > S > How about the same exit codes as acme-client? They seem fairly reasonable - 0=updated, 1=failure, 2=no change. I use this as a workaround, which I am not at all happy with. date >> /var/log/updates syspatch 2>&1 | tee -a /var/log/updates | grep -q Installing && log="$log syspatches" && _reboot=true pkg_add -vu 2>&1 | tee -a /var/log/updates | grep -q Adding && log="$log packages" && _reboot=true fw_update -v 2>&1 | tee -a /var/log/updates | grep -q ": ok" && log="$log firmware" && _reboot=true if $_reboot; then logger "$log, rebooting" shutdown -r +1 fi
Re: syspatch exit state
> Returning a non-zero exit status is generally a sign of some sort of > failure. Not applying a patch due to already having the patch applied > is not really a failure. Generally agreed, though at the same time, sysupgrade returns non-zero if there is no upgrade to apply so the same behaviour /could/ be valid here. That being said: > Instead, you could run syspatch -c from a regular cron job and > patch+reboot whenever that tells you there's new patches available. That sounds like a better approach in this case. I'll double check the behaviour of syspatch -c, and perhaps look into making a patch that updates the usage output of syspatch. Anyway, best to disregard the original diff now I think. Thanks, S
Re: Edit /etc/boot.conf
On Sun, Dec 06, 2020 at 04:21:10PM +0100, Mark Kettenis wrote:
> Both armv7 and powerpc64 support VTs, so let xenodem take the VT
> reserved for X in /etc/ttys.
>
> ok?
Sure. It will soon be time to invert the test and list machines that
don't support VTs
>
>
> Index: app/xenodm/Makefile.bsd-wrapper
> ===
> RCS file: /cvs/xenocara/app/xenodm/Makefile.bsd-wrapper,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile.bsd-wrapper
> --- app/xenodm/Makefile.bsd-wrapper 1 Apr 2020 19:58:02 - 1.5
> +++ app/xenodm/Makefile.bsd-wrapper 6 Dec 2020 14:59:40 -
> @@ -4,8 +4,8 @@
> XENODMCONFIGDIR=/etc/X11/xenodm
> PIXMAPDIR=$(XENODMCONFIGDIR)/pixmaps
>
> -.if ${MACHINE} == amd64 || ${MACHINE} == arm64 || ${MACHINE} == i386 \
> -|| ${MACHINE} == macppc
> +.if ${MACHINE} == amd64 || ${MACHINE} == arm64 || ${MACHINE} == armv7 \
> +|| ${MACHINE} == i386 || ${MACHINE} == macppc || ${MACHINE} == powerpc64
> DEFAULT_VT= --with-default-vt=vt05
> .endif
>
--
Matthieu Herrb
Re: syspatch exit state
On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > Hi, > I've been looking to have syspatch give me a quick indication of whether > a reboot is likely to be required. As a quick and dirty check, I've just > been treating "Were patches applied?" as the indicator. > > The following diff will cause syspatch to exit when applying patches > with status code 0 only if patches were actually applied. > > My biggest concern is that it does cause a change in behaviour, so > perhaps this either needs making into an option or a different approach > entirely? > > --- syspatch Sun Dec 6 14:11:12 2020 > +++ syspatch Sun Dec 6 14:10:23 2020 > @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then > _PATCH_APPLIED=true > done > fi > + > +if [ "$_PATCH_APPLIED" = "true" ]; then > + exit 0 > +else > + exit 1 > +fi > > Thanks, > S $_PATCH_APPLIED will be "true" or "false", which means that you could use it as is done elsewhere in the script: $_PATCH_APPLIED If that is the last line of the script, it (true or false) will supply the exit status of the script. No need for an if statement or explicit exit. Returning a non-zero exit status is generally a sign of some sort of failure. Not applying a patch due to already having the patch applied is not really a failure. Instead, you could run syspatch -c from a regular cron job and patch+reboot whenever that tells you there's new patches available. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: syspatch exit state
On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote: > On 06/12/2020 14:32, Otto Moerbeek wrote: > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > > > >> Hi, > >> I've been looking to have syspatch give me a quick indication of whether > >> a reboot is likely to be required. As a quick and dirty check, I've just > >> been treating "Were patches applied?" as the indicator. > >> > >> The following diff will cause syspatch to exit when applying patches > >> with status code 0 only if patches were actually applied. > >> > >> My biggest concern is that it does cause a change in behaviour, so > >> perhaps this either needs making into an option or a different approach > >> entirely? > >> > >> --- syspatch Sun Dec 6 14:11:12 2020 > >> +++ syspatch Sun Dec 6 14:10:23 2020 > >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then > >> _PATCH_APPLIED=true > >> done > >> fi > >> + > >> +if [ "$_PATCH_APPLIED" = "true" ]; then > >> + exit 0 > >> +else > >> + exit 1 > >> +fi > >> > >> Thanks, > >> S > >> > > I don't this is correct since it maks syspatch exit 1 on "no patches > > applied". > > > > -Otto > > . > That's precisely the idea- from previous discussion with a couple of > people there didn't seem to be an easy (programmatic) way to figure out > whether syspatch had done anything or not. exit code 1 normally used for error conditions. A system being up-to-date is not an error condition. -Otto > > Doing this would be a bit of a blunt way of handling things, and perhaps > it would be better gated behind a flag, but is there a better way to > make a scripted update work automatically (including rebooting as > necessary)? > > Thanks, > S
Re: syspatch exit state
On 06/12/2020 14:32, Otto Moerbeek wrote: > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > >> Hi, >> I've been looking to have syspatch give me a quick indication of whether >> a reboot is likely to be required. As a quick and dirty check, I've just >> been treating "Were patches applied?" as the indicator. >> >> The following diff will cause syspatch to exit when applying patches >> with status code 0 only if patches were actually applied. >> >> My biggest concern is that it does cause a change in behaviour, so >> perhaps this either needs making into an option or a different approach >> entirely? >> >> --- syspatch Sun Dec 6 14:11:12 2020 >> +++ syspatch Sun Dec 6 14:10:23 2020 >> @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then >> _PATCH_APPLIED=true >> done >> fi >> + >> +if [ "$_PATCH_APPLIED" = "true" ]; then >> + exit 0 >> +else >> + exit 1 >> +fi >> >> Thanks, >> S >> > I don't this is correct since it maks syspatch exit 1 on "no patches applied". > > -Otto > . That's precisely the idea- from previous discussion with a couple of people there didn't seem to be an easy (programmatic) way to figure out whether syspatch had done anything or not. Doing this would be a bit of a blunt way of handling things, and perhaps it would be better gated behind a flag, but is there a better way to make a scripted update work automatically (including rebooting as necessary)? Thanks, S
Re: Edit /etc/boot.conf
Both armv7 and powerpc64 support VTs, so let xenodem take the VT
reserved for X in /etc/ttys.
ok?
Index: app/xenodm/Makefile.bsd-wrapper
===
RCS file: /cvs/xenocara/app/xenodm/Makefile.bsd-wrapper,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile.bsd-wrapper
--- app/xenodm/Makefile.bsd-wrapper 1 Apr 2020 19:58:02 - 1.5
+++ app/xenodm/Makefile.bsd-wrapper 6 Dec 2020 14:59:40 -
@@ -4,8 +4,8 @@
XENODMCONFIGDIR=/etc/X11/xenodm
PIXMAPDIR=$(XENODMCONFIGDIR)/pixmaps
-.if ${MACHINE} == amd64 || ${MACHINE} == arm64 || ${MACHINE} == i386 \
-|| ${MACHINE} == macppc
+.if ${MACHINE} == amd64 || ${MACHINE} == arm64 || ${MACHINE} == armv7 \
+|| ${MACHINE} == i386 || ${MACHINE} == macppc || ${MACHINE} == powerpc64
DEFAULT_VT= --with-default-vt=vt05
.endif
Re: syspatch exit state
On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > Hi, > I've been looking to have syspatch give me a quick indication of whether > a reboot is likely to be required. As a quick and dirty check, I've just > been treating "Were patches applied?" as the indicator. > > The following diff will cause syspatch to exit when applying patches > with status code 0 only if patches were actually applied. > > My biggest concern is that it does cause a change in behaviour, so > perhaps this either needs making into an option or a different approach > entirely? > > --- syspatch Sun Dec 6 14:11:12 2020 > +++ syspatch Sun Dec 6 14:10:23 2020 > @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then > _PATCH_APPLIED=true > done > fi > + > +if [ "$_PATCH_APPLIED" = "true" ]; then > + exit 0 > +else > + exit 1 > +fi > > Thanks, > S > I don't this is correct since it maks syspatch exit 1 on "no patches applied". -Otto
syspatch exit state
Hi, I've been looking to have syspatch give me a quick indication of whether a reboot is likely to be required. As a quick and dirty check, I've just been treating "Were patches applied?" as the indicator. The following diff will cause syspatch to exit when applying patches with status code 0 only if patches were actually applied. My biggest concern is that it does cause a change in behaviour, so perhaps this either needs making into an option or a different approach entirely? --- syspatch Sun Dec 6 14:11:12 2020 +++ syspatch Sun Dec 6 14:10:23 2020 @@ -323,3 +323,9 @@ if ((OPTIND == 1)); then _PATCH_APPLIED=true done fi + +if [ "$_PATCH_APPLIED" = "true" ]; then + exit 0 +else + exit 1 +fi Thanks, S
