Re: Website - Missing kstat man page
On Sat, 2 Jan 2021 22:57:06 -0500, tiredtech wrote: > I came across a broken link during some pre-install research. > > While browsing URL https://www.openbsd.org/68.html, > I noticed URL link on the webpage for kstat(1) generates > a "No results found." message when pointing to its man page: > > https://man.openbsd.org/kstat > > Flagged as new, so I was curious about its general function. > > Regards > It looks like kstat isn't linked to the build so it's not built by default, therefore it's not present on the man.o.o server. The source is in src/usr.bin/kstat. If you don't have any src tree around, you can either read it on github [1] or you can fetch the raw version [2] and give it to mandoc(1) [1]: https://github.com/openbsd/src/blob/a09091e54b85e8cd86ccf4763998e3800065d5dc/usr.bin/kstat/kstat.1 [2]: https://raw.githubusercontent.com/openbsd/src/a09091e54b85e8cd86ccf4763998e3800065d5dc/usr.bin/kstat/kstat.1 (I could copy paste the resulting man page in this email, but you'd lose all the fancy markup :)) Actually, mandoc(1) supports html output, here's what it gives https://static.chown.me/private/misc/kstat.html Cheers, Daniel
Website - Missing kstat man page
I came across a broken link during some pre-install research. While browsing URL https://www.openbsd.org/68.html, I noticed URL link on the webpage for kstat(1) generates a "No results found." message when pointing to its man page: https://man.openbsd.org/kstat Flagged as new, so I was curious about its general function. Regards
ospf question
Hello list, I have a question regarding the use of ospf with OpenBSD 6.8. I have a network that consists of 23 OpenBSD 6.8 based routers (created, within a virtualbox environment on a GNU/Linux server, to match the physical network I manage - the only different being that the physical network consists of FreeBSD based routers rather than OpenBSD ones). I set this up after have replaced a FreeBSD based router with an OpenBSD based one in the real network and immediately experiencing an issue accessing parts of the network. Within my setup there is one router (router22) that is six hops away from the designated default gateway (which I'll call the firewall) and there are two paths (going different ways around the network) to get to it. I am able to run a traceroute to router22, but am not able to ping it or ssh onto it. If I ssh to the router connected to the firewall then I can ping and ssh to router22 (at that point it's only 5 hops away). If I reboot any router that lies within the path to router22 then I am subsequently able to ping and ssh router22 from the firewall. I have also subsequently duplicated the entire network again using FreeBSD 12.2 and the problem does not occur, so as far as I can see it's just an OpenBSD ospf issue. I first set this up after replacing a FreeBSD based router with an OpenBSD based one and experiencing another strange issue. In this instance the shortest path from my server network (accessible from router01) to router08, router11 and router12 was router01 <-> router13 <-> router21 <-> router08 <-> router11 <-> router12, when I put the OpenBSD router in as router13 I could no longer ping router08, router11 or router12 (though I could still ping router21). If I connected to a router in a different part of the network I was able to ping each of the inaccessible ones, so it was only when the OpenBSD based router was along the shortest path the issue manifested itself. Is anyone aware of incompatibilities between the OSPF implementation within OpenBSD and that provided by quagga on FreeBSD? Or of any limitations of OSPF on OpenBSD? In each setup I have the same hello and dead interval and have md5 crypt authentication in place on each link between routers. Each router is in area 0.0.0.0. regards, Mark
Make kernel recognize more Lynloong models
Hi,
The following patch will make kernel recognize Lynloong LM9002/9003 and
LM9013. I think LM9002/9003 is very similar to LM9001 since it works just
fine on my LM9002 with the codebase for LM9001. (Maybe they are just a
differnet batch of LM9001 for education market)
LM9013 on the other hand is fairly different from LM9001 and is more like
Yeeloong 8089 when it comes to hardware design. I might need to make a few
drivers for its IDE/USB interfaces in future for it to be fully
functional.
Index: sys/arch/loongson/loongson/machdep.c
===
RCS file: /cvs/src/sys/arch/loongson/loongson/machdep.c,v
retrieving revision 1.93
diff -u -r1.93 machdep.c
--- sys/arch/loongson/loongson/machdep.c17 Nov 2020 16:38:10 -
1.93
+++ sys/arch/loongson/loongson/machdep.c1 Jan 2021 11:43:42 -
@@ -207,6 +207,10 @@
{ "LM8101", &yeeloong_platform },
/* Lemote Lynloong all-in-one computer */
{ "LM9001", &lynloong_platform },
+ { "LM9002", &lynloong_platform },
+ { "LM9003", &lynloong_platform },
+ /* Lemote Lynloong all-in-one computer, Xueloong edition */
+ { "LM9013", &lynloong_platform },
#endif
#ifdef CPU_LOONGSON3
/* Laptops */
Re: Getting wifi bitrate
On Fri, Jan 01, 2021 at 02:13:43PM +, Björn Gohla wrote: > > [...] > >> I just want to show the network activity in my desktop status line. > > > > Understood, fair enough. > > The chosen Tx rate is not a very reliable indicator of actual throughput > > but it can serve as a wifi link quality indicator to some extent. > > >From ifconfig.c I gather that > > (nr->nr_rates[nr->nr_nrates - 1] & IEEE80211_RATE_VAL) / 2 > > is the current nominal rate in Mb/s, is that correct? > > Curiously, what I observe with the RTL8192EU is that after associating, > that value starts at 1 and as transmissions are made, moves to 54 in > increasing steps, and then stays there. I guess that corroborates your > point about incorrect information being returned by the device. That seems fine. The driver is adjusting the Tx rate up from 1 mbit to 54 mbit and then stays there since the Tx retry count is low enough even at 54 mbit. On devices which don't report anything you'd *always* see 54.
