Re: dhcpleased(8) not renewing leases
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. 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: futex(2) not working in inherited mmap'd anon memory
On Tue, Oct 26, 2021 at 11:29 PM Thomas Munro wrote: > When I do mmap(MAP_ANONYMOUS | MAP_SHARED) and then fork(), it seems > that futex(2) wakeups are not delivered between child and parent in > that memory. It does work as expected if I instead use > shmget(IPC_PRIVATE). Hello, This seems to be because such memory objects have no uvm_obj, which is needed by futex_get() to identify futexes. Could they have one? Or perhaps there is some other way to make a futex key in this case?
nvidia graphics cards: one ok, two slow: how to determine for others?
The graphics card in my PC broke (no "signal" after a few minutes) It is an NVIDIA GeForce 7100 GS. I replaced it with an NVIDIA GeForce GT 240 which I found in my "stock". But with this card I get the very slow scrolling under X again (which I posted about with a different card before: NVIDIA GeForce 8500 GT). So this is a bit confusing: why is a GeForce 7100 GS fine, while the other two are "bad"? I know I should buy an ATI card, but that's not available here. I could get a Geforce GT 710 2GB but without knowing whether it will be another "slow scrolling" card I don't want to waste 100 EUR (!) on it. Does someone have experience with this card? It seems buying a "new" PC is also not a good option right now (barely anything is available or only with very high prices). -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Syspatch -R failed after upgrading to 7.0, possible LLVM error
Relinking to create unique kernel failed; after applying /var/db/kernel.SHA256 /bsd> and , this is what my relink.log looks like: (SHA256) /bsd: OK LD="ld" sh makegap.sh 0x gapdummy.o ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS} LLVM ERROR: out of memory PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: ld -T ld.script -X --warn-common -nopie -o newbsd locore0.o [1946 object files later...] swapgeneric.o Abort trap (core dumped) *** Error 134 in /usr/share/relink/kernel/GENERIC.MP (Makefile:1788 'newbsd': @echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYS...) I would include recent dmesg output but it doesn't describe anything useful and shows a different problem in itself: Several instances of wsmouse0 detached ums0 detached uhidev0 detached uhidev0 at uhub0 port 7 configuration 1 interface 0 "Logitech USB Optical Mouse" rev 2.00/72.00 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 on repeat. And here's some sysctl output: hw.machine=amd64 hw.model=Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz hw.ncpu=12 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:c1ee24af7681944d,sd1:,sd2:af97cb0c91508e2d hw.diskcount=3 ... hw.sensors.softraid0.drive0=online (sd2), OK hw.cpuspeed=3192 hw.setperf=99 hw.vendor=CyberPowerPC hw.product=C Series hw.physmem=17071558656 hw.usermem=17071542272 hw.ncpufound=12 hw.allowpowerdown=1 hw.perfpolicy=manual hw.smt=1 hw.ncpuonline=12 -- **/slrn is to pan as Purgatory is to Hell/** OpenPGP_0xCB87D5427864E937.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: mmap with the arguments PROT_NONE and MAP_STACK
overcq wrote: > >> However, I need to know how much of the stack is currently allocated > >> and how much remains only reserved. > > > Why? > > To be able to release reservations from the beginning of the stacks > when new in-program tasks are created. So that you can create any number > of these tasks at runtime. You are attempting to micromanage physical memory in a program which can only allocate/deallocate virtual memory address space. In any case, I would never want to run any piece of software like yours which is undoubtably pulling software with unknown memory damage into a single address space. I'm reading your approach is anti-security. And I'm giving up.
Re: Asyncronous IO
On Wed, Nov 03, 2021 at 03:37:01PM +, cho...@jtan.com wrote: > I program on OpenBSD and am writing a library which presents an API > for IO. POSIX defines an API[*] for asyncronous IO and I would like > my code to support it but this API is unavailable in OpenBSD. > > Is the lack intentional (perhaps there are other plans) or is it > simply the case that no-one has sat down and written it yet? A bit of both. AIO is not often used. Using basic poll/select or the use of libevent is much preferred to build an async API. AIO is complex and in most cases not needed. > I don't mind that the async parts will not (yet) work on OpenBSD > because I can always test them elsewhere but I would like to know > which backend API(s) I should write against and therefore what > OpenBSD intends to do regarding AIO in the future. > > Cheers, > > Matthew > > [*] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html > -- :wq Claudio
Re: mmap with the arguments PROT_NONE and MAP_STACK
overcq wrote: > However, I need to know how much of the stack is currently allocated > and how much remains only reserved. Why?
Re: Encrypt traffic using one interface
On 2021-11-03, naib+li...@xn--bimann-cta.de wrote: > I'm running two remote 7.0 OpenBSD boxes at a hosting provider. Both are > connected via LAN (vio1) over a shared switch. This is a connection I do not > trust. Thus, I want to properly secure traffic flowing over this connection. > > Currently I managed to set up an SA with iked. I am not able to ping the > other host. Utilizing tcpdump, no traffic is seen on enc0 and no esp traffic > is seen on vio1. > > Is there anything I've missed? > > /etc/iked.conf@host1: > ikev2 \ > passive esp proto tcp \ You only have TCP in the flow config, so ping won't be covered. I have had very strange problems with IPsec flows restricted to certain protocols/ports before so I would try without that restriction first. Also try with net.inet.ip.forwarding=1 if you don't already have it, I don't think you are actually forwarding in this configuration but you might need "weak host model" and there's no way to change that on OpenBSD other than enabling forwarding. > enc chacha20-poly1305 \ > group curve25519 \ > ikelifetime 12h \ > lifetime 2h bytes 2G It won't be stopping things working here, but a 2G lifetime is really low. > ikectl show sa@host1: btw "ipsecctl -sa" is way easier to read if you just want to check that flows are setup, i"ikectl show sa" output is more formatted for code debug than user fault diagnosis. > iked_sas: 0xc8e656727b0 rspi 0xe3281f62f2f15c57 ispi 0x0df250d3e7e7d95c > 192.168.1.1:500->192.168.1.2:500[] ESTABLISHED r udpecap nexti > 0x0 pol 0xc8e691ab000 > sa_childsas: 0xc8e65660b00 ESP 0x80127fcd in 192.168.1.2:500 -> > 192.168.1.1:500 (LA) B=0x0 P=0xc8e65660100 @0xc8e656727b0 > sa_childsas: 0xc8e65660100 ESP 0xcfcdf2e0 out 192.168.1.1:500 -> > 192.168.1.2:500 (L) B=0x0 P=0xc8e65660b00 @0xc8e656727b0 > sa_flows: 0xc8e65681000 ESP out 192.168.1.1/32 -> 192.168.1.2/32 [6]@-1 (L) > @0xc8e656727b0 > sa_flows: 0xc8e65675400 ESP in 192.168.1.2/32 -> 192.168.1.1/32 [6]@-1 (L) > @0xc8e656727b0 > iked_activesas: 0xc8e65660b00 ESP 0x80127fcd in 192.168.1.2:500 -> > 192.168.1.1:500 (LA) B=0x0 P=0xc8e65660100 @0xc8e656727b0 > iked_activesas: 0xc8e65660100 ESP 0xcfcdf2e0 out 192.168.1.1:500 -> > 192.168.1.2:500 (L) B=0x0 P=0xc8e65660b00 @0xc8e656727b0 > iked_flows: 0xc8e65675400 ESP in 192.168.1.2/32 -> 192.168.1.1/32 [6]@-1 (L) > @0xc8e656727b0 > iked_flows: 0xc8e65681000 ESP out 192.168.1.1/32 -> 192.168.1.2/32 [6]@-1 (L) > @0xc8e656727b0 > iked_dstid_sas: 0xc8e656727b0 rspi 0xe3281f62f2f15c57 ispi 0x0df250d3e7e7d95c > 192.168.1.1:500->192.168.1.2:500[] ESTABLISHED r udpecap nexti > 0x0 pol 0xc8e691ab000 > > /etc/pf.conf@host1: > [...] > set skip on lo > set skip on enc0 > match in all scrub (no-df) > > block return > block in from { $ipv4_exthost, $ipv6_exthost } > block in quick on egress from $localIPs > block out quick on egress to $localIPs > block in quick from > > pass in on $int_if proto udp from 192.168.1.2 to 192.168.1.1 port 500 > pass out on $int_if proto udp from 192.168.1.1 to 192.168.1.2 port 500 > pass in on $int_if proto esp from 192.168.1.2 to 192.168.1.1 > pass out on $int_if proto esp from 192.168.1.1 to 192.168.1.2 > [...] That looks alright from what you've shown, but we can't check anything about the macros or which interface/s are in the "egress" group. Use "log" on the default block rule and check tcpdump -neipflog0. -- Please keep replies on the mailing list.