USB mouse often not detected
Hi, When using a PS/2 mouse everything worked fine. I swapped it for a USB mouse, but this mouse isn't always detected while booting my (386-based) OpenBSD 5.8-stable system. Replugging the mouse when the system is running usually solves the problem: the mouse is detected and works fine. Sometimes this replugging needs to be done several times on different USB ports for it to have effect. Before sending this message I checked whether the mouse itself is the problem because it's a cheap one, so I tried other OSes (Debian Linux 8.2, NetBSD 7.0 and FreeBSD 10.2) and the problem was gone, so my mouse looks OK. Possibly the problem is in the combination of my hardware with OpenBSD. However I would like to use OpenBSD. :) Is this a known problem? I saw some people on this mailing list having trouble with USB mouses periodically reconnecting, but that's not my problem: most of the time it isn't detected at all. I'm sorry I can't send a dmesg right now. :) If needed I'll post one later. Have a nice day, Paco
Re: Will mmap and the read buffer cache be unified, anyone working with it?
On 2015-11-10 14:10, Tinker wrote: ... A "safe" approach to file access would be to read data using mmap() but write data using fwrite() only. Mmap does have a read-only mode. This does NOT work in OpenBSD currently though because of the absence of unified caching. The nice thing about reading files from memory using mmap instead of using fread(), is that you offload Lots of work to the OS kernel. Suddenly file reading is free of mallocs for instance. And the program doesn't need internal file caching, so the extent of the OS' disk caching is increased. And I guess maybe the OS disk cache can prioritize better what to keep in RAM. In a way, mmap() is a way to "zero-copy file access", which is just awesome. A database that uses this technique is LMDB (OpenLDAP's default DB backend). A key feature of LMDB is that it's only 9600 locs, https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c : LMDB is interesting in how lowlevel it is, as it's written in C and the "loaded" database entries are simply pointers into the mmap():ed space. I saw some fantastic-looking benchmarks, I think at http://symas.com/mdb/#bench , where LMDB goes light-speed where others remain on the ground. (LMDB has a limit in usability in that it never shrinks a DB file, however, that is in no way because of its use of mmap() and could really be overcome by working more on it. Also, LMDB serializes its DB writes, which also is an architecture decision specific to it and which has severe performance implications - and that is unspecific to mmap() also, and could be overcome.)
Re: Will mmap and the read buffer cache be unified, anyone working with it?
Just to clarify: Security: Neutral (it's all in-kernel, on the userland side it just simplifies code and is inherently security promoting as it just is a symmetry aspect) Will unifying it improve performance?: Yes, because programs with dynamic file sizes will be able to MMAP up to some point and then fread/fwrite beyond that one. (In contrast, having anticipatory 1TB mmap:s for all mmap:ed files doesn't make sense.) I think msync() is expensive, and unifying the buffer would remove the need for msync():s all over the place! Will it make the code simpler?: Userland code, yes, by indirectly encouraging mmap use. Details: SQLite has its mmap acceleration disabled on OpenBSD because the mmmap-based access not is symmetric with the fread/fwrite which it uses above the mmapped area and by default. A "safe" approach to file access would be to read data using mmap() but write data using fwrite() only. Mmap does have a read-only mode. This does NOT work in OpenBSD currently though because of the absence of unified caching. (Sorry for not providing a diff for this.) On 2015-11-10 13:36, Tinker wrote: Really, unifying the buffer cache would make all sense in the world. Also, *all* other major OS:es have done this already, so even just doing it for the sake of symmetry would make sense. I think I talked to someone who suggested that an attempt to unify had been done before, and that the NFS filesystem drivers had been what stopped it then, by some reason they were difficult. Perhaps that could be worked around afterall? On 2015-05-22 15:27, Tinker wrote: Hi, Will mmap and the read buffer cache be unified, anyone working with it? Some programs disable features on OBSD for this reason so would be nice! (I admit though that a program combining mmap() and read() on the same file sounds like a slightly quirky design choice to me.) Thanks! Tinker
Re: Will mmap and the read buffer cache be unified, anyone working with it?
>(Sorry for not providing a diff for this.) Aww come on, you had us going until then.
Re: Will mmap and the read buffer cache be unified, anyone working with it?
Really, unifying the buffer cache would make all sense in the world. Also, *all* other major OS:es have done this already, so even just doing it for the sake of symmetry would make sense. I think I talked to someone who suggested that an attempt to unify had been done before, and that the NFS filesystem drivers had been what stopped it then, by some reason they were difficult. Perhaps that could be worked around afterall? On 2015-05-22 15:27, Tinker wrote: Hi, Will mmap and the read buffer cache be unified, anyone working with it? Some programs disable features on OBSD for this reason so would be nice! (I admit though that a program combining mmap() and read() on the same file sounds like a slightly quirky design choice to me.) Thanks! Tinker
Re: Firewall rules and features
Ok , I agree, and thank you for the accurate answer. OTOH the server was rejecting all the other request, (i do not think it was badly configure) and it ended up rejecting the good one also (after a lng time of use) I first look in nsd manpages to see if i could figure why and found nothing ( a log like i reject packet because ...) I tried verbosity: 2, ratelimit: 1024 ( but nsd wasnt up to date - NSD version 3.2.5 ) I wanted to have a workaround, of course there is another authoritative to answer, therefore i ended up filtering content. If i run authoritative server can i filter to answer to only certain IP addresses ? Like a list of public/root DNS ? My next step was to look at dnssec, which would be nice to have anyway. On Mon, Nov 9, 2015 at 10:34 PM, Nick Holland wrote: > On 11/09/15 16:45, sven falempin wrote: > > For the first time ever i did something with iptable > > that i dont know how to do (simply) with > > pf. > > Something i think it is usefull. > > > > I have a domain server, nsd, it serves whatever.com, > > Authoritative server, then. > > > the server is like flooded with request for no reason, > > Welcome to the Internet. It happens. > > > with iptables i was able to add > > <-m string --hex-string whatever|03|com> > > in the rules. > > > > So i only accept DNS request that matters to me. > > > > Is there a way ? (something simpler than diverting to a > > sort of grep -v ). > > I'd call that a wrong way to do it, definitely. > > If your name server is configured properly, it should be ignoring domain > requests it isn't authoritative for. Not a problem. If you are running > a resolver, it should be resolving only for the IP addresses you manage > (here PF can help you, but the resolver can deal with that, too). > > > Would it be a cool feature ? or because it s a protocol shall > > it be done inside relayd ? > > No. String and pattern matching in the kernel is not a really good > plan. And if you are doing it in an application outside of the kernel, > why not just do it in NSD and be done with it? > > Nor is this solving a problem. Let NSD do its job correctly, and it > will just ignore those queries. DNS queries are really small, and > authoritative servers put very little load on the processor. The query > is going to get received, looked at, and either responded to or > dropped...adding extra layers here to change who receives and processes > the query isn't helping anything. In fact -- assuming NSD is fairly > efficient (I think it is), what I propose is this: > Packet comes in (kernel) > Packet is compared against domains served (NSD) > Response or drop (NSD) > > What you propose is this: > Packet comes in (kernel) > packet is compared against domains served (filter) > drop ... OR -> > packet is compared against domains served (AGAIN!) (NSD) > response (NSD) > > I don't think you win anything here by duplicating a step. > > OR if you want to be nasty, set up a full resolver that returns the IP > of some really nasty, rude or inappropriate site for ALL queries except > the ones that should be answering for. (actually, I don't recommend > doing this, but it made me grin to think about it. "Why do I keep > ending up on the My Little Pony website??"). Again, just because you > CAN do something doesn't make it a good idea. > > Nick. > > -- - () ascii ribbon campaign - against html e-mail /\
Re: Firewall rules and features
On 11/09/15 16:45, sven falempin wrote: > For the first time ever i did something with iptable > that i dont know how to do (simply) with > pf. > Something i think it is usefull. > > I have a domain server, nsd, it serves whatever.com, Authoritative server, then. > the server is like flooded with request for no reason, Welcome to the Internet. It happens. > with iptables i was able to add > <-m string --hex-string whatever|03|com> > in the rules. > > So i only accept DNS request that matters to me. > > Is there a way ? (something simpler than diverting to a > sort of grep -v ). I'd call that a wrong way to do it, definitely. If your name server is configured properly, it should be ignoring domain requests it isn't authoritative for. Not a problem. If you are running a resolver, it should be resolving only for the IP addresses you manage (here PF can help you, but the resolver can deal with that, too). > Would it be a cool feature ? or because it s a protocol shall > it be done inside relayd ? No. String and pattern matching in the kernel is not a really good plan. And if you are doing it in an application outside of the kernel, why not just do it in NSD and be done with it? Nor is this solving a problem. Let NSD do its job correctly, and it will just ignore those queries. DNS queries are really small, and authoritative servers put very little load on the processor. The query is going to get received, looked at, and either responded to or dropped...adding extra layers here to change who receives and processes the query isn't helping anything. In fact -- assuming NSD is fairly efficient (I think it is), what I propose is this: Packet comes in (kernel) Packet is compared against domains served (NSD) Response or drop (NSD) What you propose is this: Packet comes in (kernel) packet is compared against domains served (filter) drop ... OR -> packet is compared against domains served (AGAIN!) (NSD) response (NSD) I don't think you win anything here by duplicating a step. OR if you want to be nasty, set up a full resolver that returns the IP of some really nasty, rude or inappropriate site for ALL queries except the ones that should be answering for. (actually, I don't recommend doing this, but it made me grin to think about it. "Why do I keep ending up on the My Little Pony website??"). Again, just because you CAN do something doesn't make it a good idea. Nick.
Re: Firewall rules and features
Thank you Pedro fot http://ftp.openbsd.org/pub/OpenBSD/5.8/packages/amd64/dnsfilter-0.4p0.tgz I am not sure this is as good as it could be, according to the mail there is room for improvement. Worth a test , and it s better to improve than to add up yet another small program, i wonder how good is the libdns compared to other. Best regards, On Mon, Nov 9, 2015 at 6:38 PM, Pedro Caetano wrote: > Hi, > > I guess one could use pf's divert-to and dnsfilter. > > http://marc.info/?l=openbsd-misc&m=134187877220567&w=2 > > Regards, > Pedro Caetano > > On Mon, Nov 9, 2015 at 9:45 PM, sven falempin > wrote: > >> For the first time ever i did something with iptable >> that i dont know how to do (simply) with >> pf. >> Something i think it is usefull. >> >> I have a domain server, nsd, it serves whatever.com, >> the server is like flooded with request for no reason, >> >> with iptables i was able to add >> <-m string --hex-string whatever|03|com> >> in the rules. >> >> So i only accept DNS request that matters to me. >> >> Is there a way ? (something simpler than diverting to a >> sort of grep -v ). >> >> Would it be a cool feature ? or because it s a protocol shall >> it be done inside relayd ? >> >> Best regards. >> >> -- >> >> - >> () ascii ribbon campaign - against html e-mail >> /\ >> >> > -- - () ascii ribbon campaign - against html e-mail /\
Re: Firewall rules and features
Hi, I guess one could use pf's divert-to and dnsfilter. http://marc.info/?l=openbsd-misc&m=134187877220567&w=2 Regards, Pedro Caetano On Mon, Nov 9, 2015 at 9:45 PM, sven falempin wrote: > For the first time ever i did something with iptable > that i dont know how to do (simply) with > pf. > Something i think it is usefull. > > I have a domain server, nsd, it serves whatever.com, > the server is like flooded with request for no reason, > > with iptables i was able to add > <-m string --hex-string whatever|03|com> > in the rules. > > So i only accept DNS request that matters to me. > > Is there a way ? (something simpler than diverting to a > sort of grep -v ). > > Would it be a cool feature ? or because it s a protocol shall > it be done inside relayd ? > > Best regards. > > -- > > - > () ascii ribbon campaign - against html e-mail > /\
Re: Current status of Enlightenment on OpenBSD
Just a quick update: the mouse pointer problem was caused by wsmoused being activated. Stopping the daemon solves the problem in X. The problem was also present with fvwm, just didn't try it with wsmoused active before. E17, instead, often freezes while normal operation. On Mon, Nov 9, 2015 at 9:47 PM, Paolo Aglialoro wrote: > Hi all, > > I was asking myself, after uslessly querying the internet for something > recent (2015/2014), if there is somebody in the list using E17 on their > OpenBSD boxen. In particular I have these questions: > > - does your mouse pointer move? after startx mine from trackpad does not, > neither with an external mouse, while either on CLI or with stock wm moves > perfectly; also added the ibus config lines to .xinitrc as prescripted by > /usr/local/share/doc/pkg-readmes/ibus-1.5.5p2 > > - in the initial config menu are you offered with language options other > than "System Default"? > > - why in the packages are there two versions of Enlightenment? One is E17, > and the other older and smaller one reports a 1.0.9p4 version, maybe it's a > relic of E16, what for? > > - right now on Enlightenment page the currently reported version of the > whole DM is 0.19.2, is anybody taking care of it? Is E17 instead the last > thing one can run because the are no plans for 0.19.2? > > - 0.19.2 brings in some interesting side-software like Terminology, Rage > etc. has anybody tried to port them? > > Thanks
Firewall rules and features
For the first time ever i did something with iptable that i dont know how to do (simply) with pf. Something i think it is usefull. I have a domain server, nsd, it serves whatever.com, the server is like flooded with request for no reason, with iptables i was able to add <-m string --hex-string whatever|03|com> in the rules. So i only accept DNS request that matters to me. Is there a way ? (something simpler than diverting to a sort of grep -v ). Would it be a cool feature ? or because it s a protocol shall it be done inside relayd ? Best regards. -- - () ascii ribbon campaign - against html e-mail /\
Re: rtadvd not picking up dynamic ranges automatically anymore
Thanks Giancarlo, I appreciate the recommendation to use ifstated. I'd used it in the past years for something at a job I was working at that I cannot remember what it was now, but it worked good. I do however understand the importance of reporting any regression as soon as it is noticed, but I have to admit the first time I noticed it, I wasn't sure if it was a one off incident and back then where I lived my cable service was regrettably more reliable than it is now (the crap shoot that is moving). Now that my service goes out more often and/or I've needed to restart my firewall or certain services to debug other issues, I've seen the issue arise enough to confirm that there is indeed an issue with rtadvd. In once case, a simple reboot caused rtadvd to come up before the prefix was assigned via my DHCPv6 client. rtadvd did not pickup the prefix dynamically and was refusing to advertise it until I restarted it. In another case, the same DHCPv6 client was restarted, and I forgot to restart rtadvd and the internal interface had it's old prefix removed and and new one added. rtadvd continued advertising the old prefix which was now unroutable. It neither was able to detect that the old prefix was removed and retire it in it's RAs, nor detect that a new prefix was added and start advertising it. I pulled up the man page for it just to confirm that the previous behavior of being able to auto detect prefixes assigned to the monitored interface was normal behavior. I came to that conclusion because there is a flag ( -s ) you can use to call rtadvd with to prevent it from dynamically advertising prefixes and only use statically setup prefixes (presumably from the config file, of which I have no need of currently). I am willing to file a bug report even if it's a little late. What do I need to do to help out. I don't know much C/C++ but I can help wherever possible. And many thanks to both of you Giancarlo and Martin for replying. I understand that IPv6 is not yet very popular or used yet, so that functionality of OpenBSD isn't likely to get much attention. Therefore I don't mind helping to debug this issue any way I can. Btw, I confirmed that rtadvd had no knowledge of the changes to the prefixes assigned to the monitored interface by doing as the man page suggests and sending a SIGUSR1 to the pid and saw the output in /var/log/daemon where it was showing outdated prefix information. If I were to best guess it, it stopped working sometime in 2014 (I was still living at my old residence where I had much more stable service). I usually update within a month of release, so that would mean it stopped working in either 5.5 or 5.6 as it was not working in 5.7 and is still not working in 5.8. Sly On 11/09/2015 11:21 AM, Giancarlo Razzolini wrote: > Em 09-11-2015 13:52, Martin Pieuchot escreveu: >> As soon as you notice a regression please try to notify us. I'm sorry >> to say so, but we don't have the manpower to dig for a regression that >> might have happen since "a couple of releases". > I know Martin. For me it is not a regression, because I only recently, > ie, OpenBSD 5.8, started using it with IPv6 enabled CPE's. I'm working > on a very detailed bug report, I think I found a routing bug regarding > IPv6, I'll test on -current later this week. As soon as I have all the > info, I'll post to tech@. What I can talk right now is that, on OpenBSD > 5.8-stable, if you have a interface with inet6 autoconf enabled, you > aren't able to use manual configuration on any other interface (ULA > addressing). The routes simply vanish right after they are added. I > confirmed this behaviour with route monitor. > >> One of the reason we ask for a dmesg is that we can easily identify when >> things broke. We try the best we can not to break things, but sometimes >> it is hard. Sorry for that. > I was just confirming to the OP that I too had seen this behaviour. > Every time I've stumbled upon what I suspect might be a regression or a > bug I try to make sure before I report, but I always report them. So far > this happened only once on OpenBSD. > >> Now if you prefer to cook your own workaround, that's up to you > I don't like to cook workarounds, but sometimes they are necessary. In > my case I need to monitor changes so I can update DNS records, I was > just extending that so the OP could do another thing (restart rtadvd). I > don't know anything that could be done in my case, since my ISP and CPE > will change the prefix anytime the CPE restarts or the CPE connection to > the ISP is lost. > > Cheers, > Giancarlo Razzolini
Current status of Enlightenment on OpenBSD
Hi all, I was asking myself, after uslessly querying the internet for something recent (2015/2014), if there is somebody in the list using E17 on their OpenBSD boxen. In particular I have these questions: - does your mouse pointer move? after startx mine from trackpad does not, neither with an external mouse, while either on CLI or with stock wm moves perfectly; also added the ibus config lines to .xinitrc as prescripted by /usr/local/share/doc/pkg-readmes/ibus-1.5.5p2 - in the initial config menu are you offered with language options other than "System Default"? - why in the packages are there two versions of Enlightenment? One is E17, and the other older and smaller one reports a 1.0.9p4 version, maybe it's a relic of E16, what for? - right now on Enlightenment page the currently reported version of the whole DM is 0.19.2, is anybody taking care of it? Is E17 instead the last thing one can run because the are no plans for 0.19.2? - 0.19.2 brings in some interesting side-software like Terminology, Rage etc. has anybody tried to port them? Thanks
return qemu.img to real partition
i follow current of openbsd on Linux's kvm of ext2_fs . and return this qemu image to openbsd partition by tar over ssh . ( http://openbsd-akita.blogspot.jp/2015/11/export-kvms-image-to-real-machine.html ) but i hear there is qemu-nbd in Linux. i try it . # modprobe nbd max_part=8 # qemu-nbd --connect=/dev/nbd0 /mnt/sda3/home/yuma/TC-5.img # mount /dev/nbd0p1 /mnt/kvm # ls /mnt/kvm lost+found mydata.tgz tce COPY sudo umount /mnt/kvm sudo qemu-nbd --disconnect /dev/nbd0 this is very convinient . i hope openbsd's qemu-nbd come true . --- regards
Re: installboot with amd64 root on softraid crypto, NOT 'a' partition
> On Sun, 8 Nov 2015 21:22:04 -0800 > Nathan Wheeler wrote: > > I ran into this exact same issue when I was trying to create a > > rollback install with CRYPTO for a sort of appliance I develop/manage > > for my company. We only have remote access with console and remote > > hands aren't easy to get so when upgrading it'd be nice to have a > > rollback in case something happens. > > > > You can definitely boot a kernel off a different partition, but the > > kernel still assumes the root disk is 'a'. You have to tell the kernel > > to ask you for the root partition with "boot -a". Or you can compile > > your own kernel with the root disk hardcoded as it mentions in this > > post: http://www.undeadly.org/cgi?action=article&sid=20110530221728 > > Isn't a story of the kernel configuration file? > It doesn't seem 'a' is hard coded (cannot change) since actually -a > can override that value. People should be careful what they ask for: - The entropy file - /etc/boot.conf I think this is a clear case of (1) don't waste timet explaining why it is the way it is, (2) no warranty, (3) people who wish to hurt themselves can go into the kitchen, (4) people who run into problems are asked to not submit bug reports from their frankenstein machines.
Re: installboot with amd64 root on softraid crypto, NOT 'a' partition
On Sun, 8 Nov 2015 21:22:04 -0800 Nathan Wheeler wrote: > I ran into this exact same issue when I was trying to create a > rollback install with CRYPTO for a sort of appliance I develop/manage > for my company. We only have remote access with console and remote > hands aren't easy to get so when upgrading it'd be nice to have a > rollback in case something happens. > > You can definitely boot a kernel off a different partition, but the > kernel still assumes the root disk is 'a'. You have to tell the kernel > to ask you for the root partition with "boot -a". Or you can compile > your own kernel with the root disk hardcoded as it mentions in this > post: http://www.undeadly.org/cgi?action=article&sid=20110530221728 Isn't a story of the kernel configuration file? It doesn't seem 'a' is hard coded (cannot change) since actually -a can override that value. > But I've come to the same conclusion that most people would say on > this list that its just not a good idea. I definitely don't plan to > put that practice in production. But if its just a personal use > laptop, maybe it'll be OK, up to you. I understand that story. I'm not complaining but just wondering why "boot hd0j:/bsd" works but "boot sr0j:/bsd" doesn't work. --yasuoka
Re: rtadvd not picking up dynamic ranges automatically anymore
Em 09-11-2015 13:52, Martin Pieuchot escreveu: > As soon as you notice a regression please try to notify us. I'm sorry > to say so, but we don't have the manpower to dig for a regression that > might have happen since "a couple of releases". I know Martin. For me it is not a regression, because I only recently, ie, OpenBSD 5.8, started using it with IPv6 enabled CPE's. I'm working on a very detailed bug report, I think I found a routing bug regarding IPv6, I'll test on -current later this week. As soon as I have all the info, I'll post to tech@. What I can talk right now is that, on OpenBSD 5.8-stable, if you have a interface with inet6 autoconf enabled, you aren't able to use manual configuration on any other interface (ULA addressing). The routes simply vanish right after they are added. I confirmed this behaviour with route monitor. > > One of the reason we ask for a dmesg is that we can easily identify when > things broke. We try the best we can not to break things, but sometimes > it is hard. Sorry for that. I was just confirming to the OP that I too had seen this behaviour. Every time I've stumbled upon what I suspect might be a regression or a bug I try to make sure before I report, but I always report them. So far this happened only once on OpenBSD. > > Now if you prefer to cook your own workaround, that's up to you I don't like to cook workarounds, but sometimes they are necessary. In my case I need to monitor changes so I can update DNS records, I was just extending that so the OP could do another thing (restart rtadvd). I don't know anything that could be done in my case, since my ISP and CPE will change the prefix anytime the CPE restarts or the CPE connection to the ISP is lost. Cheers, Giancarlo Razzolini
Re: rtadvd not picking up dynamic ranges automatically anymore
On 09/11/15(Mon) 13:11, Giancarlo Razzolini wrote: > Em 09-11-2015 12:45, Sly Midnight escreveu: > > [...] > > This was not a big deal as rtadvd would simply see the new prefix on my > > internal interface and start sending out RA's with that prefix. And > > naturally my internal clients would automatically reconfigure themselves. > > > > Now I've noticed for a couple releases or more rtadvd does not notice a > > change of the available prefixes assigned to the interface it both > > monitors and advertises on. I have not changed my config for it, as I > > just run it without a configuration file invoking it's default behavior > > (since I cannot know what my IPv6 prefix will be ahead of time). > > I noticed this same behaviour. I devised two solutions, one is to use > ifstated to monitor link changes and restart rtadvd accordingly and the > other is to use ULA on the internal network. As soon as you notice a regression please try to notify us. I'm sorry to say so, but we don't have the manpower to dig for a regression that might have happen since "a couple of releases". One of the reason we ask for a dmesg is that we can easily identify when things broke. We try the best we can not to break things, but sometimes it is hard. Sorry for that. Now if you prefer to cook your own workaround, that's up to you ;) Cheers, Martin
Re: rtadvd not picking up dynamic ranges automatically anymore
Em 09-11-2015 12:45, Sly Midnight escreveu: > I am writing the misc@openbsd.org thread to see if anyone else with IPv6 > experience on OpenBSD has noticed this behavior with the rtadvd daemon. I did. > > I have been using OpenBSD as my firewall now for just under 4 years > (prior to that I used FreeBSD). When I first started using it I used > HE.net's tunnelbroker service to provision my internal network with an > IPv6 subnet with my firewall being the routing endpoint. I've used sixxs. > > This worked well with the rtadvd daemon even without a config, because > it was a static tunnel where the prefix of the subnet was always the > same (unless I manually did something to change it myself). The prefix sixxs give you is also static, so, rtadvd can be run without a config and everything just works. > > However sometime in late 2012 I was able to start taking advantage of > the native IPv6 of my ISP (Comcast), when I was troubleshooting some > other setup a tcpdump showed IPv6 was finally live in my area. After > going through the trouble of finding a way to make it work with a > combination of RA's (Router Advertisements) and DHCPv6, I was able to > get myself directly on my ISP's IPv6 connection. I still employed > rtadvd for provisioning IPv6 internally on my internal subnet. > > The only thing I noticed was that unlike my static IPv6 tunnel, the IPv6 > service from my ISP would change the subnet prefix almost any time the > DHCPv6 client was restarted or at a minimum the firewall was rebooted > (like when a new version of OpenBSD was released and I upgraded in place). Same here. My prefix changes every time my CPE is restarted, or the connection is lost. It stays stable across my OpenBSD firewall reboots though, since my CPE is a router and I'm not using pppoe. > > This was not a big deal as rtadvd would simply see the new prefix on my > internal interface and start sending out RA's with that prefix. And > naturally my internal clients would automatically reconfigure themselves. > > Now I've noticed for a couple releases or more rtadvd does not notice a > change of the available prefixes assigned to the interface it both > monitors and advertises on. I have not changed my config for it, as I > just run it without a configuration file invoking it's default behavior > (since I cannot know what my IPv6 prefix will be ahead of time). I noticed this same behaviour. I devised two solutions, one is to use ifstated to monitor link changes and restart rtadvd accordingly and the other is to use ULA on the internal network. > > Any idea if this was an intentional change to rtadvd or is this a bug > I've run into? I know it used to work that way. I don't know, but things have been changing fast on the IPv6 OpenBSD world. There are some things which didn't made in time for 5.8 that might help you, if you're willing to run -current. These days I prefer using ULA and making nat, so I can assure my internal address space will never change. Cheers, Giancarlo Razzolini
rtadvd not picking up dynamic ranges automatically anymore
Good Morning. I am writing the misc@openbsd.org thread to see if anyone else with IPv6 experience on OpenBSD has noticed this behavior with the rtadvd daemon. I have been using OpenBSD as my firewall now for just under 4 years (prior to that I used FreeBSD). When I first started using it I used HE.net's tunnelbroker service to provision my internal network with an IPv6 subnet with my firewall being the routing endpoint. This worked well with the rtadvd daemon even without a config, because it was a static tunnel where the prefix of the subnet was always the same (unless I manually did something to change it myself). However sometime in late 2012 I was able to start taking advantage of the native IPv6 of my ISP (Comcast), when I was troubleshooting some other setup a tcpdump showed IPv6 was finally live in my area. After going through the trouble of finding a way to make it work with a combination of RA's (Router Advertisements) and DHCPv6, I was able to get myself directly on my ISP's IPv6 connection. I still employed rtadvd for provisioning IPv6 internally on my internal subnet. The only thing I noticed was that unlike my static IPv6 tunnel, the IPv6 service from my ISP would change the subnet prefix almost any time the DHCPv6 client was restarted or at a minimum the firewall was rebooted (like when a new version of OpenBSD was released and I upgraded in place). This was not a big deal as rtadvd would simply see the new prefix on my internal interface and start sending out RA's with that prefix. And naturally my internal clients would automatically reconfigure themselves. Now I've noticed for a couple releases or more rtadvd does not notice a change of the available prefixes assigned to the interface it both monitors and advertises on. I have not changed my config for it, as I just run it without a configuration file invoking it's default behavior (since I cannot know what my IPv6 prefix will be ahead of time). Any idea if this was an intentional change to rtadvd or is this a bug I've run into? I know it used to work that way. Sly
Re: LC_COLLATE
In the meantime i managed it to compile Postgresql with icu-support. Though Postgresql is still not able to *create* a database with "de_DE.UTF"-collation. So the icu-workaround is useless for database-creation with other lc_collations. So much ado about nothing ... -- View this message in context: http://openbsd-archive.7691.n7.nabble.com/LC-COLLATE-tp282248p282412.html Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: upd(4) wrong reads
ping On 11/04/15 11:44, Martijn van Duren wrote: Hello misc@, I've installed a UPS (eaton ellipse 600) at a customer of mine, which attaches as a upd(4) device without problems. When monitoring this device with sensorsd it sporadically sends out emails about power problems, even when there are no problems at that moment location. When taking a closer look at the logs it appears that sensorsd regularly reads wrong data from the device. Is there a way to detect whether this issue is in the UPS or with the driver? I've placed an extra check on indicator0 with the shutdown command, so there haven't been any untimely shutdowns yet, but it might be just a matter of star and moon alignment before both percent0 and indicator0 are read wrong simultaniously. Sincerely, Martijn van Duren $ sysctl hw.sensors.upd0 hw.sensors.upd0.indicator0=On (Charging), OK hw.sensors.upd0.indicator1=Off (Discharging), OK hw.sensors.upd0.indicator2=Off (NeedReplacement), OK hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK hw.sensors.upd0.indicator4=On (ACPresent), OK hw.sensors.upd0.indicator5=Off (Overload), OK hw.sensors.upd0.percent0=100.00% (RemainingCapacity), OK hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK hw.sensors.upd0.timedelta0=0.00 secs (RunTimeToEmpty), OK $ zgrep sensorsd /var/log/daemon* /var/log/daemon:Nov 4 07:00:20 server sensorsd[5]: upd0.percent0: within limits: 100.00% /var/log/daemon:Nov 4 08:58:24 server sensorsd[5]: upd0.percent0: exceeds limits: 19.00% is below 20.00% /var/log/daemon:Nov 4 08:58:44 server sensorsd[5]: upd0.percent0: within limits: 100.00% /var/log/daemon:Nov 4 09:31:37 server sensorsd[1790]: startup, system has 40 sensors /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.indicator0: On, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.indicator1: Off, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.indicator2: Off, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.indicator3: Off, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.indicator4: On, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.indicator5: Off, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.percent0: 100.00%, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.percent0: within limits: 100.00% /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.percent1: 100.00%, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: upd0.timedelta0: 0.00 secs, OK /var/log/daemon:Nov 4 09:31:52 server sensorsd[10211]: softraid0.drive0: online, OK /var/log/daemon:Nov 4 09:32:31 server sensorsd[15990]: startup, system has 40 sensors /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.indicator0: On, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.indicator1: Off, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.indicator2: Off, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.indicator3: Off, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.indicator4: On, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.indicator5: Off, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.percent0: 100.00%, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.percent0: within limits: 100.00% /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.percent1: 100.00%, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: upd0.timedelta0: 0.00 secs, OK /var/log/daemon:Nov 4 09:32:46 server sensorsd[15230]: softraid0.drive0: online, OK /var/log/daemon.0.gz:Nov 3 21:47:35 server sensorsd[5]: upd0.percent0: exceeds limits: 19.00% is below 20.00% /var/log/daemon.0.gz:Nov 3 21:47:55 server sensorsd[5]: upd0.percent0: within limits: 100.00% /var/log/daemon.0.gz:Nov 3 22:48:57 server sensorsd[5]: upd0.indicator0: On, UNKNOWN /var/log/daemon.0.gz:Nov 3 22:48:57 server sensorsd[5]: upd0.indicator1: Off, UNKNOWN /var/log/daemon.0.gz:Nov 3 22:48:57 server sensorsd[5]: upd0.indicator2: Off, UNKNOWN /var/log/daemon.0.gz:Nov 3 22:48:57 server sensorsd[5]: upd0.indicator3: Off, UNKNOWN /var/log/daemon.0.gz:Nov 3 22:48:57 server sensorsd[5]: upd0.indicator4: On, UNKNOWN /var/log/daemon.0.gz:Nov 3 22:48:57 server sensorsd[5]: upd0.indicator5: Off, UNKNOWN /var/log/daemon.0.gz:Nov 3 22:49:17 server sensorsd[5]: upd0.indicator0: On, OK /var/log/daemon.0.gz:Nov 3 22:49:17 server sensorsd[5]: upd0.indicator1: Off, OK /var/log/daemon.0.gz:Nov 3 22:49:17 server sensorsd[5]: upd0.indicator2: Off, OK /var/log/daemon.0.gz:Nov 3 22:49:17 server sensorsd[5]: upd0.indicator3: Off, OK /var/log/daemon.0.gz:Nov 3 22:49:17 server sensorsd[5]: upd0.indicator4: On, OK /var/log/daemon.0.gz:Nov 3 22:49:17 server sensorsd[5]: upd0.indicator5: Off, OK /var/log/daemon.0.gz:Nov 3 23:49:24 server sensorsd[5]: upd0.percent0: exceeds limits: 19.00% is below 20.00% /var/log/daemon.0.gz:Nov 3 23:49:44 server se
