On Fri, Jun 09, 2017 at 10:36:45PM +0200, Christian Weisgerber wrote:
> The example in the pppoe(4) man page also includes
>
> !/sbin/route add default -ifp pppoe0 0.0.0.1
>
> to specify the default route. What happens to that?
Good question. It raises an interesting point: Setting a de
On Fri, Jun 09, 2017 at 05:37:44PM +0100, Jason McIntyre wrote:
> why do you have to specify 0.0.0.0 *and* dynaddr?
If there is no address on the interface, the code in sppp_set_ip_addrs()
loops over an empty interface address list and hence does nothing.
IPCP will still negotiate an address but a
On Sat, Jun 10, 2017 at 12:45:01AM +0200, Theo Buehler wrote:
> On Fri, Jun 09, 2017 at 11:59:44PM +0200, Theo Buehler wrote:
> > On Fri, Jun 09, 2017 at 11:55:26PM +0200, Adam Wolk wrote:
> > > On Fri, Jun 09, 2017 at 11:54:03PM +0200, Adam Wolk wrote:
> > > > On Fri, Jun 09, 2017 at 09:28:29PM +0
On Fri, Jun 09, 2017 at 11:59:44PM +0200, Theo Buehler wrote:
> On Fri, Jun 09, 2017 at 11:55:26PM +0200, Adam Wolk wrote:
> > On Fri, Jun 09, 2017 at 11:54:03PM +0200, Adam Wolk wrote:
> > > On Fri, Jun 09, 2017 at 09:28:29PM +, ra...@openmailbox.org wrote:
> > > > Hello!
> > > >
> > > > Here
On Fri, Jun 09, 2017 at 11:55:26PM +0200, Adam Wolk wrote:
> On Fri, Jun 09, 2017 at 11:54:03PM +0200, Adam Wolk wrote:
> > On Fri, Jun 09, 2017 at 09:28:29PM +, ra...@openmailbox.org wrote:
> > > Hello!
> > >
> > > Here is a patch with a pledge bugfix in netcat and some minor style
> > > impr
On Fri, Jun 09, 2017 at 11:54:03PM +0200, Adam Wolk wrote:
> On Fri, Jun 09, 2017 at 09:28:29PM +, ra...@openmailbox.org wrote:
> > Hello!
> >
> > Here is a patch with a pledge bugfix in netcat and some minor style
> > improvements.
> >
> > An example of how to trigger the bug:
> >
> > $ nc
On Fri, Jun 09, 2017 at 09:28:29PM +, ra...@openmailbox.org wrote:
> Hello!
>
> Here is a patch with a pledge bugfix in netcat and some minor style
> improvements.
>
> An example of how to trigger the bug:
>
> $ nc -Ptest -v -c blog.tintagel.pl 443
> nc: pledge: Operation not permitted
>
>
sorry! looks like my email client corrupted the patch, here it is hosted
on a paste site https://paste.debian.net/970854/
Hello!
Here is a patch with a pledge bugfix in netcat and some minor style
improvements.
An example of how to trigger the bug:
$ nc -Ptest -v -c blog.tintagel.pl 443
nc: pledge: Operation not permitted
credits to
* awolk@ for drawing attention to netcat.
* Juuso Lapinlampi for suggesting to
Stefan Sperling:
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev em0 authproto pap \
> authname 'testcaller' authkey 'donttell' \
>dynaddr dyndest up
>
> Tested on my ADSL line and it works as expected.
The example in the pppoe(4) m
No need for temporary variables either, strtonum guarantees through
maxval that its return value won't overflow when casted.
Index: brconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
retrieving revision 1.15
diff -u -p -r1.
On Fri, Jun 09, 2017 at 06:33:46PM +0200, Stefan Sperling wrote:
> Currently, sppp(4) interfaces use a destination address of 0.0.0.1 to
> indicate that the destination address should be assigned by the peer:
>
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev em0 authprot
Currently, sppp(4) interfaces use a destination address of 0.0.0.1 to
indicate that the destination address should be assigned by the peer:
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev em0 authproto pap \
authname 'testcaller' authkey 'donttell' up
On Fri, Jun 09, 2017 at 04:40:18PM +0200, Martin Pieuchot wrote:
> Now with the correct diff:
OK bluhm@
>
> Index: net/radix.c
> ===
> RCS file: /cvs/src/sys/net/radix.c,v
> retrieving revision 1.56
> diff -u -p -r1.56 radix.c
> ---
On Fri, Jun 09, 2017 at 03:54:04PM +0200, Martin Pieuchot wrote:
> Updated diff:
>
> - use a clever trick in sorflush() to make the new assert happy.
Perhaps a bit too clever. On my amd64 struct socket has nearly 400
bytes. That may be too much for our kernel stack.
> - convert sbappendrecor
On 09/06/17(Fri) 16:23, Martin Pieuchot wrote:
> On 09/06/17(Fri) 15:46, Alexander Bluhm wrote:
> > On Fri, Jun 09, 2017 at 03:11:05PM +0200, Martin Pieuchot wrote:
> > > > The static variable last_zeroed does not look MP safe. If I get
> > > > this code correctly it is only an optimization to avo
On Fri, Jun 09, 2017 at 04:23:13PM +0200, Martin Pieuchot wrote:
> I couldn't convince myself that rn_search() do not check bits
> after 'mlen' so I added the memset() as you suggested.
It looks like you forgot to put the memset() in the diff.
> @@ -432,14 +440,10 @@ rn_addmask(void *n_arg, int s
On Fri, Jun 09, 2017 at 03:48:49PM +0200, Hrvoje Popovski wrote:
> On 9.6.2017. 14:55, Alexandr Nedvedicky wrote:
> > Hello,
> >
> >
> > On Fri, Jun 09, 2017 at 01:11:01PM +0200, Alexander Bluhm wrote:
> >> On Fri, Jun 09, 2017 at 10:55:46AM +0200, Alexandr Nedvedicky wrote:
> >>> would it make s
On 09/06/17(Fri) 15:46, Alexander Bluhm wrote:
> On Fri, Jun 09, 2017 at 03:11:05PM +0200, Martin Pieuchot wrote:
> > > The static variable last_zeroed does not look MP safe. If I get
> > > this code correctly it is only an optimization to avoid multiple
> > > zeroing in addmask_key. This does no
On 09/06/17(Fri) 00:32, Alexander Bluhm wrote:
> On Tue, Jun 06, 2017 at 05:15:40PM +0200, Martin Pieuchot wrote:
> > TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses
> > to their sockets are serialized via the NET_LOCK(). On the other hand
> > pfkey and routing sockets acces
On 9.6.2017. 14:55, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Fri, Jun 09, 2017 at 01:11:01PM +0200, Alexander Bluhm wrote:
>> On Fri, Jun 09, 2017 at 10:55:46AM +0200, Alexandr Nedvedicky wrote:
>>> would it make sense to commit a poor man's solution below, before pfsync(4)
>>> will get to sh
On Fri, Jun 09, 2017 at 03:11:05PM +0200, Martin Pieuchot wrote:
> > The static variable last_zeroed does not look MP safe. If I get
> > this code correctly it is only an optimization to avoid multiple
> > zeroing in addmask_key. This does not work anyway with addmask_key
> > on the stack.
>
> Y
On Fri, Jun 09, 2017 at 03:28:07PM +0200, Alexander Bluhm wrote:
> On Wed, May 31, 2017 at 02:29:03PM +0200, Florian Riehm wrote:
> > @@ -359,6 +333,7 @@ kr_fib_decouple(void)
> > void
> > kr_dispatch_msg(int fd, short event, void *bula)
> > {
> > + /* XXX this is stupid */
> > dispatch_rt
On Wed, May 31, 2017 at 02:29:03PM +0200, Florian Riehm wrote:
> @@ -359,6 +333,7 @@ kr_fib_decouple(void)
> void
> kr_dispatch_msg(int fd, short event, void *bula)
> {
> + /* XXX this is stupid */
> dispatch_rtmsg();
> }
I guess this comment refers to the event_loopexit(NULL) in osp
On Fri, Jun 09, 2017 at 02:48:58PM +0200, Alexander Bluhm wrote:
> On Fri, Jun 09, 2017 at 09:16:01AM +, Florian Obser wrote:
> > I don't think we need a knob for this, doing it per default if we
> > have the source link layer address should be fine.
> >
> > See RFC 7772 why this is a good thi
On 08/06/17(Thu) 23:46, Alexander Bluhm wrote:
> On Tue, Jun 06, 2017 at 03:36:12PM +0200, Martin Pieuchot wrote:
> > +#define SALEN(sa) (*(u_char *)sa)
>
> Put () around macro arguments.
> #define SALEN(sa) (*(u_char *)(sa))
Done.
> > -int
> > +static int
> > rn_refines(void *m_arg, void
Hello,
On Fri, Jun 09, 2017 at 01:11:01PM +0200, Alexander Bluhm wrote:
> On Fri, Jun 09, 2017 at 10:55:46AM +0200, Alexandr Nedvedicky wrote:
> > would it make sense to commit a poor man's solution below, before pfsync(4)
> > will get to shape? The idea is to grab PF_LOCK, just before we pass th
On Fri, Jun 09, 2017 at 09:16:01AM +, Florian Obser wrote:
> I don't think we need a knob for this, doing it per default if we
> have the source link layer address should be fine.
>
> See RFC 7772 why this is a good thing.
>
> OK?
I wonder whether the
/* update counter */
if
On Fri, Jun 09, 2017 at 10:55:46AM +0200, Alexandr Nedvedicky wrote:
> would it make sense to commit a poor man's solution below, before pfsync(4)
> will get to shape? The idea is to grab PF_LOCK, just before we pass the data
> to PF for further processing.
Whatever helps to make progress with pf
I don't think we need a knob for this, doing it per default if we
have the source link layer address should be fine.
See RFC 7772 why this is a good thing.
OK?
diff --git rtadvd.c rtadvd.c
index 1f470a06c31..219b357e50b 100644
--- rtadvd.c
+++ rtadvd.c
@@ -141,7 +141,7 @@ static int prefix_check
Hello,
would it make sense to commit a poor man's solution below, before pfsync(4)
will get to shape? The idea is to grab PF_LOCK, just before we pass the data
to PF for further processing.
regards
sasha
8<---8<---8<--8<
--- src/sys/net/if_
Hi,
There is an ongoing confusion in sed's source about the concept of EOL:
the code contradicts itself as to whether it should be determined by a
trailing NUL or by looking up the `len' field of the SPACE structure.
At least two commands (`l' and `s') assume that the pattern space is
always NUL-
Hi,
This diff passes M_CANFAIL to malloc(9) calls which use M_WAITOK but are
tested for failure. OK?
Index: sys/dev/usb/if_urndis.c
===
RCS file: /cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 if
33 matches
Mail list logo
