Re: Mouse scrolling issues for anyone else?
* Ricky Cintron [2021-11-03 04:07]: > I'm not sure if this is a bug, so I'm sending this to misc to see if others > are experiencing the same thing (or can test to confirm the existence > of an issue). > > After upgrading my OpenBSD-current system this past Saturday (Oct. 30 > snapshot), > scrolling with my mouse in tmux and neovim stopped working. However, scrolling > in xterm, mupdf, and Firefox continues to work normally. I upgrade weekly, > so I don't know when this changed other than at some point during the week > after Saturday Oct. 23. I upgraded on Sunday and Monday to check if it was > already dealt with, but the issue remains. That looks like an intentional change: https://marc.info/?l=openbsd-cvs=163570554325770=2 You can enable mouse tracking again with: - CTRL+Right-Mouse-Button->Allow Mouse Ops - xterm -xrm 'xterm*allowMouseOps: true' - put the above setting into Xresources Regards Ralf
Re: bind dhcpd to IP address
Hi Valdrin, that setup works fine. You would use "ip helper-address" on the Ciscos to forward the DHCP requests to your OpenBSD box. The forwarded requests use the specified helper address as unicast destination. No need to have the VLANs present on your OpenBSD box. I'm running dhcpd without -u for that. dhcpd will pickup all packets with destination port 67 on the specified interface via bpf. No need to bind to a specific IP. I understand your last question as: Can dhcpd provide leases for subnets when the dhcpd box has no IP addresses within the range? The answer is yes. You will need subnet declarations for all pools in dhcpd.conf though. Regards, Ralf * Valdrin MUJA [2021-06-09 23:45]: > Hi misc, > > > I have 5 vlans terminated in Cisco switch as Layer 3. > > So the users' gateway is Cisco switch. > > The default gateway of Cisco switch is OpenBSD 6.9, which works as an office > firewall. > > The switch also works as a dhcp server. However, I want OpenBSD office > firewall to also act as a dhcp server. > > Is this possible while OpenBSD has no vlans on it? Only static routes for > these ip networks are installed. > > > I would set dhcp relay on the Cisco switch side, but when I looked at > dhcpd(8), I was not entirely sure. > > I see that dhcpd can listen on an ip address with the -u[bind_address] > parameter, but these lines confused me: > > ''With this option, dhcpd can answer DHCPINFORM from clients on non Ethernet > interfaces such as tun(4) or pppx(4)’’ > > What I understand from above is; if I configure -u for a physical (em0) > interface’s ip address it will not bind to em0’s IP address. > > It will use 255.255.255.255 instead of this. So it will not work; right? > > > One last and probably related question: > > Can OpenBSD be configured to distribute ip pools which it doesn’t have? > > Thanks for reading… >
Re: lego ev3 or nxt software?
* Joel Rees joel.r...@gmail.com [2015-01-08 13:01]: I've been looking around the 'net, and I haven't seen anyone either using openbsd as a robot OS for LEGO's controllers or using openbsd as a developers platform for them. Anyone on the list care to point out something I missed or tell me they've been able to do this, maybe using linux emulation? I've used nbc/nxc to program Mindstorms NXT on OpenBSD in the past. For compiling nbc/nxc you need fpc, which is available in ports. There are a couple of libusb based tools to control NXT, those should work as well. Cheers, Ralf
Re: Forwarding to a proxy on a different system with pf
* John Tate j...@johntate.org [2013-05-03 17:23]:
I have a squid proxy listening in transparent mode on another faster
system, but I can't seem to get packets there with pf. I tried simply
modifying the other divert-to rule to use the IP address of that system. It
doesn't seem to work, packets don't reach that system.
#pass in quick on $int_if inet proto tcp to port http divert-to 127.0.0.1
port 3128
pass in quick on $int_if inet proto tcp to port http divert-to 10.0.0.10
port 3128
How should I be doing this? I couldn't find anything on Google.
Some time ago I did a similar setup with multiple proxies on seperate machines.
The OpenBSD machine had three interfaces:
- em1: client network
- em2: proxies
- em0: outbound
The inbound redirection rules looked somehow like this:
proxy1=10.0.0.5 fd00::5
proxy2=10.0.0.6 fd00::6
table proxies { $proxy1 $proxy2 }
pass in quick on em1 proto tcp from any to any port 80 \
route-to { (em2 proxies) } round-robin
This should work for both IPv4 and IPv6.
To make this a bit more interesting, I made the proxy do non-local bind to the
client IP for the outbound connection. To get return traffic back to the
correct proxy, you can use a bridge on em2 to tag connection by MAC address:
/etc/hostname.bridge0:
up
add em2
rule pass in on em2 src 00:12:34:56:78:01 tag proxy1
rule pass in on em2 src 00:12:34:56:78:02 tag proxy2
With that in place you can route return traffic to the correct proxy although
the proxy's outbound connection uses the source IP of the original client. If I
remember correctly the use of tables here makes it possible to write one rule
per proxy that works for both IPv4 and IPv6:
table proxy1 { $proxy1 }
table proxy2 { $proxy2 }
pass in quick on em2 proto tcp from !proxy1 \
tagged proxy1 reply-to (em2 proxy1)
pass in quick on em2 proto tcp from !proxy2 \
tagged proxy2 reply-to (em2 proxy2)
I hope this still works.
Cheers,
Ralf
Re: firefox-18.0p0 segmentation faulting after upgrade to current
Hi,
* OpenBSD open...@crowsons.net [2013-01-22 00:45]:
Hi Misc,
I've just upgraded to -current (OpenBSD 5.2-current (GENERIC) #17: Fri
Jan 18 19:42:57 MST 2013) dmesg at [2] from the Jan 11 snapshot and
done a pkg_add -vui.
But when I start firefox[1] now it opens the window but shortly
afterwards core dumps.
I've observed reproducible crashes on startup as well, similar symptoms, also
i386. Firefox creates the browser window and then crashes. This is with
firefox 18.0.1 built from ports, on -current as of yesterday. Here is the
backtrace:
#0 0x01875abd in kill () at stdin:2
2 stdin: No such file or directory.
in stdin
(gdb) bt
#0 0x01875abd in kill () at stdin:2
#1 0x018e1626 in raise (s=11) at /usr/src/lib/libc/gen/raise.c:39
#2 0x0254f066 in XRE_InstallX11ErrorHandler ()
from /usr/local/lib/firefox-18.0.1/libxul.so.37.0
#3 0x000b in ?? ()
#4 0xcfbc5c04 in ?? ()
#5 0x in ?? ()
Current language: auto; currently asm
(gdb)
From the firefox 18.0.1 source code:
nsEmbedFunctions.cpp:
XRE_InstallX11ErrorHandler()
{
InstallX11ErrorHandler();
}
nsX11ErrorHandler.cpp:
void
InstallX11ErrorHandler()
{
XSetErrorHandler(X11Error);
Display *display = mozilla::DefaultXDisplay();
NS_ASSERTION(display, No X display);
if (PR_GetEnv(MOZ_X_SYNC)) {
XSynchronize(display, True);
}
}
X11Util.h:
inline Display*
DefaultXDisplay()
{
#if defined(MOZ_WIDGET_GTK)
return GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
#elif defined(MOZ_WIDGET_QT)
return gfxQtPlatform::GetXDisplay();
#endif
}
Very strange. So if the backtrace is trustworthy looks like
gdk_display_get_default fails for some reason.
Cheers,
Ralf
