Better call poll - pkg_add / ftp can never timeout
Dear Reader
I already send email about my issue with pkg_add staying up for a long time.
I cannot change the sysctl because other connections need large inactivity.
I finally got a 'decent' diff working, still not very good imho,
tls_read shall provide something smart as poll reply the data amount ready
to be fetch but because of the crypto layer, it cannot be used.
Also the FD is inside the tls context.
Also kept it out of
I do hope this, or a better this, can somewhat end up in base.
I suspect some kind of relay or transparent proxy to be bugged,
or a routing to get wrong during the transfer. This creating a socket
that does not ever close but does not send data. Or worse.
Anyway I'd like my pkg_add to quit after a while, and -w is only
doing the connection part.
I guess the variable should be rename too in another diff maybe or the same
don't know.
maybe SIGALARM could be used to effectively timeout in the read
payload part.
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.167
diff -u -p -r1.167 fetch.c
--- fetch.c 10 Feb 2018 06:25:16 - 1.167
+++ fetch.c 13 Oct 2018 03:51:53 -
@@ -63,6 +63,9 @@
#else /* !NOSSL */
struct tls;
#endif /* !NOSSL */
+#ifndef SMALL
+#include
+#endif /* SMALL */
#include "ftp_var.h"
#include "cmds.h"
@@ -173,6 +176,33 @@ tooslow(int signo)
_exit(2);
}
+#ifndef SMALL
+int
+ftp_poll(struct pollfd pfd[]) {
+ int nready;
+ struct timespec timeout;
+ sigset_t blocked, omask;
+ sigemptyset();
+ sigaddset(, SIGALRM); //PROGRESS METER -_-
+ sigprocmask(SIG_BLOCK, , );
+
+ timeout.tv_sec = connect_timeout;
+ timeout.tv_nsec = 0;
+
+ nready = ppoll(pfd, 1, , );
+ if (nready == -1) {
+ errx(1, "poll");
+ }
+ if (nready == 0) {
+ warn("Timeout\n");
+ return 1;
+ }
+ if ((pfd[0].revents & (POLLERR|POLLNVAL)))
+ errx(1, "bad fd");
+ return 0;
+}
+#endif
+
/*
* Retrieve URL, via the proxy in $proxyvar if necessary.
* Modifies the string argument given.
@@ -210,6 +240,10 @@ url_get(const char *origline, const char
int status;
int save_errno;
const size_t buflen = 128 * 1024;
+#ifndef SMALL
+ struct pollfd pfd[1];
+ pfd[0].fd = -1;
+#endif
direction = "received";
@@ -609,6 +643,12 @@ noslash:
goto cleanup_url_get;
}
+#ifndef SMALL
+ if (connect_timeout) {
+ pfd[0].fd = fd;
+ pfd[0].events = POLLIN;
+ }
+#endif /* !SMALL */
#ifndef NOSSL
if (ishttpsurl) {
if (proxyenv && sslpath) {
@@ -659,6 +699,11 @@ noslash:
signal(SIGALRM, SIG_DFL);
alarmtimer(0);
}
+#ifndef SMALL
+ if (connect_timeout) {
+ fcntl(pfd[0].fd , F_SETFL, O_NONBLOCK);
+ }
+#endif /* !SMALL */
/*
* Construct and send the request. Proxy requests don't want
leading /.
@@ -763,6 +808,11 @@ noslash:
warn("Writing HTTP request");
goto cleanup_url_get;
}
+#ifndef SMALL
+ if (pfd[0].fd != -1)
+ if (ftp_poll(pfd))
+ goto cleanup_url_get;
+#endif
if ((buf = ftp_readline(fin, tls, )) == NULL) {
warn("Receiving HTTP reply");
goto cleanup_url_get;
@@ -833,6 +883,11 @@ noslash:
filesize = -1;
for (;;) {
+#ifndef SMALL
+ if (pfd[0].fd != -1)
+ if (ftp_poll(pfd))
+ goto cleanup_url_get;
+#endif
if ((buf = ftp_readline(fin, tls, )) == NULL) {
warn("Receiving HTTP reply");
goto cleanup_url_get;
@@ -978,6 +1033,11 @@ noslash:
len = 1;
oldinti = signal(SIGINFO, psummary);
while (len > 0) {
+#ifndef SMALL
+ if (pfd[0].fd != -1)
+ if (ftp_poll(pfd))
+ goto cleanup_url_get;
+#endif
len = ftp_read(fin, tls, buf, buflen);
bytes += len;
for (cp = buf, wlen = len; wlen > 0; wlen -= i, cp += i) {
--
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do
Re: doas(1): Exit Status
Dave Cameron wrote: > I believe this updated patch enumerates all possible cases, though I'm > not sure the style is ideal: > > -snip- > EXIT STATUS > doas may fail for one of the following reasons: > > • The config file /etc/doas.conf could not be parsed. > • The user attempted to run a command which is not permitted. > • The password was incorrect. > • The password was required, but -n was given. > • The specified command was not found or is not executable. > > Otherwise, the exit status of doas shall be that of command, the > shell if the -s option was given, or 0 if the -C or -L options > were given. You think you've identified a problem and now you insist there MUST be a change made How did you get confused in the first place?
Re: doas(1): Exit Status
On Fri, 12 Oct 2018 17:55:14 +0100 Jason McIntyre wrote: > On Fri, Oct 12, 2018 at 10:13:13PM +1300, Dave Cameron wrote: > > doas(1) currently states: > > -clip- > > EXIT STATUS > > The doas utility exits 0 on success, and >0 if an error > > occurs. It may fail for one of the following reasons: > > > > o The config file /etc/doas.conf could not be parsed. > > o The user attempted to run a command which is not permitted. > > o The password was incorrect. > > o The specified command was not found or is not executable. > > -clip- > > This is incorrect, doas returns the exit status of command as in: > > -clip- > > $ doas false && echo "was true" > > -no output- > > > > $ doas true && echo "was true" > > was true > > -clip- > > > > Manpage amended, to be like nice(1). > > > > Patch below: > > > > hi. > > this is not quite the full story, i think: for options like -C the man > page is correct. so i think your diff should somehow spell out that > generally doas will exit with the status of command, but can itself > exit in such and such a manner if invoked with the options .. > > jmc > I believe this updated patch enumerates all possible cases, though I'm not sure the style is ideal: -snip- EXIT STATUS doas may fail for one of the following reasons: • The config file /etc/doas.conf could not be parsed. • The user attempted to run a command which is not permitted. • The password was incorrect. • The password was required, but -n was given. • The specified command was not found or is not executable. Otherwise, the exit status of doas shall be that of command, the shell if the -s option was given, or 0 if the -C or -L options were given. -snip- I also added the error condition when a password is required non-interactively. Someone else may be able to put it better. Dave Cameron Index: usr.bin/doas/doas.1 === RCS file: /cvs/src/usr.bin/doas/doas.1,v retrieving revision 1.19 diff -u -r1.19 doas.1 --- usr.bin/doas/doas.1 4 Sep 2016 15:20:37 - 1.19 +++ usr.bin/doas/doas.1 12 Oct 2018 22:03:53 - @@ -87,8 +87,8 @@ The default is root. .El .Sh EXIT STATUS -.Ex -std doas -It may fail for one of the following reasons: +.Nm +may fail for one of the following reasons: .Pp .Bl -bullet -compact .It @@ -100,8 +100,17 @@ .It The password was incorrect. .It +The password was required, but -n was given. +.It The specified command was not found or is not executable. .El +.Pp +Otherwise, the exit status of +.Nm +shall be that of +.Ar command , +the shell if the -s option was given, +or 0 if the -C or -L options were given. .Sh SEE ALSO .Xr su 1 , .Xr doas.conf 5 --
Re: doas(1): Exit Status
Well, the proposal is incorrect. doas *executes* the command, which then does whatever it does. It isn't doas doing anything anymore, so doas doesn't need to document anything. It has *executed* the other command and cannot speak on the matter of what that command will do. For instance, the -C or -L options. exits 0. See it? It can only speak on the matter of when doas it's exists succesfully or unsuccesfully, it cannot speak to what happens when it follows the path via execve, so the topic is avoided entirely, on purpose. I think the manual page explains the situation correctly and accurately, and hasn't missed a step. > On Fri, Oct 12, 2018 at 10:13:13PM +1300, Dave Cameron wrote: > > doas(1) currently states: > > -clip- > > EXIT STATUS > > The doas utility exits 0 on success, and >0 if an error occurs. It may > > fail for one of the following reasons: > > > > o The config file /etc/doas.conf could not be parsed. > > o The user attempted to run a command which is not permitted. > > o The password was incorrect. > > o The specified command was not found or is not executable. > > -clip- > > This is incorrect, doas returns the exit status of command as in: > > -clip- > > $ doas false && echo "was true" > > -no output- > > > > $ doas true && echo "was true" > > was true > > -clip- > > > > Manpage amended, to be like nice(1). > > > > Patch below: > > > > hi. > > this is not quite the full story, i think: for options like -C the man > page is correct. so i think your diff should somehow spell out that > generally doas will exit with the status of command, but can itself > exit in such and such a manner if invoked with the options .. > > jmc > > > Index: usr.bin/doas/doas.1 > > === > > RCS file: /cvs/src/usr.bin/doas/doas.1,v > > retrieving revision 1.19 > > diff -u -r1.19 doas.1 > > --- usr.bin/doas/doas.1 4 Sep 2016 15:20:37 - 1.19 > > +++ usr.bin/doas/doas.1 12 Oct 2018 07:36:29 - > > @@ -87,8 +87,8 @@ > > The default is root. > > .El > > .Sh EXIT STATUS > > -.Ex -std doas > > -It may fail for one of the following reasons: > > +.Nm > > +may fail for one of the following reasons: > > .Pp > > .Bl -bullet -compact > > .It > > @@ -102,6 +102,11 @@ > > .It > > The specified command was not found or is not executable. > > .El > > +.Pp > > +Otherwise, the exit status of > > +.Nm > > +shall be that of > > +.Ar command . > > .Sh SEE ALSO > > .Xr su 1 , > > .Xr doas.conf 5 > > > > > > > > -- > > >
Re: doas(1): Exit Status
Dave Cameron wrote: > doas(1) currently states: > -clip- > EXIT STATUS > The doas utility exits 0 on success, and >0 if an error occurs. It may > fail for one of the following reasons: > > o The config file /etc/doas.conf could not be parsed. > o The user attempted to run a command which is not permitted. > o The password was incorrect. > o The specified command was not found or is not executable. > -clip- > This is incorrect, doas returns the exit status of command as in: no, this is inaccurate. after a successful exec, there is no doas process. it neither returns nor exits, it doesn't exist.
Re: bgpd fix mrt table dumps
ok
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.10.12 13:08:15 +0200:
> Some time ago I busted mrt dumps. This fixes them again.
>
> Run the mrt rib_dump_r runner in the poll loop before checking for queued
> imsgs. This makes sure that data is produced and pushed out quickly. Only
> run the runner when the mrt state is not MRT_STATE_REMOVE (since that
> would restart the dump) and there are no queued messages.
>
> --
> :wq Claudio
>
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.433
> diff -u -p -r1.433 rde.c
> --- rde.c 3 Oct 2018 11:36:39 - 1.433
> +++ rde.c 12 Oct 2018 07:45:15 -
> @@ -282,6 +281,11 @@ rde_main(int debug, int verbose)
> i = PFD_PIPE_COUNT;
> for (mctx = LIST_FIRST(_mrts); mctx != 0; mctx = xmctx) {
> xmctx = LIST_NEXT(mctx, entry);
> +
> + if (mctx->mrt.state != MRT_STATE_REMOVE &&
> + mctx->mrt.wbuf.queued == 0)
> + rib_dump_r(>ribctx);
> +
> if (mctx->mrt.wbuf.queued) {
> pfd[i].fd = mctx->mrt.wbuf.fd;
> pfd[i].events = POLLOUT;
>
Re: doas(1): Exit Status
On Fri, Oct 12, 2018 at 10:13:13PM +1300, Dave Cameron wrote: > doas(1) currently states: > -clip- > EXIT STATUS > The doas utility exits 0 on success, and >0 if an error occurs. It may > fail for one of the following reasons: > > o The config file /etc/doas.conf could not be parsed. > o The user attempted to run a command which is not permitted. > o The password was incorrect. > o The specified command was not found or is not executable. > -clip- > This is incorrect, doas returns the exit status of command as in: > -clip- > $ doas false && echo "was true" > -no output- > > $ doas true && echo "was true" > was true > -clip- > > Manpage amended, to be like nice(1). > > Patch below: > hi. this is not quite the full story, i think: for options like -C the man page is correct. so i think your diff should somehow spell out that generally doas will exit with the status of command, but can itself exit in such and such a manner if invoked with the options .. jmc > Index: usr.bin/doas/doas.1 > === > RCS file: /cvs/src/usr.bin/doas/doas.1,v > retrieving revision 1.19 > diff -u -r1.19 doas.1 > --- usr.bin/doas/doas.1 4 Sep 2016 15:20:37 - 1.19 > +++ usr.bin/doas/doas.1 12 Oct 2018 07:36:29 - > @@ -87,8 +87,8 @@ > The default is root. > .El > .Sh EXIT STATUS > -.Ex -std doas > -It may fail for one of the following reasons: > +.Nm > +may fail for one of the following reasons: > .Pp > .Bl -bullet -compact > .It > @@ -102,6 +102,11 @@ > .It > The specified command was not found or is not executable. > .El > +.Pp > +Otherwise, the exit status of > +.Nm > +shall be that of > +.Ar command . > .Sh SEE ALSO > .Xr su 1 , > .Xr doas.conf 5 > > > > -- >
Re: 802.1q with 0 tag
Hi!
I'll look into the problems(vlan interface with 0 tag and issues
priority differeces) you mentioned. I tested your idea of having vlan
interface without tag and IP on top of physical interface, but IP
traffic doesn't get picked up by parent.
Extreme(Brocade) SLX does it. Depending on the ingress port
configuration packets on egress can be with or without dot1q header.
Seems, it doesn't cause issues with other operating systems.
Rivo
On Fri, 2018-10-12 at 13:38 +1000, David Gwynne wrote:
> Hi Rivo,
>
> vlan(4) can be configured to receive (and send) packets with 0 as the
> tag on the wire, which this diff will break.
>
> I'm pretty confident you can leave an IP configured on the physical
> network interface, and create and configure a vlan interface on it
> without setting a VLAN id. The untagged frames should be received as
> normal on the parent, and the tagged frames with the priority will
> come in on the vlan interface but still get accepted for IP on the
> parent.
>
> Note that the default priority of packets in the OpenBSD kernel is 3,
> which might be higher than what you expect an untagged packets
> priority to be. The default 802.1q priority is 1 iirc.
>
> I'm curious as to where you see both tagged and untagged frames at
> the same time.
>
> dlg
>
> > On 11 Oct 2018, at 7:20 pm, Rivo Nurges
> > wrote:
> >
> > Hi!
> >
> > In theory 802.1q header with vlan tag 0 can be used to just signal
> > priority. Now I'm seeing this in the wild. On a untagged port some
> > packets are coming with dotq header and some without. Currently we
> > drop
> > all the packets with dotq header and vlan tag 0.
> >
> > Following patch fixes this by recording the priority and removing
> > the
> > header, so existing code to handle the packet. At least NetBSD does
> > something similar.
> >
> > Rivo
> >
> > diff --git sys/net/if_ethersubr.c sys/net/if_ethersubr.c
> > index 76f6c3147e0..68f5b03b4f4 100644
> > --- sys/net/if_ethersubr.c
> > +++ sys/net/if_ethersubr.c
> > @@ -362,6 +362,22 @@ ether_input(struct ifnet *ifp, struct mbuf *m,
> > void *cookie)
> >
> > etype = ntohs(eh->ether_type);
> >
> > + /*
> > +* 802.1Q header with a tag of 0 can be used to store priority.
> > +*/
> > + if (etype == ETHERTYPE_VLAN) {
> > + struct ether_vlan_header *evl = (void *)eh;
> > + if (EVL_VLANOFTAG(evl->evl_tag) == EVL_VLID_NULL) {
> > + etype = ntohs(evl->evl_proto);
> > + m->m_pkthdr.pf.prio = EVL_PRIOFTAG(evl-
> > >evl_tag);
> > + /* IEEE 802.1p has prio 0 and 1 swapped */
> > + if (m->m_pkthdr.pf.prio <= 1)
> > + m->m_pkthdr.pf.prio = !m-
> > >m_pkthdr.pf.prio;
> > + memmove((char *)eh + EVL_ENCAPLEN, eh,
> > sizeof(*eh));
> > + m_adj(m, EVL_ENCAPLEN);
> > + }
> > + }
> > +
> > switch (etype) {
> > case ETHERTYPE_IP:
> > input = ipv4_input;
> >
bgpd fix mrt table dumps
Some time ago I busted mrt dumps. This fixes them again.
Run the mrt rib_dump_r runner in the poll loop before checking for queued
imsgs. This makes sure that data is produced and pushed out quickly. Only
run the runner when the mrt state is not MRT_STATE_REMOVE (since that
would restart the dump) and there are no queued messages.
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.433
diff -u -p -r1.433 rde.c
--- rde.c 3 Oct 2018 11:36:39 - 1.433
+++ rde.c 12 Oct 2018 07:45:15 -
@@ -282,6 +281,11 @@ rde_main(int debug, int verbose)
i = PFD_PIPE_COUNT;
for (mctx = LIST_FIRST(_mrts); mctx != 0; mctx = xmctx) {
xmctx = LIST_NEXT(mctx, entry);
+
+ if (mctx->mrt.state != MRT_STATE_REMOVE &&
+ mctx->mrt.wbuf.queued == 0)
+ rib_dump_r(>ribctx);
+
if (mctx->mrt.wbuf.queued) {
pfd[i].fd = mctx->mrt.wbuf.fd;
pfd[i].events = POLLOUT;
doas(1): Exit Status
doas(1) currently states: -clip- EXIT STATUS The doas utility exits 0 on success, and >0 if an error occurs. It may fail for one of the following reasons: o The config file /etc/doas.conf could not be parsed. o The user attempted to run a command which is not permitted. o The password was incorrect. o The specified command was not found or is not executable. -clip- This is incorrect, doas returns the exit status of command as in: -clip- $ doas false && echo "was true" -no output- $ doas true && echo "was true" was true -clip- Manpage amended, to be like nice(1). Patch below: Index: usr.bin/doas/doas.1 === RCS file: /cvs/src/usr.bin/doas/doas.1,v retrieving revision 1.19 diff -u -r1.19 doas.1 --- usr.bin/doas/doas.1 4 Sep 2016 15:20:37 - 1.19 +++ usr.bin/doas/doas.1 12 Oct 2018 07:36:29 - @@ -87,8 +87,8 @@ The default is root. .El .Sh EXIT STATUS -.Ex -std doas -It may fail for one of the following reasons: +.Nm +may fail for one of the following reasons: .Pp .Bl -bullet -compact .It @@ -102,6 +102,11 @@ .It The specified command was not found or is not executable. .El +.Pp +Otherwise, the exit status of +.Nm +shall be that of +.Ar command . .Sh SEE ALSO .Xr su 1 , .Xr doas.conf 5 --
