OpenBSD Xenocara supports "dummy" driver for headless X? (wd support FB resizing, Xvfb does not)
Hi misc@, I did not find any mentioning of OpenBSD Xenocara use of the "dummy" video driver on mailing list nor web. Digging into code and documentation, I think it looks like it's available and should work. I'll try this out soon, this is mostly to mention the topic and to check if anyone has any comments. The idea is to run a dummy framebuffer X server which is resizeable, as backend for X11Vnc. Support for dynamic resizing of the X framebuffer, which is delivered through Xrandr by the VNC framebuffer resize feature, is great when you VNC in from computers with different resolutions. The conventional way to resize the X framebuffer would be to restart Xvfb(1) (http://man.openbsd.org/Xvfb.1) with the new resolution specified as command line argument. I got the idea of the existence of a dynamically resizeable virtual X backend from the X11vnc's manual page (https://linux.die.net/man/1/x11vnc) mentioning of the author's "Xdummy" script where "an advantage of Xdummy over Xvfb is that Xdummy supports RANDR dynamic screen resizing." The script's sourcecode is at http://www.karlrunge.com/x11vnc/Xdummy , X11vnc's manual goes on to say that it "only works on Linux", derp, and the script has shellscript and C parts that seem to implement privilege separation logics that OpenBSD already provides, and what it does overall seems to be to generate the xorg.conf(5) configuration attached below. The "Display drivers:" section in http://man.openbsd.org/xorg.conf.5#SEE_ALSO lists no dummy driver, however, a "xf86-video-dummy" driver is located in the source tree (https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/). So I guess this should be tested and experimented with. Any comments are welcome. The X11vnc command line to deliver resizing should be "x11vnc -display :0 -localhost -xrandr resize". I presume that the xorg.conf below neither works nor is practical on OpenBSD, but probably a good one can be created easily with it as inspiration. Thanks, Tinker Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Mouse0" "CorePointer" EndSection Section "Files" EndSection Section "Module" Load "dbe" Load "extmod" Load "freetype" Load "glx" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "Unknown" HorizSync 30.0 - 130.0 VertRefresh 50.0 - 250.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "dummy" VideoRam 24000 VendorName "foovideo Corporation" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor"Monitor0" DefaultDepth24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Section "ServerFlags" Option "DontVTSwitch" "true" Option "AllowMouseOpenFail" "true" Option "PciForceNone" "true" EndSection
Re: counting dropped packets for pf
On 2018-03-28, 3 wrote: > hi guys. when the pflow option first appeared, i was surprised by the > stupidity of those who implemented it- pflow could not be specified > for block-rules, i.e. dropped packets were not taken into account. as > a result of this approach, the usefulness of pflow sought to zero for > those cases where traffic really had to be counted. but then i found > the way out- the default blocking rule first duplicated packets on a > special, only for this created localhost, which had only one rule - > receiving all incoming packets and the pflow option set, this allowed > to take into account dropped packets too. now i updated system, and > saw that the low level taken by developers fell even lower- now it is > impossible to specify dub-to for block-rules. i dont know how to get > around this now, im a simple user and tired of fighting hands-from-ass > developers. can anyone share their hacks for this? > > ps: sry for my english The English is mostly readable, the attitude is rather abrasive though. pflow hooks into pf states. There is no state for a blocked packet. I think you'll be happier with a BPF-based flow capture tool, there are two in ports.
Re: OpenBSD Xenocara supports "dummy" driver for headless X? (wd support FB resizing, Xvfb does not)
See https://marc.info/?l=openbsd-misc&m=151877018030790&w=2 Is it relevant? Jiri
httpd.conf path substitution
Hi there,
its not really an issue but I noticed if I want to substitute a path for
the tls key or cert I get a syntax error from httpd -n
So is there some special syntax for this or is it simply not possible to
do something like
tls_key ="/path/to/key"
tls_cert ="/path/to/cert"
server "domain.tld" {
tls {
key $tls_key
certificate $tls_cert
}
}
regards
--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden
http://www.ghweb.de
fon: +49 351 8107220 fax: +49 351 8107227
Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
you print it, think about your responsibility and commitment to the
ENVIRONMENT
Re: counting dropped packets for pf
On 03/28/18 22:03, 3 wrote: > maybe im so dumb and blind to see pflow here.. and maybe deal not in > me. where is pflow? pflow gets the data it exports from the state table. Blocked connections do not create state table entries. This means that pflow does not have the information you're looking for. You can still get detailed information about blocked connection attempts, in the aggregate via labels as I showed you, or from pflog. You could even have your block rules logged to a separate pflog interface. Others have alredy pointed you at other alternatives. Obsessing about pflow unfortunately isn't going to get you anywhere. Exploring the other options might. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: httpd.conf path substitution
On Mar 29, 2018 4:58 AM, Markus Rosjat wrote:
>
> Hi there,
>
> its not really an issue but I noticed if I want to substitute a path for
> the tls key or cert I get a syntax error from httpd -n
>
> So is there some special syntax for this or is it simply not possible to
> do something like
>
> tls_key ="/path/to/key"
> tls_cert ="/path/to/cert"
>
> server "domain.tld" {
>
> tls {
> key $tls_key
> certificate $tls_cert
> }
>
> }
>
> regards
>
> --
> Markus Rosjat fon: +49 351 8107223 mail: ros...@ghweb.de
>
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
>
> http://www.ghweb.de
> fon: +49 351 8107220 fax: +49 351 8107227
>
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
> you print it, think about your responsibility and commitment to the
> ENVIRONMENT
>
I seem to remember seeing this on the list semi recently. I believe it had
something to do with quotes and macro expansion. Perhaps look through the
archives I think you will find the answer.
kqueue EV_DISPATCH and EV_EOF interaction
Hello,
I've been re-writing the polling mechanisms in the Erlang VM and stumbled
across
something that might be a bug in the OpenBSD implementation of kqueue.
When using EV_DISPATCH, the event is never triggered again after the EV_EOF
flag has been delivered, even though there is more data to be read from the
socket.
I've attached a smallish program that shows the problem.
The shortened ktrace output looks like this on OpenBSD 6.2:
29672 a.out0.012883 CALL kevent(4,0x7f7e8220,1,0,0,0)
29672 a.out0.012888 STRU struct kevent { ident=5, filter=EVFILT_READ,
flags=0x81, fflags=0<>, data=0, udata=0x0 }
29672 a.out0.012895 RET kevent 0
29672 a.out0.012904 CALL kevent(4,0,0,0x7f7e7cf0,32,0)
29672 a.out0.013408 STRU struct kevent { ident=5, filter=EVFILT_READ,
flags=0x81, fflags=0<>, data=6, udata=0x0 }
29672 a.out0.013493 RET kevent 1
29672 a.out0.013548 CALL read(5,0x7f7e8286,0x2)
29672 a.out0.013562 RET read 2
29672 a.out0.013590 CALL kevent(4,0x7f7e8220,1,0,0,0)
29672 a.out0.013594 STRU struct kevent { ident=5, filter=EVFILT_READ,
flags=0x84, fflags=0<>, data=0, udata=0x0 }
29672 a.out0.013608 RET kevent 0
29672 a.out1.08 CALL kevent(4,0,0,0x7f7e7cf0,32,0)
29672 a.out1.022537 STRU struct kevent { ident=5, filter=EVFILT_READ,
flags=0x8081, fflags=0<>, data=4, udata=0x0 }
29672 a.out1.022572 RET kevent 1
29672 a.out1.022663 CALL read(5,0x7f7e8286,0x2)
29672 a.out1.022707 RET read 2
29672 a.out1.022816 CALL kevent(4,0x7f7e8220,1,0,0,0)
29672 a.out1.022822 STRU struct kevent { ident=5, filter=EVFILT_READ,
flags=0x84, fflags=0<>, data=0, udata=0x0 }
29672 a.out1.022835 RET kevent 0
29672 a.out2.032238 CALL kevent(4,0,0,0x7f7e7cf0,32,0)
29672 a.out5.277194 PSIG SIGINT SIG_DFL
In this example I would have expected the last kevent call to return with
EV_EOF and
data set to 2, but it does not trigger again. If I don't use EV_DISPATCH,
the event is
triggered again and the program terminates.
Does anyone know if this is the expected behavior or a bug?
I've worked around this issue by using EV_ONESHOT instead of EV_DISPATCH on
OpenBSD for now, but would like to use EV_DISPATCH in the future as I've
found
that it aligns better with the abstractions that I use, and could possibly
be a little bit
more performant.
Lukas
PS. If relevant, it seems like FreeBSD does behave the way that I expected,
i.e.
it triggers again for EV_DISPATCH after EV_EOF has been shown. DS.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define USE_DISPATCH 1
int main() {
struct addrinfo *addr;
struct addrinfo hints;
int kq, listen_s, fd = -1;
struct kevent evSet;
struct kevent evList[32];
/* open a TCP socket */
memset(&hints, 0, sizeof hints);
hints.ai_family = PF_UNSPEC; /* any supported protocol */
hints.ai_flags = AI_PASSIVE; /* result for bind() */
hints.ai_socktype = SOCK_STREAM; /* TCP */
int error = getaddrinfo ("127.0.0.1", "8080", &hints, &addr);
if (error)
errx(1, "getaddrinfo failed: %s", gai_strerror(error));
listen_s = socket(addr->ai_family, addr->ai_socktype, addr->ai_protocol);
if (setsockopt(listen_s, SOL_SOCKET, SO_REUSEADDR, &(int){ 1 }, sizeof(int)) < 0)
errx(1, "setsockopt(SO_REUSEADDR) failed");
bind(listen_s, addr->ai_addr, addr->ai_addrlen);
listen(listen_s, 5);
kq = kqueue();
system("echo -n abcdef | nc -v -w 1 127.0.0.1 8080 &");
EV_SET(&evSet, listen_s, EVFILT_READ, EV_ADD, 0, 0, NULL);
if (kevent(kq, &evSet, 1, NULL, 0, NULL) == -1)
err(1, "kevent");
while(1) {
int i;
int nev = kevent(kq, NULL, 0, evList, 32, NULL);
for (i = 0; i < nev; i++) {
if (evList[i].ident == listen_s) {
struct sockaddr_storage addr;
socklen_t socklen = sizeof(addr);
if (fd != -1)
close(fd);
fd = accept(evList[i].ident, (struct sockaddr *)&addr, &socklen);
printf("accepted %d\n", fd);
#if USE_DISPATCH
EV_SET(&evSet, fd, EVFILT_READ, EV_ADD|EV_DISPATCH, 0, 0, NULL);
#else
EV_SET(&evSet, fd, EVFILT_READ, EV_ADD, 0, 0, NULL);
#endif
if (kevent(kq, &evSet, 1, NULL, 0, NULL) == -1)
err(1, "kevent");
} else {
if (evList[i].flags & EV_EOF && evList[i].data == 0) {
printf("closing %d\n", fd);
close(fd);
fd = -1;
exit(0);
} else if (evList[i].filter == EVFILT_READ) {
char buff[2];
read(fd, buff, 2);
if (evList[i].flags & EV_EOF) printf("EOF: ");
printf("read %c%c from %d\n", buff[0], buff[1], fd);
Re: counting dropped packets for pf
On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote: > > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300: > >> > On 03/28/18 15:04, 3 wrote: > >> >> hi guys. when the pflow option first appeared, i was surprised by the > >> >> stupidity of those who implemented it- pflow could not be specified > >> >> for block-rules, i.e. dropped packets were not taken into account. as > i understand- no kosher ways. im asking for illegal ways. many years > ago there was no way either, but i found a way out. i dont think you > are dumber than me > You are asking, "How do I use a wrench as a screwdriver?"
Re: counting dropped packets for pf
On Mar 29, 2018 8:35 AM, Eric Furman wrote: > > On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote: > > > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300: > > >> > On 03/28/18 15:04, 3 wrote: > > >> >> hi guys. when the pflow option first appeared, i was surprised by the > > >> >> stupidity of those who implemented it- pflow could not be specified > > >> >> for block-rules, i.e. dropped packets were not taken into account. as > > i understand- no kosher ways. im asking for illegal ways. many years > > ago there was no way either, but i found a way out. i dont think you > > are dumber than me > > > > You are asking, "How do I use a wrench as a screwdriver?" > You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.
Re: counting dropped packets for pf
Вы писали 29 марта 2018 г., 16:35:45: > On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote: >> > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300: >> >> > On 03/28/18 15:04, 3 wrote: >> >> >> hi guys. when the pflow option first appeared, i was surprised by the >> >> >> stupidity of those who implemented it- pflow could not be specified >> >> >> for block-rules, i.e. dropped packets were not taken into account. as >> i understand- no kosher ways. im asking for illegal ways. many years >> ago there was no way either, but i found a way out. i dont think you >> are dumber than me >> > You are asking, "How do I use a wrench as a screwdriver?" yep. and comrade ed...@pettijohn-web.com understand me. hello, edgar. you are smart ^_^
Re: ThinkPad X250 not resuming
On Thu, Mar 29, 2018 at 05:56:05AM +, Mike Larkin wrote: > Turn off the TPM in the bios and try again. Working now. Thank you. -- db
Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?
On February 16, 2018 4:35 PM, Jiri B wrote:
> On Fri, Feb 16, 2018 at 12:19:44AM -0800, Mike Larkin wrote:
>
> > Xvfb + x11vnc worked fine in the test I just did.
>
> Yes, it does, thanks for confirmation.
>
> I was curious why X11 'dummy' mode does not if it should be
> used in environments without graphical card for headless X11
> server.
>
> Maybe it does not work as our xf86-video-dummy is old,
>
> https://github.com/freedesktop/xorg-xf86-video-dummy/commit/87249af5faf85c8d093e910c069faa4db0aee843#diff-67e997bcfdac55191033d57a16d1408a
>
> I'll stick to Xvfb for now and I'll give a try to build
> newer xf86-video-dummy.
>
> Jiri
(Thread crossreferenced with
https://marc.info/?t=15223071333&r=1&w=2 .)
Thanks for reporting that you got X dummy working, though only on
baremetal but not in a VMM, the latter crashing at X start with
message "(EE) xf86OpenConsole: No console driver found".
Do you have any idea what "No console driver found" here means, like,
is it trying to open some hardware descriptor and it can't find it in
VMM because VMM won't produce it while some PCI device on your
baremetal would? Anyhow weird considering the X is supposed to not
touch any hardware ("dummy" = graphics driver and "void" = mouse and
keyboard drivers.)
Did you get any idea about the detail cause?
If any patch needs testing e.g. upgrade to latest
https://github.com/freedesktop/xorg-xf86-video-dummy/ feel free to let
me know.
Thanks,
Tinker
Re: httpd.conf path substitution
On Thu, Mar 29, 2018 at 11:58:09AM +0200, Markus Rosjat wrote:
> Hi there,
>
> its not really an issue but I noticed if I want to substitute a path
> for the tls key or cert I get a syntax error from httpd -n
>
> So is there some special syntax for this or is it simply not
> possible to do something like
>
> tls_key ="/path/to/key"
> tls_cert ="/path/to/cert"
>
> server "domain.tld" {
>
> tls {
> key $tls_key
> certificate $tls_cert
> }
>
> }
Make sure that "/path/to/{ key,cert }" exists.
Why not type "/path/to/{ key,cert }" inside the tls declaration?
You don´t have to use these filenames multiple times in httpd.conf.
Only once. So why do you want to define a macro for them?
Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?
On Thu, Mar 29, 2018 at 11:03:21AM -0400, Tinker wrote:
> On February 16, 2018 4:35 PM, Jiri B wrote:
> > On Fri, Feb 16, 2018 at 12:19:44AM -0800, Mike Larkin wrote:
> >
> > > Xvfb + x11vnc worked fine in the test I just did.
> >
> > Yes, it does, thanks for confirmation.
> >
> > I was curious why X11 'dummy' mode does not if it should be
> > used in environments without graphical card for headless X11
> > server.
> >
> > Maybe it does not work as our xf86-video-dummy is old,
> >
> > https://github.com/freedesktop/xorg-xf86-video-dummy/commit/87249af5faf85c8d093e910c069faa4db0aee843#diff-67e997bcfdac55191033d57a16d1408a
> >
> > I'll stick to Xvfb for now and I'll give a try to build
> > newer xf86-video-dummy.
> >
> > Jiri
>
> (Thread crossreferenced with
> https://marc.info/?t=15223071333&r=1&w=2 .)
>
> Thanks for reporting that you got X dummy working, though only on
> baremetal but not in a VMM, the latter crashing at X start with
> message "(EE) xf86OpenConsole: No console driver found".
>
> Do you have any idea what "No console driver found" here means, like,
> is it trying to open some hardware descriptor and it can't find it in
> VMM because VMM won't produce it while some PCI device on your
> baremetal would? Anyhow weird considering the X is supposed to not
> touch any hardware ("dummy" = graphics driver and "void" = mouse and
> keyboard drivers.)
>
> Did you get any idea about the detail cause?
>
> If any patch needs testing e.g. upgrade to latest
> https://github.com/freedesktop/xorg-xf86-video-dummy/ feel free to let
> me know.
>
> Thanks,
> Tinker
what do you hope to achieve here?
Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?
On March 29, 2018 11:36 PM, Mike Larkin wrote: .. > > (Thread crossreferenced with > > https://marc.info/?t=15223071333&r=1&w=2 .) > > > > Thanks for reporting that you got X dummy working, though only on > > baremetal but not in a VMM, the latter crashing at X start with > > message "(EE) xf86OpenConsole: No console driver found". .. > what do you hope to achieve here? Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal. My hope is that dummy X + X11vnc will give the same but allow dynamic resizing of the X framebuffer upon request to do so via Xrandr from a VNC resize command. This protocol interaction is what happens when you resize a VNC client window. This will be practical when you have one X/VNC server that you will access from different computers with different screens and screen resolutions, or you just benefit of dynamically resizing the X framebuffer without needing to restart all your running X programs. With Xvfb you'd be inclined to have some different launch scripts for your different monitors and usecases, e.g. 1400x1000px, 2500x1500px and 800x600px variants for surfing web, checking top, checking network stats etc. . With dummy X you can just resize the same framebuffer as you go along depending on needs from time to time.
Re: OpenBSD Xenocara supports "dummy" driver for headless X? (wd support FB resizing, Xvfb does not)
On March 29, 2018 5:00 PM, Jiri B wrote: > See https://marc.info/?l=openbsd-misc&m=151877018030790&w=2 > > Is it relevant? > > Jiri Hi Jiri B! Thanks for highlighting your post from last month! I skimmed it through then but couldn't recall it now. So the whole thread is at https://marc.info/?t=15187399242&r=1&w=2 . So, in the earlier post in the same thread https://marc.info/?l=openbsd-misc&m=151873989824579&w=2 , you say that you got the dummy driver going on a headless OpenBSD installation, that you took your xorg.conf from https://xpra.org/xorg.conf , and that the only caveat was that it works on baremetal but not in a VMM. Awesome that you got it to work! Did you see dynamic resizing working (from X11vnc via Xrandr to X server)? Did you notice any constraints/limits/bugs other than the VMM failure? I'll test dummy X + X11vnc soon (on baremetal) soon and report back. Thanks, Tinker
Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?
On Thu, Mar 29, 2018 at 11:59:21AM -0400, Tinker wrote: > On March 29, 2018 11:36 PM, Mike Larkin wrote: > .. > > > (Thread crossreferenced with > > > https://marc.info/?t=15223071333&r=1&w=2 .) > > > > > > Thanks for reporting that you got X dummy working, though only on > > > baremetal but not in a VMM, the latter crashing at X start with > > > message "(EE) xf86OpenConsole: No console driver found". > .. > > what do you hope to achieve here? > > Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal. > > My hope is that dummy X + X11vnc will give the same but allow dynamic > resizing of the X framebuffer upon request to do so via Xrandr from a > VNC resize command. > > This protocol interaction is what happens when you resize a VNC client > window. > > This will be practical when you have one X/VNC server that you will > access from different computers with different screens and screen > resolutions, or you just benefit of dynamically resizing the X > framebuffer without needing to restart all your running X programs. > > With Xvfb you'd be inclined to have some different launch scripts for > your different monitors and usecases, e.g. 1400x1000px, 2500x1500px and > 800x600px variants for surfing web, checking top, checking network > stats etc. . With dummy X you can just resize the same framebuffer as > you go along depending on needs from time to time. > I see. good luck.
Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?
On Thu, 29 Mar 2018 11:59:21 -0400 Tinker wrote: > On March 29, 2018 11:36 PM, Mike Larkin wrote: > > what do you hope to achieve here? > > Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal. > > My hope is that dummy X + X11vnc will give the same but allow dynamic > resizing of the X framebuffer upon request to do so via Xrandr from a > VNC resize command. Have you tried Xvnc as a X server?
Re: counting dropped packets for pf
> On 03/28/18 22:03, 3 wrote: >> maybe im so dumb and blind to see pflow here.. and maybe deal not in >> me. where is pflow? > pflow gets the data it exports from the state table. > Blocked connections do not create state table entries. > This means that pflow does not have the information you're looking for. > You can still get detailed information about blocked connection > attempts, in the aggregate via labels as I showed you, or from pflog. > You could even have your block rules logged to a separate pflog interface. > Others have alredy pointed you at other alternatives. Obsessing about > pflow unfortunately isn't going to get you anywhere. Exploring the other > options might. i accept your challenge! ^^ but first i will describe my scheme of pf.conf(this is important): block all # default block match from (self) tag PASS # default output match bla-bla1 to (self) tag PASS match bla-bla2 to (self) tag PASS .. match bla-blaN to (self) tag PASS match from lan:network tag PASS # its actually an anchor here, loadable from match to lan:network tag PASS # another file, but it does not matter match out on egress inet from !(self) tagged PASS nat-to (egress) # nat pass quick tagged PASS # one(no other) final pass -- in this place we have all the packets that were not accepted and that will be later blocked by the default block. -- we need only those who entered on egress(pppoe0 for me): pass in quick on pppoe0 all route-to(vether0 10.0.0.1) keep state (pflow) # any fake inteface is here -- now all these packets selected by us get back to the entrance of the rules(before default block). -- we can leave them as they are, but its better to delete them: block quick on vether0 # need to place as the first rule -- lets see what we have got if enable logging: Mar 29 20:42:46.984161 rule 92/(match) [uid 0, pid 54243] pass in on pppoe0: 24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 53, id 5542, len 48) Mar 29 20:42:46.984176 rule 0/(match) [uid 0, pid 54243] block out on vether0: 24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 53, id 5542, len 48) .. and more(i found four matching packets in this interval, but it is difficult to synchronize pf's log and log of the flowd) process_flow: ACCEPT flow FLOW recv_time 2018-03-29T20:43:42.634715 proto 17 tcpflags 00 tos 00 agent [127.0.0.1] src [24.201.182.114]:46574 dst [188.235.31.7]:36824 gateway [0.0.0.0] packets 3 octets 144 in_if 7 out_if 0 sys_uptime_ms 2h20m51s.000 time_sec 2018-03-29T20:43:42 time_nanosec 634520582 netflow ver 5 flow_start 2h19m55s.000 flow_finish 2h20m5s.000 src_AS 0 src_masklen 0 dst_AS 0 dst_masklen 0 engine_type 10752 engine_id 10752 seq 11273 source 0 crc32 output_flow_enqueue: offset 1624 alloc 16384 -- what you say? ;)
Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?
On March 30, 2018 12:39 AM, Mike Larkin wrote: > On Thu, Mar 29, 2018 at 11:59:21AM -0400, Tinker wrote: > > On March 29, 2018 11:36 PM, Mike Larkin mlar...@azathoth.net wrote: > > .. > > > > (Thread crossreferenced with > > > > https://marc.info/?t=15223071333&r=1&w=2 .) > > > > Thanks for reporting that you got X dummy working, though only on > > > > baremetal but not in a VMM, the latter crashing at X start with > > > > message "(EE) xf86OpenConsole: No console driver found". > > > > .. > > > > > > > > what do you hope to achieve here? > > > > Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal. > > My hope is that dummy X + X11vnc will give the same but allow dynamic > > resizing of the X framebuffer upon request to do so via Xrandr from a > > VNC resize command. > > > > This protocol interaction is what happens when you resize a VNC client > > window. > > > > This will be practical when you have one X/VNC server that you will > > access from different computers with different screens and screen > > resolutions, or you just benefit of dynamically resizing the X > > framebuffer without needing to restart all your running X programs. > > With Xvfb you'd be inclined to have some different launch scripts for > > your different monitors and usecases, e.g. 1400x1000px, 2500x1500px and > > 800x600px variants for surfing web, checking top, checking network > > stats etc. . With dummy X you can just resize the same framebuffer as > > you go along depending on needs from time to time. > > I see. good luck. So, I did get dummy X going. Start command "Xorg +extension GLX +extension RANDR +extension RENDER -config custom-xorg.conf", draft /etc/X11/custom-xorg.conf copied below. VNC seems to not support dynamic resizing according to the definition i suggested above. "resizing" may mean that the xrandr CLI tool lets you choose between a selection of 16:9 resolutions, and that the VNC client would resize its framebuffer, instead of disconnecting. I tried with two of the most popular VNC clients and they did *not* handle the resize but instead disconnected. Not sure why. On March 30, 2018 1:09 AM, Karel Gardas wrote: > On Thu, 29 Mar 2018 11:59:21 -0400 > Tinker t1...@protonmail.ch wrote: > > On March 29, 2018 11:36 PM, Mike Larkin mlar...@azathoth.net wrote: > > > what do you hope to achieve here? > > > > Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal. > > > > My hope is that dummy X + X11vnc will give the same but allow dynamic > > > > resizing of the X framebuffer upon request to do so via Xrandr from a > > > > VNC resize command. > > Have you tried Xvnc as a X server? Not recently. What about it? Are you aware of any tool that gives a "persistent" X environment that also allows very convenient live resizing of the framebuffer? Best regards, Tinker /etc/X11/custom-xorg.conf: Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0""CorePointer" EndSection Section "ServerFlags" Option "DontVTSwitch" "true" Option "AllowMouseOpenFail" "true" Option "PciForceNone" "true" Option "AutoEnableDevices" "false" Option "AutoAddDevices" "false" EndSection Section "Module" Load "dbe" Load "extmod" Load "freetype" Load "glx" EndSection Section "InputDevice" Identifier "Mouse0" Option "CorePointer" "true" Driver "void" EndSection Section "InputDevice" Identifier "Keyboard0" Option "CoreKeyboard" "true" Driver "void" EndSection Section "Device" Identifier "Device0" Driver "dummy" # Option "ConstantDPI" "true" # VideoRam 4096000 # VideoRam 256000 VideoRam 192000 EndSection Section "Monitor" Identifier "Monitor0" HorizSync 5.0 - 1000.0 VertRefresh 5.0 - 200.0 # Modeline "1440x900" Option "DPMS" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" # Viewport 0 0 Depth 24 # Modes "1440x900" # Virtual 8192 4096 EndSubSection EndSection
Re: SNI PCD-5T - MP operation on OpenBSD 6.3-current
Hi Frank —
> I got this nice old "workstation" from the mid 90ies with dual P54C
> processors and i430NX chipset and want to operate it in MP mode with
> OpenBSD. Unfortunately this doesn't work as expected currently.
Are you able to describe "doesn't work as expected" a bit more? Does it hang
after the dmesg? do you get to login? Something else?
> I've
> already tried with 6.1, 6.2 and 6.3-current-1521924436. Find attached
> the full dmesg output for 6.3-[...] below, but I suspect that the
> following message is the most relevant one:
>
> ```
> [...]
> bios0: MP default configuration 6 not supported
> [...]
> ```
>
> I actually don't know the meaning of it, can someone perhaps shed some
> light on it?
It means you got to this bit of code (see sys/arch/i386/i386/mpbios.c):
if (mp_fps->pap == 0) {
if (mp_fps->mpfb1 == 0)
printf("%s: MP fps invalid: "
"no default config and no configuration table\n",
self->dv_xname);
else
printf("%s: MP default configuration %d not "
"supported\n", self->dv_xname, mp_fps->mpfb1);
goto err;
}
mp_fps is the "MP floating point structure" (see 4.1 in the MP spec). Now, we
know the pap (Physical Address Pointer) is zero which means the MP config table
doesn't exist on your system. So when there's no config table, the spec wants
to use a default setup. (see section 5 of the spec).
To know which default config to use we’d need to use the MP information byte #1
according to the spec. Your dmesg shows the value is 6 and the spec says a
value of 6 refers to 2 cpus with EISA+PCI bus and integrated APIC).
It may be the case that more work is needed to add support for this setup.
Haven’t looked much further than that so far...
