Re: dhcpleased[59824]: sendto: Permission denied
You did not even look at the list rules. "Do your homework first.. No desire to deprive you of a learning experience." Nobody is here to hold your hand. They do too much of that at work. You must be knowledgeable of the subject. If not, use Google (many web sites for teaching) or switch to FreeBSD with support for the novice. The boss gave up a DARPA research grant rather than make changes for them. On Sat, Jul 8, 2023, 11:42 Mark wrote: > What kind of anger and rudeness is that? > > We're all (at least those who ask questions) learning here. @misc is for > that, right? > > And I think you should learn, too. You must. > > You said it's -no way- related to PF. Yet, it was PF in the end. > > Anyway, stop blindly insulting people here. > > > > Zack Newman , 8 Tem 2023 Cmt, 20:02 tarihinde > şunu yazdı: > > > I am only replying to this in the interest of closure since I am > > already part of this thread, but disclaimer here is some tough love. > > > > You need to stop being lazy and actually understand your network > > topology, the security/privacy real or contrived-I see you adhere to > > the whole security by obscurity nonsense with the masking of the last > > 2 octets of that IPv4 address-and pf. Besides your first attempt at > > "magically" fixing your problem which was doomed to fail for the > > reasons I gave, you are now asking for people to guess what rules you > > need. > > > > Do you "really need to block 'martians'"? Seriously? Ignoring the > > philosophical trap of what you mean by "need", do you even know what a > > "martian" is; and if not, then why are you blindly blocking them? If you > > don't know what you are doing, then just don't do it. I don't even know > > what a "martian" is other than an alien thing from outer space. In the > > interest of providing a modicum of constructive criticism as opposed to > > just criticism, here you go: > > > > > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > > . > > > > > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > > Not sure if that is what "martians" refer to, but your "martians" > > appear to be a proper subset of what is listed there or at least close. > > With that information, seek out what those blocks mean and decide based > > on your topology and security/privacy needs if you should block > > them. > > > > Should I block 192.168.3.2 on my laptop? What about > > ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 > > on my VPS? Those are obviously rhetorical questions as only I know (or > > at least _should_ know) what my network topology is like, what > > services I run, to whom I want to serve, etc. > > > > You clearly blindly copied and pasted some rules you found without > > knowing what they do or why you are doing it as evidenced by the rather > > embarrassing blocking of your DHCP server. If you are going to be lazy > > and just want stuff to magically work, then disable pf. Bam. Don't need > > to worry about anything. If you plan to block stuff though, then > > actually learn about what you are blocking and why. > > > > Here is a tiny olive branch: I would allow all egress traffic from your > > VPS since that is within _my_ wheel of trust. If my VPS is trying to > > talk to an IP, then either it is already compromised or at least running > > software it shouldn't at which point I have bigger problems; or it > > needs to. Does that "magical" rule apply to you? I don't know, and it > > sounds like you don't either. Even if it does, you will still need to > > decide if you want to allow other IPs to send traffic; but that requires > > you to learn more about your topology, pf, and security/privacy needs. > > > > >
Re: dhcpleased[59824]: sendto: Permission denied
Jul 8, 2023 20:42:57 Mark wrote: > Anyway, stop blindly insulting people here. More blood, more fun.. indeed. I guess this should complaint with some specs from Texas, uh? PS: Mark, don't give it up we are all with you! It is just the next big frontier to do mailing :)
Re: Intel DRM error on T 440
On 7/6/23 01:46, Jonathan Drews wrote: uname: OpenBSD 7.3 GENERIC.MP#1125 amd64 I get the following error message when my Thinkpad T440 wakes up: drm:pid73944:intel_dp_aux_wait_done *ERROR* [drm] *ERROR* AUX A/DDI A/PHY A: did not complete or timeout within 10ms (status 0xa01300e1) I have Googled that error message and no fixes turn up. In other respects, my OpenBSD T440 works just great. My rc.conf.local contains this:> apmd_flags=-A pf=YES pkg_scripts=messagebus cupsd mysqld xenodm_flags= Any suggestions as to what I may have misconfigured would be helpful. I have loaded the firmware using fw_update. This error did not occur in OpenBSD 7.2. I believe what you are seeing is an informative message about what is going on under the covers, not an problem you (as a user) need to deal with if everything is working as it should be. However, if things are NOT working as they should, messages like this are potentially helpful to developers to track down the problem. Hardware is often imperfect, and often doesn't behave as documented, and has to be "fixed" (or more accurately, worked around) in software. I think that's all you are seeing here -- notification that something was worked around (or at least, didn't behave as expected) -- if there are no other symptoms. Nick.
Re: dhcpleased[59824]: sendto: Permission denied
In the interest of transparency, an individual was kind enough to teach me that the term "martian" is in fact defined in RFC 1812: https://www.rfc-editor.org/rfc/rfc1812#page-149 Thank you for the information.
Re: dhcpleased[59824]: sendto: Permission denied
Clearly you cannot read either. Please show me where I said "it's -no way- related to PF". I'm waiting... I'll do the work for you. "Certainly could be. If this happens consistently around a particular time, you can 'live dangerously' and allow all traffic temporarily to see if the issue is resolved. More safely, use tcpdump(8) to see if you can find the problem." Hm, looks like I said that PF "certainly could be" the problem. That is literally the first thing I said in this thread. I even concluded that initial e-mail with the following: "If it is a pf(4) issue, then it not related to that traffic." Look at the antecedent there. I did not claim PF was not an issue. What I _correctly_ claimed was that the issue was _not_ related to blocking DHCP traffic on UDP port 67. If that claim is wrong, please prove me wrong. I am not being facetious either. I would love to _learn_ where I am wrong. I'll even go to the lengths of showing you how you could go about proving that claim wrong. See if you have any issues with the following rules: # Options. set block-policy drop # Macros. ext_if = # Filtering rules. block in quick on $ext_if inet proto udp to port 68 block out quick on $ext_if inet proto udp to port 67 pass quick If you have issues, then my claim was in fact wrong. Which is great! I get to learn something. And I think you should learn, too. You must. I agree which is why I learned about my network topology and what rules in my pf.conf(5) do instead of crossing my fingers and hoping some rules I found on the Internet would work. I even offered to learn how exactly your FreeBSD setup worked despite that being a different OS. You never took me up on that offer on trying to understand what is happening though. Instead you were again lazily content that adding a rule to the likely list of rules you didn't even understand was good enough. I will hopefully learn to have much lower standards for the people on @misc, and perhaps wait until I at least have had a cup of coffee before I reply.
Re: dhcpleased[59824]: sendto: Permission denied
What kind of anger and rudeness is that? We're all (at least those who ask questions) learning here. @misc is for that, right? And I think you should learn, too. You must. You said it's -no way- related to PF. Yet, it was PF in the end. Anyway, stop blindly insulting people here. Zack Newman , 8 Tem 2023 Cmt, 20:02 tarihinde şunu yazdı: > I am only replying to this in the interest of closure since I am > already part of this thread, but disclaimer here is some tough love. > > You need to stop being lazy and actually understand your network > topology, the security/privacy real or contrived-I see you adhere to > the whole security by obscurity nonsense with the masking of the last > 2 octets of that IPv4 address-and pf. Besides your first attempt at > "magically" fixing your problem which was doomed to fail for the > reasons I gave, you are now asking for people to guess what rules you > need. > > Do you "really need to block 'martians'"? Seriously? Ignoring the > philosophical trap of what you mean by "need", do you even know what a > "martian" is; and if not, then why are you blindly blocking them? If you > don't know what you are doing, then just don't do it. I don't even know > what a "martian" is other than an alien thing from outer space. In the > interest of providing a modicum of constructive criticism as opposed to > just criticism, here you go: > > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > . > > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > Not sure if that is what "martians" refer to, but your "martians" > appear to be a proper subset of what is listed there or at least close. > With that information, seek out what those blocks mean and decide based > on your topology and security/privacy needs if you should block > them. > > Should I block 192.168.3.2 on my laptop? What about > ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 > on my VPS? Those are obviously rhetorical questions as only I know (or > at least _should_ know) what my network topology is like, what > services I run, to whom I want to serve, etc. > > You clearly blindly copied and pasted some rules you found without > knowing what they do or why you are doing it as evidenced by the rather > embarrassing blocking of your DHCP server. If you are going to be lazy > and just want stuff to magically work, then disable pf. Bam. Don't need > to worry about anything. If you plan to block stuff though, then > actually learn about what you are blocking and why. > > Here is a tiny olive branch: I would allow all egress traffic from your > VPS since that is within _my_ wheel of trust. If my VPS is trying to > talk to an IP, then either it is already compromised or at least running > software it shouldn't at which point I have bigger problems; or it > needs to. Does that "magical" rule apply to you? I don't know, and it > sounds like you don't either. Even if it does, you will still need to > decide if you want to allow other IPs to send traffic; but that requires > you to learn more about your topology, pf, and security/privacy needs. > >
Re: IPsec "road warrior" VPN not getting set up properly.
Thus said Anthony Coulter on Thu, 06 Jul 2023 21:52:54 -0400: > I would also suggest comparing the "hackiness" of NDP proxying to the > hackiness of NAT, which is how we solve this same problem in IPv4. I realize I'm coming in late to this discussion, and may not actually have anything of value to add, but... I'm not sure how NDP proxying and NAT are related at all. I seems to me that NDP proxying is more akin to proxy ARP than NAT: http://man.openbsd.org/arp#s Andy
Re: dhcpleased[59824]: sendto: Permission denied
I am only replying to this in the interest of closure since I am already part of this thread, but disclaimer here is some tough love. You need to stop being lazy and actually understand your network topology, the security/privacy real or contrived-I see you adhere to the whole security by obscurity nonsense with the masking of the last 2 octets of that IPv4 address-and pf. Besides your first attempt at "magically" fixing your problem which was doomed to fail for the reasons I gave, you are now asking for people to guess what rules you need. Do you "really need to block 'martians'"? Seriously? Ignoring the philosophical trap of what you mean by "need", do you even know what a "martian" is; and if not, then why are you blindly blocking them? If you don't know what you are doing, then just don't do it. I don't even know what a "martian" is other than an alien thing from outer space. In the interest of providing a modicum of constructive criticism as opposed to just criticism, here you go: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml Not sure if that is what "martians" refer to, but your "martians" appear to be a proper subset of what is listed there or at least close. With that information, seek out what those blocks mean and decide based on your topology and security/privacy needs if you should block them. Should I block 192.168.3.2 on my laptop? What about ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 on my VPS? Those are obviously rhetorical questions as only I know (or at least _should_ know) what my network topology is like, what services I run, to whom I want to serve, etc. You clearly blindly copied and pasted some rules you found without knowing what they do or why you are doing it as evidenced by the rather embarrassing blocking of your DHCP server. If you are going to be lazy and just want stuff to magically work, then disable pf. Bam. Don't need to worry about anything. If you plan to block stuff though, then actually learn about what you are blocking and why. Here is a tiny olive branch: I would allow all egress traffic from your VPS since that is within _my_ wheel of trust. If my VPS is trying to talk to an IP, then either it is already compromised or at least running software it shouldn't at which point I have bigger problems; or it needs to. Does that "magical" rule apply to you? I don't know, and it sounds like you don't either. Even if it does, you will still need to decide if you want to allow other IPs to send traffic; but that requires you to learn more about your topology, pf, and security/privacy needs.
Re: dhcpleased[59824]: sendto: Permission denied
So it seems PF was indeed blocking my DHCP stuff. After disabling PF for a
long time, I grabbed this:
"Jul 7 19:13:54 mailsrv dhcpleased[15591]: adding 95.214.xxx.xxx to vio0
(lease from 172.31.1.1)"
from /var/log/daemon file. Noticed; "lease from 172.31.1.1" that's the DHCP
server of my server provider it seems.
(Still weird, as I receive an IP starting like; 95.214.xx from that,
anyways)
AND, I had in my pf.conf file;
martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }"
block drop in quick on $ext_if from $martians to any
block drop out quick on $ext_if from any to $martians
See "172.16.0.0/12" there among the IPs?
Removed that block from the martians and it seems my problem is solved.
Question: for a mail/web server VPS box with a single public IP with only
one NIC, do I really need to block "martians"?
Best wishes.
Mark.
Otto Moerbeek , 4 Tem 2023 Sal, 21:44 tarihinde şunu yazdı:
> On Mon, Jul 03, 2023 at 10:34:24AM -0600, Zack Newman wrote:
>
> > On 7/3/23 11:25, Mark wrote:
> > > I'm getting (I think once per day) "dhcpleased[59824]: sendto:
> Permission
> > > denied" error message in my daemon and messages log files.
> > >
> > > I think that's happening due to my PF configuration.
> >
> > Certainly could be. If this happens consistently around a particular
> > time, you can "live dangerously" and allow all traffic temporarily to
> > see if the issue is resolved. More safely, use tcpdump(8) to see if you
> > can find the problem.
> >
> > > I tried to add:
> > > pass log quick on $ext_if proto udp from any to any port = 67
> > > in my pf.conf file, didn't help.
> >
> > Completely useless. DHCP traffic never makes its way to pf(4) due to
> > being handled by bpf(4) first, so you don't need such a rule-in fact
> > you could explicitly block such traffic, and it won't matter. Proof:
>
> That may be true for reading dhcp packets, but in some cases
> dhcpleased sends UDP datagram lika any ordinary program, for other
> cases it uses BPF for sending. As the error reported is for sending,
> it *is* possible that pf plays a role.
>
> -Otto
>
> >
> > router# cat /etc/pf.conf
> > # Options.
> > set block-policy drop
> >
> > # Macros.
> > wan = em0
> >
> > # Filtering rules.
> > block in quick on $wan inet proto udp to port 68
> > block out quick on $wan inet proto udp to port 67
> > pass quick
> >
> > router# rcctl stop dhcpcd
> > dhcpcd(ok)
> > router# rm -rf /var/run/dhcpcd/
> > router# ifconfig em0 -inet
> > router# ifconfig em0 -inet6
> > router# ifconfig em0 down
> > router# pfctl -f /etc/pf.conf
> > router# tcpdump -ntt -i em0 -w pkts.dat 'udp and ip and (dst port 67 or
> dst port 68)' &
> > [1] 98425
> > router# tcpdump: listening on em0, link-type EN10MB
> > router# rcctl start dhcpcd
> > dhcpcd(ok)
> > router# pkill -x tcpdump
> >
> > 12551 packets received by filter
> > 0 packets dropped by kernel
> > router# tcpdump -nr pkts.dat
> > 10:02:29.663056 0.0.0.0.68 > 255.255.255.255.67: xid:0x3544268 [|bootp]
> > 10:02:32.802098 0.0.0.0.68 > 255.255.255.255.67: xid:0x3544268 secs:3
> [|bootp]
> > 10:02:32.857942 96.120.140.45.67 > 73.78.65.184.68: xid:0x3544268
> Y:73.78.65.184 G:96.120.140.45 [|bootp] [tos 0x10]
> >
> > The use of dhcpcd(8) is not relevant. I choose to use it for both DHCPv6
> > and DHCP so that I only have one daemon. I am _not_ recommending its
> > use over dhcpleased(8). The point is to show that such traffic is
> > allowed regardless of what rules you have in pf(4).
> >
> > If it is a pf(4) issue, then it not related to that traffic.
> >
>
>
Re: Self-hosting OpenBSD server, any documentation?
On 7/8/23 1:03 AM, Theo de Raadt wrote: Jonathan Drews wrote: On Sat, Jul 8, 2023, at 01:42, Jonas Borchelt wrote: The book "Absolute OpenBSD" is an excellent choice to expand your knowledge of the OpenBSD operating system. It was written by Michael W. Lucas and is regarded as a comprehensive resource for beginners and advanced users alike. It covers various aspects of OpenBSD, including installation, network security, system administration, and more. Enjoy reading it! There is another book by Michael Lucas that may be of benefit: "Httpd and Relayd Mastery". You can buy it as a *.pdf from Tilted Windmill Press. One day I really should try this self-hosting which seems to be all the rage. For those of us not very good at promoting, it turns out to be a very self-serving endeavor.
Re: Audio issue: noise/interference
On Fri, Jul 07, 2023 at 06:23:26PM -0400, Ricky Cintron wrote: > I recently resolved an audio issue where I could hear a constant, light > static noise in my earphones. It wasn't loud or distracting, but it was > always there. The solution was to remove 'mix' as a source for mix2 and > mix3. > > However, once I got rid of that static, I noticed some additional noise > that was apparently hidden behind the original static. Compared to the > first issue, this noise is quieter and not constant. Anyway, it > manifests itself in the following ways: > > 1) Very light static noise that never increases, but I've noticed that > when I load a web page (YouTube, for example), the noise is silenced > until the page finishes loading. This also sometimes happens when I > move the mouse cursor around the web browser window, but very briefly. > It's easier to notice when loading a page since it lasts longer. > > 2) Moving the mouse generates a barely audible buzzing sound, but this > either doesn't occur or is barely noticeable when moving the cursor on > a web browser window. > > To troubleshoot, I inspected all the cables in the back of the > computer (power, DP, ethernet, USB keyboard, USB mouse, speakers/line), > and unplugged them (except the power cable) one at a time. I didn't > hear a difference, good or bad. I also turned some mixerctl knobs with > no noticeable effects. > > Does anyone have any ideas? This isn't a big deal since I can't notice > it while listening to audio, and it's pretty easy to tune out even > without audio, but I'd still like to remove it if possible. I'm > considering buying a USB audio interface, so if that even works, that > could be a solution. Check that your AC power plug is connected to the ground. Possibly plug the computer in another plug, in another room, and see if this makes any difference. FWIW, I managed to reduce similar noises by putting ferrite rings on most cables, the HDMI cable was a significant source of noise in my case. I didn't try to put ferrite rings on the internal cables (ex. those between the power supply and the motherboard), but it might make sense as well. Certain motherboards are just not well designed and noise might remain, no matter what you do. A good audio interface would solve this problem, assuming you're using speakers that don't generate noise or passive headphones. HTH
Re: Self-hosting OpenBSD server, any documentation?
https://www.openbsd.org/faq/index.html https://www.openbsdhandbook.com/ https://openbsdrouterguide.net/ These are easy to follow introductions. Also the man pages, all of the mentioned refer to them. On 7/8/23 09:32, lisper.drea...@tutanota.com wrote: Hi, misc! What documents would you recommend for setting up a self-hosted OpenBSD server? This way I might learn more about OpenBSD and what is under its hood. Cheers, Andy
Re: Self-hosting OpenBSD server, any documentation?
Jonathan Drews wrote: > > > > On Sat, Jul 8, 2023, at 01:42, Jonas Borchelt wrote: > > The book "Absolute OpenBSD" is an excellent choice to expand your knowledge > > of the OpenBSD operating system. It was written by Michael W. Lucas and is > > regarded as a comprehensive resource for beginners and advanced users > > alike. It covers various aspects of OpenBSD, including installation, > > network security, system administration, and more. Enjoy reading it! > > > There is another book by Michael Lucas that may be of benefit: "Httpd and > Relayd Mastery". > You can buy it as a *.pdf from Tilted Windmill Press. > One day I really should try this self-hosting which seems to be all the rage.
Re: Self-hosting OpenBSD server, any documentation?
On Sat, Jul 8, 2023, at 01:42, Jonas Borchelt wrote: > The book "Absolute OpenBSD" is an excellent choice to expand your knowledge > of the OpenBSD operating system. It was written by Michael W. Lucas and is > regarded as a comprehensive resource for beginners and advanced users alike. > It covers various aspects of OpenBSD, including installation, network > security, system administration, and more. Enjoy reading it! > There is another book by Michael Lucas that may be of benefit: "Httpd and Relayd Mastery". You can buy it as a *.pdf from Tilted Windmill Press.
Re: Self-hosting OpenBSD server, any documentation?
The book "Absolute OpenBSD" is an excellent choice to expand your knowledge of the OpenBSD operating system. It was written by Michael W. Lucas and is regarded as a comprehensive resource for beginners and advanced users alike. It covers various aspects of OpenBSD, including installation, network security, system administration, and more. Enjoy reading it! Best Jonas > Am 08.07.2023 um 09:35 schrieb lisper.drea...@tutanota.com: > > Hi, misc! > What documents would you recommend for setting up a self-hosted OpenBSD > server? > This way I might learn more about OpenBSD and what is under its hood. > > Cheers, > Andy > > -- > Sent with Tutanota, enjoy secure & ad-free emails.
Self-hosting OpenBSD server, any documentation?
Hi, misc! What documents would you recommend for setting up a self-hosted OpenBSD server? This way I might learn more about OpenBSD and what is under its hood. Cheers, Andy -- Sent with Tutanota, enjoy secure & ad-free emails.
