Wouldn't it be cool...!
What if you could set up a pf rule to: overload an ip address into a table if they tried to access the wrong port on an address and overload flush global immediately into a blocklist ( max-src-states 0)! or with max-src-conn-rate 2/60 when sshd behaves in such a manner as to confirm that a successful connection has taken place, that max-src-conn-rate gets reset for that connection so that you could log in and log out faster than twice in a minute without getting put on a blocklist!
Re: Cannot access internet with virtual switch
On Fri, Apr 6, 2018 at 4:40 PM, Aham Brahmasmiwrote: > Hello misc, > > Problem > A physical server with a switch (add em0 up) cannot access the internet. > However, the same host with a bridge (add em0 up) can access the > internet. > > Steps > $ ifconfig > em0: flags=8843 mtu 1500 > lladdr 22:22:22:22:22:22 > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (1000baseT full-duplex,master) > status: active > inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255 > ... > $ doas route -n show > Routing tables > > Internet: > Destination GatewayFlags Refs Use Mtu Prio Iface > default 20.20.20.1 UGS0 1XXX - 8 em0 > 224/4 127.0.0.1 URS00 32768 8 lo0 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 1X 32768 1 lo0 > 20.20.20/24 20.20.20.20UCn1 9XX - 4 em0 > 20.20.20.1 33:33:33:33:33:33 UHLch 1 1XXX - 3 em0 > 20.20.20.20 44:44:44:44:44:44 UHLl 0X - 1 em0 > 20.20.20.25520.20.20.20UHb00 - 1 em0 > $ ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms > ... > $ doas ifconfig switch0 create > $ doas ifconfig switch0 add em0 > $ doas ifconfig switch0 up > $ ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > ^C > --- 8.8.8.8 ping statistics --- > 31 packets transmitted, 0 packets received, 100.0% packet loss Hi, Seems you haven't started switchd(8), or connected your switch to it -- it shouldn't forward traffic until you do so. > $ ifconfig > em0: flags=8b43 mtu > 1500 > lladdr 22:22:22:22:22:22 > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (1000baseT full-duplex,master) > status: active > inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255 > switch0: flags=41 > index 6 llprio 3 > groups: switch > datapath xx maxflow 1 maxgroup 1000 > em0 flags=0<> > port 1 ifpriority 0 ifcost 0 > ... > $ doas route -n show > Routing tables > > Internet: > Destination GatewayFlags Refs Use Mtu Prio Iface > default 20.20.20.1 UGS0 1XXX - 8 em0 > 224/4 127.0.0.1 URS00 32768 8 lo0 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 1X 32768 1 lo0 > 20.20.20/24 20.20.20.20UCn1 9XX - 4 em0 > 20.20.20.1 33:33:33:33:33:33 UHLch 1 1XXX - 3 em0 > 20.20.20.20 44:44:44:44:44:44 UHLl 0X - 1 em0 > 20.20.20.25520.20.20.20UHb00 - 1 em0 > $ doas ifconfig switch0 destroy > $ ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms > > Repeating the above steps with bridge0 does let the ping pass through > after the bridge is brought up. The only delta between the switch and > bridge output is in the ifconfig. > $ ifconfig > bridge0: flags=41 > index 8 llprio 3 > groups: bridge > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rtsp > em0 flags=3 > port 1 ifpriority 0 ifcost 0 > ... > > I have run "doas route -n monitor" in a separate session while doing > this. However, I cannot comprehend the output. pf is not involved - > running tcpdump -nettti pflog0 with the catchall "block log" produces > the normal output of blocked packets with the bridge. However, it stops > producing the normal output of blocked packets with the switch. Once the > switch is destroyed, it is back to normal blocked packets output. > > What am I doing wrong/missing? The only thing that stands out to me is > the em0 flags=0<> line in the ifconfig for the switch. And I do not know > what to make of it. > > Regards, > ab > -|-|-|-|-|-|-|-- >
[Arduino Library] Does WifiDriverInit() is missing in some package ?
Hello all, I would like to share my issue with the compilation of the sketch provided by arduino.cc concerning the Wifi Whield. After few try and some unrefferenced reference (IPAddress, WiFiDrv)... as expected i edited the MAkefile: LIBRARIES=SPI WiFi IPAddress WiFiDrv Question: as i still have an error message: /usr/local/bin/avr-g++ -c -mmcu=atmega328p -I. -gstabs -DF_CPU=1600 -DARDUINO=100 -I/usr/local/share/arduino//cores/arduino -I/usr/local/share/arduino//libraries/SPI -I/usr/local/share/arduino//libraries/WiFi -I/usr/local/share/arduino//libraries/IPAddress -I/usr/local/share/arduino//libraries/WiFiDrv -I/usr/local/share/arduino//libraries/SD -I/usr/local/share/arduino//libraries/File -I/usr/local/share/arduino//libraries/utility/SdFile -I/usr/local/share/arduino//libraries/utility/SdVolume -I/usr/local/share/arduino//libraries/utility/Sd2Card -I/usr/local/share/arduino//libraries/SPI/utility/ -I/usr/local/share/arduino//libraries/WiFi/utility/ -I/usr/local/share/arduino//libraries/IPAddress/utility/ -I/usr/local/share/arduino//libraries/WiFiDrv/utility/ -I/usr/local/share/arduino//libraries/SD/utility/ -I/usr/local/share/arduino//libraries/File/utility/ -I/usr/local/share/arduino//libraries/utility/SdFile/utility/ -I/usr/local/share/arduino//libraries/utility/SdVolume/utility/ -I/usr/local/share/arduino//libraries/utility/Sd2Card/utility/ -I/usr/local/share/arduino//variants/standard -Os -ffunction-sections -fdata-sections /usr/local/share/arduino//cores/arduino/IPAddress.cpp -o IPAddress.o make: don't know how to make WiFiDrv.o (prerequisite of: applet/core.a) Stop in /home/olivier/Code/Arduino/Project/wifi Did i miss something, something to do ? Here, i am not sure to understand well, what happens, with avrdude or avr-libc. Thanks in advance.
Cannot access internet with virtual switch
Hello misc, Problem A physical server with a switch (add em0 up) cannot access the internet. However, the same host with a bridge (add em0 up) can access the internet. Steps $ ifconfig em0: flags=8843mtu 1500 lladdr 22:22:22:22:22:22 index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255 ... $ doas route -n show Routing tables Internet: Destination GatewayFlags Refs Use Mtu Prio Iface default 20.20.20.1 UGS0 1XXX - 8 em0 224/4 127.0.0.1 URS00 32768 8 lo0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1X 32768 1 lo0 20.20.20/24 20.20.20.20UCn1 9XX - 4 em0 20.20.20.1 33:33:33:33:33:33 UHLch 1 1XXX - 3 em0 20.20.20.20 44:44:44:44:44:44 UHLl 0X - 1 em0 20.20.20.25520.20.20.20UHb00 - 1 em0 $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms ... $ doas ifconfig switch0 create $ doas ifconfig switch0 add em0 $ doas ifconfig switch0 up $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ^C --- 8.8.8.8 ping statistics --- 31 packets transmitted, 0 packets received, 100.0% packet loss $ ifconfig em0: flags=8b43 mtu 1500 lladdr 22:22:22:22:22:22 index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255 switch0: flags=41 index 6 llprio 3 groups: switch datapath xx maxflow 1 maxgroup 1000 em0 flags=0<> port 1 ifpriority 0 ifcost 0 ... $ doas route -n show Routing tables Internet: Destination GatewayFlags Refs Use Mtu Prio Iface default 20.20.20.1 UGS0 1XXX - 8 em0 224/4 127.0.0.1 URS00 32768 8 lo0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 1X 32768 1 lo0 20.20.20/24 20.20.20.20UCn1 9XX - 4 em0 20.20.20.1 33:33:33:33:33:33 UHLch 1 1XXX - 3 em0 20.20.20.20 44:44:44:44:44:44 UHLl 0X - 1 em0 20.20.20.25520.20.20.20UHb00 - 1 em0 $ doas ifconfig switch0 destroy $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms Repeating the above steps with bridge0 does let the ping pass through after the bridge is brought up. The only delta between the switch and bridge output is in the ifconfig. $ ifconfig bridge0: flags=41 index 8 llprio 3 groups: bridge priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rtsp em0 flags=3 port 1 ifpriority 0 ifcost 0 ... I have run "doas route -n monitor" in a separate session while doing this. However, I cannot comprehend the output. pf is not involved - running tcpdump -nettti pflog0 with the catchall "block log" produces the normal output of blocked packets with the bridge. However, it stops producing the normal output of blocked packets with the switch. Once the switch is destroyed, it is back to normal blocked packets output. What am I doing wrong/missing? The only thing that stands out to me is the em0 flags=0<> line in the ifconfig for the switch. And I do not know what to make of it. Regards, ab -|-|-|-|-|-|-|--
OpenBSD-based network switch with >16 GigE ports.
Hello, I'm looking to buy a new switch for house network. Ideally I'd like to setup everything here on OpenBSD, but I'm not lucky to find any OpenBSD-based switch. I need just GigE ports, at least 18-20. Preferably fanless. 1-2U shallow depth into small rack. I know all those Marvells, Broadcoms etc. holding majority in switch business with strict NDAs are not OpenBSD friendly, but still hope something may have slipped from my sight. Any advice appreciated. Thanks! Karel
Re: Documenting library promises.
Ingo Schwarzewrote: > Hi Kristaps, > > Kristaps Dzonsons BSD.LV wrote on Sat, Apr 07, 2018 at 01:37:32AM +0700: > > > The only reason I suggest a standalone section is that it's easier > > to standardise across manpages. > > For that goal, using ".Ss Pledge promises" > at the end of the DESCRIPTION might work. > > For now, such consistency would be local to the ksql package (and > maybe some related packages like kcgi?), and i don't anticipate a > large number of other non-base libraries that want to integrate > with pledge(2) in the near future. But even if some other libraries > pick it up from there, that wouldn't seem undesirable to me. BTW, there is another approach: Describe what your function does properly. For instance, use terminology that a libc-level programmer will recognize as implying use of particular libc interfaces, which they can mentally maps back pledge concepts. (This reminds me of the warts in libc we got rid of -- to allow the creation of pledge. syslog() doesn't use sockets. DNS is a special socket, and regular sockets can't do DNS. isatty() is used extensively in libc, so it abstracted out to ensure ioctl is taken away. Various things like this were taken away inside libc, so that programmers don't need to be shocked "That operation seems so simple, why does it do something so complicated which I never expected?"
Re: OpenBSD VMM VMs Crash
On Fri, Apr 06, 2018 at 06:55:05PM +0200, Aaron Marcher wrote: > Ohai, > > for me OpenBSD VMM VMs crash after some (undefined) time while logging the > following on the host: > vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument > Apart from that VMM works es expected. > > Regards, > Aaron > > -- > Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/ > Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion > GPG: 0x7A65E38D55BE96FE > Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE > Aaron, This is not a very good bug report. Please provide the following information: * dmesg of host * vm.conf * Guest information (dmesg if OpenBSD) * What is the guest doing when it dies? * What is the host doing when the guest dies? +--+ Carlos
Re: OpenBSD VMM VMs Crash
On Fri, Apr 06, 2018 at 06:55:05PM +0200, Aaron Marcher wrote: > Ohai, > > for me OpenBSD VMM VMs crash after some (undefined) time while logging the > following on the host: > vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument > Apart from that VMM works es expected. > > Regards, > Aaron > > -- > Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/ > Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion > GPG: 0x7A65E38D55BE96FE > Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE > could be anything. enable VMM_DEBUG and send me what you see in dmesg after the crash.
Re: Documenting library promises.
Hi Kristaps, Kristaps Dzonsons BSD.LV wrote on Sat, Apr 07, 2018 at 01:37:32AM +0700: > The only reason I suggest a standalone section is that it's easier > to standardise across manpages. For that goal, using ".Ss Pledge promises" at the end of the DESCRIPTION might work. For now, such consistency would be local to the ksql package (and maybe some related packages like kcgi?), and i don't anticipate a large number of other non-base libraries that want to integrate with pledge(2) in the near future. But even if some other libraries pick it up from there, that wouldn't seem undesirable to me. > How about .Sh RESOURCES? I don't like that because the term "resources" is so broad that it is hard for users to guess what they might find there. Maybe something related to X11, or to setrlimit(2), or books and mailing lists on the subject? Also, trying to standardize a section requires that the section is widely needed and that the subject matter is very mature. Premature attempts to standardize new top-level sections, mostly in other operating systems, already left us with various half-dead sections that are not being used consistently and of doubtful utility (LIBRARY, IMPLEMENTATION NOTES, SECURITY CONSIDERATIONS, ..., not even talking about what OpenSolaris / illumos did). > This would also fit other systems like Capsicum. > Though in practice, I think we'll find only pledge documented there. Then i'd suggest to not try to plan ahead for theoretical ideas that are not likely to get done at all. Besides, as Theo said, Capsicum is so different from pledge(2) that what is possible with pledge(2) likely cannot be done with Capsicum - regarding documentation just like regarding consistent application to the complete codebase of a whole operating system. Yours, Ingo
OpenBSD VMM VMs Crash
Ohai, for me OpenBSD VMM VMs crash after some (undefined) time while logging the following on the host: vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument Apart from that VMM works es expected. Regards, Aaron -- Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/ Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion GPG: 0x7A65E38D55BE96FE Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE
Re: Documenting library promises.
Kristaps Dzonsonswrote: > The only reason I suggest a standalone section is that it's easier to > standardise across manpages. I do not see a way to do this in libc. So standardise isn't really required. You are talking about doing this in a port library, not a base library. I don't know how we would do this in a base library, without being overly specific and screwing ourselves in the future somehow. It feels too early to give pledge a formal specification. > How about .Sh RESOURCES? This would also fit other systems like > Capsicum. Though in practice, I think we'll find only pledge documented > there. You really think you'll find common ground?? I'm extremely sceptical. The underlying concepts couldn't be different. pledge disables "grouped actions" taken against objects, whereas capsicum reduces ability to gain new objects but generally leaves all style of actions intact. A pledge context can be described in 2-3 words, but capsicum is a heavy environment one cannot describe so easily. Also, don't want capsicum or any other non-OpenBSD described in OpenBSD manual pages. What you do in your own pages is your own concern, but then premature standardization doesn't matter.
Re: Documenting library promises.
>> .Sh SANDBOXING >> On >> .Ox , >> the >> .Fn khttp_parse >> function requires the >> .Qq stdio proc >> promises to >> .Xr pledge 2 . > > As long as it is only a single sentence, that could easily go right > after the description of the individual function in the DESCRIPTION, > or alternatively at the end of the DESCRIPTION section. Custom > sections are not very nice, in particular when they are so short > that they hardly justify opening a new section in the first place. > > If you really want to describe multiple different sandboxing > systems, then i guess ".Sh SANDBOXING" after the DESCRIPTION > might make sense. I'm not all that sure that describing any other > system will be possible without going overboard; they are typically > much too complicated to be summarized without excessive verbosity. > But you shall no doubt see whether or not it works... Ingo, The only reason I suggest a standalone section is that it's easier to standardise across manpages. Saying "it should go after the function" is too open to interpretation. Moreover, some functions may have varying promises depending upon function parameters, which will rapidly eat into space better left to the functions themselves. How about .Sh RESOURCES? This would also fit other systems like Capsicum. Though in practice, I think we'll find only pledge documented there. Best, Kristaps
Re: Documenting library promises.
> .Sh SANDBOXING And please stop using that word. It has been misused so many times, by now it is misleads. pledge is not a sandbox (whatever the hell a sandbox is)
Re: Documenting library promises.
Hi Kristaps, Kristaps Dzonsons BSD.LV wrote on Fri, Apr 06, 2018 at 09:57:09PM +0700: > Short: what do you recommend for documenting an external library's > pledge(2) requirements? That is an interesting question indeed. I never considered it before, so i will think about it in some detail. For a bit of context, let me first explain how documentation of pledge(2) requirements inside the OpenBSD C library itself works, and why the documentation was designed that way. On first sight, it might seem most user-friendly if each and every section 3 manual page for the C library would state the pledge(2) requirements for each individual library function. But that would have three important downsides: (1) It would be hard to do. There are very many manual pages, so it would require much work for initial setup. (2) It would be unmaintainable, in particular while pledge(2) is still in very active development. Pledge evolved through incremental tweaking. Usage patterns were studied and modeled, the resulting pledge promises applied across the whole three, and the resulting experience allowed to refine the analysis and improve the way pledge(2) itself worked, based on real-world usage. Rinse and repeat, literally dozens of times, over years of careful work. Keeping many hundred manual pages in sync with that gradual evolution would have been flat-out impossible. (3) It would have put the focus in the wrong place. One among the chief ideas of pledge(2) is to avoid the splintered character of traditional syscall filters, where you are forced to filter each syscall, or even worse each of the arguments of each syscall, individually, and consequently completely lose the overview of what you are really doing before you even get started. Instead, pleadge promises enable high-level logical feature groups. The essential job of pledge(2) documentation is not to say that the FOO promise enables the BAR argument of the BAZ syscall, but that pledging FOO is required when you want to do operations of the BAR kind, no matter with which calls or arguments. Of course, once pledge(2) is completely stable, there would be nothing wrong with *also* documenting the effect in individual library functions manuals for user convenience, even though that would imply some redundancy. But given that pledge(2) is still quite actively worked on, i doubt it will happen soon, if ever at all. That said, for external libraries, putting your stuff directly into the pledge(2) manual is obviously not an option. Also, i agree that documenting pledge(2) requirements for external libraries is very useful, because these requirements are often quite non-obvious and hard to guess by just looking at the pledge(2) manual page itself, because many library manuals intentionally, and sensibly, do not document how exactly the library operates internally. Note that for external libraries, the above arguments do not apply: (1) Well-designed external libraries have small numbers of functions, so problem (1) is not a concern. (2) The logical functionality of functions in external libraries is hopefully mostly stable, and the required promises will rarely be affected by changes in pledge(2) itself. Also, pledge(2) has already stabilized considerably, so problem (2) is no longer a major concern - though a bit of maintenace may be required now and then if you put such information into your manual pages. (3) The pledge(2) manual explains the high-level logic, your manuals add the specifics for your library, without duplication of information. That is a clean division of tasks, so problem (3) is not a concern. > Longer: https://bsd.network/@florian/99802355448571943 > > The question raised in this... um... toot?... is which promises are > required by an external library call, in this case khttp_parse(3) in > kcgi. Sure, we can always just run the program, look in > /var/log/messages for failure, and edit our promises. But just... no. > > In this particular case, I've documented this function's requirements > unofficially here and there---tutorials and such. But it's not > canonical. What I'd like is to put these directly into the manpages. Absolutely agreed. "Complete functional description in one canonical place, do not scatter reference-manual-type information across multiple sources" is among the most important requirements for good documentation. > .Sh SANDBOXING > On > .Ox , > the > .Fn khttp_parse > function requires the > .Qq stdio proc > promises to > .Xr pledge 2 . As long as it is only a single sentence, that could easily go right after the description of the individual function in the DESCRIPTION, or alternatively at the end of the DESCRIPTION section. Custom sections are not very nice, in particular when they are so short that they hardly
Documenting library promises.
Hi folks, Short: what do you recommend for documenting an external library's pledge(2) requirements? Longer: https://bsd.network/@florian/99802355448571943 The question raised in this... um... toot?... is which promises are required by an external library call, in this case khttp_parse(3) in kcgi. Sure, we can always just run the program, look in /var/log/messages for failure, and edit our promises. But just... no. In this particular case, I've documented this function's requirements unofficially here and there---tutorials and such. But it's not canonical. What I'd like is to put these directly into the manpages. Something like: .Sh SANDBOXING On .Ox , the .Fn khttp_parse function requires the .Qq stdio proc promises to .Xr pledge 2 . This encourages developers to use the tightest possible promises. And as mdoc(7) is meant not to be system-specific, this might also include information on, say, .Fx's Capsicum, or maybe whatever Linux uses this week. It already has "SECURITY CONSIDERATIONS", but that just doesn't seem quite right. Thoughts? Kristaps
is gif(4) not backward compatible between 6.3 and 6.2?
Hi, I am in need of setting up an IPV4 tunnel over IPv6 in gif between a 6.3-current and a 6.2 router. Only I'm not able to establish the tunnel. In revision 1.109 of /sys/net/if_gif.c there went a change that changed the next header (protocol) to IPPROTO_GRE (protocol 47?) and that's what I'm observing on the 6.2 box is that it doesn't recognize the GRE becuase it might be expecting IPENCAP (protocol 4?). Am I forced to bring the 6.2 box to 6.3? Or is this a bug that crept in? Inline is a tcpdump: 16:19:27.803168 (authentic,confidential): SPI 0xf24bfe38: fd43:5602:29bd:16:0:de ad:beef:1 > fd43:5602:29bd:16:0:dead:beef:16: fd43:5602:29bd:16:0:dead:beef:1 > fd43:5602:29bd:16:0:dead:beef:16: [R] 5400 sum 0x4e38 off 0x0 (rtaf=0xff01) (rta f=0x2526)[|gre] (len 84, hlim 64) (len 124, hlim 64) : 6000 007c 2940 fd43 5602 29bd 0016 `|)@.CV.)... 0010: dead beef 0001 fd43 5602 29bd 0016 .CV.)... 0020: dead beef 0016 6000 0054 2f40 `T/@ 0030: fd43 5602 29bd 0016 dead beef 0001 .CV.)... 0040: fd43 5602 29bd 0016 dead beef 0016 .CV.)... 0050: 4500 0054 4e38 ff01 f535 ac10 100a E..TN8.5 0060: ac10 1010 0800 8cc6 a056 fec7 b8c0 .V.. 0070: 72b7 f575 4327 4fda 71dd 45a5 ff30 7ec4 r..uC'O.q.E..0~. 0080: 1315 5d1b 1819 1a1b 1c1d 1e1f 2021 2223 ..]. !"# 0090: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 00a0: 3435 3637 4567 16:19:27.803207 (authentic,confidential): SPI 0x0f8c22de: fd43:5602:29bd:16:0:de ad:beef:16 > fd43:5602:29bd:16:0:dead:beef:1: fd43:5602:29bd:16:0:dead:beef:16 > fd43:5602:29bd:16:0:dead:beef:1: icmp6: parameter problem next header - octet 6 [icmp6 cksum ok] (len 132, hlim 64) (len 172, hlim 64) : 6000 00ac 2940 fd43 5602 29bd 0016 `.)@.CV.)... 0010: dead beef 0016 fd43 5602 29bd 0016 .CV.)... 0020: dead beef 0001 6000 0084 3a40 `.:@ 0030: fd43 5602 29bd 0016 dead beef 0016 .CV.)... 0040: fd43 5602 29bd 0016 dead beef 0001 .CV.)... 0050: 0401 009c 0006 6000 0054 2f40 `T/@ 0060: fd43 5602 29bd 0016 dead beef 0001 .CV.)... 0070: fd43 5602 29bd 0016 dead beef 0016 .CV.)... 0080: 4500 0054 4e38 ff01 f535 ac10 100a E..TN8.5 0090: ac10 1010 0800 8cc6 a056 fec7 b8c0 .V.. 00a0: 72b7 f575 4327 4fda 71dd 45a5 ff30 7ec4 r..uC'O.q.E..0~. 00b0: 1315 5d1b 1819 1a1b 1c1d 1e1f 2021 2223 ..]. !"# 00c0: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 00d0: 3435 3637 4567 Regards, -peter
Issues with relayd
Hi misc@ I am running relayd as a reverse TLS proxy on OpenBSD 6.3 release with the GENERIC kernel. I have noticed two issues that happen: (1) netstat reports that the Recv-q for the ip protocol steadily climbs and never goes back to 0 unless I restart relayd and (2) I am getting a lot of spurious TLS handshake errors that I can't pin down. I am running relayd with relayd -vv logging. Below is output from my relayd.log and dmesg. Thanks, Matt /var/log/relayd: Apr 5 23:45:43 panther relayd[94018]: startup Apr 5 23:46:08 panther relayd[43579]: relay_tls_transaction: session 1: scheduling on EV_READ Apr 5 23:46:08 panther relayd[43579]: relay ghost, tls session 1 established (1 active) Apr 5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 2: scheduling on EV_READ Apr 5 23:46:15 panther relayd[43579]: relay ghost, tls session 2 established (1 active) Apr 5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 3: scheduling on EV_READ Apr 5 23:46:15 panther relayd[43579]: relay ghost, tls session 3 established (1 active) Apr 5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 4: scheduling on EV_READ Apr 5 23:46:15 panther relayd[11143]: relay_tls_transaction: session 1: scheduling on EV_READ Apr 5 23:46:15 panther relayd[43579]: relay ghost, tls session 4 established (2 active) Apr 5 23:46:15 panther relayd[11143]: relay ghost, tls session 1 established (1 active) Apr 5 23:46:21 panther relayd[11143]: relay_tls_transaction: session 2: scheduling on EV_READ Apr 5 23:46:22 panther relayd[11143]: relay ghost, tls session 2 established (1 active) Apr 5 23:47:04 panther relayd[11143]: relay_tls_transaction: session 3: scheduling on EV_READ Apr 5 23:47:04 panther relayd[11143]: relay ghost, tls session 3 established (1 active) Apr 5 23:47:09 panther relayd[11143]: relay_tls_transaction: session 4: scheduling on EV_READ Apr 5 23:47:09 panther relayd[11143]: relay ghost, tls session 4 established (2 active) Apr 5 23:47:09 panther relayd[73657]: relay_tls_transaction: session 1: scheduling on EV_READ Apr 5 23:47:09 panther relayd[11143]: relay_tls_transaction: session 5: scheduling on EV_READ Apr 5 23:47:09 panther relayd[73657]: relay ghost, tls session 1 established (1 active) Apr 5 23:47:09 panther relayd[11143]: relay ghost, tls session 5 established (1 active) Apr 5 23:48:23 panther relayd[73657]: relay_tls_transaction: session 2: scheduling on EV_READ Apr 5 23:48:23 panther relayd[73657]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number Apr 5 23:48:23 panther relayd[73657]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:23 panther relayd[73657]: relay_tls_transaction: session 3: scheduling on EV_READ Apr 5 23:48:23 panther relayd[73657]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: error:1402710B:SSL routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number Apr 5 23:48:23 panther relayd[73657]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:24 panther relayd[73657]: relay_tls_transaction: session 4: scheduling on EV_READ Apr 5 23:48:24 panther relayd[73657]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: error:1402710B:SSL routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number Apr 5 23:48:24 panther relayd[73657]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:24 panther relayd[43579]: relay_tls_transaction: session 5: scheduling on EV_READ Apr 5 23:48:24 panther relayd[43579]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: error:1402710B:SSL routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number Apr 5 23:48:24 panther relayd[43579]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:24 panther relayd[73657]: relay_tls_transaction: session 5: scheduling on EV_READ Apr 5 23:48:24 panther relayd[73657]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: error:1402710B:SSL routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number Apr 5 23:48:24 panther relayd[73657]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:24 panther relayd[43579]: relay_tls_transaction: session 6: scheduling on EV_READ Apr 5 23:48:24 panther relayd[43579]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: unexpected EOF Apr 5 23:48:24 panther relayd[43579]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:25 panther relayd[43579]: relay_tls_transaction: session 7: scheduling on EV_READ Apr 5 23:48:25 panther relayd[43579]: TLS handshake failed: ghost: relay_tls_handshake: handshake failed: error:140270C1:SSL routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher Apr 5 23:48:25 panther relayd[43579]: relay_close: sessions inflight decremented, now 0 Apr 5 23:48:25 panther relayd[11143]: relay_tls_transaction: session 6: scheduling on EV_READ Apr 5
Re: Compilations errors with plan9port on 2018/04/05 snapshot
On 04/05, Philip Guenther wrote: > On Thu, Apr 5, 2018 at 9:50 PM, Philip Guentherwrote: > > > On Thu, Apr 5, 2018 at 7:53 PM, Patrick Marchand > > wrote: > > > >> Output of compiling plan9port on amd64 with the april 5 snaphot > >> > > ... > > > >> ===> Patching for plan9port-20180117 > >> Segmentation fault (core dumped) > >> *** Warning in /usr/ports/plan9/plan9port: "uname -m" returned non-zero > >> > > > > dmesg from this box, please. > > > > Also, does this segfault happen consistently at that same exact spot, or is > it inconsistent? It appears to be inconsistent, I've joined a file containing a few failed runs and another with the dmesg. OpenBSD 6.3-current (GENERIC.MP) #135: Thu Apr 5 12:31:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8261529600 (7878MB) avail mem = 8004067328 (7633MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET42W (1.20 )" date 09/13/2017 bios0: LENOVO 20BTS0Y500 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.59 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpihpet0: recalibrated TSC frequency 2593996580 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.22 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.22 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.22 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 3 (EXP1) acpiprt3 at acpi0: bus 4 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 10 (EXP6) acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1 acpipwrres1 at acpi0: NVP3, resource for PEG_ acpipwrres2 at acpi0: NVP2,
Re: iwi(4) fatal firmware error
On Thu, Apr 5, 2018 at 3:37 AM, Stefan Sperlingwrote: > > Is this a purely cosmetic issue or does it actually prevent your > wifi connection from working? > > These looks like potentially harmless errors which happen during > association. > Does the driver recover from these errors automatically? It should be able > to. > > As to why the firmware reports such errors: We have no idea. It's a black > box. > As far as I can tell, it recovers. Lately, it's been doing it at odd hours when I'm not actually using it, but I've never come back to it being disconnected or anything like that. I had it next to me streaming music with Pianobar for a few hours yesterday without any hiccups. I'll just ignore these. Thanks, stsp!
The modesetting driver uses acceleration or not?
Hello, In the modesetting video driver man page states that it is a non-accelerated driver, but you have a option to set the acceleration method. If it is non-accelerated driver why can you set the acceleration? Thanks.