Re: GPS hardware and TTYs
On 23.07.2019 16:16, Theo de Raadt wrote: > Todd C. Miller wrote: > > On Tue, 23 Jul 2019 13:42:28 -0600, Scott Seekamp wrote: > > I tested by: > > - unplugging the sensor > > - changing /etc/ttys > > - kill -HUP 1 > > - plugging sensor in and waiting 30 seconds > > - check sysctl output for data > You need to run "ttyflags ttyU0" instead of sending a HUP to init. > If the cua device works I would expect that setting the local flag > in /etc/ttys for ttyU0 would be sufficient. That is what I suspect also. But that doesn't seem right. Something is wrong. Internal cabling error? Thanks Todd and Theo (again!). I redid my tests using "ttyflags ttyU0" instead of HUP'ing init. Same response. I found a few other folks with what looks to be the same device putting the dial out device in as well so it does seem to be more than just my unit. The cable is non-removable on the device so there's not much to work with there. If anyone is curious the device I have is: https://www.ebay.com/itm/USB-GPS-Receiver-Module-Antenna-Output-USB-Global-4M-FLASH-1-5m-BN-82U-GLONASS/273794727010?hash=item3fbf6ffc62:g:kmIAAOSw4~1cp097 Chipset manufacturer: https://www.u-blox.com/en/product/ubx-m8030-series#tab-document-resources I can start the ldattach process outside of /etc/ttys so this isn't a critical issue, just a curiosity. Much appreciate the response and if there's other information I can provide please let me know. Thanks Scott
Re: SCM
The problem with tags/branches is on the input side (parsing RCS files), at least we haven't had good results with cvsps-based tooling or rcsparse-based. I don't think it will make much difference whether conversion is by way of svn or not (except there will be extra conversion-related artefacts going by way of svn). It could likely be fixed on a one off conversion by repo surgery, but as the master repo is unlikely to be switched (various reasons already mentioned in this thread), conversion would need to be on an ongoing basis without constant tweaks.. -- Sent from a phone, apologies for poor formatting. On 23 July 2019 19:42:24 Adam Thompson wrote: On 2019-07-23 12:43, Stuart Henderson wrote: On 2019-07-22, Stefan Sperling wrote: If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these. I haven't tried this with the OpenBSD code base, but in a previous life I did a CVS to Git conversion starting with a repo that resembled OpenBSD's in many ways. The "solution" was to get to git by way of SVN. SVN was able to preserve branches/tags/etc. from CVS into SVN, and was then able to in turn be converted to git through SVN's git-compatibility layer (IIRC). Whether this helps anyone out there... *shrug* -Adam
Re: GPS hardware and TTYs
Todd C. Miller wrote: > On Tue, 23 Jul 2019 13:42:28 -0600, Scott Seekamp wrote: > > > I tested by: > > > > - unplugging the sensor > > > > - changing /etc/ttys > > > > - kill -HUP 1 > > > > - plugging sensor in and waiting 30 seconds > > > > - check sysctl output for data > > You need to run "ttyflags ttyU0" instead of sending a HUP to init. > If the cua device works I would expect that setting the local flag > in /etc/ttys for ttyU0 would be sufficient. That is what I suspect also. But that doesn't seem right. Something is wrong. Internal cabling error?
Re: GPS hardware and TTYs
On Tue, 23 Jul 2019 13:42:28 -0600, Scott Seekamp wrote: > I tested by: > > - unplugging the sensor > > - changing /etc/ttys > > - kill -HUP 1 > > - plugging sensor in and waiting 30 seconds > > - check sysctl output for data You need to run "ttyflags ttyU0" instead of sending a HUP to init. If the cua device works I would expect that setting the local flag in /etc/ttys for ttyU0 would be sufficient. - todd
Re: GPS hardware and TTYs
On 23.07.2019 11:56, Theo de Raadt wrote: > Scott Seekamp wrote: > >> I purchased an inexpensive USB GPS receiver to test with time keeping on >> my OpenBSD 6.5 box. It's a "u-blox" supported by the nmea driver. >> >> Following the man pages for ldattach it says: >> >> "Specifies the name of the serial line. device should be a string of the >> form "cuaXX" or "/dev/cuaXX". >> >> cua(4) [1] devices should be used when ldattach is started from the >> command line; when started using init(8) [2], tty(4) [3] devices should >> be used." >> >> However, if I use ttyU0 as the device in /etc/ttys I never get the >> hw.sensors.nmea0 tree created. If I manually start ldattach with cuaU0 >> or put cuaU0 in /etc/ttys everything behaves as expected. > > There should never be cua devices in /etc/ttys, so something is curiously > wrong. > > Can you try playing with some of the following flags, and tell us > which ones work, from ttys(4): > > Additionally, the following flags modify the default behavior of the > terminal line. Some of these flags may not be supported by a terminal > line driver. The flag fields should not be quoted. > > localTreat the line as if it is locally connected. > > rtscts Use RTS/CTS hardware flow control, if possible. > > mdmbuf Use DTR/DCD flow control if possible. > > softcar Ignore hardware carrier on the line. > > Try all. Some of them will have similar effects. I tested by: - unplugging the sensor - changing /etc/ttys - kill -HUP 1 - plugging sensor in and waiting 30 seconds - check sysctl output for data No difference in behavior with any of the flags above. Dmesg output of the device is: umodem0 at uhub0 port 3 configuration 1 interface 0 "u-blox AG - www.u-blox.com u-blox GNSS receiver" rev 1.10/3.01 addr 3 umodem0: data interface 1, has CM over data, has no break umodem0: status change notification available ucom0 at umodem0 I know I'm not telling you anything you don't already know, but according to the ttys manpage: > Whereas the dial-in device (the tty) normally requires a hardware signal to > indicate to the system that it is active, the dial-out device (the cua) does > not, and hence can communicate unimpeded with a device such as a modem, or > with another system over a serial link. Is it possible the sensor doesn't behave properly to tell the system it's ready? Thanks for the help! Scott
Re: possible athn(4) bug in 6.5-current involving AR5418 chipset on used ThinkPad T60
On Tue, Jul 23, 2019 at 12:49:56PM -0400, Matthew Graybosch wrote: > On 7/11/19 5:57 AM, Stefan Sperling wrote: > > > Testing just bsd.rd is enough. If the bsd.rd environment is too limiting > > you could also install to a USB stick and boot from it for testing purposes. > > > > Either approach should suffice to test a wifi connection. > > Hi, Stefan. Sorry it took so long to get back to you, but I tried the > following releases by installing to USB over the last couple of weeks: > > * 6.4 > * 6.3 > * 6.2 > * 6.1 > * 6.0 > * 5.9 > * 5.8 > > Unfortunately, I didn't get better results with any of these. athn0 would > sporadically work when explicitly set up in 11g mode, but would usually just > balk with "athn0: Device Timeout". > > Sorry to have wasted your time on this. > > -- > Matthew Graybosch > Not at all! You've shown that this isn't a recent regression. If I had hardware to work with I could try to get it working. But I don't have any AR5418 devices. This commit make it look like problems with AR5418 were known a decade ago already and never quite fixed: CVSROOT:/cvs Module name:src Changes by: dam...@cvs.openbsd.org 2010/04/07 10:31:16 Modified files: sys/dev/ic : athn.c Log message: txq->lastds is only valid when txq is not empty. Check for emptiness of the TX queue instead of lastds != NULL. I have a feeling this might fix the "device timeout" issues reported by Rivo Nurges on his AR5418 unveiled by athn.c r1.28 commit, though he is not around to confirm. This is a candidate for -stable.
Re: SCM
On 2019-07-23 12:43, Stuart Henderson wrote: On 2019-07-22, Stefan Sperling wrote: If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these. I haven't tried this with the OpenBSD code base, but in a previous life I did a CVS to Git conversion starting with a repo that resembled OpenBSD's in many ways. The "solution" was to get to git by way of SVN. SVN was able to preserve branches/tags/etc. from CVS into SVN, and was then able to in turn be converted to git through SVN's git-compatibility layer (IIRC). Whether this helps anyone out there... *shrug* -Adam
Re: GPS hardware and TTYs
Scott Seekamp wrote: > I purchased an inexpensive USB GPS receiver to test with time keeping on > my OpenBSD 6.5 box. It's a "u-blox" supported by the nmea driver. > > Following the man pages for ldattach it says: > > "Specifies the name of the serial line. device should be a string of the > form "cuaXX" or "/dev/cuaXX". > > cua(4) [1] devices should be used when ldattach is started from the > command line; when started using init(8) [2], tty(4) [3] devices should > be used." > > However, if I use ttyU0 as the device in /etc/ttys I never get the > hw.sensors.nmea0 tree created. If I manually start ldattach with cuaU0 > or put cuaU0 in /etc/ttys everything behaves as expected. There should never be cua devices in /etc/ttys, so something is curiously wrong. Can you try playing with some of the following flags, and tell us which ones work, from ttys(4): Additionally, the following flags modify the default behavior of the terminal line. Some of these flags may not be supported by a terminal line driver. The flag fields should not be quoted. localTreat the line as if it is locally connected. rtscts Use RTS/CTS hardware flow control, if possible. mdmbuf Use DTR/DCD flow control if possible. softcar Ignore hardware carrier on the line. Try all. Some of them will have similar effects.
GPS hardware and TTYs
I purchased an inexpensive USB GPS receiver to test with time keeping on my OpenBSD 6.5 box. It's a "u-blox" supported by the nmea driver. Following the man pages for ldattach it says: "Specifies the name of the serial line. device should be a string of the form "cuaXX" or "/dev/cuaXX". cua(4) [1] devices should be used when ldattach is started from the command line; when started using init(8) [2], tty(4) [3] devices should be used." However, if I use ttyU0 as the device in /etc/ttys I never get the hw.sensors.nmea0 tree created. If I manually start ldattach with cuaU0 or put cuaU0 in /etc/ttys everything behaves as expected. Is this a documentation issue, hardware issue, something else? I have confirmed the same behavior on 2 servers (one current and one 6.5). Even with this hiccup the process has been incredibly easy and smooth. I'm constantly impressed with the work put into the OS and associated tools. Thanks Scott Links: -- [1] https://man.openbsd.org/cua.4 [2] https://man.openbsd.org/init.8 [3] https://man.openbsd.org/tty.4
Re: SCM
On 2019-07-22, Stefan Sperling wrote: > > If your university class prefers using git, I'd recommend the repository at > https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these.
Re: possible athn(4) bug in 6.5-current involving AR5418 chipset on used ThinkPad T60
On 7/11/19 5:57 AM, Stefan Sperling wrote: Testing just bsd.rd is enough. If the bsd.rd environment is too limiting you could also install to a USB stick and boot from it for testing purposes. Either approach should suffice to test a wifi connection. Hi, Stefan. Sorry it took so long to get back to you, but I tried the following releases by installing to USB over the last couple of weeks: * 6.4 * 6.3 * 6.2 * 6.1 * 6.0 * 5.9 * 5.8 Unfortunately, I didn't get better results with any of these. athn0 would sporadically work when explicitly set up in 11g mode, but would usually just balk with "athn0: Device Timeout". Sorry to have wasted your time on this. -- Matthew Graybosch
Re: Partition alignment on softraid crypto disks
wrote: > Hi list, > > It's often recommended to align partitions on 1M boundaries. False. disklabel has some mysterious heuristics, and that is what is recommended. When "recommendations" changes (which may be platform specific or because newer generations of disks show up), then the default heuristics will change. There is no need for manual calculation. > Is this the right thing to do or am I overthinking it? You are overthinking it.
Partition alignment on softraid crypto disks
Hi list, It's often recommended to align partitions on 1M boundaries. I was wondering what this means when creating partitions on softraid crypto disks. Let me give an example: Say we have a physical disk sd0 with 512B sectors. This disk contains a partition sd0a with an offset of 2048 which is a 1M boundary. We create the softraid crypto disk sd1 on sd0a. The first 528 sectors of sd0a are reserved for softraid metadata so sd1 has an offset of 2048+528 relative to sd0. So far so good. Now let's create partition sd1a. What offset should we give it? Should we take the 528 sectors of softraid metadata into account? In that case sd1a should have an offset of 2048-528=1520 relative to sd1 which results in an offset of 2048+528+1520=4096 relative to sd0 which is an 1M boundary as desired. Is this the right thing to do or am I overthinking it? Thanks! -Paul
Re: [iked] differentiating policies by dstid
Hello Tobias, thanks a lot, that solved the question for me (at least on the server :) ). Using ASN1 ids iked detects the matching policy. However, it then uses RFC7427 for auth (SIG), but the Windows 10 clients use RSA_SIG. This causes a mismatch and the connection can't be established. (Yet, Windows 10 is lacking support for aforementioned RFC). So, I have to find another way, but thank you very much. Best regards, Alex
Re: SCM
Den mån 22 juli 2019 kl 17:05 skrev Австин Ким : > Hi, > > As someone completely new to OpenBSD the one immediate first impression > that most peculiarly sticks out like a sore thumb to me is the Project’s > use of CVS for source code management. I am curious why the Project > continues to use CVS and/or if developers have in the past considered > migrating the codebase to a distributed SCM system like Mercurial which > IMHO might make branching and merging easier on developers, especially more > recent developers coming out of universities. Is it because the Project > prefers using a centralized versus distributed SCM system? Or is it just > because that’s just the way it has always been done and why change that? > And would migration to something like hg be a possibility in the future > that might possibly lower the psychological barrier of entry for newer > developers? (And btw this is meant as a sincere question with no intention > to start a contentious debate; really just asking out of curiosity because > seeing CVS diffs in the mailing lists was what visually jumped out most > prominently to me for the first time; I’m sure after spending more time > with OpenBSD it could be something I could just get used to.) > Thanks for all the wonderful responses to my previous post which really > helped me gain a better understanding of the Project! > As Nick Holland wrote here on the same topic: https://marc.info/?l=openbsd-misc&m=136724343006024&w=2 the last quote is kind of telling it all: --- Want to sell OpenBSD on an alternative? Find a product that was really crappy, switched development tools, and suddenly started rivaling OpenBSD for quality for no reason other than the switch of development tools. --- -- May the most significant bit of your life be positive.
