Re: wsmouse mapping button clicks
On Mon, 2018-05-14 at 20:09 -0400, Patrick Marchand wrote: > On 05/14, Ulf Brosziewski wrote: > > Hi Patrick, > > > > thanks for the infos. I'm afraid you're out of luck, it seems > > that this device would need vendor-/model-specific extensions > > in our HID-mouse driver. It only announces two "regular" buttons, > > so our driver won't look for more (what xinput shows as buttons 4 > > and 5 are mappings from "Z axis" values). No kind of button > > mapping will help. If it's a workaround for you, you might enable > > middle-button emulation in X. > > > > I was afraid of that. Well guess I'll have to return it then. > > Has anybody tried a Contour Unicomp mouse? I'm guessing it should > work fine and will probably be ideal for use with acme. > > Thanks for the help Ulf. > FWIW I seem to be in the same situation with my Razer Mamba.
Re: Remote kernel debugging with kgdb and vmm
On Sun, 2018-05-13 at 22:22 +0300, IL Ka wrote: > AFAIK kgdb (remote debug) is not supported: > http://openbsd-archive.7691.n7.nabble.com/on-line-kernel-debugging-tt > 335833.html#a341551 > > You can debug running kernel but functionality is limited. Thanks. Looks like using QEmu gdbserver[1] us my best option then. [1] https://bit.ly/2KYiTA4
Remote kernel debugging with kgdb and vmm
Hello, I'd like to dive into the bridge driver and I am trying to setup a kernel debugging environment. I chose to use VMM to do that but I don't seem to find a way to connect my local gdb to the VMM console. I guess I would need another serial device for KGDB, but I have not found how to do that in the man. Is anyone using VMM for this? Or plain old QEMU? Thanks, Xavier
Re: tap+bridge: arp reply not forwarded
On Sun, 2018-05-06 at 17:51 -0400, Xavier Guerin wrote:
> On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> > On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > > Hello list,
> > > >
> > > > Working with a user-space TCP-IP, I tried to setup a local
> > > > bridge
> > > > between two taps, each tap being driver by a user-space client
> > > > and
> > > > server.
> > > >
> > > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > > >
> > > > I am interestingly stuck at the ARP discovery phase. When the
> > > > client
> > > > send its ARP request, the server receives it and replies.
> > > > However,
> > > > the
> > > > client never gets the reply back.
> > > >
> > > > Some research indicated that since the client is getting an
> > > > echoed
> > > > version of its request, the bridge learns its address
> > > > preventing
> > > > the reply from being forwared.
> > > >
> > > > Would my understanding be correct? If so, is there any way to
> > > > correct
> > > > this behavior?
> > > >
> > > > Thanks,
> > > > xavier
> > > >
> > >
> > > What version are you running?
> > >
> > > I ask because of the following:
> > > https://www.openbsd.org/errata63.html
> > > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.pa
> > > tc
> > > h.
> > > sig
> > >
> > > +--+
> > > Carlos
> > >
> >
> > I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> > long time). I just applied the patch and tried again, but no cigar.
> >
> > Here is exactly what is happening:
> >
> > 1. On TAP0, the server waits for any request on 10.1.0.1 (user-
> > space
> > stack address)
> > 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> > (also
> > user-space address)
> > 3. The ARP table of the client is empty, so it sends a broadcast
> > ARP
> > request.
> > 4. Both the server AND the client receive that request, the client
> > ignores it
> > 5. The server responds to the client but the client never receives
> > the
> > reply
> >
> > I can see the reply packet leaving TAP0 and passing through
> > BRIDGE0.
> > It
> > just simply never show up on TAP1.
> >
> > /x
> >
>
> Looking at the source code for the bridge and doing some debugging in
> VMM, it looks like the reply gets dropped at that point:
>
> sys/net/if_bridge.c:1182
>
> if (bridge_ourether(ifl, eh->ether_shost)) {
> m_freem(m);
> return;
> }
>
> In my case, ifl is the sending address and, of course, the source
> ethernet is ours.
>
> Doing some barbaric massaging of the inner FOREACH got me to the
> point
> where my ARP reply was received by my stack. I also was able to get a
> S/SA/A sequence but eventually the stack failed after its first P.
>
> I'll investigate the TCP misbehaving using static ARP routes as Edgar
> suggested.
>
> /x
>
I'm running out of luck apparently... Now that ARP is out of the way,
the user-space client sends an S frame to the user-space server through
tap2. The server uses tap1, which sees the frame (per tcpdump).
However, the read() function on tap1 never returns any data.
Re: tap+bridge: arp reply not forwarded
On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > Hello list,
> > >
> > > Working with a user-space TCP-IP, I tried to setup a local bridge
> > > between two taps, each tap being driver by a user-space client
> > > and
> > > server.
> > >
> > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > >
> > > I am interestingly stuck at the ARP discovery phase. When the
> > > client
> > > send its ARP request, the server receives it and replies.
> > > However,
> > > the
> > > client never gets the reply back.
> > >
> > > Some research indicated that since the client is getting an
> > > echoed
> > > version of its request, the bridge learns its address preventing
> > > the reply from being forwared.
> > >
> > > Would my understanding be correct? If so, is there any way to
> > > correct
> > > this behavior?
> > >
> > > Thanks,
> > > xavier
> > >
> >
> > What version are you running?
> >
> > I ask because of the following:
> > https://www.openbsd.org/errata63.html
> > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patc
> > h.
> > sig
> >
> > +--+
> > Carlos
> >
>
> I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> long time). I just applied the patch and tried again, but no cigar.
>
> Here is exactly what is happening:
>
> 1. On TAP0, the server waits for any request on 10.1.0.1 (user-space
> stack address)
> 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> (also
> user-space address)
> 3. The ARP table of the client is empty, so it sends a broadcast ARP
> request.
> 4. Both the server AND the client receive that request, the client
> ignores it
> 5. The server responds to the client but the client never receives
> the
> reply
>
> I can see the reply packet leaving TAP0 and passing through BRIDGE0.
> It
> just simply never show up on TAP1.
>
> /x
>
Looking at the source code for the bridge and doing some debugging in
VMM, it looks like the reply gets dropped at that point:
sys/net/if_bridge.c:1182
if (bridge_ourether(ifl, eh->ether_shost)) {
m_freem(m);
return;
}
In my case, ifl is the sending address and, of course, the source
ethernet is ours.
Doing some barbaric massaging of the inner FOREACH got me to the point
where my ARP reply was received by my stack. I also was able to get a
S/SA/A sequence but eventually the stack failed after its first P.
I'll investigate the TCP misbehaving using static ARP routes as Edgar
suggested.
/x
Re: tap+bridge: arp reply not forwarded
On Sun, 2018-05-06 at 09:34 -0400, Xavier Guerin wrote:
> On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote:
> > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote:
> > > Hello list,
> > >
> > > Working with a user-space TCP-IP, I tried to setup a local bridge
> > > between two taps, each tap being driver by a user-space client
> > > and
> > > server.
> > >
> > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space
> > >
> > > I am interestingly stuck at the ARP discovery phase. When the
> > > client
> > > send its ARP request, the server receives it and replies.
> > > However,
> > > the
> > > client never gets the reply back.
> > >
> > > Some research indicated that since the client is getting an
> > > echoed
> > > version of its request, the bridge learns its address preventing
> > > the reply from being forwared.
> > >
> > > Would my understanding be correct? If so, is there any way to
> > > correct
> > > this behavior?
> > >
> > > Thanks,
> > > xavier
> > >
> >
> > What version are you running?
> >
> > I ask because of the following:
> > https://www.openbsd.org/errata63.html
> > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patc
> > h.
> > sig
> >
> > +--+
> > Carlos
> >
>
> I am running 6.3 but was missing that patch (hadn't syspatch'd in a
> long time). I just applied the patch and tried again, but no cigar.
>
> Here is exactly what is happening:
>
> 1. On TAP0, the server waits for any request on 10.1.0.1 (user-space
> stack address)
> 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2
> (also
> user-space address)
> 3. The ARP table of the client is empty, so it sends a broadcast ARP
> request.
> 4. Both the server AND the client receive that request, the client
> ignores it
> 5. The server responds to the client but the client never receives
> the
> reply
>
> I can see the reply packet leaving TAP0 and passing through BRIDGE0.
> It
> just simply never show up on TAP1.
>
> /x
>
Looking at the source code for the bridge and doing some debugging in
VMM, it looks like the reply gets dropped at that point:
sys/net/if_bridge.c:1182
if (bridge_ourether(ifl, eh->ether_shost)) {
m_freem(m);
return;
}
In my case, ifl is the sending address and, of course, the source
ethernet is ours.
Doing some barbaric massaging of the inner FOREACH got me to the point
where my ARP reply was received by my stack. I also was able to get a
S/SA/A sequence but eventually the stack failed after its first P.
I'll investigate the TCP misbehaving using static ARP routes as Edgar
suggested.
/x
Re: tap+bridge: arp reply not forwarded
On Sat, 2018-05-05 at 21:07 -0700, Carlos Cardenas wrote: > On Sat, May 05, 2018 at 11:37:07PM -0400, Xavier Guerin wrote: > > Hello list, > > > > Working with a user-space TCP-IP, I tried to setup a local bridge > > between two taps, each tap being driver by a user-space client and > > server. > > > > user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space > > > > I am interestingly stuck at the ARP discovery phase. When the > > client > > send its ARP request, the server receives it and replies. However, > > the > > client never gets the reply back. > > > > Some research indicated that since the client is getting an echoed > > version of its request, the bridge learns its address preventing > > the reply from being forwared. > > > > Would my understanding be correct? If so, is there any way to > > correct > > this behavior? > > > > Thanks, > > xavier > > > > What version are you running? > > I ask because of the following: > https://www.openbsd.org/errata63.html > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/003_arp.patch. > sig > > +--+ > Carlos > I am running 6.3 but was missing that patch (hadn't syspatch'd in a long time). I just applied the patch and tried again, but no cigar. Here is exactly what is happening: 1. On TAP0, the server waits for any request on 10.1.0.1 (user-space stack address) 2. On TAP1, the client tries to connect to 10.1.0.1 from 10.1.0.2 (also user-space address) 3. The ARP table of the client is empty, so it sends a broadcast ARP request. 4. Both the server AND the client receive that request, the client ignores it 5. The server responds to the client but the client never receives the reply I can see the reply packet leaving TAP0 and passing through BRIDGE0. It just simply never show up on TAP1. /x
tap+bridge: arp reply not forwarded
Hello list, Working with a user-space TCP-IP, I tried to setup a local bridge between two taps, each tap being driver by a user-space client and server. user-space <-> TAP0 <-> BRIDGE0 <-> TAP1 <-> user-space I am interestingly stuck at the ARP discovery phase. When the client send its ARP request, the server receives it and replies. However, the client never gets the reply back. Some research indicated that since the client is getting an echoed version of its request, the bridge learns its address preventing the reply from being forwared. Would my understanding be correct? If so, is there any way to correct this behavior? Thanks, xavier
User-space TCP/IP testing with tap, bridge and PF
Hello list, I am developing a userspace TCP/IP stack. Most of the time on my servers I use special NICs and API to bypass the kernel. When on the go I'd like to do the same on my OpenBSD dev laptop. I chose to use tap + bridge and some PF-fu to try to make it work, but after several fruitless hours i am stumped. Here is my setup: userspace <-> tap0 <-> bridge0 <-> iwm0 TAP0 is left unconfigured (except for link0). No route is present for my userspace stack. I added the following in pf.conf to get out to the Internet: > pass out on $lan_if proto tcp from 10.1.0.1 to any nat-to ($lan_if:0) 10.1.0.1 being my userspace stack's IP. I've gone as far as having one of my packet sent to its destination address and come back to iwm0. Then, OpenBSD does the reverse translation and schlepts the packet back on the bridge. However, because of the lack of route to my userspace stack, openbsd uses the defaut route's MAC, which is not the one for my tap0 device and therefore the packet never reaches its destination through bridge0. I tried to add a static route for the userspace stack's IP but I don't seem to be able to do that (route fails between "address unreachable" and "invalid argument" when specifying either the device of the link address). Is my approach correct? If so, how get I get openbsd to use the proper MAC address on the return path? Thanks! xavier
