Re: ChatGPT writes a pf.conf by spec, earns an "F" grade
On 8/6/23 06:32, Sean Kamath wrote: On Jun 7, 2023, at 01:28, Peter N. M. Hansteen wrote: Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those who would be interested. So in the thread that made you try it (https://bsd.network/@dch/110501874752402311) they said: "@pitrh I’m still waiting for it to explain my pf .conf setup to me” Which is kinda the inverse of “make me a pf.conf file”. I am curious if “explain to me this pf.conf in plain english” would work. :-) Probably about as well. It's the "Chinese Room" AI concept all over again. No "understanding", just rules. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: ChatGPT writes a pf.conf by spec, earns an "F" grade
> On Jun 7, 2023, at 01:28, Peter N. M. Hansteen wrote: > > Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those > who would be interested. So in the thread that made you try it (https://bsd.network/@dch/110501874752402311) they said: "@pitrh I’m still waiting for it to explain my pf .conf setup to me” Which is kinda the inverse of “make me a pf.conf file”. I am curious if “explain to me this pf.conf in plain english” would work. :-) Sean
Re: paket tag, veb0, virtual machine and relayd
On Wed, Jun 7, 2023 at 4:38 AM Stuart Henderson wrote: > On 2023-06-07, Nick Bouliane wrote: > > I have a bridge veb0 to which is connected tap1, the interface of a > virtual > > machine. > > On the bridge I have a rule for tap1: > > pass in on tap1 src 11:22:33:44:55:66 tag VM1 > > > > In the bridge I also have an interface vport0 with the IP address > > 1921.168.0.1 > > This virtual machine has the IP 192.168.0.2 > > > > When a packet comes out of the VM (i.e: curl) it gets tagged by the rule > > that I have on the veb bridge. > > I know the tag is working because I can drop packets with pf (pf.conf) > if I > > add that rule: > > block in on tap1 tagged VM1 > > > > I have relayd listening on vport0 and in my relayd.conf I have this > filter: > > pass path "/something.html" tagged VM1 > > Those "rule tags" are specific to relayd and are not connected with the > PF tags at all. > > The only place relayd interacts with PF tags is if you use "pftag" in a > relayd redirection. > Thank you for enlightening me ! > > > -- > Please keep replies on the mailing list. > >
Re: paket tag, veb0, virtual machine and relayd
On 2023-06-07, Nick Bouliane wrote: > I have a bridge veb0 to which is connected tap1, the interface of a virtual > machine. > On the bridge I have a rule for tap1: > pass in on tap1 src 11:22:33:44:55:66 tag VM1 > > In the bridge I also have an interface vport0 with the IP address > 1921.168.0.1 > This virtual machine has the IP 192.168.0.2 > > When a packet comes out of the VM (i.e: curl) it gets tagged by the rule > that I have on the veb bridge. > I know the tag is working because I can drop packets with pf (pf.conf) if I > add that rule: > block in on tap1 tagged VM1 > > I have relayd listening on vport0 and in my relayd.conf I have this filter: > pass path "/something.html" tagged VM1 Those "rule tags" are specific to relayd and are not connected with the PF tags at all. The only place relayd interacts with PF tags is if you use "pftag" in a relayd redirection. -- Please keep replies on the mailing list.
ChatGPT writes a pf.conf by spec, earns an "F" grade
Prompted by a followup on Mastodon, I was enticed to see what feeding a prose spec for a pf.conf to ChatGPT would produce. TL;DR: it failed miserably, but in a way that would have lead the gullible to try it out raw, leading them down a route that would lead to loads of misery and frustration. Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those who would be interested. All the best, Peter -- 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.
