Re: Filesystem corruption on OpenBSD routers after power outage?
Ted Unangst wrote: > Theo de Raadt wrote: > > How does sync() fix this? Please explain this. Look at the source > > code. > > > > sync() is an asyncronous call requesting syncronization, and once > > it has marked the blocks that should be pushed, it returns before > > the work has been done. > > Ah, indeed. > > > > 2. cp could do an fsync call. There was a thread about this a while ago? > > > > How does fsync fix this? What if it returns an error. What do you do next. > > Should cp spin until fsync returns non-error, or what should it do. > > Exit with an error? Same as if it got EIO or ENOSPC from a write? Then the > command chain will stop before the mv. The OP demonstrated a problem. Any solution presented should try to fix the problem, not just "maybe".
Re: Filesystem corruption on OpenBSD routers after power outage?
Theo de Raadt wrote: > How does sync() fix this? Please explain this. Look at the source > code. > > sync() is an asyncronous call requesting syncronization, and once > it has marked the blocks that should be pushed, it returns before > the work has been done. Ah, indeed. > > 2. cp could do an fsync call. There was a thread about this a while ago? > > How does fsync fix this? What if it returns an error. What do you do next. > Should cp spin until fsync returns non-error, or what should it do. Exit with an error? Same as if it got EIO or ENOSPC from a write? Then the command chain will stop before the mv.
Re: Filesystem corruption on OpenBSD routers after power outage?
Ted Unangst wrote: > Mogens Jensen wrote: > > Even after many tries, I have not yet been able to corrupt the > > filesystem so fsck cannot repair it without manual intervention. > > However, if power is removed while the 'reorder_kernel' script runs, > > the system will become completely unbootable. I could do this multiple > > times. > > The new kernel is installed like this: > umask 077 && cp bsd /nbsd && mv /nbsd /bsd > > So a crash during compilation or linking shouldn't affect reboot. However, > there's a window between cp and mv where some of the new kernel may reside in > unwritten dirty buffers. Then mv will rewrite the directory entry. A crash at > this point will leave you with a broken kernel. I agree, dirty buffers are being pushed too slowly. > A few possible fixes. > > 1. Insert a sync call in there. Kinda heavyweight, but works. How does sync() fix this? Please explain this. Look at the source code. sync() is an asyncronous call requesting syncronization, and once it has marked the blocks that should be pushed, it returns before the work has been done. BUGS sync() may return before the buffers are completely flushed. This has been marked as a bug for over half your life, to the point where it isn't actually a bug. It is the design of the system call. So it doesn't solve what you want to solve. Who will be first person to says sync(); sync(); sync(); > 2. cp could do an fsync call. There was a thread about this a while ago? How does fsync fix this? What if it returns an error. What do you do next. Should cp spin until fsync returns non-error, or what should it do. > 3. mv could do the fsync instead, to make sure it doesn't move incomplete > files. Same question.
Re: Filesystem corruption on OpenBSD routers after power outage?
Mogens Jensen wrote: > Even after many tries, I have not yet been able to corrupt the > filesystem so fsck cannot repair it without manual intervention. > However, if power is removed while the 'reorder_kernel' script runs, > the system will become completely unbootable. I could do this multiple > times. The new kernel is installed like this: umask 077 && cp bsd /nbsd && mv /nbsd /bsd So a crash during compilation or linking shouldn't affect reboot. However, there's a window between cp and mv where some of the new kernel may reside in unwritten dirty buffers. Then mv will rewrite the directory entry. A crash at this point will leave you with a broken kernel. A few possible fixes. 1. Insert a sync call in there. Kinda heavyweight, but works. 2. cp could do an fsync call. There was a thread about this a while ago? 3. mv could do the fsync instead, to make sure it doesn't move incomplete files.
Re: relayd shows ssh sessions as idle
Joel Carnat(j...@carnat.net) on 2019.06.12 16:10:25 +0200:
> Hi,
>
> I have configured relayd(8) on my vmd(8) host so that I can connect to
> the running VMs using SSH.
>
> Using relayctl(8), I can see that those sessions have the same value for
> age and idle ; even when something happens in the SSH sessions.
>
> Is this expected or an error in my relayd.conf ?
>
> Thanks.
>
>
> # config snippet
>
> protocol sshtcp {
> tcp { nodelay, socket buffer 65536 }
this uses the implicit "splice" option.
If you add "no splice" to the tcp options, the idle time will be reset.
The reason is this: After connection setup, relayd "splices" the socket
connecting to the ssh client to the socket connecting to the ssh server.
After that, the kernel takes care of transfering data between the client
connection and the forward connection. relayd does not see the traffic
anymore.
It will only touch the connection again, when a maximum number of bytes are
transfered, or a timeout triggers.
For tcp connections, the max number of bytes is unlimited, and the timeout
is set toyour session timeout.
(For http connections, the max number of bytes is smaller, because relayd
wants to look at the headers of the next http request).
So relayd cannot know if the connection has been idle. It will only know
when it reaches "session timeout". If you dont like this, use "no splice".
However, that makes the connection slower and consume more cpu.
/Benno
> }
> relay ssh_vm1 {
> listen on $public_ip port 8022
> protocol sshtcp
> transparent forward to $vm1 port 8022
> session timeout 28800
> }
> #
>
>
--
Re: Filesystem corruption on OpenBSD routers after power outage?
Since posting this question I have been trying to intentionally corrupt the router filesystem, by simulating power outages while writing files and various other things. Even after many tries, I have not yet been able to corrupt the filesystem so fsck cannot repair it without manual intervention. However, if power is removed while the 'reorder_kernel' script runs, the system will become completely unbootable. I could do this multiple times. A situation could be that the electric grid is unstable, so power will return and a new outage will occur shortly after, if this happens during the boot process at the exact time 'reorder_kernel' is running, the system will break because of a corrupt kernel and repair is not possible remotely. Is there a way to avoid 'reorder_kernel' during the boot process and run it manually instead? Thanks in advance. Mogens Jensen
Re: IPTV handling on OpenBSD soft router
Could it be that your IPTV is using a non-IP protocoll, e.g. an ethertype which
is not IPv4 nor IPv6, but something different? Like Powerline, G.hn or so? --
And which is blocked by pf?There are several protocol and type fields on the
different layers (MAC, IP, TCP/UDP), and I recently noticed that tools and man
pages do not always identify them very clearly or are somewhat misnamed (for
historical reasons I'd say).Btw., I'm looking for a pointer to packet formats
of ethertypes 0x88e1 and 0x8912, which my current filter bubble or info
availability didn't allow me to find until now. They show up in tcpdump
although they are not TCP nor even IP, and wireshark doesn't decrypt the
payload, which I'm interested in.
Ursprüngliche Nachricht Von: Родин Максим
Datum: 16.06.19 22:16 (GMT+01:00) An: OpenBSD general
usage list Betreff: [misc] IPTV handling on OpenBSD soft
router Hello,I am trying to set up an IPTV-box behind a soft router.When my
internet (iptv) provider installed the IPTV box he said thatI need a switch
before my soft router to let IPTV stream successfully pass to the IPTV box.I
thought that a virtual bridge interface would be enough for this purpose.I
created a bridge0 interface and added three interfaces to it:em0 - a physical
one which delivers internet and iptv from my provider.em2 - a physical one to
which the IPTV-box is connected and which receives a mac binded ip address from
the local network of my provider(100.65.129.0/24).vether0 - a virtual one which
receives an external ip address from dhcp server of my provider (it therefore
belongs to egress group) and through which my home computers access the
internet using NAT ({ vether1 em1 em3 athn0 }).When PF is disabled the IPTV-box
is working.When PF is enabled the IPTV box works for several seconds and then
the picture freezes. When I change to another TV channel it works again for
several seconds and then it freezes again.My pf settings are listed below (I
used some of the config in PF user's guide)I do no filtering on the ports
needed (em0, em2)When I do:tcpdump -n -e -i pflog0 not ifname vether0It shows
no blocked packetsWhat am I
missing?""router
root ~ # cat /etc/pf.conf# $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42
deraadt Exp $## See pf.conf(5) and /etc/examples/pf.confint_if = "{ vether1 em1
em3 athn0 }"table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16
\ 172.16.0.0/12 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
203.0.113.0/24 }table persist file "/etc/pf/bad_ip"block log allset
block-policy dropset loginterface egressset skip on lomatch out on egress inet
from (vether1:network) to any nat-to (egress:0)block in quick on egress from
to anyblock return out quick on egress from any to pass
out quick inetpass in on $int_if inet# IPTVpass on em2pass on em0#pass in on
egress inet proto tcp from ! to (egress) port 22pass in on egress inet
proto tcp from ! to (egress) port 80pass in on egress inet proto { tcp
udp } from any to (egress) port { 51413 22034 6890:6999 6881 } rdr-to
192.168.1.4pass in on egress inet proto { tcp udp } from any to (egress) port {
5 } rdr-to 192.168.1.65#block return# block stateless traffic#pass
# establish keep-state# By default, do not permit remote connections
to X11#block return in on ! lo0 proto tcp to port
6000:6010""" --
Best regardsMaksim Rodin
Re: hardware security (was Re: Installing OpenBSD on Supermicro A2SDi-4C-HLN4F
apparently the F-35 project sources motherboards for key instrumentation from China. This is a new economic cold war. Do what you feel best but a big part of this is politics. Maybe the list should qualify when a mail thread is verging on personal politics and out of strictly technical subject the list is supposed to handle. regards > On 16 Jun 2019, at 21:28, Luke A. Call wrote: > > And I think I read that Supermicro is moving production > out of China because of the perceptions of risk (and/or actual > risks) of sensitive electronics manufacturing there. > > Forgive/ignore if this question is excessive here, but I > wonder if anyone has knowledge or educated perspective to share > on this: I have avoided Chinese products (like Lenovo) due to > government history/means/motive/opportunity to put in backdoors > or things with which I might be less comfortable than the > backdoors unfortunately inserted by someone else. Just like I've > been favoring AMD due to Intel's track record and evident attitude.) > Yes, the US government has been reported to waylay hardware > during shipping, etc., and Bruce Schneier and/or others > have said the problem of vetting hardware is beyond > the ability of individuals or most businesses, given the > extreme economic and technical complexity involved. (And > I realize that suspicion can be carried too far, and cost/benefit > estimates can sometimes even favor less caution, but one has to > choose whom to work with, given tradeoffs and an imperfect world. > I know Theo has said in efffect that hardware security is not > a problem OBSD can address, and if that is the final answer, OK.) > > But I wonder sometimes if anyone knows of a laptop &/or desktop > vendor where the odds seem most favorable, maybe why you > think so, and where they are likely to work with OBSD. (System76, > librem, dell, small/local manufacturers)? (My audio, video, and > battery needs are minimal, but *quiet* effective thermal management, & > 16GB+ RAM are important, and reliability & compilation speed.) > AMD CPUs preferred, as going exotic sounds like more $ and > harder to get spare parts. And I probably don't have the ability > now or later to become expert at choosing many individual > components. Thanks in advance. > -- > Luke Call > Things I want to say to many (a lightly-loading site): > http://lukecall.net (updated 2019-06-09) > > > On 06-15 15:11, Stuart Henderson wrote: >> On 2019-06-15, ms wrote: >>> There were some serious security issues with hardware and software from >>> Supermicro (espionage chips, firmware) >> >> Assuming you mean the allegations in that Bloomberg piece, there was no >> evidence found supporting them. >> >> https://hackaday.com/2019/05/14/what-happened-with-supermicro/ etc >> >> There are the usual problems with BMC security, cpu bugs, etc, but those >> are by no means unique to supermicro. >> >> >
