Fix dwge(4) on Rockchip SoCs

2018-05-05 Thread Mark Kettenis
Lost a few hairs over this one.  Turns out you have to write these
registers in the right order to program the address filter correctly.

With this diff the Gigabit Ethernet interface on the Rock64 works.

ok?


Index: dev/ic/dwc_gmac.c
===
RCS file: /cvs/src/sys/dev/ic/dwc_gmac.c,v
retrieving revision 1.9
diff -u -p -r1.9 dwc_gmac.c
--- dev/ic/dwc_gmac.c   7 Apr 2018 22:43:12 -   1.9
+++ dev/ic/dwc_gmac.c   5 May 2018 21:43:54 -
@@ -304,13 +304,13 @@ dwc_gmac_reset(struct dwc_gmac_softc *sc
 void
 dwc_gmac_write_hwaddr(struct dwc_gmac_softc *sc, uint8_t *enaddr)
 {
-   uint32_t lo, hi;
+   uint32_t hi, lo;
 
+   hi = enaddr[4] | (enaddr[5] << 8);
lo = enaddr[0] | (enaddr[1] << 8) | (enaddr[2] << 16)
| (enaddr[3] << 24);
-   hi = enaddr[4] | (enaddr[5] << 8);
-   bus_space_write_4(sc->sc_bst, sc->sc_bsh, AWIN_GMAC_MAC_ADDR0LO, lo);
bus_space_write_4(sc->sc_bst, sc->sc_bsh, AWIN_GMAC_MAC_ADDR0HI, hi);
+   bus_space_write_4(sc->sc_bst, sc->sc_bsh, AWIN_GMAC_MAC_ADDR0LO, lo);
 }
 
 int



Re: [PATCH] mv -P

2018-05-05 Thread Theo de Raadt
Wow.

A better answer would have been "Really sorry Theo and everyone, but I
always come off as a dick..."

your opinion and screed don't change anything.

attila  wrote:

> Theo de Raadt  wrote:
> > >"Theo de Raadt"  wrote:
> > >> attila  wrote:
> > >> > Hi tech@,
> > >> > 
> > >> > I frequently want to move a file from one place to another and shred
> > >> > the original via the rm(1) -P option.  On several occasions I have
> > >> > forgotten about wanting to shred the original file when using mv(1)
> > >> > instead (out of habit) and ended up losing the ability to do so easily
> > >> > because mv(1) unlinks the original in the cross-filesystem case.
> > >> > 
> > >> > This patch adds a -P option to mv(1) that does the same thing rm -P
> > >> > does in all the cases where it would normally just unlink the source
> > >> > file.
> > >> > 
> > >> > Maybe someone else has shared my "d'oh!" moment after typing mv?
> > >> > Maybe this isn't worth it and should just be dealt with using a shell
> > >> > alias, but to me this feels cleaner.
> > >> > 
> > >> > Feedback most welcome as always.
> > >> 
> > >> over my dead body.
> > >
> > >A better answer would've been:
> > >
> > >POSIX gives us no way to "shred" a file and our non-standard
> > >extension to rm already irks us; we don't want to add yet another
> > >to mv.
> > >
> > >That would've made sense, and also would've been polite.  More
> > >importantly it would've been better for someone to have found that in
> > >the archives than what you said, which will surely leave people who
> > >find it wondering why you behave this way.
> > 
> > att...@stalphonsos.com whoever the hell you are, you don't get to tell
> > me when i am being impolite.  you are some random hiding behind an
> > email address, while everyone knows exactly who I am and where I come
> > from, with >20 years of opinion turned into validity under my belt (and
> > some wrong, but that goes with the territory)
> 
> I'm many things but anonymous isn't one of them:
> 
> attila@xix:~ 121:$ grep attila /usr/src/sys/dev/usb/urng.c
>  * Copyright (C) 2015 Sean Levy 
> 
> > On the other hand, random mostly-anon people who aren't brave enough
> > to put their full credentials into their email address tend to have
> > close to zero influence.  Shocking isn't it?  Know how to fix that?
> 
> Nothing to fix.  Those of us with Jewish last names who aren't
> zionists frequently take the approach of not blasting our last names
> across the net in every communication because we've learned that
> zionists are aggressive and it doesn't make sense to make it easy for
> them to target/abuse you.  None the less, I've never made a secret of
> who I am or that attila = Sean Levy, I just prefer not to use the
> latter in casual communication.  Anything of mine in your trees has
> had my real name attached to it since it was imported.
> 
> > So your opinion (AND JUDGEMENT ME OF) counts for far less, and you
> > should (a) consider your idiotic position, (b) recognize you aren't
> > someone who can land / not land the proposed change, and (c) realize
> > randoms on the internet/unix don't succeed change the internet/unix -
> > much to their anonymous nature, oh the dismay, oh my god.
> 
> The substance of your screed comes down to: "Don't you know who I am?"
> 
> > Over my dead body I said.
> > 
> > I mean it.  I will not permit the stupidity.  Nor will I accept the
> > stupidity of trying to call me out for calling out the stupid.
> 
> So in your view you were "calling out the stupid" by answering a patch
> with "over my dead body," and my objecting to your rudeness is also
> stupidity.  This is not an interpretation that too many people I've
> met in real life would share, but I guess that isn't the case here.
> 
> Good to know.
> 
> You also sent me a private email which was ruder and more direct.  In
> it you ask me what gives me the right... to do what, I'm not sure, but
> I guess you mean: what gives me the right to call out your rudeness?
> 
> Every person born has that right, Theo.  Everyone has the right to
> reject rudeness directed at them.
> 
> Pax, -A
> -- 
> https://haqistan.net/~attila | attila@{stalphonsos.com,haqistan.net}
> pgp: 0x62A729CF | C2CE 2487 03AC 4C2F 101D  09C1 4068 D5D5 62A7 29CF



Re: [PATCH] mv -P

2018-05-05 Thread attila
Theo de Raadt  wrote:
> >"Theo de Raadt"  wrote:
> >> attila  wrote:
> >> > Hi tech@,
> >> > 
> >> > I frequently want to move a file from one place to another and shred
> >> > the original via the rm(1) -P option.  On several occasions I have
> >> > forgotten about wanting to shred the original file when using mv(1)
> >> > instead (out of habit) and ended up losing the ability to do so easily
> >> > because mv(1) unlinks the original in the cross-filesystem case.
> >> > 
> >> > This patch adds a -P option to mv(1) that does the same thing rm -P
> >> > does in all the cases where it would normally just unlink the source
> >> > file.
> >> > 
> >> > Maybe someone else has shared my "d'oh!" moment after typing mv?
> >> > Maybe this isn't worth it and should just be dealt with using a shell
> >> > alias, but to me this feels cleaner.
> >> > 
> >> > Feedback most welcome as always.
> >> 
> >> over my dead body.
> >
> >A better answer would've been:
> >
> >POSIX gives us no way to "shred" a file and our non-standard
> >extension to rm already irks us; we don't want to add yet another
> >to mv.
> >
> >That would've made sense, and also would've been polite.  More
> >importantly it would've been better for someone to have found that in
> >the archives than what you said, which will surely leave people who
> >find it wondering why you behave this way.
> 
> att...@stalphonsos.com whoever the hell you are, you don't get to tell
> me when i am being impolite.  you are some random hiding behind an
> email address, while everyone knows exactly who I am and where I come
> from, with >20 years of opinion turned into validity under my belt (and
> some wrong, but that goes with the territory)

I'm many things but anonymous isn't one of them:

attila@xix:~ 121:$ grep attila /usr/src/sys/dev/usb/urng.c
 * Copyright (C) 2015 Sean Levy 

> On the other hand, random mostly-anon people who aren't brave enough
> to put their full credentials into their email address tend to have
> close to zero influence.  Shocking isn't it?  Know how to fix that?

Nothing to fix.  Those of us with Jewish last names who aren't
zionists frequently take the approach of not blasting our last names
across the net in every communication because we've learned that
zionists are aggressive and it doesn't make sense to make it easy for
them to target/abuse you.  None the less, I've never made a secret of
who I am or that attila = Sean Levy, I just prefer not to use the
latter in casual communication.  Anything of mine in your trees has
had my real name attached to it since it was imported.

> So your opinion (AND JUDGEMENT ME OF) counts for far less, and you
> should (a) consider your idiotic position, (b) recognize you aren't
> someone who can land / not land the proposed change, and (c) realize
> randoms on the internet/unix don't succeed change the internet/unix -
> much to their anonymous nature, oh the dismay, oh my god.

The substance of your screed comes down to: "Don't you know who I am?"

> Over my dead body I said.
> 
> I mean it.  I will not permit the stupidity.  Nor will I accept the
> stupidity of trying to call me out for calling out the stupid.

So in your view you were "calling out the stupid" by answering a patch
with "over my dead body," and my objecting to your rudeness is also
stupidity.  This is not an interpretation that too many people I've
met in real life would share, but I guess that isn't the case here.

Good to know.

You also sent me a private email which was ruder and more direct.  In
it you ask me what gives me the right... to do what, I'm not sure, but
I guess you mean: what gives me the right to call out your rudeness?

Every person born has that right, Theo.  Everyone has the right to
reject rudeness directed at them.

Pax, -A
-- 
https://haqistan.net/~attila | attila@{stalphonsos.com,haqistan.net}
pgp: 0x62A729CF | C2CE 2487 03AC 4C2F 101D  09C1 4068 D5D5 62A7 29CF



Re: unbuffered fread does not set error/EOF flags

2018-05-05 Thread Vadim Zhukov
2018-05-05 22:12 GMT+03:00 Vadim Zhukov :
> Hi all!
>
> Recently I was working on a program that uses stdio functions heavily.
> While hunting for a bug, I've temporarily disabled buffering (via
> setvbuf(f, NULL, _IONBF, 0)) and realized that program behavior was
> changed heavily. The cause was that fread() stopped setting error flag
> after hitting EAGAIN. It looks like its code is missing setting
> EOF/error flags totally in case of unbuffered read, and first patch
> (below) fixes this.
>
> I'm not sure if "r" variable value should be propagated to fp->_r, or
> not. I've assumed that since things work without it now, this doesn't
> need a change. And headache stops me from further investigation for now,
> sorry.
>
> I understand that use stdio functions without buffering is somewhat
> exotic, and that's for sure is the reason noone found this bug yet. But
> this is still a bad thing, IMHO.
>
> While looking through the libc code I've also found that __sread() drops
> __SOFF flag unconditionally for all read errors. IMHO, the EAGAIN case
> shouldn't be affected here, since, obviously current offset doesn't
> change and is still well-known.
>
> So... any comments, or ever okays? :)

Doing "cvs diff" before mailing the patch works better than doing after.
Sorry.

--
WBR,
  Vadim Zhukov


Index: stdio/fread.c
===
RCS file: /cvs/src/lib/libc/stdio/fread.c,v
retrieving revision 1.15
diff -u -p -r1.15 fread.c
--- stdio/fread.c   21 Sep 2016 04:38:56 -  1.15
+++ stdio/fread.c   5 May 2018 19:14:27 -
@@ -79,6 +79,10 @@ fread(void *buf, size_t size, size_t cou
p += r;
resid -= r;
}
+if (r == 0)
+fp->_flags |= __SEOF;
+else if (r < 0)
+fp->_flags |= __SERR;
FUNLOCKFILE(fp);
return ((total - resid) / size);
}
Index: stdio/stdio.c
===
RCS file: /cvs/src/lib/libc/stdio/stdio.c,v
retrieving revision 1.10
diff -u -p -r1.10 stdio.c
--- stdio/stdio.c   21 Sep 2016 04:38:56 -  1.10
+++ stdio/stdio.c   5 May 2018 19:14:27 -
@@ -32,6 +32,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "local.h"
 
@@ -49,7 +50,7 @@ __sread(void *cookie, char *buf, int n)
/* if the read succeeded, update the current offset */
if (ret >= 0)
fp->_offset += ret;
-   else
+   else if (errno != EAGAIN)
fp->_flags &= ~__SOFF;  /* paranoia */
return (ret);
 }



unbuffered fread does not set error/EOF flags

2018-05-05 Thread Vadim Zhukov
Hi all!

Recently I was working on a program that uses stdio functions heavily.
While hunting for a bug, I've temporarily disabled buffering (via
setvbuf(f, NULL, _IONBF, 0)) and realized that program behavior was
changed heavily. The cause was that fread() stopped setting error flag
after hitting EAGAIN. It looks like its code is missing setting
EOF/error flags totally in case of unbuffered read, and first patch
(below) fixes this.

I'm not sure if "r" variable value should be propagated to fp->_r, or
not. I've assumed that since things work without it now, this doesn't
need a change. And headache stops me from further investigation for now,
sorry.

I understand that use stdio functions without buffering is somewhat
exotic, and that's for sure is the reason noone found this bug yet. But
this is still a bad thing, IMHO.

While looking through the libc code I've also found that __sread() drops
__SOFF flag unconditionally for all read errors. IMHO, the EAGAIN case
shouldn't be affected here, since, obviously current offset doesn't
change and is still well-known.

So... any comments, or ever okays? :)

--
WBR,
  Vadim Zhukov


Index: stdio/fread.c
===
RCS file: /cvs/src/lib/libc/stdio/fread.c,v
retrieving revision 1.15
diff -u -p -r1.15 fread.c
--- stdio/fread.c   21 Sep 2016 04:38:56 -  1.15
+++ stdio/fread.c   5 May 2018 19:02:04 -
@@ -79,6 +79,10 @@ fread(void *buf, size_t size, size_t cou
p += r;
resid -= r;
}
+if (r == 0)
+fp->_flags |= __SEOF;
+else if (r < 0)
+fp->_flags |= __SERR;
FUNLOCKFILE(fp);
return ((total - resid) / size);
}
Index: stdio/stdio.c
===
RCS file: /cvs/src/lib/libc/stdio/stdio.c,v
retrieving revision 1.10
diff -u -p -r1.10 stdio.c
--- stdio/stdio.c   21 Sep 2016 04:38:56 -  1.10
+++ stdio/stdio.c   5 May 2018 19:02:04 -
@@ -49,7 +49,7 @@ __sread(void *cookie, char *buf, int n)
/* if the read succeeded, update the current offset */
if (ret >= 0)
fp->_offset += ret;
-   else
+   else if (errno != EAGAIN)
fp->_flags &= ~__SOFF;  /* paranoia */
return (ret);
 }



Re: ifconfig(8): pltime and vltime are measured in seconds

2018-05-05 Thread Jason McIntyre
On Sat, May 05, 2018 at 03:26:09PM +0200, Paul de Weerd wrote:
> Hi Jason,
> 
> Thanks for your reply.  Yes, that's better.  Here you go:
> 

fixed, thanks.
jmc

> 
> Index: ifconfig.8
> ===
> RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
> retrieving revision 1.305
> diff -u -p -r1.305 ifconfig.8
> --- ifconfig.816 Mar 2018 19:45:13 -  1.305
> +++ ifconfig.85 May 2018 13:25:12 -
> @@ -1197,7 +1197,7 @@ Fill the interface index
>  .Pq the lowermost 64th bit of an IPv6 address
>  automatically.
>  .It Cm pltime Ar n
> -Set preferred lifetime for the address.
> +Set preferred lifetime for the address, in seconds.
>  .It Cm soii
>  Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
>  as per RFC 7217, for link local and SLAAC addresses on the interface.
> @@ -1219,7 +1219,7 @@ Set the IPv6 tentative address bit.
>  .It Cm -tentative
>  Clear the IPv6 tentative address bit.
>  .It Cm vltime Ar n
> -Set valid lifetime for the address.
> +Set valid lifetime for the address, in seconds.
>  .El
>  .Sh INTERFACE GROUPS
>  .Nm ifconfig
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 



Re: ifconfig(8): pltime and vltime are measured in seconds

2018-05-05 Thread Klemens Nanni
On Sat, May 05, 2018 at 03:26:09PM +0200, Paul de Weerd wrote:
> Thanks for your reply.  Yes, that's better.  Here you go:
I agree, OK kn.



Re: ifconfig(8): pltime and vltime are measured in seconds

2018-05-05 Thread Jason McIntyre
On Sat, May 05, 2018 at 03:26:09PM +0200, Paul de Weerd wrote:
> Hi Jason,
> 
> Thanks for your reply.  Yes, that's better.  Here you go:
> 

ok me.
jmc

> 
> Index: ifconfig.8
> ===
> RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
> retrieving revision 1.305
> diff -u -p -r1.305 ifconfig.8
> --- ifconfig.816 Mar 2018 19:45:13 -  1.305
> +++ ifconfig.85 May 2018 13:25:12 -
> @@ -1197,7 +1197,7 @@ Fill the interface index
>  .Pq the lowermost 64th bit of an IPv6 address
>  automatically.
>  .It Cm pltime Ar n
> -Set preferred lifetime for the address.
> +Set preferred lifetime for the address, in seconds.
>  .It Cm soii
>  Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
>  as per RFC 7217, for link local and SLAAC addresses on the interface.
> @@ -1219,7 +1219,7 @@ Set the IPv6 tentative address bit.
>  .It Cm -tentative
>  Clear the IPv6 tentative address bit.
>  .It Cm vltime Ar n
> -Set valid lifetime for the address.
> +Set valid lifetime for the address, in seconds.
>  .El
>  .Sh INTERFACE GROUPS
>  .Nm ifconfig
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 



Re: ifconfig(8): pltime and vltime are measured in seconds

2018-05-05 Thread Paul de Weerd
Hi Jason,

Thanks for your reply.  Yes, that's better.  Here you go:


Index: ifconfig.8
===
RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.305
diff -u -p -r1.305 ifconfig.8
--- ifconfig.8  16 Mar 2018 19:45:13 -  1.305
+++ ifconfig.8  5 May 2018 13:25:12 -
@@ -1197,7 +1197,7 @@ Fill the interface index
 .Pq the lowermost 64th bit of an IPv6 address
 automatically.
 .It Cm pltime Ar n
-Set preferred lifetime for the address.
+Set preferred lifetime for the address, in seconds.
 .It Cm soii
 Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
 as per RFC 7217, for link local and SLAAC addresses on the interface.
@@ -1219,7 +1219,7 @@ Set the IPv6 tentative address bit.
 .It Cm -tentative
 Clear the IPv6 tentative address bit.
 .It Cm vltime Ar n
-Set valid lifetime for the address.
+Set valid lifetime for the address, in seconds.
 .El
 .Sh INTERFACE GROUPS
 .Nm ifconfig

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 



Re: Don't send icmp redirect to the same interface a forwarded packet came in on

2018-05-05 Thread Christopher Zimmermann
On 2018-05-05 Martin Pieuchot  wrote:
> On 03/05/18(Thu) 17:19, Christopher Zimmermann wrote:
> > On 2018-05-03 Martin Pieuchot  wrote:  
> > > On 02/05/18(Wed) 14:45, Christopher Zimmermann wrote:  
> > > > On 2018-05-02 Martin Pieuchot  wrote:
> > > > > On 02/05/18(Wed) 11:47, Christopher Zimmermann wrote:
> > > > > > I just want to bring this up again. Can some network guru give me 
> > > > > > an ok
> > > > > > or some feedback please?  
> > > > > 
> > > > > Can you explain with words why we shouldn't send a redirect?  The
> > > > > comment above your diff states clearly:
> > > > > 
> > > > >   "If forwarding packet using same interface that it came in on,
> > > > >   perhaps should send a redirect to sender to shortcut a hop."
> > > > > 
> > > > > So you're suggesting no to do that, why?
> > > > 
> > > > That's not exactly what I'm suggesting.
> > > > 
> > > > In this setting:
> > > > 
> > > > A 192.168.4.7 <--> 192.168.4.1 Gateway 192.168.1.1 <--> 192.168.1.2 B
> > > > 
> > > > I observed this senseless redirect:
> > > > 
> > > > 192.168.4.1 > 192.168.4.7: icmp: redirect 192.168.1.2 to host 
> > > > 192.168.4.1
> > > > in plain language it means:
> > > > "Hi 192.168.4.7, I'm 192.168.4.1. You sent me a packet for 192.168.1.2.
> > > > I'm not the best route, next time send it to 192.168.4.1."
> > > > So the gateway is instructing host 192.168.4.7 to use gateway
> > > > 192.168.4.1 instead of 192.168.4.1. (this is not a typo!)
> > > 
> > > How does your routing table looks like?  
> > 
> > % doas ifconfig vlan2   
> >   
> > vlan2: flags=8843 mtu 1500  
> > 
> >   
> > index 7 priority 0 llprio 3
> > encap: vnetid 2 parent em2
> > status: active
> > inet 192.168.4.1 netmask 0xfff0 broadcast 192.168.4.15
> > % doas route -n show -inet
> > Routing tables
> > 
> > Internet:
> > DestinationGatewayFlags   Refs  Use   Mtu  Prio 
> > Iface
> > default62.27.93.143   UGS563324 - 8 
> > pppoe0
> > 224/4  127.0.0.1  URS00 32768 8 lo0
> > 62.27.93.143   85.212.225.8   UHh11 - 8 
> > pppoe0
> > 85.212.225.8   85.212.225.8   UHl0 1589 - 1 
> > pppoe0
> > 127/8  127.0.0.1  UGRS   00 32768 8 lo0
> > 127.0.0.1  127.0.0.1  UHhl   9 1131 32768 1 lo0
> > 192.168.0/22   192.168.4.1UGS0  314 - 8 
> > vlan2 <- this is the culprit
> > 192.168.4.0/28 192.168.4.1UCn20 - 4 
> > vlan2
> > 
> > You'll note I manually (Flag S) added this rather senseless route to gateway
> > 192.268.4.1 (Flag G), which is the very same machine.  
> 
> See, that's why the redirect message doesn't make sense.  Because it
> uses the info from this route.  Now What I'm not getting is where did
> you configured 192.168.1.1?

It's the IP of the other end of the IPsec tunnel.


-- 
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
2779 7F73 44FD 0736 B67A  C410 69EC 7922 34B4 2566



Re: ifconfig(8): pltime and vltime are measured in seconds

2018-05-05 Thread Jason McIntyre
On Sat, May 05, 2018 at 01:50:30PM +0200, Paul de Weerd wrote:
> During a discussion on IPv6 with Undeadly editor Ross Richardson, he
> pointed out that ifconfig(8) doesn't mention the unit of the arguments
> to the pltime and vltime options.  Here's a diff to fix that:
> 

hi.

> 
> Index: ifconfig.8
> ===
> RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
> retrieving revision 1.305
> diff -u -p -r1.305 ifconfig.8
> --- ifconfig.816 Mar 2018 19:45:13 -  1.305
> +++ ifconfig.85 May 2018 11:45:03 -
> @@ -1197,7 +1197,9 @@ Fill the interface index
>  .Pq the lowermost 64th bit of an IPv6 address
>  automatically.
>  .It Cm pltime Ar n
> -Set preferred lifetime for the address.
> +Set preferred lifetime for the address,
> +.Ar n
> +is given in seconds.

could we get away with just

...for the address,
in seconds.

because i don;t like the sentence splice. if not, i guess

...for the address,
where
.Ar n
...

but i think it is clear enough to just say "in seconds".
jmc

>  .It Cm soii
>  Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
>  as per RFC 7217, for link local and SLAAC addresses on the interface.
> @@ -1219,7 +1221,9 @@ Set the IPv6 tentative address bit.
>  .It Cm -tentative
>  Clear the IPv6 tentative address bit.
>  .It Cm vltime Ar n
> -Set valid lifetime for the address.
> +Set valid lifetime for the address,
> +.Ar n
> +is given in seconds.
>  .El
>  .Sh INTERFACE GROUPS
>  .Nm ifconfig
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 



[patch] simplify old_filename handling in ed(1)

2018-05-05 Thread Martijn van Duren
Hello tech@,

The following patch simplifies the filename handling for ed and removes
a few BACKWARDS flags. This patch changes the code in the following
ways:
- If there's no valid filename always fail early. This would be
identical if we were to disable the BACKWARDS flag.
- If there's a new valid filename always save it as the new current
filename, even if there's an error condition further down the line.

This also fixes an weird quirk in the current code:
$ ed -p'>'
>H
>e
?
no current filename
>e
?
warning: file modified

And fixes an off by one in get_filename.
OK?

martijn@

Index: main.c
===
RCS file: /cvs/src/bin/ed/main.c,v
retrieving revision 1.61
diff -u -p -r1.61 main.c
--- main.c  26 Feb 2018 17:35:08 -  1.61
+++ main.c  5 May 2018 12:34:15 -
@@ -67,7 +67,7 @@ void handle_winch(int);
 static int next_addr(void);
 static int check_addr_range(int, int);
 static int get_matching_node_addr(regex_t *, int);
-static char *get_filename(void);
+static char *get_filename(int);
 static int get_shell_command(void);
 static int append_lines(int);
 static int join_lines(int, int);
@@ -544,7 +544,7 @@ exec_command(void)
} else if (!isspace((unsigned char)*ibufp)) {
seterrmsg("unexpected command suffix");
return ERR;
-   } else if ((fnp = get_filename()) == NULL)
+   } else if ((fnp = get_filename(1)) == NULL)
return ERR;
GET_COMMAND_SUFFIX();
if (delete_lines(1, addr_last) < 0)
@@ -554,15 +554,7 @@ exec_command(void)
return ERR;
else if (open_sbuf() < 0)
return FATAL;
-   if (*fnp && *fnp != '!')
-   strlcpy(old_filename, fnp, sizeof old_filename);
-#ifdef BACKWARDS
-   if (*fnp == '\0' && *old_filename == '\0') {
-   seterrmsg("no current filename");
-   return ERR;
-   }
-#endif
-   if (read_file(*fnp ? fnp : old_filename, 0) < 0)
+   if (read_file(fnp, 0) < 0)
return ERR;
clear_undo_stack();
modified = 0;
@@ -575,16 +567,14 @@ exec_command(void)
} else if (!isspace((unsigned char)*ibufp)) {
seterrmsg("unexpected command suffix");
return ERR;
-   } else if ((fnp = get_filename()) == NULL)
+   } else if ((fnp = get_filename(1)) == NULL)
return ERR;
else if (*fnp == '!') {
seterrmsg("invalid redirection");
return ERR;
}
GET_COMMAND_SUFFIX();
-   if (*fnp)
-   strlcpy(old_filename, fnp, sizeof old_filename);
-   puts(strip_escapes(old_filename));
+   puts(strip_escapes(fnp));
break;
case 'g':
case 'v':
@@ -708,20 +698,11 @@ exec_command(void)
return ERR;
} else if (addr_cnt == 0)
second_addr = addr_last;
-   if ((fnp = get_filename()) == NULL)
+   if ((fnp = get_filename(0)) == NULL)
return ERR;
GET_COMMAND_SUFFIX();
if (!isglobal) clear_undo_stack();
-   if (*old_filename == '\0' && *fnp != '!')
-   strlcpy(old_filename, fnp, sizeof old_filename);
-#ifdef BACKWARDS
-   if (*fnp == '\0' && *old_filename == '\0') {
-   seterrmsg("no current filename");
-   return ERR;
-   }
-#endif
-   if ((addr = read_file(*fnp ? fnp : old_filename,
-   second_addr)) < 0)
+   if ((addr = read_file(fnp, second_addr)) < 0)
return ERR;
else if (addr)
modified = 1;
@@ -845,23 +826,15 @@ exec_command(void)
if (!isspace((unsigned char)*ibufp)) {
seterrmsg("unexpected command suffix");
return ERR;
-   } else if ((fnp = get_filename()) == NULL)
+   } else if ((fnp = get_filename(0)) == NULL)
return ERR;
if (addr_cnt == 0 && !addr_last)
first_addr = second_addr = 0;
else if (check_addr_range(1, addr_last) < 0)
return ERR;
GET_COMMAND_SUFFIX();
-   if (*old_filename == '\0' && *fnp != '!')
-   strlcpy(old_filename, fnp, sizeof old_filename);
-#ifdef BACKWARDS
-   if (*fnp == '\0' && *old_filename == '\0') {
-   seterrmsg("no current filename");
-   return ERR;

in6_ioctl: some more cleanup

2018-05-05 Thread Theo Buehler
Now that the dust has settled a bit, I'd like to simplify in6_ioctl() a
bit more. At the moment it still has two tangled switches that deal with
SIOCAIFADDR_IN6 and SIOCDIFADDR_IN6. We can disentangle them at the cost
of repeating a few lines, but I think it's worth it.

I also introduced another function to make in6_ioctl() appear a bit more
symmetric.

Index: sys/netinet6/in6.c
===
RCS file: /var/cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.224
diff -u -p -r1.224 in6.c
--- sys/netinet6/in6.c  4 May 2018 19:43:07 -   1.224
+++ sys/netinet6/in6.c  5 May 2018 12:21:41 -
@@ -116,6 +116,7 @@ const struct in6_addr in6mask96 = IN6MAS
 const struct in6_addr in6mask128 = IN6MASK128;
 
 int in6_ioctl(u_long, caddr_t, struct ifnet *, int);
+int in6_ioctl_change_ifaddr(u_long, caddr_t, struct ifnet *);
 int in6_ioctl_get(u_long, caddr_t, struct ifnet *);
 int in6_ifinit(struct ifnet *, struct in6_ifaddr *, int);
 void in6_unlink_ifa(struct in6_ifaddr *, struct ifnet *);
@@ -206,12 +207,6 @@ in6_control(struct socket *so, u_long cm
 int
 in6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp, int privileged)
 {
-   struct  in6_ifreq *ifr = (struct in6_ifreq *)data;
-   struct  in6_ifaddr *ia6 = NULL;
-   struct  in6_aliasreq *ifra = (struct in6_aliasreq *)data;
-   struct sockaddr_in6 *sa6;
-   int error = 0;
-
if (ifp == NULL)
return (ENXIO);
 
@@ -225,11 +220,10 @@ in6_ioctl(u_long cmd, caddr_t data, stru
case SIOCGIFALIFETIME_IN6:
return (in6_ioctl_get(cmd, data, ifp));
case SIOCAIFADDR_IN6:
-   sa6 = >ifra_addr;
-   break;
case SIOCDIFADDR_IN6:
-   sa6 = >ifr_addr;
-   break;
+   if (!privileged)
+   return (EPERM);
+   return (in6_ioctl_change_ifaddr(cmd, data, ifp));
case SIOCSIFADDR:
case SIOCSIFDSTADDR:
case SIOCSIFBRDADDR:
@@ -242,6 +236,16 @@ in6_ioctl(u_long cmd, caddr_t data, stru
default:
return (EOPNOTSUPP);
}
+}
+
+int
+in6_ioctl_change_ifaddr(u_long cmd, caddr_t data, struct ifnet *ifp)
+{
+   struct  in6_ifreq *ifr = (struct in6_ifreq *)data;
+   struct  in6_ifaddr *ia6 = NULL;
+   struct  in6_aliasreq *ifra = (struct in6_aliasreq *)data;
+   struct sockaddr_in6 *sa6;
+   int error = 0, newifaddr = 0, plen;
 
/*
 * Find address for this interface, if it exists.
@@ -255,6 +259,16 @@ in6_ioctl(u_long cmd, caddr_t data, stru
 * presence of ifra_addr, and reject invalid ones here.
 * It also decreases duplicated code among SIOC*_IN6 operations.
 */
+   switch(cmd) {
+   case SIOCAIFADDR_IN6:
+   sa6 = >ifra_addr;
+   break;
+   case SIOCDIFADDR_IN6:
+   sa6 = >ifr_addr;
+   break;
+   default:
+   panic("unknown ioctl %lu", cmd);
+   }
 
NET_LOCK();
 
@@ -279,8 +293,7 @@ in6_ioctl(u_long cmd, caddr_t data, stru
}
}
ia6 = in6ifa_ifpwithaddr(ifp, >sin6_addr);
-   } else
-   ia6 = NULL;
+   }
 
switch (cmd) {
case SIOCDIFADDR_IN6:
@@ -293,10 +306,8 @@ in6_ioctl(u_long cmd, caddr_t data, stru
 */
if (ia6 == NULL) {
error = EADDRNOTAVAIL;
-   goto err;
+   break;
}
-   /* FALLTHROUGH */
-   case SIOCAIFADDR_IN6:
/*
 * We always require users to specify a valid IPv6 address for
 * the corresponding operation.
@@ -304,19 +315,22 @@ in6_ioctl(u_long cmd, caddr_t data, stru
if (ifra->ifra_addr.sin6_family != AF_INET6 ||
ifra->ifra_addr.sin6_len != sizeof(struct sockaddr_in6)) {
error = EAFNOSUPPORT;
-   goto err;
-   }
-   if (!privileged) {
-   error = EPERM;
-   goto err;
+   break;
}
+   in6_purgeaddr(>ia_ifa);
+   dohooks(ifp->if_addrhooks, 0);
break;
-   }
 
-   switch (cmd) {
case SIOCAIFADDR_IN6:
-   {
-   int plen, newifaddr = 0;
+   /*
+* We always require users to specify a valid IPv6 address for
+* the corresponding operation.
+*/
+   if (ifra->ifra_addr.sin6_family != AF_INET6 ||
+   ifra->ifra_addr.sin6_len != sizeof(struct sockaddr_in6)) {
+   error = EAFNOSUPPORT;
+   break;
+   }
 
/* reject read-only flags */
if ((ifra->ifra_flags & IN6_IFF_DUPLICATED) != 0 

ifconfig(8): pltime and vltime are measured in seconds

2018-05-05 Thread Paul de Weerd
During a discussion on IPv6 with Undeadly editor Ross Richardson, he
pointed out that ifconfig(8) doesn't mention the unit of the arguments
to the pltime and vltime options.  Here's a diff to fix that:


Index: ifconfig.8
===
RCS file: /home/OpenBSD/cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.305
diff -u -p -r1.305 ifconfig.8
--- ifconfig.8  16 Mar 2018 19:45:13 -  1.305
+++ ifconfig.8  5 May 2018 11:45:03 -
@@ -1197,7 +1197,9 @@ Fill the interface index
 .Pq the lowermost 64th bit of an IPv6 address
 automatically.
 .It Cm pltime Ar n
-Set preferred lifetime for the address.
+Set preferred lifetime for the address,
+.Ar n
+is given in seconds.
 .It Cm soii
 Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
 as per RFC 7217, for link local and SLAAC addresses on the interface.
@@ -1219,7 +1221,9 @@ Set the IPv6 tentative address bit.
 .It Cm -tentative
 Clear the IPv6 tentative address bit.
 .It Cm vltime Ar n
-Set valid lifetime for the address.
+Set valid lifetime for the address,
+.Ar n
+is given in seconds.
 .El
 .Sh INTERFACE GROUPS
 .Nm ifconfig

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 



Re: Don't send icmp redirect to the same interface a forwarded packet came in on

2018-05-05 Thread Martin Pieuchot
On 03/05/18(Thu) 17:19, Christopher Zimmermann wrote:
> On 2018-05-03 Martin Pieuchot  wrote:
> > On 02/05/18(Wed) 14:45, Christopher Zimmermann wrote:
> > > On 2018-05-02 Martin Pieuchot  wrote:  
> > > > On 02/05/18(Wed) 11:47, Christopher Zimmermann wrote:  
> > > > > I just want to bring this up again. Can some network guru give me an 
> > > > > ok
> > > > > or some feedback please?
> > > > 
> > > > Can you explain with words why we shouldn't send a redirect?  The
> > > > comment above your diff states clearly:
> > > > 
> > > >   "If forwarding packet using same interface that it came in on,
> > > >   perhaps should send a redirect to sender to shortcut a hop."
> > > > 
> > > > So you're suggesting no to do that, why?  
> > > 
> > > That's not exactly what I'm suggesting.
> > > 
> > > In this setting:
> > > 
> > > A 192.168.4.7 <--> 192.168.4.1 Gateway 192.168.1.1 <--> 192.168.1.2 B
> > > 
> > > I observed this senseless redirect:
> > > 
> > > 192.168.4.1 > 192.168.4.7: icmp: redirect 192.168.1.2 to host 192.168.4.1
> > > in plain language it means:
> > > "Hi 192.168.4.7, I'm 192.168.4.1. You sent me a packet for 192.168.1.2.
> > > I'm not the best route, next time send it to 192.168.4.1."
> > > So the gateway is instructing host 192.168.4.7 to use gateway
> > > 192.168.4.1 instead of 192.168.4.1. (this is not a typo!)  
> > 
> > How does your routing table looks like?
> 
> % doas ifconfig vlan2 
> 
> vlan2: flags=8843 mtu 1500
>   
>   
> index 7 priority 0 llprio 3
> encap: vnetid 2 parent em2
> status: active
> inet 192.168.4.1 netmask 0xfff0 broadcast 192.168.4.15
> % doas route -n show -inet
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> default62.27.93.143   UGS563324 - 8 pppoe0
> 224/4  127.0.0.1  URS00 32768 8 lo0
> 62.27.93.143   85.212.225.8   UHh11 - 8 pppoe0
> 85.212.225.8   85.212.225.8   UHl0 1589 - 1 pppoe0
> 127/8  127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1  127.0.0.1  UHhl   9 1131 32768 1 lo0
> 192.168.0/22   192.168.4.1UGS0  314 - 8 vlan2 
> <- this is the culprit
> 192.168.4.0/28 192.168.4.1UCn20 - 4 vlan2
> 
> You'll note I manually (Flag S) added this rather senseless route to gateway
> 192.268.4.1 (Flag G), which is the very same machine.

See, that's why the redirect message doesn't make sense.  Because it
uses the info from this route.  Now What I'm not getting is where did
you configured 192.168.1.1?



Use console speed from device tree

2018-05-05 Thread Mark Kettenis
Diff below makes com(4) use the console speed from /chosen/stdout-path
when probided.  

stdout-path: 'serial0:115200n8'

We could also parse the partity and number of bits, but frankly that
isn't worth it.  Everybody uses 8 bits with no parity these days.
I'll make the same changes to armv7 if I get an ok for this.


Index: arch/arm64/arm64/machdep.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
retrieving revision 1.31
diff -u -p -r1.31 machdep.c
--- arch/arm64/arm64/machdep.c  29 Mar 2018 21:35:23 -  1.31
+++ arch/arm64/arm64/machdep.c  5 May 2018 11:15:06 -
@@ -56,7 +56,8 @@ uint8_t *bootmac = NULL;
 
 extern uint64_t esym;
 
-int stdout_node = 0;
+int stdout_node;
+int stdout_speed;
 
 void (*cpuresetfn)(void);
 void (*powerdownfn)(void);
@@ -150,6 +151,30 @@ inittodr(time_t base)
printf("WARNING: CHECK AND RESET THE DATE!\n");
 }
 
+static int
+atoi(const char *s)
+{
+   int n, neg;
+
+   n = 0;
+   neg = 0;
+
+   while (*s == '-') {
+   s++;
+   neg = !neg;
+   }
+
+   while (*s != '\0') {
+   if (*s < '0' || *s > '9')
+   break;
+
+   n = (10 * n) + (*s - '0');
+   s++;
+   }
+
+   return (neg ? -n : n);
+}
+
 void *
 fdt_find_cons(const char *name)
 {
@@ -165,8 +190,10 @@ fdt_find_cons(const char *name)
if (fdt_node_property(node, "stdout-path", ) > 0) {
if (strchr(stdout, ':') != NULL) {
strlcpy(buf, stdout, sizeof(buf));
-   if ((p = strchr(buf, ':')) != NULL)
-   *p = '\0';
+   if ((p = strchr(buf, ':')) != NULL) {
+   *p++ = '\0';
+   stdout_speed = atoi(p);
+   }
stdout = buf;
}
if (stdout[0] != '/') {
Index: arch/arm64/dev/com_fdt.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/com_fdt.c,v
retrieving revision 1.4
diff -u -p -r1.4 com_fdt.c
--- arch/arm64/dev/com_fdt.c2 Apr 2018 12:59:39 -   1.4
+++ arch/arm64/dev/com_fdt.c5 May 2018 11:15:06 -
@@ -80,7 +80,6 @@ com_fdt_init_cons(void)
if (bus_space_map(comconsiot, reg.addr, reg.size, 0, ))
return;
 
-   comconsrate = B115200;
cn_tab = _fdt_cons;
 }
 
@@ -136,6 +135,7 @@ com_fdt_attach(struct device *parent, st
SET(sc->sc_hwflags, COM_HW_CONSOLE);
SET(sc->sc_swflags, COM_SW_SOFTCAR);
comconsfreq = sc->sc_frequency;
+   comconsrate = stdout_speed ? stdout_speed : B115200;
}
 
if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
Index: arch/arm64/include/fdt.h
===
RCS file: /cvs/src/sys/arch/arm64/include/fdt.h,v
retrieving revision 1.3
diff -u -p -r1.3 fdt.h
--- arch/arm64/include/fdt.h20 Mar 2018 23:04:48 -  1.3
+++ arch/arm64/include/fdt.h5 May 2018 11:15:06 -
@@ -35,6 +35,7 @@ struct fdt_attach_args {
 };
 
 extern int stdout_node;
+extern int stdout_speed;
 extern bus_space_tag_t fdt_cons_bs_tag;
 
 void *fdt_find_cons(const char *);