Re: dhcpleased(8) not renewing leases
On Freitag, 5. November 2021 16:33:11 -03 Sebastian Benoit wrote: > Eike Lantzsch ZP6CGE(zp6...@gmx.net) on 2021.11.04 18:07:57 -0300: > > On Mittwoch, 3. November 2021 14:41:08 -03 Zack Newman wrote: > > > dhcpleased(8) is unable to renew DHCP leases from my ISP, > > > Xfinity/Comcast. This in turn is causing leases to expire leading > > > to > > > IPv4 drops that last between 15 and 20 seconds until a new lease > > > can > > > be binded. Note that lease binding does succeed. > > > > Hi Zack, > > Similarily here. Did you specify a lladdr in your hostname.if after > > "dhcp"? > > I get a lease with my hardware MAC address without specifying > > lladdr, > > but it is not the right one of course. If I force the fake MAC > > address and then I ask for a new lease I get nothing. > > I'm going to write about it later together with all the pertinent > > infomation. Just now I am too busy with other disasters. > > please include tcpdump of both the non-working attempts and the > working attempts (if it is indeed successful with dhclient), with a > command like this: > > tcpdump -enlp -i iwm0 port 67 and port 68 > > Also include your hostname.if file and dhclient.conf and > dhcpleased.conf if any. > Thank you Sebastian! Will do as soon as possible. But I think I ought to open a new thread as my problem does not seem to be related to Zack's. All the best 2 U Eike > > Cheers > > Eike > > > > > For about a month before the release of OpenBSD 7.0, I had been > > > using > > > dhcpleased(8) instead of dhclient(8) on OpenBSD 6.9 as I wanted to > > > be > > > "ahead of the curve" before the eventual release of OpenBSD 7.0. > > > During that time, there were no problems with lease renewals. I > > > have > > > not made any hardware or software changes other than the upgrade > > > to > > > 7.0. > > > > > > I've factory reset my bridge modem about a dozen times, I've > > > changed > > > the MAC address of the interface connected to the modem, I've > > > experimented using different NICs altogether, and nothing has > > > worked. > > > At the time, I "knew" it was Xfinity; so I demanded that a tech > > > come > > > over and inspect the cable lines and modem. They said it was fine; > > > although based on Internet reviews, that doesn't say much as they > > > are > > > often wrong. It wasn't until I had a slice of humble pie and > > > actually > > > considered that the problem was indeed my router that I was able > > > to > > > fix the problem by switching to dhcpcd which I have been already > > > using for DHCPv6. Sure enough, I have had no issues with IPv4 > > > renewals since then. > > > > > > I do know that Xfinity, at least where I am, does NOT respond to > > > unicast renewals for both DHCP and DHCPv6, but I am unsure if that > > > is > > > relevant. Before I successfully switched to dhcpcd, I made sure to > > > > > log dhcpleased(8) over night. Here are the results: > > [snip]
Re: Accounts Updates
On Fri, Nov 05, 2021 at 05:09:07PM +0300, Vitaliy Makkoveev wrote: > Yeah, don't forget to include both sides photos of your credit > cards. And the output from dmesg, please ;-). > > > On 5 Nov 2021, at 16:57, Sven F. wrote: > > > > zeitzone ? > > > > -- Forwarded message - > > From: source-changes > > Date: Fri, Nov 5, 2021 at 9:00 AM > > Subject: Accounts Updates > > To: > > > > > > Verify account > > > > Your account has been listed > > > > source-changes > > > > Sign-in details > > > > > > Email : source-chan...@openbsd.org > > > > Date: 11/5/2021 6:53:26 a.m. > > > > > > All openbsd.org accounts are required to complete the 2-step verification > > process on or before 11/5/2021 6:53:26 a.m. to avoid email suspension. > > Your account has been listed for suspension today if not verified. > > > > Complete process > > > > > > Thanks, > > > > The openbsd.org account team > > > > > > -- > > -- > > - > > Knowing is not enough; we must apply. Willing is not enough; we must do >
Re: Installation partitioning: core dump and /var size
On Fri, Nov 05, 2021 at 11:15:13AM +0200, u...@mailo.com wrote: > Also asked on: > https://unix.stackexchange.com/questions/676245/openbsd-core-dump-and-var-size > > I'm trying to figure out my partitioning which leads to > https://man.openbsd.org/disklabel#AUTOMATIC_DISK_ALLOCATION > which says: > > "/var13% of disk. 80M – 2x size of crash dump" > > But how do I know the size of crash dump? The point of auto-allocation is that this computation is done for you. But a crash dump is roughly the size of your physcial mem. Actually the max for /var is 4G *plus* 2x physical mem. So the table in the man page is not completely right. -Otto > I can't find it neither in OpenBSD's installation guide, nor in > https://man.openbsd.org/savecore.8 > nor in the internet at large. > > The only clue I've found is in > http://man.openbsd.org/man8/crash.8 > "the system dumps the contents of physical memory > onto a mass storage peripheral device" > > "physical memory". > So do rules of estimating swap partition size apply here as well? > > May I ask for some actual numbers/functions/tables? > Perhaps similar to the table in > https://askubuntu.com/a/49138 > answer on swap size: > > Amount of RAMSwap space Swap space > in the systemif allowing for hibernation > -- -- --- > ≤ 2 GB 2x RAM 3x RAM > > 2 GB – 8 GB= RAM 2x RAM > > 8 GB – 64 GB ≥ 4 GB 1.5x RAM > > 64 GB ≥ 4 GB Hibernation not recommended > > I am an ordinary user who is not going to test OpenBSD for crashiness > but to just run it the more stable the better > but for the possibility of a crash be able to report it. > >
Re: dhcpleased(8) not renewing leases
Eike Lantzsch ZP6CGE(zp6...@gmx.net) on 2021.11.04 18:07:57 -0300: > On Mittwoch, 3. November 2021 14:41:08 -03 Zack Newman wrote: > > dhcpleased(8) is unable to renew DHCP leases from my ISP, > > Xfinity/Comcast. This in turn is causing leases to expire leading to > > IPv4 drops that last between 15 and 20 seconds until a new lease can > > be binded. Note that lease binding does succeed. > Hi Zack, > Similarily here. Did you specify a lladdr in your hostname.if after > "dhcp"? > I get a lease with my hardware MAC address without specifying lladdr, > but it is not the right one of course. If I force the fake MAC address > and then I ask for a new lease I get nothing. > I'm going to write about it later together with all the pertinent > infomation. Just now I am too busy with other disasters. please include tcpdump of both the non-working attempts and the working attempts (if it is indeed successful with dhclient), with a command like this: tcpdump -enlp -i iwm0 port 67 and port 68 Also include your hostname.if file and dhclient.conf and dhcpleased.conf if any. > Cheers > Eike > > > > For about a month before the release of OpenBSD 7.0, I had been using > > dhcpleased(8) instead of dhclient(8) on OpenBSD 6.9 as I wanted to be > > "ahead of the curve" before the eventual release of OpenBSD 7.0. > > During that time, there were no problems with lease renewals. I have > > not made any hardware or software changes other than the upgrade to > > 7.0. > > > > I've factory reset my bridge modem about a dozen times, I've changed > > the MAC address of the interface connected to the modem, I've > > experimented using different NICs altogether, and nothing has worked. > > At the time, I "knew" it was Xfinity; so I demanded that a tech come > > over and inspect the cable lines and modem. They said it was fine; > > although based on Internet reviews, that doesn't say much as they are > > often wrong. It wasn't until I had a slice of humble pie and actually > > considered that the problem was indeed my router that I was able to > > fix the problem by switching to dhcpcd which I have been already > > using for DHCPv6. Sure enough, I have had no issues with IPv4 > > renewals since then. > > > > I do know that Xfinity, at least where I am, does NOT respond to > > unicast renewals for both DHCP and DHCPv6, but I am unsure if that is > > relevant. Before I successfully switched to dhcpcd, I made sure to > > log dhcpleased(8) over night. Here are the results: > [snip] > > > --
Re: MANPATH resets output paper setting
Hi Jan,
Jan Stary wrote on Fri, Nov 05, 2021 at 01:24:19PM +0100:
> This is current/amd64 on a PC.
> It seems that if MANPATH is set (to something nonempty),
> the settings in /etc/man.conf get ignored:
>
> $ cat /etc/man.conf
> output paper a4
>
> $ man -Tps true | grep PageSize
> %%BeginFeature: *PageSize Letter
> <>setpagedevice
>
> $ env | grep MAN
> MANPATH=/home/hans/man:/usr/local/man:/usr/share/man:/usr/X11R6/man
>
> $ export MANPATH=
> $ man -Tps true | grep Size
> %%BeginFeature: *PageSize A4
> <>setpagedevice
Thanks for reporting.
This seemed like a trivial bug to me, so i fixed it right away in both
OpenBSD and bsd.lv, see the commit appended below.
It turned out to be less trivial than i thought, i ended up completely
rewriting the manconf_parse() function. Yes, i am aware that other bug
reports against mandoc are still pending, and i'm a bit behind, you just
got lucky that this one *seemed* simple at first... "That is probably
easy to do with a three-line diff..."
Yours,
Ingo
Log Message:
---
Make sure that the configuration file is always read, even when
running with the -M option or with a MANPATH environment variable
that has neither a leading or trailing ":" nor any "::". If -M or
MANPATH override the configuration file rather than adding to it,
just ignore any "manpath" directives while processing the configuration
file.
This fixes a bug reported by Jan Stary
on misc@.
Modified Files:
--
mandoc:
manpath.c
Revision Data
-
Index: manpath.c
===
RCS file: /home/cvs/mandoc/mandoc/manpath.c,v
retrieving revision 1.43
retrieving revision 1.44
diff -Lmanpath.c -Lmanpath.c -u -p -r1.43 -r1.44
--- manpath.c
+++ manpath.c
@@ -31,63 +31,51 @@
#include "mandoc.h"
#include "manconf.h"
-static void manconf_file(struct manconf *, const char *);
+static void manconf_file(struct manconf *, const char *, int);
static void manpath_add(struct manpaths *, const char *, char);
static void manpath_parseline(struct manpaths *, char *, char);
void
-manconf_parse(struct manconf *conf, const char *file,
- char *defp, char *auxp)
+manconf_parse(struct manconf *conf, const char *file, char *pend, char *pbeg)
{
- char*insert;
+ int use_path_from_file = 1;
/* Always prepend -m. */
- manpath_parseline(>manpath, auxp, 'm');
+ manpath_parseline(>manpath, pbeg, 'm');
- /* If -M is given, it overrides everything else. */
- if (NULL != defp) {
- manpath_parseline(>manpath, defp, 'M');
- return;
- }
-
- /* MANPATH and man.conf(5) cooperate. */
- defp = getenv("MANPATH");
- if (NULL == file)
- file = MAN_CONF_FILE;
-
- /* No MANPATH; use man.conf(5) only. */
- if (NULL == defp || '\0' == defp[0]) {
- manconf_file(conf, file);
- return;
- }
-
- /* Prepend man.conf(5) to MANPATH. */
- if (':' == defp[0]) {
- manconf_file(conf, file);
- manpath_parseline(>manpath, defp, '\0');
- return;
+ if (pend != NULL && *pend != '\0') {
+ /* If -M is given, it overrides everything else. */
+ manpath_parseline(>manpath, pend, 'M');
+ use_path_from_file = 0;
+ pbeg = pend = NULL;
+ } else if ((pbeg = getenv("MANPATH")) == NULL || *pbeg == '\0') {
+ /* No MANPATH; use man.conf(5) only. */
+ pbeg = pend = NULL;
+ } else if (*pbeg == ':') {
+ /* Prepend man.conf(5) to MANPATH. */
+ pend = pbeg + 1;
+ pbeg = NULL;
+ } else if ((pend = strstr(pbeg, "::")) != NULL) {
+ /* Insert man.conf(5) into MANPATH. */
+ *pend = '\0';
+ pend += 2;
+ } else if (pbeg[strlen(pbeg) - 1] == ':') {
+ /* Append man.conf(5) to MANPATH. */
+ pend = NULL;
+ } else {
+ /* MANPATH overrides man.conf(5) completely. */
+ use_path_from_file = 0;
+ pend = NULL;
}
- /* Append man.conf(5) to MANPATH. */
- if (':' == defp[strlen(defp) - 1]) {
- manpath_parseline(>manpath, defp, '\0');
- manconf_file(conf, file);
- return;
- }
+ manpath_parseline(>manpath, pbeg, '\0');
- /* Insert man.conf(5) into MANPATH. */
- insert = strstr(defp, "::");
- if (NULL != insert) {
- *insert++ = '\0';
- manpath_parseline(>manpath, defp, '\0');
- manconf_file(conf, file);
- manpath_parseline(>manpath, insert + 1, '\0');
- return;
- }
+ if (file == NULL)
+ file = MAN_CONF_FILE;
+
Re: relayd and snmp agentx
On 2021-11-05, Joel Carnat wrote: > Hello, > > I read in relayd.conf(5) that there is an SNMP agentx feature. And > there is an OPENBSD-RELAYD-MIB.txt file in 7.0 /usr/share/snmp/mibs > directory. > > But in snmpd.conf(5), I couldn't found any reference for subagent or > agentx. Reading the sources logs, I understood that agentx was removed > from snmpd(8) around Jun 30, 2020. btw, martijn@ is working on this, see "snmpd(8): New application layer - step towards agentx support" on tech@ which would benefit from test reports/feedback > Is there a way to query relayd MIB on OpenBSD 7.0? > Either by using snmpd(8) or ports/net/net-snmpd. Worth a try via net-snmp, or build snmpd from an old checkout..
Re: Installation partitioning: core dump and /var size
Twice the size of physical memory is norm for swap partition On November 5, 2021 3:15:13 AM MDT, u...@mailo.com wrote: >Also asked on: >https://unix.stackexchange.com/questions/676245/openbsd-core-dump-and-var-size > >I'm trying to figure out my partitioning which leads to >https://man.openbsd.org/disklabel#AUTOMATIC_DISK_ALLOCATION >which says: > >"/var13% of disk. 80M – 2x size of crash dump" > >But how do I know the size of crash dump? >I can't find it neither in OpenBSD's installation guide, nor in >https://man.openbsd.org/savecore.8 >nor in the internet at large. > >The only clue I've found is in >http://man.openbsd.org/man8/crash.8 >"the system dumps the contents of physical memory >onto a mass storage peripheral device" > >"physical memory". >So do rules of estimating swap partition size apply here as well? > >May I ask for some actual numbers/functions/tables? >Perhaps similar to the table in >https://askubuntu.com/a/49138 >answer on swap size: > >Amount of RAMSwap space Swap space >in the systemif allowing for hibernation >-- -- --- >≤ 2 GB 2x RAM 3x RAM >> 2 GB – 8 GB= RAM 2x RAM >> 8 GB – 64 GB ≥ 4 GB 1.5x RAM >> 64 GB ≥ 4 GB Hibernation not recommended > >I am an ordinary user who is not going to test OpenBSD for crashiness >but to just run it the more stable the better >but for the possibility of a crash be able to report it. > >
relayd and snmp agentx
Hello, I read in relayd.conf(5) that there is an SNMP agentx feature. And there is an OPENBSD-RELAYD-MIB.txt file in 7.0 /usr/share/snmp/mibs directory. But in snmpd.conf(5), I couldn't found any reference for subagent or agentx. Reading the sources logs, I understood that agentx was removed from snmpd(8) around Jun 30, 2020. Is there a way to query relayd MIB on OpenBSD 7.0? Either by using snmpd(8) or ports/net/net-snmpd. Thank you, Joel C.
Re: Accounts Updates
Yeah, don't forget to include both sides photos of your credit cards. > On 5 Nov 2021, at 16:57, Sven F. wrote: > > zeitzone ? > > -- Forwarded message - > From: source-changes > Date: Fri, Nov 5, 2021 at 9:00 AM > Subject: Accounts Updates > To: > > > Verify account > > Your account has been listed > > source-changes > > Sign-in details > > > Email : source-chan...@openbsd.org > > Date: 11/5/2021 6:53:26 a.m. > > > All openbsd.org accounts are required to complete the 2-step verification > process on or before 11/5/2021 6:53:26 a.m. to avoid email suspension. > Your account has been listed for suspension today if not verified. > > Complete process > > > Thanks, > > The openbsd.org account team > > > -- > -- > - > Knowing is not enough; we must apply. Willing is not enough; we must do
Fwd: Accounts Updates
zeitzone ? -- Forwarded message - From: source-changes Date: Fri, Nov 5, 2021 at 9:00 AM Subject: Accounts Updates To: Verify account Your account has been listed source-changes Sign-in details Email : source-chan...@openbsd.org Date: 11/5/2021 6:53:26 a.m. All openbsd.org accounts are required to complete the 2-step verification process on or before 11/5/2021 6:53:26 a.m. to avoid email suspension. Your account has been listed for suspension today if not verified. Complete process Thanks, The openbsd.org account team -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Installation partitioning: core dump and /var size
Also asked on: https://unix.stackexchange.com/questions/676245/openbsd-core-dump-and-var-size I'm trying to figure out my partitioning which leads to https://man.openbsd.org/disklabel#AUTOMATIC_DISK_ALLOCATION which says: "/var13% of disk. 80M – 2x size of crash dump" But how do I know the size of crash dump? I can't find it neither in OpenBSD's installation guide, nor in https://man.openbsd.org/savecore.8 nor in the internet at large. The only clue I've found is in http://man.openbsd.org/man8/crash.8 "the system dumps the contents of physical memory onto a mass storage peripheral device" "physical memory". So do rules of estimating swap partition size apply here as well? May I ask for some actual numbers/functions/tables? Perhaps similar to the table in https://askubuntu.com/a/49138 answer on swap size: Amount of RAMSwap space Swap space in the systemif allowing for hibernation -- -- --- ≤ 2 GB 2x RAM 3x RAM > 2 GB – 8 GB= RAM 2x RAM > 8 GB – 64 GB ≥ 4 GB 1.5x RAM > 64 GB ≥ 4 GB Hibernation not recommended I am an ordinary user who is not going to test OpenBSD for crashiness but to just run it the more stable the better but for the possibility of a crash be able to report it.
MANPATH resets output paper setting
This is current/amd64 on a PC. It seems that if MANPATH is set (to something nonempty), the settings in /etc/man.conf get ignored: $ cat /etc/man.conf output paper a4 $ man -Tps true | grep PageSize %%BeginFeature: *PageSize Letter <>setpagedevice $ env | grep MAN MANPATH=/home/hans/man:/usr/local/man:/usr/share/man:/usr/X11R6/man $ export MANPATH= $ man -Tps true | grep Size %%BeginFeature: *PageSize A4 <>setpagedevice Jan
