Re: ntpd:support adjusting initial time = y2k36 on 32-bit time_t platforms
Brent Cook busterb at gmail.com writes: + T4 += (uint64_t)tv.tv_sec + JAN_1970 + 1.0e-6 * tv.tv_usec; snip + return ((uint64_t)tv.tv_sec + JAN_1970 + 1.0e-6 * tv.tv_usec); snip Can gettime_from_timeval be used over the code instead of repeating same chunk? T4 += gettime_from_timeval(... return gettime_from_timeval(...
Re: allow stateless address auto configuration when v6 forwarding is enabled
On Mon, Mar 23, 2015 at 06:21:40PM +, Florian Obser wrote: [ this originated on misc@: https://marc.info/?t=14170362181r=1w=2 ] so there are setups out there where a router gets a default route (and maybe a prefix) via SLAAC (think dsl / cable line). Currently the kernel does not accept a default route via SLAAC when forwarding is enabled. Since we have a per-interface flag to enable SLAAC we can lift this restriction. I already have one OK and one testresult. More tests / OKs / Comments? Is there already a way to obtain prefixes but avoid the default route? That would be useful to me. The only way I could think of so far are rdomains. But that seems overkill.
Re: allow stateless address auto configuration when v6 forwarding is enabled
On Mon, Mar 23, 2015 at 08:22:46PM +0100, Stefan Sperling wrote: On Mon, Mar 23, 2015 at 06:21:40PM +, Florian Obser wrote: [ this originated on misc@: https://marc.info/?t=14170362181r=1w=2 ] so there are setups out there where a router gets a default route (and maybe a prefix) via SLAAC (think dsl / cable line). Currently the kernel does not accept a default route via SLAAC when forwarding is enabled. Since we have a per-interface flag to enable SLAAC we can lift this restriction. I already have one OK and one testresult. More tests / OKs / Comments? Is there already a way to obtain prefixes but avoid the default route? That would be useful to me. Well, what we currently have without this diff behaves that way. Enable forwarding and the kernel only processes the prefix. AFAIC that's not a feature but an accident. I'm not quite sure what your use case is though... The only way I could think of so far are rdomains. But that seems overkill. -- I'm not entirely sure you are real.
Prinde OFERTA si pleci in VACANTA!
Apasati aici daca nu vizualizati corect e-mailul. logo-jinfo.jpg gplus.pngtwitter.pngwordpress.pngfacebook.png info_tel.png Cautam pentru tine cele mai bune oferte de vacanta ! Esti senior? Asteptam datele tale de contact ( intr-un mesaj privat) si iti trimitem – CARDUL GOLD PENTRU SENIORI ! j'info tours - golden card seniori - 31.jpg Descopera toate circuitele marca J'Info Tours pe site-ul www.jinfotours.ro Reduceri Maxime suleyman-magnificul.jpg Acasa la Suleyman Magnificul Plecare 24 mai 2015 10 zile / 9 nopti Transport : Avion Bucuresti ? Istanbul ?Ankara ? Cappadocia ? Konya ? Pamukkale ? Kusadasi ? Izmir ? Canakkale de la 539 € Vezi detalii japonia.jpg Coreea de Sud - Japonia Plecare 7 aprilie 2015 17 zile/15 nopti Transport : Avion de la 3033 € Vezi detalii portugalia.jpg Spania - Maroc - Portugalia Plecare 1 mai 2015 15 zile / 14 nopti Transport : Avion de la 934 € Vezi detalii maroc.jpg Maroc Plecare 8 aprilie 2015 9 zile / 8 nopti Transport : Avion de la 573 € Vezi detalii china reducere.jpg China - Invatamintele lui Buddha Plecare 26 iunie 2015 12 zile / 10 zile Transport: Avion de la 1065 € Vezi detalii china hong kong.jpg China - Hong Kong Plecare 26 iunie 2015 14 zile/ 12 nopti Transport: Avion de la 1410 € Vezi detalii londra social.jpg Vacanta la Londra Plecare 9 aprilie 2015 6 zile / 5 nopti Transport : Avion de la 290 € Vezi detalii israel iordania.jpg Israel - Iordania Plecare 9 aprilie 2015 8 zile / 7 nopti Transport: Avion de la 475 € Vezi detalii rusia noptile albe.jpg Rusia Noptile Albe Moscova St. Petersburg Plecare 22 iunie 2015 Trasport: Avion de la 583 € Vezi detalii israel red.jpg Israel Plecari 9 aprilie si 1 mai 2015 6 zile / 5 nopti Trasnport: Avion de la 290 € Vezi detalii Nu ai gasit vacanta dorita ? Contacteaza-ne pentru o oferta personalizata! Ati primit acest email ca urmare a inregistrarii dumneavoastra pe www.jinfotours.ro sau datorita afilierii la newsletterul nostru. Click aici pentru a nu mai primi acest gen de emailuri.
allow stateless address auto configuration when v6 forwarding is enabled
[ this originated on misc@:
https://marc.info/?t=14170362181r=1w=2 ]
so there are setups out there where a router gets a default route
(and maybe a prefix) via SLAAC (think dsl / cable line).
Currently the kernel does not accept a default route via SLAAC when
forwarding is enabled. Since we have a per-interface flag to enable
SLAAC we can lift this restriction.
I already have one OK and one testresult.
More tests / OKs / Comments?
diff --git netinet6/nd6.c netinet6/nd6.c
index 7ffed43..30c9414 100644
--- netinet6/nd6.c
+++ netinet6/nd6.c
@@ -610,8 +610,7 @@ nd6_purge(struct ifnet *ifp)
}
}
- /* XXX: too restrictive? */
- if (!ip6_forwarding (ifp-if_xflags IFXF_AUTOCONF6)) {
+ if (ifp-if_xflags IFXF_AUTOCONF6) {
/* refresh default router list */
defrouter_select();
}
@@ -1574,12 +1573,8 @@ fail:
* defrtrlist_update called the function as well. However, I believe
* we can compromise the overhead, since it only happens the first
* time.
-* XXX: although defrouter_select() should not have a bad effect
-* for those are not autoconfigured hosts, we explicitly avoid such
-* cases for safety.
*/
- if (do_update ln-ln_router !ip6_forwarding
- (ifp-if_xflags IFXF_AUTOCONF6))
+ if (do_update ln-ln_router (ifp-if_xflags IFXF_AUTOCONF6))
defrouter_select();
return rt;
diff --git netinet6/nd6_rtr.c netinet6/nd6_rtr.c
index 50f577d..e8659e0 100644
--- netinet6/nd6_rtr.c
+++ netinet6/nd6_rtr.c
@@ -106,7 +106,7 @@ nd6_rs_input(struct mbuf *m, int off, int icmp6len)
char src[INET6_ADDRSTRLEN], dst[INET6_ADDRSTRLEN];
/* If I'm not a router, ignore it. XXX - too restrictive? */
- if (!ip6_forwarding || (ifp-if_xflags IFXF_AUTOCONF6))
+ if (!ip6_forwarding)
goto freeit;
/* Sanity checks */
@@ -579,7 +579,7 @@ defrtrlist_del(struct nd_defrouter *dr)
* as a next hop.
*/
/* XXX: better condition? */
- if (!ip6_forwarding (dr-ifp-if_xflags IFXF_AUTOCONF6))
+ if (!ip6_forwarding)
rt6_flush(dr-rtaddr, dr-ifp);
if (dr-installed) {
@@ -712,21 +712,6 @@ defrouter_select(void)
int s = splsoftnet();
/*
-* This function should be called only when acting as an autoconfigured
-* host. Although the remaining part of this function is not effective
-* if the node is not an autoconfigured host, we explicitly exclude
-* such cases here for safety.
-*/
- /* XXX too strict? */
- if (ip6_forwarding) {
- nd6log((LOG_WARNING,
- defrouter_select: called unexpectedly (forwarding=%d)\n,
- ip6_forwarding));
- splx(s);
- return;
- }
-
- /*
* Let's handle easy case (3) first:
* If default router list is empty, there's nothing to be done.
*/
@@ -879,7 +864,7 @@ defrtrlist_update(struct nd_defrouter *new)
/* entry does not exist */
if (new-rtlifetime == 0) {
/* flush all possible redirects */
- if (!ip6_forwarding (new-ifp-if_xflags IFXF_AUTOCONF6))
+ if (new-ifp-if_xflags IFXF_AUTOCONF6)
rt6_flush(new-rtaddr, new-ifp);
splx(s);
return (NULL);
--
I'm not entirely sure you are real.
Re: memory leak in wsdisplay.c (during WSDISPLAY_LDFONT)
On Sun, 22 Mar 2015 23:45:49 +0100 (CET) Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sun, 22 Mar 2015 17:47:54 -0400 from: dan mclaughlin thev...@openmailbox.org On Sun, 22 Mar 2015 14:33:36 +0100 (CET) Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sun, 22 Mar 2015 04:30:54 -0400 from: dan mclaughlin thev...@openmailbox.org i think i found a memory leak in wsdisplay.c. when adding a font, wsfontload loads the font data into a buffer, and passes that thru the ioctl in a wsdisplay_font struct. in wsdisplay.c where the ioctl is handled, a new buffer of kernel memory is allocated and the data is then copied there, via copyin(). that kernel buffer replaces the original userland data in the original wsdisplay_font struct from wsfontload, which is then passed on to vga_load_font() in vga.c, and then again to vga_loadchars() where the data is copied onto the card. after that i don't see the kernel buffer being used. after calling vga_load_font, the only data structure pointing to it is the original wsdisplay_font struct allocated in wsfontload. There is no real memory leak. Loaded fonts simply stay loaded. The vga(4) driver might load the font onto the hardware, but rasops(4) for example doen't. But even with vga(4) the data needs to stay around such that you can reload the font onto the (for example after suspend/resume). i think that would be true if those functions were used, which they do not appear to be. just to be sure, i added some printf()s to wsfont_add() and recompiled, and they were not displayed. maybe this is an arch issue? i am using i386. The rasops code does call wsfont_add(). Not sure why the vga code doesn't do that. Perhaps miod@ can shed some light on this. If it is indeed inappropriate for the vga code to call wsfont_add(), then the vga code should probably free the font data. this may relate to the problem that led me here, and maybe the solution is for vga to store that data as well. this came about because i was upgrading my desktop from 4.0 to -current, and the newer s3virge driver didn't work (froze with blank screen on startup), didn't find anything online that helped and just wanted a working system so i changed to vesa. vesa has a different problem, that i was going to report to bugs@ after some more investigation to see if i could fix it, but i think that problem may indirectly relate to this. what happens is that when i run X, it garbled any fonts i have loaded via wsfontload. while X is running, if i switch to a screen using a loaded font, there are broken lines running thru the middle of where there should be text. when X exits, cells on the screen are either empty or full. if i reload the font, and switch to a running X, it garbles it again. my solution to this was to implement WSDISPLAY_DELFONT (as 'wsfontload -d N') to delete and then reload the font in a script, which has been working for me, even if it is an ugly solution. but i wonder, if instead the solution to that problem may be to reload the fonts after a switch, since i think vesa may be using that memory, and thus maybe the font data SHOULD be saved. maybe this vesa problem is unrelated, but if it is related it would have a bearing on the current issue. any advice is welcome. if there is something i can hunt down a pointer would help, or if i should just report this to bugs@. i also wanted to be sure i understood the code before i brought out my WSDISPLAY_DELFONT patches (pretty much a straight-forward reversal of WSDISPLAY_LDFONT). it's worked for me for over a month now.
OpenSSH: ssh protocol 1 now disabled at compile time
Hi, I just committed a change to src/usr.bin/ssh/Makefile.inc to compile- time disable SSH protocol 1. This protocol is old, unsafe and really, really shouldn't be used at all any more. If you have need of it, then you can re-enable it for yourself using the knob in Makefile.inc. If you run into bugs related to this change, please tell open...@openssh.com and we'll fix them quickly. We're deliberately doing this change early in the release cycle to flush out bugs and find out how many people are still using this terrible old protocol. -d
