Re: Partition completely wiped out, why?
On Wed, Jan 10, 2024 at 12:21:12AM +0100, Jonas Bechtel wrote: > > > Dear "misc" list attendees, > > maybe someone of you has an idea what happened. > > Ten years ago I installed OpenBSD 5.[?] which included setting up a > small partition of 2 GB, including the full OS with kernel, programs, > web-related data, etc.. Occasionally the partition was full so I had to > gzip some logs. Please don't mind that I didn't update the OS - I must > have been very lucky that nothing serious happened, at least I didn't > notice anything suspicious. > > What also may be noted is that the ufs magic 0x00011954 (or, > 1954 0001, in hexdump switched 2-bytes) was present at position 0x255c > and 0x455c and several times at larger offsets. (very helpful, this > post: https://bugzilla.kernel.org/show_bug.cgi?id=197733; looked > similar to mine few days ago) > > This weekend I installed OpenBSD 7.4. (Btw I dislike that the fdisk > "quit" command writes changes, just a side note. Finally I > reconstructed the partition table (fresh MBR pointing to the still > intact disklabel) with the help of GNU/Linux tools i'm familiar with) I > assigned a mount point to the old partition, "/oldbsd5", which worked > on first boot. I just saw the usual files usr, mnt, ... when invoking > "ls /oldbsd5", assumed it was working then. Automatic fstab entry was > > [hash].j /oldbsd5 ffs rw,nodev,nosuid 1 2 > > Then I deleted "rw," from fstab and maybe rebooted the system once or > twice. I'm pretty sure that I never made rm -rf on that directory. Then > I found out (with df -h) that the partition is empty. Really actually > empty, so theres no hidden file, no file, no lost+found, just nothing. > > The data, however, is still scattered on disk. I can see the lines of > known text files with grep. I also can see the signature at 0x455c, but > not any more at 0x255c. fsck doesn't find anything problematic. > > > I have no clue. a) What happened?, b) How easy would it be to get the > data back? (not too important, not my first data loss, but annoying, > anyway) > > > > Best Regards > Jonas Is the disk mounted? I seem to remember a fstab line without rw or ro is not mounted. -Otto
File corruption on SSD disk
I'm running OpenBSD on a Protectli box as a router/firewall. The disk is
an SSD. Every now and then I reboot it ("sudo shutdown -r now") just to
make sure it comes back up. Several times it hung on disk errors that
the auto 'fsck' can't fix. I was able to manually run 'fsck' and answer
its prompts to clean up the problems, which sometimes were unreferenced
inodes or similar things. It deleted some files in /var. The system runs
OK, so perhaps the files aren't used in my minimal setup.
I have two questions:
(1) In "/etc/rc" I changed [fsck -p "$@"] to [fsck -f "$@"] in an
attempt to get it to force fix problems, so the system could recover
without someone manually doing it. That didn't work (it still stopped
startup with the disk errors), so I tried making it [do_fsck -f -y] but
that didn't work either. How does one make the system recover (e.g., how
would an unstaffed/dark computer operations center do it)?
(2) Why would the system develop disk problems? Might the SSD be
failing? Should I proactively replace it? If I do replace it, should I
start fresh with a clean install versus cloning the current disk?
By the way, the SSD is a Samsung SSD 870 EVO 500GB (only using a tiny
bit of it). Micromat's Lifespan says it has 100% life left, and their
Tech Tools Pro found no bad blocks.
--Randall
Partition completely wiped out, why?
Dear "misc" list attendees, maybe someone of you has an idea what happened. Ten years ago I installed OpenBSD 5.[?] which included setting up a small partition of 2 GB, including the full OS with kernel, programs, web-related data, etc.. Occasionally the partition was full so I had to gzip some logs. Please don't mind that I didn't update the OS - I must have been very lucky that nothing serious happened, at least I didn't notice anything suspicious. What also may be noted is that the ufs magic 0x00011954 (or, 1954 0001, in hexdump switched 2-bytes) was present at position 0x255c and 0x455c and several times at larger offsets. (very helpful, this post: https://bugzilla.kernel.org/show_bug.cgi?id=197733; looked similar to mine few days ago) This weekend I installed OpenBSD 7.4. (Btw I dislike that the fdisk "quit" command writes changes, just a side note. Finally I reconstructed the partition table (fresh MBR pointing to the still intact disklabel) with the help of GNU/Linux tools i'm familiar with) I assigned a mount point to the old partition, "/oldbsd5", which worked on first boot. I just saw the usual files usr, mnt, ... when invoking "ls /oldbsd5", assumed it was working then. Automatic fstab entry was [hash].j /oldbsd5 ffs rw,nodev,nosuid 1 2 Then I deleted "rw," from fstab and maybe rebooted the system once or twice. I'm pretty sure that I never made rm -rf on that directory. Then I found out (with df -h) that the partition is empty. Really actually empty, so theres no hidden file, no file, no lost+found, just nothing. The data, however, is still scattered on disk. I can see the lines of known text files with grep. I also can see the signature at 0x455c, but not any more at 0x255c. fsck doesn't find anything problematic. I have no clue. a) What happened?, b) How easy would it be to get the data back? (not too important, not my first data loss, but annoying, anyway) Best Regards Jonas
Re: mountd
On Tue, Jan 09, 2024 at 07:27:47AM +0100, Otto Moerbeek wrote: > resreved means that the port number is below 1024. The RPC system, > (which is used to implement NFS) iuses portmapper to determine which > service runs on which port. What problem are you trying to solve? I'm not a fan of that terminology, especially since /etc/services actually contains several ports reserved for services that are well above 1024. For instance, see https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers (found in 30 seconds on google, which lists ports 2375-2380 as "reserved" among others). IANA seems to define range 0-1023 as "System ports" see https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
Re: Weird network performance with iwn(4)
Thanks for taking a shot at this! I fiddled with the few options this AP has related to the 5GHz mode, nothing special, really (channel width, number, mode). Interestingly enough, the AP says its Country is set to 'EU' (whatever that means) - can't grasp why it would report 'US', though. Anyway, thanks again, I'll just leave it at that and use 2.4GHz. Daniel On Tuesday, January 9th, 2024 at 15:31, Stefan Sperling wrote: > > > On Thu, Dec 21, 2023 at 09:23:42AM +0100, Stefan Sperling wrote: > > > could you send me a pcap of 5GHz beacons from this AP? > > > Nothing in the beacon you sent off-list stands out. > I don't see a reason why things wouldn't work as they should. > > The AP is set to country 'US' -- if this is incorrect then try > setting the contry code to the actual country the AP is located in. > The AP uses an 80MHz channel config in the first channel segment (with > center channel 42), which should work anywhere in the world. So there > is no reason to believe that the country code would cause issues. > However, Intel firmware uses black-box regulatory heuristics which the > driver has little control over. With some luck a wrong country code is > the reason for your trouble. > > Otherwise, I don't know. You could try turning configurable features > of the AP off one-by-one to see if a factor which triggers the issue > can be identified that way.
Re: Weird network performance with iwn(4)
On Thu, Dec 21, 2023 at 09:23:42AM +0100, Stefan Sperling wrote: > could you send me a pcap of 5GHz beacons from this AP? Nothing in the beacon you sent off-list stands out. I don't see a reason why things wouldn't work as they should. The AP is set to country 'US' -- if this is incorrect then try setting the contry code to the actual country the AP is located in. The AP uses an 80MHz channel config in the first channel segment (with center channel 42), which should work anywhere in the world. So there is no reason to believe that the country code would cause issues. However, Intel firmware uses black-box regulatory heuristics which the driver has little control over. With some luck a wrong country code is the reason for your trouble. Otherwise, I don't know. You could try turning configurable features of the AP off one-by-one to see if a factor which triggers the issue can be identified that way.
Re: mountd
> On Tue, Jan 09, 2024 at 10:13:56AM +0300, 4 wrote:
> No need to be so dramatic, the ports only change when the service is
> restarted, so there is no need for constant monitoring and/or script
> running. Either you run the script (a one-liner, by the way, see below)
> on the server upon starting the daemon, or run it on the firewall via
> cron at appropriate intervals (I'm assuming you don't reboot your server
> every 10 minutes, so it can be run at large intervals).
> You may not find it "very pretty", but hey, it works fine. NFS over
> firewalls decidedly isn't great, but it's the smallest of my NFS woes.
> OT, they got to the moon with the computing power of a pocket
> calculator, and the physics of going to mars are pretty much the same,
> so I find your argument moot. Also, its literally a one line script.
> Not exactly rocket science.
> rpcinfo -p a.b.c.d | awk 'NR>1 { print "pass inet proto " $3 " to port "
> $4 " flags any" }' | pfctl -a "portmap/$a" -f -
forget about the moon. with such a high-quality script you won't even be able
get to the nearest mcdonalds >_< even eighteen years ago this did much better.
i'm setting up a chinese ip-camera, and i need to restart nfs frequently for
testing(yes, i later opened everything for the tests, but at first i didn’t
understand the reason. and this camera is another example of something that
will never reach the moon >:( hikvision- maybe you've heard? ;)). although with
the camera is already ended, but i just still don't understand why openbsd is
"fighting in the wrong direction", because everyone else can do "-p" %\ “this
is for your safety, please don’t leave the house”- oh, i’ve heard that
somewhere before :D
Re: mountd
> On Tue, Jan 09, 2024 at 10:13:56AM +0300, 4 wrote: > These kind of off-topic remarks won't help you getting answers, > -Otto "i'm only human after all don't put your blame on me"
Re: relayd forward with tls
On Tue, Jan 09, 2024 at 06:24:36AM +0100, Uwe Werler wrote:
> Take a look at the example in man relayd.conf. You have to set the X-header
> like:
>
> match header set "X-Forwarded-For" \ value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" \ value
> "$SERVER_ADDR:$SERVER_PORT"
>
That doesn't seem to make difference. I had that set when I first
notice the problem. I still get
Jan 9 07:10:24 stable relayd[29792]: relay wwwtls, session 1 (1 active),
fqdn1, 127.0.0.1 -> 127.0.0.1:8080, done, GET -> 127.0.0.1:8080;
Jan 9 07:10:25 stable relayd[28442]: relay wwwtls, session 1 (1 active),
fqdn2, 127.0.0.1 -> 127.0.0.1:8081, done, GET -> 127.0.0.1:8081;
Jan 9 07:10:31 stable relayd[29792]: relay wwwtls2, session 2 (1 active), 0,
127.0.0.1 -> 127.0.0.1:8080, done, GET
Jan 9 07:10:35 stable relayd[28442]: relay wwwtls2, session 2 (1 active), 0,
127.0.0.1 -> 127.0.0.1:8080, done, GET
with the X-Forwarded-{For,By} set.
> I could post an example when I'm back at my machine.
>
> Am 8. Januar 2024 23:51:33 MEZ schrieb Adriano Barbosa
> :
> >On Mon, Jan 08, 2024 at 07:01:04AM -0800, Paul Pace wrote:
> >> On 1/7/24 1:31 PM, Adriano Barbosa wrote:
> >> > On Sun, Jan 07, 2024 at 05:21:04AM -0800, Paul Pace wrote:
> >> > > On 1/6/24 7:35 PM, Adriano Barbosa wrote:
> >> > > > On Thu, Jan 04, 2024 at 06:57:10PM -0800, Paul Pace wrote:
> >> > > > > On 1/4/24 10:22 AM, Adriano Barbosa wrote:
> >> > > > > > Hi!
> >> > > > > > I'm trying to use relayd with multiple FQDNs mixing remote
> >> > > > > > servers
> >> > > > > > with and without tls:
> >> > > > > >
> >> > > > > > relayd -- fqdn1 --> 127.0.0.1 (no tls)
> >> > > > > > -- fqdn2 --> x.x.x.x (with tls)
> >> > > > > >
> >> > > > > > I wrote my relayd.conf like this:
> >> > > > > >
> >> > > > > > table { 127.0.0.1 }
> >> > > > > > table { x.x.x.x }
> >> > > > > >
> >> > > > > > http protocol https {
> >> > > > > >tls keypair fqdn1
> >> > > > > >tls keypair fqdn2
> >> > > > > >
> >> > > > > >match request header "Host" value "fqdn1" tag "fqdn1"
> >> > > > > >pass request tagged "fqdn1" forward to
> >> > > > > >
> >> > > > > >match request header "Host" value "fqdn2" tag "fqdn2"
> >> > > > > >pass request tagged "fqdn2" forward to
> >> > > > > > }
> >> > > > > >
> >> > > > > > relay wwwtls {
> >> > > > > >listen on egress port 443 tls
> >> > > > > >protocol https
> >> > > > > >forward to port 80
> >> > > > > >forward with tls to port 443
> >> > > > > > }
> >> > > > >
> >> > > > > With one forward requiring TLS in a relay block, relayd will
> >> > > > > require TLS for
> >> > > > > all forward statements in the relay block.
> >> > > > >
> >> > > > > >
> >> > > > > > I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply
> >> > > > > > from
> >> > > > > > server".
> >> > > > > > Removing "with tls" on the second forward, fqdn1 works and fqdn2
> >> > > > > > gives
> >> > > > > > a "Client sent an HTTP request to an HTTPS server."
> >> > > > > >
> >> > > > > > Is it possible to have relayd working on this scenario? What am I
> >> > > > > > missing here?
> >> > > > > >
> >> > > > > > Obrigado!
> >> > > > > > --
> >> > > > > > Adriano
> >> > > > >
> >> > > >
> >> > > > Thank you for the response.
> >> > > >
> >> > > > Digging a little more, I found that if I change the listen port from
> >> > > > 443 to values other than 443 and 80, the "match request host" filter
> >> > > > stops working. The behaviour is the same with or without "with tls"
> >> > > > on
> >> > > > the relay.
> >> > > >
> >> > > > With port 443:
> >> > > > stable# curl --insecure https://fqdn1
> >> > > > Server 1
> >> > > > stable# curl --insecure https://fqdn2
> >> > > > Server 2
> >> > > >
> >> > > > With port 4430 and allegedly any port other than 80 and 443:
> >> > > > stable# curl --insecure https://fqdn1:4430
> >> > > > Server 1
> >> > > > stable# curl --insecure https://fqdn2:4430
> >> > > > Server 1
> >> > > >
> >> > > What does curl -vk show?
> >> > >
> >> >
> >> > Unfortunately, no difference. Follows:
> >> >
> >> > $ curl --insecure -vk https://fqdn2
> >> > * Host fqdn2:443 was resolved.
> >> > * IPv6: (none)
> >> > * IPv4: 127.0.0.1
> >> > * Trying 127.0.0.1:443...
> >> > * Connected to fqdn2 (127.0.0.1) port 443
> >> > * ALPN: curl offers h2,http/1.1
> >> > * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> >> > * TLSv1.3 (IN), TLS handshake, Server hello (2):
> >> > * TLSv1.3 (IN), TLS handshake, Unknown (8):
> >> > * TLSv1.3 (IN), TLS handshake, Certificate (11):
> >> > * TLSv1.3 (IN), TLS handshake, CERT verify (15):
> >> > * TLSv1.3 (IN), TLS handshake, Finished (20):
> >> > * TLSv1.3 (OUT), TLS handshake, Finished (20):
> >> > * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
> >> > * ALPN: server did not agree on a protocol. Uses default.
> >> > * Server certificate:
> >> > * subject: C=BR; ST=MS;
Re: TSO and LRO while forwarding traffic
On Tue, Jan 09, 2024 at 05:14:47AM +, Valdrin MUJA wrote: > I've got a question about TSO and LRO: > > How does enabling TSO and/or LRO on the Ethernet cards of a network > device that will serve as a router and firewall affect the forward > traffic of users accessing the internet behind this device? LRO will merge several receiving packets together by hardware. Later on the outgoing path, TSO will be used to split them intro peaces of max. mss size. Thus, TCP segments will be reformed be these features. TSO alone does not affect routing. Without LRO, TSO is just used for traffic initiated by your router. > In short, should I keep these features on or turn them off in my OpenBSD > firewall? > What is the OpenBSD recommendation? I recommend to keep it turned on. Just turn it off, if you case of errors. When you have issues which you can fix by turning it off, just send us a bug report. bye, Jan
Re: mountd
On Tue, Jan 09, 2024 at 10:13:56AM +0300, 4 wrote:
> >> i'm quoting the man page for mountd:
> >> The -n flag historically allowed clients to use non-reserved ports
> >> when
> >> communicating with mountd. In OpenBSD, a reserved port is always
> >> used.
> >> "reserved port". "always".. however the port is different each time. how
> >> to deal with this?
> >>
>
> > resreved means that the port number is below 1024. The RPC system,
> > (which is used to implement NFS) iuses portmapper to determine which
> > service runs on which port. What problem are you trying to solve?
>
> > -Otto
> i'm trying to solve the problem of which port need to open on the pf.
> the variant of processing rpcinfo output with script and then putting
> a rules into an anchor is not very pretty. especially considering that
> this is not enough, and i still need to repeat this action by cron.
> this variant works, but it's not even close to how it should work %\
> why i should solve such the task at a time when humanity is flying to
> conquer Mars?
>
No need to be so dramatic, the ports only change when the service is
restarted, so there is no need for constant monitoring and/or script
running. Either you run the script (a one-liner, by the way, see below)
on the server upon starting the daemon, or run it on the firewall via
cron at appropriate intervals (I'm assuming you don't reboot your server
every 10 minutes, so it can be run at large intervals).
You may not find it "very pretty", but hey, it works fine. NFS over
firewalls decidedly isn't great, but it's the smallest of my NFS woes.
OT, they got to the moon with the computing power of a pocket
calculator, and the physics of going to mars are pretty much the same,
so I find your argument moot. Also, its literally a one line script.
Not exactly rocket science.
rpcinfo -p a.b.c.d | awk 'NR>1 { print "pass inet proto " $3 " to port "
$4 " flags any" }' | pfctl -a "portmap/$a" -f -
--
Re: mountd
On Tue, Jan 09, 2024 at 10:13:56AM +0300, 4 wrote: > i'm trying to solve the problem of which port need to open on the pf. the > variant of processing rpcinfo output with script and then putting a rules > into an anchor is not very pretty. especially considering that this is not > enough, and i still need to repeat this action by cron. this variant works, > but it's not even close to how it should work %\ why i should solve such the > task at a time when humanity is flying to conquer Mars? In my possibly very traditinal thinking I would suggest that if you need to mount file systems located on the other side of a firewall, it would be useful to consider whether your network design is in fact fit for the purpose. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://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: mountd
On Tue, Jan 09, 2024 at 10:13:56AM +0300, 4 wrote: > >> i'm quoting the man page for mountd: > >> The -n flag historically allowed clients to use non-reserved ports > >> when > >> communicating with mountd. In OpenBSD, a reserved port is always > >> used. > >> "reserved port". "always".. however the port is different each time. how > >> to deal with this? > >> > > > resreved means that the port number is below 1024. The RPC system, > > (which is used to implement NFS) iuses portmapper to determine which > > service runs on which port. What problem are you trying to solve? > > > -Otto > i'm trying to solve the problem of which port need to open on the pf. the > variant of processing rpcinfo output with script and then putting a rules > into an anchor is not very pretty. especially considering that this is not > enough, and i still need to repeat this action by cron. this variant works, > but it's not even close to how it should work %\ why i should solve such the > task at a time when humanity is flying to conquer Mars? > These kind of off-topic remarks won't help you getting answers, -Otto
Re: mountd
>> i'm quoting the man page for mountd: >> The -n flag historically allowed clients to use non-reserved ports when >> communicating with mountd. In OpenBSD, a reserved port is always used. >> "reserved port". "always".. however the port is different each time. how to >> deal with this? >> > resreved means that the port number is below 1024. The RPC system, > (which is used to implement NFS) iuses portmapper to determine which > service runs on which port. What problem are you trying to solve? > -Otto i'm trying to solve the problem of which port need to open on the pf. the variant of processing rpcinfo output with script and then putting a rules into an anchor is not very pretty. especially considering that this is not enough, and i still need to repeat this action by cron. this variant works, but it's not even close to how it should work %\ why i should solve such the task at a time when humanity is flying to conquer Mars?
