Re: Ergonomic USB wired mouse
I'm using Logitech MX Vertical. Nice mouse, IMO one of the most ergonomic ones though it needs some adaptation. It has 2 additional buttons which do NOT work on -current (better to say, they work like scrolling the wheel instead being left and right), I'd like to know how to make them work BTW. On Linux it works well. Oliver Marugg wrote: Hi I am preparing switching my desktop from another OS to OpenBSD. Is anyone using an Evoluent USB Wired Mouse (C/4 or 4 small) with OpenBSD? Or any other great ideas about an ergonomic mouse working with OpenBSD? Many thanks. -oliver
Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day
Do you consider memory an issue?
What is the speed of your memory?
Unix load average can occasionally be deceiving.
What make of Ethernets are you running?
Regards
Patrick
> On Aug 19, 2019, at 5:28 AM, radek wrote:
>
> Hello Patrick,
>
>> Does your ISP implement authoritative DNS?
>> Do you suspect a UDP issue?
> My VPN is configured with IPs, not with domain names. Does DNS and/or UDP
> matter anyway?
>
>> Is a managed (switch) involved?
> No, it is not. I do not use any switches in my testing setup.
> GW1--ISP1_modem--.--ISP2_modem--GW2
>
> Has duplex ever been an issue?
> I have never noticed any duplex issue.
>
>
> On Sun, 18 Aug 2019 16:07:14 -0500
> Patrick Dohman wrote:
>
>> Does your ISP implement authoritative DNS?
>> Do you suspect a UDP issue?
>> Is a managed (switch) involved? Has duplex ever been an issue?
>> Regards
>> Patrick
>>
>>> On Aug 18, 2019, at 1:03 PM, Radek wrote:
>>>
>>> Hello,
>>>
>>> I have two testing gateways (6.5/i386) with site-to-side VPN between its
>>> LANs (OpenIKED).
>>> Both gws are fully syspatched, have public IPs and the same iked/pf
>>> configuration.
>>>
>>> Unfortunately, the network traffic over the VPN tunnel stalls few times a
>>> day.
>>>
>>> On the one side I use a script to monitor VPN tunnel with ping, it restarts
>>> iked and emails me if there is no ping over the VPN tunnel.
>>> Date: Sat, 17 Aug 2019 22:10:30 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 06:00:20 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 11:09:00 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 19:03:02 +0200 (CEST)
>>>
>>>
>>> In 6.3/i386 I have the same problem, but more frequently.
>>> Date: Sat, 17 Aug 2019 23:03:56 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 01:37:50 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 04:12:31 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 06:46:25 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 09:20:22 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 11:59:08 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 14:34:38 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 17:12:57 +0200 (CEST)
>>> Date: Sun, 18 Aug 2019 19:47:16 +0200 (CEST)
>>>
>>> Do I have any bugs/deficiencies in my configs, missed something?
>>> Is there any way to make it work uninterruptedly?
>>> I would be very greatful if you could help me with this case.
>>>
>>> $cat /etc/hostname.enc0
>>> up
>>>
>>> $cat /etc/hostname.vr3
>>> inet 10.0.17.254 255.255.255.0 NONE description "LAN17"
>>> group trust
>>>
>>> $cat /etc/iked.conf
>>> local_gw_RAC17 = "10.0.17.254" # lan_RAC
>>> local_lan_RAC17 = "10.0.17.0/24"
>>> remote_gw_MON = "1.2.3.5" # fw_MON
>>> remote_lan_MON = "172.16.1.0/24"
>>> ikev2 quick active esp \
>>> from $local_gw_RAC17 to $remote_gw_MON \
>>> from $local_lan_RAC17 to $remote_lan_MON peer $remote_gw_MON \
>>> childsa enc chacha20-poly1305 \
>>> psk "psk"
>>>
>>> $cat /etc/pf.conf
>>> # RAC-fwTEST
>>> ext_if = "vr0"
>>> lan_rac_if = "vr3" # vr3 -
>>> lan_rac_local = $lan_rac_if:network # 10.0.17.0/24
>>> backup_if = "vr2" # vr2 - lewy port
>>> backup_local= $backup_if:network # 10.0.117/24
>>>
>>> bud = "1.2.3.0/25"
>>> rdk_wy = "1.2.3.4"
>>> rdk_mon = "1.2.3.5"
>>> panac_krz = "1.2.3.6"
>>> panac_rac = "1.2.3.7"
>>>
>>> set fingerprints "/dev/null"
>>> set skip on { lo, enc0 }
>>> set block-policy drop
>>> set optimization normal
>>> set ruleset-optimization basic
>>>
>>> antispoof quick for {lo0, $lan_rac_if, $backup_if }
>>>
>>> match out log on $ext_if from { $lan_rac_local, $backup_local } nat-to
>>> $ext_if set prio (3, 7)
>>>
>>> block all
>>>
>>> match in all scrub (no-df random-id)
>>> match out all scrub (no-df random-id)
>>> pass out on egress keep state
>>>
>>> pass from { 10.0.201.0/24, $lan_rac_local, $backup_local } to any set prio
>>> (3, 7) keep state
>>>
>>> ssh_port= "1071"
>>> table const { $bud, $rdk_wy, $rdk_mon, $panac_krz, $panac_rac,
>>> 10.0.2.0/24, 10.0.15.0/24, 10.0.100.0/24 }
>>> table persist counters
>>> block from
>>> pass in log quick inet proto tcp from to $ext_if port $ssh_port
>>> flags S/SA \
>>> set prio (7, 7) keep state \
>>> (max-src-conn 15, max-src-conn-rate 2/10, overload flush
>>> global)
>>>
>>> icmp_types = "{ echoreq, unreach }"
>>> pass inet proto icmp all icmp-type $icmp_types \
>>> set prio (7, 7) keep state
>>>
>>> table const { $rdk_mon, $panac_rac, $panac_krz }
>>> pass out quick on egress proto esp from (egress:0) to
>>>set prio (6, 7) keep state
>>> pass out quick on egress proto udp from (egress:0) to port
>>> {500, 4500} set prio (6, 7) keep state
>>> pass in quick on egress proto esp from to (egress:0)
>>>set prio (6, 7) keep state
>>> pass in quick on egress proto udp from to (egress:0) port
>>> {500, 4500} set prio (6, 7) keep state
>>> pass out quick on trust received-on enc0 set prio (6, 7) keep state
>>>
>>> pass in on egress proto udp from any to (egress:0)
Re: Ergonomic USB wired mouse
I am using the Logitech wireless with the trackball on the LEFT side. I would really like to use a second mouse at the same time for my left hand with a trackball on the RIGHT side. I don't like center ball mice. Anyone know of one of these? I like using a mouse for each hand. Chris Bennett
subscribe
pf.conf anchor directories
hiya can you have lines like this in pf.conf anchor "authpf/vpn/*" in on $VPN_IFACE anchor "authpf/wireless/*" in on $WIRE_IFACE and have anchors in /etc/authpf/vpn with your vpn rules and anchors in /etc/authpf/wireless with your wireless rules ? shadrock
Re: Ergonomic USB wired mouse
Hello, On 08/19, Oliver Marugg wrote: > I am preparing switching my desktop from another OS to OpenBSD. Is anyone > using an Evoluent USB Wired Mouse (C/4 or 4 small) with OpenBSD? Or any > other great ideas about an ergonomic mouse working with OpenBSD? Most mouses should work, though I remember having problems with mouses that have more than 3 buttons (The extra buttons didnt do anything) I'm using the contour unimouse right now and it works great. Trackballs work as well. Have a nice day
Ergonomic USB wired mouse
Hi I am preparing switching my desktop from another OS to OpenBSD. Is anyone using an Evoluent USB Wired Mouse (C/4 or 4 small) with OpenBSD? Or any other great ideas about an ergonomic mouse working with OpenBSD? Many thanks. -oliver
Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day
Hello Patrick,
> Does your ISP implement authoritative DNS?
> Do you suspect a UDP issue?
My VPN is configured with IPs, not with domain names. Does DNS and/or UDP
matter anyway?
> Is a managed (switch) involved?
No, it is not. I do not use any switches in my testing setup.
GW1--ISP1_modem--.--ISP2_modem--GW2
Has duplex ever been an issue?
I have never noticed any duplex issue.
On Sun, 18 Aug 2019 16:07:14 -0500
Patrick Dohman wrote:
> Does your ISP implement authoritative DNS?
> Do you suspect a UDP issue?
> Is a managed (switch) involved? Has duplex ever been an issue?
> Regards
> Patrick
>
> > On Aug 18, 2019, at 1:03 PM, Radek wrote:
> >
> > Hello,
> >
> > I have two testing gateways (6.5/i386) with site-to-side VPN between its
> > LANs (OpenIKED).
> > Both gws are fully syspatched, have public IPs and the same iked/pf
> > configuration.
> >
> > Unfortunately, the network traffic over the VPN tunnel stalls few times a
> > day.
> >
> > On the one side I use a script to monitor VPN tunnel with ping, it restarts
> > iked and emails me if there is no ping over the VPN tunnel.
> > Date: Sat, 17 Aug 2019 22:10:30 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 06:00:20 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 11:09:00 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 19:03:02 +0200 (CEST)
> >
> >
> > In 6.3/i386 I have the same problem, but more frequently.
> > Date: Sat, 17 Aug 2019 23:03:56 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 01:37:50 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 04:12:31 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 06:46:25 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 09:20:22 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 11:59:08 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 14:34:38 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 17:12:57 +0200 (CEST)
> > Date: Sun, 18 Aug 2019 19:47:16 +0200 (CEST)
> >
> > Do I have any bugs/deficiencies in my configs, missed something?
> > Is there any way to make it work uninterruptedly?
> > I would be very greatful if you could help me with this case.
> >
> > $cat /etc/hostname.enc0
> > up
> >
> > $cat /etc/hostname.vr3
> > inet 10.0.17.254 255.255.255.0 NONE description "LAN17"
> > group trust
> >
> > $cat /etc/iked.conf
> > local_gw_RAC17 = "10.0.17.254" # lan_RAC
> > local_lan_RAC17 = "10.0.17.0/24"
> > remote_gw_MON = "1.2.3.5" # fw_MON
> > remote_lan_MON = "172.16.1.0/24"
> > ikev2 quick active esp \
> > from $local_gw_RAC17 to $remote_gw_MON \
> > from $local_lan_RAC17 to $remote_lan_MON peer $remote_gw_MON \
> > childsa enc chacha20-poly1305 \
> > psk "psk"
> >
> > $cat /etc/pf.conf
> > # RAC-fwTEST
> > ext_if = "vr0"
> > lan_rac_if = "vr3" # vr3 -
> > lan_rac_local = $lan_rac_if:network # 10.0.17.0/24
> > backup_if = "vr2" # vr2 - lewy port
> > backup_local= $backup_if:network # 10.0.117/24
> >
> > bud = "1.2.3.0/25"
> > rdk_wy = "1.2.3.4"
> > rdk_mon = "1.2.3.5"
> > panac_krz = "1.2.3.6"
> > panac_rac = "1.2.3.7"
> >
> > set fingerprints "/dev/null"
> > set skip on { lo, enc0 }
> > set block-policy drop
> > set optimization normal
> > set ruleset-optimization basic
> >
> > antispoof quick for {lo0, $lan_rac_if, $backup_if }
> >
> > match out log on $ext_if from { $lan_rac_local, $backup_local } nat-to
> > $ext_if set prio (3, 7)
> >
> > block all
> >
> > match in all scrub (no-df random-id)
> > match out all scrub (no-df random-id)
> > pass out on egress keep state
> >
> > pass from { 10.0.201.0/24, $lan_rac_local, $backup_local } to any set prio
> > (3, 7) keep state
> >
> > ssh_port= "1071"
> > table const { $bud, $rdk_wy, $rdk_mon, $panac_krz, $panac_rac,
> > 10.0.2.0/24, 10.0.15.0/24, 10.0.100.0/24 }
> > table persist counters
> > block from
> > pass in log quick inet proto tcp from to $ext_if port $ssh_port
> > flags S/SA \
> >set prio (7, 7) keep state \
> >(max-src-conn 15, max-src-conn-rate 2/10, overload
> > flush global)
> >
> > icmp_types = "{ echoreq, unreach }"
> > pass inet proto icmp all icmp-type $icmp_types \
> >set prio (7, 7) keep state
> >
> > table const { $rdk_mon, $panac_rac, $panac_krz }
> > pass out quick on egress proto esp from (egress:0) to
> >set prio (6, 7) keep state
> > pass out quick on egress proto udp from (egress:0) to port
> > {500, 4500} set prio (6, 7) keep state
> > pass in quick on egress proto esp from to (egress:0)
> >set prio (6, 7) keep state
> > pass in quick on egress proto udp from to (egress:0) port
> > {500, 4500} set prio (6, 7) keep state
> > pass out quick on trust received-on enc0 set prio (6, 7) keep state
> >
> > pass in on egress proto udp from any to (egress:0) port
> > {isakmp,ipsec-nat-t} set prio (6,7) keep state
> > pass in on egress proto {ah,esp} set prio (6,7) keep state
> >
> > # By default, do not permit remote connections to X11
> > block return in on ! lo0 proto tcp to port 6000:6010
> >
> > $cat
Re: IPv6 problems
Le dimanche 18 août 2019 à 11:50 +0200, list a écrit : > When I take a closer look and run tcpdump while pinging I see the > following output: > (With route to fe80::1%vio added and the normal hostname.vio0) > > 11:40:36.446539 fe80:: > ff02::1:ff00:1: icmp6: neighbor sol: > who has fe80::1 > > This line is being repeated over and over again. I left out all the > other traffic that is not related to my /64. > > Hm... > Any ideas ? > > I've got a feeling that somethings wrong with that fe80::1 > address... Hello, A router may be configured to use fe80::1 LL address, but it may not too. It's not a standard AFAIK. I never encountered one myself. If no one responds to your neighbor sol packet, it's probably because no router uses this address. To discover routers in an unknown network, I use "ping6 ff02::2%vio0", as ff02::2 is a standard multicast address for "ip6-allrouters" (as ff02::1 is for all nodes) -- Bastien
Re: openrsync out of memory
Olivier Antoine(olivier.anto...@gmail.com) on 2019.08.19 11:34:06 +0200: > Hi, > On i386: before patch: > $ dd if=/dev/urandom of=in bs=1M count=2k > $ openrsync --rsync-path=/usr/bin/openrsync -av in localhost:out > Transfer starting: 1 files > sender.c:551: error: in: mmap: Cannot allocate memory > client.c:85: error: rsync_sender > receiver.c:345: error: poll: hangup > server.c:145: error: rsync_receiver > > With your patch: > $ patch -p0 < /tmp/1 > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |diff --git usr.bin/rsync/uploader.c usr.bin/rsync/uploader.c > |index fd07b22caeb..cce8b47a4c9 100644 > |--- usr.bin/rsync/uploader.c > |+++ usr.bin/rsync/uploader.c > -- > Patching file usr.bin/rsync/uploader.c using Plan A... > Hunk #1 succeeded at 158. > Hunk #2 succeeded at 741. > Hunk #3 succeeded at 910. > Hmm... Ignoring the trailing garbage. > done > > $ cd usr.bin/rsync/ && make -j3 && doas make install > ??? > > $ openrsync --rsync-path=/usr/bin/openrsync -av in localhost:out > Transfer starting: 1 files > sender.c:551: error: in: mmap: Cannot allocate memory > client.c:85: error: rsync_sender > receiver.c:345: error: poll: hangup > server.c:145: error: rsync_receiver > > From what I see, the mmap problem is on sender.c Thanks, i'll work on that one too. /Benno
Re: openrsync out of memory
Hi,
On i386: before patch:
$ dd if=/dev/urandom of=in bs=1M count=2k
$ openrsync --rsync-path=/usr/bin/openrsync -av in localhost:out
Transfer starting: 1 files
sender.c:551: error: in: mmap: Cannot allocate memory
client.c:85: error: rsync_sender
receiver.c:345: error: poll: hangup
server.c:145: error: rsync_receiver
With your patch:
$ patch -p0 < /tmp/1
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|diff --git usr.bin/rsync/uploader.c usr.bin/rsync/uploader.c
|index fd07b22caeb..cce8b47a4c9 100644
|--- usr.bin/rsync/uploader.c
|+++ usr.bin/rsync/uploader.c
--
Patching file usr.bin/rsync/uploader.c using Plan A...
Hunk #1 succeeded at 158.
Hunk #2 succeeded at 741.
Hunk #3 succeeded at 910.
Hmm... Ignoring the trailing garbage.
done
$ cd usr.bin/rsync/ && make -j3 && doas make install
…
$ openrsync --rsync-path=/usr/bin/openrsync -av in localhost:out
Transfer starting: 1 files
sender.c:551: error: in: mmap: Cannot allocate memory
client.c:85: error: rsync_sender
receiver.c:345: error: poll: hangup
server.c:145: error: rsync_receiver
>From what I see, the mmap problem is on sender.c
Cheers,
On Sat, Aug 17, 2019 at 4:53 PM Sebastian Benoit wrote:
>
> Joe Davis(m...@jo.ie) on 2019.08.16 12:26:36 +0100:
> > By the looks of it, openrsync does attempt to map the entire file, from
> > usr.bin/rsync/uploader.c:
> >
> > mapsz = st.st_size;
> > map = mmap(NULL, mapsz, PROT_READ, MAP_SHARED, *fileinfd, 0);
> >
> > The likely reason for your out of memory error is the default datasize
> > in login.conf. IIRC on some arches it's set to 768MB by default, which
> > would allow your 300MB file to transfer, but would cause mmap to fail
> > upon attempting to map the 1.6GB one.
> >
> > Increasing the default limits in /etc/login.conf should fix the problem.
> >
> > Note that rsync (not openrsync), doesn't use mmap for other reasons,
> > from rsync-3.1.3/fileio.c:
> >
> > /* This provides functionality somewhat similar to mmap() but using read().
> > * It gives sliding window access to a file. mmap() is not used because of
> > * the possibility of another program (such as a mailer) truncating the
> > * file thus giving us a SIGBUS. */
> >
> > Cheers,
> > Joe
>
> Hi,
>
> this replaces the mmap() with pread(), please try it out.
>
> I dont much like the error handling here, but its a start.
>
> ok?
>
>
> diff --git usr.bin/rsync/uploader.c usr.bin/rsync/uploader.c
> index fd07b22caeb..cce8b47a4c9 100644
> --- usr.bin/rsync/uploader.c
> +++ usr.bin/rsync/uploader.c
> @@ -158,8 +158,8 @@ init_blk(struct blk *p, const struct blkset *set, off_t
> offs,
> p->len = idx < set->blksz - 1 ? set->len : set->rem;
> p->offs = offs;
>
> - p->chksum_short = hash_fast(map + offs, p->len);
> - hash_slow(map + offs, p->len, p->chksum_long, sess);
> + p->chksum_short = hash_fast(map, p->len);
> + hash_slow(map, p->len, p->chksum_long, sess);
> }
>
> /*
> @@ -741,8 +741,9 @@ rsync_uploader(struct upload *u, int *fileinfd,
> {
> struct blkset blk;
> struct stat st;
> - void *map, *bufp;
> - size_t i, mapsz, pos, sz;
> + void *mbuf, *bufp;
> + ssize_t msz;
> + size_t i, pos, sz;
> off_t offs;
> int c;
> const struct flist *f;
> @@ -909,35 +910,46 @@ rsync_uploader(struct upload *u, int *fileinfd,
> blk.csum = u->csumlen;
>
> if (*fileinfd != -1 && st.st_size > 0) {
> - mapsz = st.st_size;
> - map = mmap(NULL, mapsz, PROT_READ, MAP_SHARED, *fileinfd, 0);
> - if (map == MAP_FAILED) {
> - ERR("%s: mmap", u->fl[u->idx].path);
> - close(*fileinfd);
> - *fileinfd = -1;
> - return -1;
> - }
> -
> init_blkset(, st.st_size);
> assert(blk.blksz);
>
> blk.blks = calloc(blk.blksz, sizeof(struct blk));
> if (blk.blks == NULL) {
> ERR("calloc");
> - munmap(map, mapsz);
> + close(*fileinfd);
> + *fileinfd = -1;
> + return -1;
> + }
> +
> + if ((mbuf = calloc(1, blk.len)) == NULL) {
> + ERR("calloc");
> close(*fileinfd);
> *fileinfd = -1;
> return -1;
> }
>
> offs = 0;
> - for (i = 0; i < blk.blksz; i++) {
> - init_blk([i],
> - , offs, i, map, sess);
> + i = 0;
> + do {
> + msz = pread(*fileinfd, mbuf, blk.len, offs);
> +
xl2tpd cannot connect to PPPoE VPN server
Hello, I set up an xl2tp client using xl2tpd port on OpenBSD amd64 stable. Most of the time I connect to a Mikrotik PPPoE VPN server and the connection runs without problems but sometimes I cannot make a connection. When this happens I see the following in the /var/log/daemon: tail -f /var/log/daemon | grep xl2tpd Jul 25 13:27:07 nb1 xl2tpd[96632]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc. Jul 25 13:27:07 nb1 xl2tpd[96632]: Forked by Scott Balmos and David Stipp, (C) 2001 Jul 25 13:27:07 nb1 xl2tpd[96632]: Inherited by Jeff McAdams, (C) 2002 Jul 25 13:27:07 nb1 xl2tpd[96632]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016 Jul 25 13:27:07 nb1 xl2tpd[96632]: Listening on IP address 0.0.0.0, port 1701 Jul 25 13:27:07 nb1 xl2tpd[96632]: Connecting to host IPADDRESS, port 1701 Jul 25 13:27:38 nb1 xl2tpd[96632]: Maximum retries exceeded for tunnel 39276. Closing. Jul 25 13:27:38 nb1 xl2tpd[96632]: Connection 0 closed to 91.234.97.130, port 1701 (Timeout) When I check the port 1701 on the VPN host with netcat it is open. When I ask a VPN admin on their side to check my connection attempts they do not see anything. When I make a connection using Windows or Ubuntu machine at the same time, it connects without problems. What can be the problem? -- Best regards, Maksim Rodin
