Re: bce(4) - descriptor error
On 1/22/2015 3:40 PM, Mark Kettenis wrote: Date: Thu, 22 Jan 2015 19:38:42 +0100 (CET) From: Mark Kettenis Date: Thu, 22 Jan 2015 18:04:44 +0100 From: Stefan Sperling It looks as if some ring descriptor data is still being allocated with bus_dmamem_alloc(). That function probably doesn't respect the mapping constraints bce(4) hardware requires. This diff makes bce use the same memory allocation APIs as bwi(4) is using. Some bwi devices have the same 1GB problem and I know the bwi code works fine with such devices. So perhaps applying the same approach to bce will fix your issue. I'd really prefer it if we'd solve this issue by promoting _bus_dmamem_alloc_range() to a first class citizen. I'll try to recover an old diff that did this tonight. No harm in testing this diff though to verify that it indeed solves the issue. So here is the alternative diff. Only amd64/i386 are actually implemented, but those are the only platforms we support bce(4) on. This diff from mark.kettenis also seems to work with 4GM of RAM installed. I also did the ping -f and scp tests. It seems that performance may be a bit better with this patch but it is hard to tell for sure. Thanks! -- John Merriam
Re: bce(4) - descriptor error
On 1/22/2015 12:04 PM, Stefan Sperling wrote: It looks as if some ring descriptor data is still being allocated with bus_dmamem_alloc(). That function probably doesn't respect the mapping constraints bce(4) hardware requires. This diff makes bce use the same memory allocation APIs as bwi(4) is using. Some bwi devices have the same 1GB problem and I know the bwi code works fine with such devices. So perhaps applying the same approach to bce will fix your issue. Diff is compile-tested only due to lack of hardware at my end. This diff from stsp seems to work with 4GB of RAM installed. In addition to the ping -f test I also did an scp test and performance looks good. Thanks! -- John Merriam
Re: bce(4) - descriptor error
On 2015-01-22 15:40, Mark Kettenis wrote: Date: Thu, 22 Jan 2015 19:38:42 +0100 (CET) From: Mark Kettenis > Date: Thu, 22 Jan 2015 18:04:44 +0100 > From: Stefan Sperling > > On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote: > > So, what could be the problem then? Theoretically it did work as of the > > 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This > > message: > > > > http://marc.info/?l=openbsd-tech&m=130217668909255 > > > > seems to verify that it did actually work at one point. > > It looks as if some ring descriptor data is still being allocated with > bus_dmamem_alloc(). That function probably doesn't respect the mapping > constraints bce(4) hardware requires. > > This diff makes bce use the same memory allocation APIs as bwi(4) is > using. Some bwi devices have the same 1GB problem and I know the bwi > code works fine with such devices. So perhaps applying the same approach > to bce will fix your issue. I'd really prefer it if we'd solve this issue by promoting _bus_dmamem_alloc_range() to a first class citizen. I'll try to recover an old diff that did this tonight. No harm in testing this diff though to verify that it indeed solves the issue. So here is the alternative diff. Only amd64/i386 are actually implemented, but those are the only platforms we support bce(4) on. Your diff also seems to work and pass the ping -f test with <= 1GB RAM. I will also test this tonight with 4GB RAM installed in the machine. Thanks -- John Merriam
Re: Default pf-ruleset not using /etc/services
On 22 January 2015 at 07:59, wrote:
> Hello,
>
> I recently lost access to a co-located server, because I used a non-standard
> port for ssh access.
>
> The default pf-ruleset (in /etc/rc) had kicked in.
>
> Would it be more correct to have the rulset in /etc/rc use /etc/services
> instead of hardcoding port 22 into the rule?
>
> Something like this;
>
> 326,327c326,327
> < RULES="$RULES\npass in proto tcp from any to any port 22 keep state"
> < RULES="$RULES\npass out proto { tcp, udp } from any to any port 53
> keep state"
> ---
>>
>> RULES="$RULES\npass in proto tcp from any to any port ssh keep
>> state"
>> RULES="$RULES\npass out proto { tcp, udp } from any to any port
>> domain keep state"
>
>
>
> --
> Kind regards
> Brian Vangsgaard
>
Fixed in -current. All hard coded port numbers (22, 53, 111, 2049)
replaced with names (ssh, domain, sunrpc, nfsd).
Ken
Re: bce(4) - descriptor error
> Date: Thu, 22 Jan 2015 19:38:42 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Thu, 22 Jan 2015 18:04:44 +0100
> > From: Stefan Sperling
> >
> > On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote:
> > > So, what could be the problem then? Theoretically it did work as of the
> > > 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This
> > > message:
> > >
> > > http://marc.info/?l=openbsd-tech&m=130217668909255
> > >
> > > seems to verify that it did actually work at one point.
> >
> > It looks as if some ring descriptor data is still being allocated with
> > bus_dmamem_alloc(). That function probably doesn't respect the mapping
> > constraints bce(4) hardware requires.
> >
> > This diff makes bce use the same memory allocation APIs as bwi(4) is
> > using. Some bwi devices have the same 1GB problem and I know the bwi
> > code works fine with such devices. So perhaps applying the same approach
> > to bce will fix your issue.
>
> I'd really prefer it if we'd solve this issue by promoting
> _bus_dmamem_alloc_range() to a first class citizen. I'll try to
> recover an old diff that did this tonight.
>
> No harm in testing this diff though to verify that it indeed solves
> the issue.
So here is the alternative diff. Only amd64/i386 are actually
implemented, but those are the only platforms we support bce(4) on.
Index: dev/pci/if_bce.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bce.c,v
retrieving revision 1.40
diff -u -p -r1.40 if_bce.c
--- dev/pci/if_bce.c22 Dec 2014 02:28:51 - 1.40
+++ dev/pci/if_bce.c22 Jan 2015 20:38:05 -
@@ -315,8 +315,9 @@ bce_attach(struct device *parent, struct
* XXX PAGE_SIZE is wasteful; we only need 1KB + 1KB, but
* due to the limition above. ??
*/
- if ((error = bus_dmamem_alloc(sc->bce_dmatag, 2 * PAGE_SIZE,
- PAGE_SIZE, 2 * PAGE_SIZE, &seg, 1, &rseg, BUS_DMA_NOWAIT))) {
+ if ((error = bus_dmamem_alloc_range(sc->bce_dmatag, 2 * PAGE_SIZE,
+ PAGE_SIZE, 2 * PAGE_SIZE, &seg, 1, &rseg, BUS_DMA_NOWAIT,
+ (bus_addr_t)0, (bus_addr_t)0x3fff))) {
printf(": unable to alloc space for ring descriptors, "
"error = %d\n", error);
uvm_km_free(kernel_map, (vaddr_t)sc->bce_data,
Index: arch/amd64/amd64/bus_dma.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
retrieving revision 1.46
diff -u -p -r1.46 bus_dma.c
--- arch/amd64/amd64/bus_dma.c 16 Nov 2014 12:30:56 - 1.46
+++ arch/amd64/amd64/bus_dma.c 22 Jan 2015 20:38:05 -
@@ -424,7 +424,7 @@ _bus_dmamem_alloc(bus_dma_tag_t t, bus_s
* memory under the 4gig boundary.
*/
return (_bus_dmamem_alloc_range(t, size, alignment, boundary,
- segs, nsegs, rsegs, flags, (paddr_t)0, (paddr_t)0x));
+ segs, nsegs, rsegs, flags, (bus_addr_t)0, (bus_addr_t)0x));
}
/*
@@ -662,7 +662,7 @@ _bus_dmamap_load_buffer(bus_dma_tag_t t,
int
_bus_dmamem_alloc_range(bus_dma_tag_t t, bus_size_t size, bus_size_t alignment,
bus_size_t boundary, bus_dma_segment_t *segs, int nsegs, int *rsegs,
-int flags, paddr_t low, paddr_t high)
+int flags, bus_addr_t low, bus_addr_t high)
{
paddr_t curaddr, lastaddr;
struct vm_page *m;
Index: arch/amd64/include/bus.h
===
RCS file: /home/cvs/src/sys/arch/amd64/include/bus.h,v
retrieving revision 1.31
diff -u -p -r1.31 bus.h
--- arch/amd64/include/bus.h29 Mar 2014 18:09:28 - 1.31
+++ arch/amd64/include/bus.h22 Jan 2015 20:38:05 -
@@ -594,6 +594,9 @@ struct bus_dma_tag {
*/
int (*_dmamem_alloc)(bus_dma_tag_t, bus_size_t, bus_size_t,
bus_size_t, bus_dma_segment_t *, int, int *, int);
+ int (*_dmamem_alloc_range)(bus_dma_tag_t, bus_size_t, bus_size_t,
+ bus_size_t, bus_dma_segment_t *, int, int *, int,
+ bus_addr_t, bus_addr_t);
void(*_dmamem_free)(bus_dma_tag_t,
bus_dma_segment_t *, int);
int (*_dmamem_map)(bus_dma_tag_t, bus_dma_segment_t *,
@@ -622,6 +625,9 @@ struct bus_dma_tag {
#definebus_dmamem_alloc(t, s, a, b, sg, n, r, f) \
(*(t)->_dmamem_alloc)((t), (s), (a), (b), (sg), (n), (r), (f))
+#definebus_dmamem_alloc_range(t, s, a, b, sg, n, r, f, l, h) \
+ (*(t)->_dmamem_alloc_range)((t), (s), (a), (b), (sg), \
+ (n), (r), (f), (l), (h))
#definebus_dmamem_free(t, sg, n) \
(*(t)->_dmamem_free)((t), (sg), (n))
#definebus_dmamem_map(t, sg, n, s, k, f) \
@@ -686,6 +692,6 @@ paddr_t _bus_dmamem_mmap(bus_dma_tag_t t
int_bus_dmamem_alloc_range(bus_dma_tag_t ta
Re: bce(4) - descriptor error
On Thu, 22 Jan 2015, Stefan Sperling wrote: > On Thu, Jan 22, 2015 at 12:47:28PM -0500, John Merriam wrote: > > The machine currently has the 1GB DIMM in it. I tested the patch and it > > seems to work with <= 1GB RAM. ping -f test returned similar results so > > performance likely isn't affected. > > You sure? This would be the first time I wrote a driver diff > that didn't panic the machine on first try :) > :) Yeah, it does seem to work at least with <= 1GB RAM. I am not a C expert. Even less so when it comes to OS kernels. And even less when it comes to hardware drivers. But, when I look over your patch, it looks fine to me. Will let you know tonight (EST) how I fare with 4GB installed in the machine. Thanks -- John Merriam
Re: bce(4) - descriptor error
> Date: Thu, 22 Jan 2015 18:04:44 +0100 > From: Stefan Sperling > > On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote: > > So, what could be the problem then? Theoretically it did work as of the > > 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This > > message: > > > > http://marc.info/?l=openbsd-tech&m=130217668909255 > > > > seems to verify that it did actually work at one point. > > It looks as if some ring descriptor data is still being allocated with > bus_dmamem_alloc(). That function probably doesn't respect the mapping > constraints bce(4) hardware requires. > > This diff makes bce use the same memory allocation APIs as bwi(4) is > using. Some bwi devices have the same 1GB problem and I know the bwi > code works fine with such devices. So perhaps applying the same approach > to bce will fix your issue. I'd really prefer it if we'd solve this issue by promoting _bus_dmamem_alloc_range() to a first class citizen. I'll try to recover an old diff that did this tonight. No harm in testing this diff though to verify that it indeed solves the issue.
Re: bce(4) - descriptor error
On Thu, Jan 22, 2015 at 12:47:28PM -0500, John Merriam wrote: > The machine currently has the 1GB DIMM in it. I tested the patch and it > seems to work with <= 1GB RAM. ping -f test returned similar results so > performance likely isn't affected. You sure? This would be the first time I wrote a driver diff that didn't panic the machine on first try :)
Re: bce(4) - descriptor error
On 2015-01-22 12:04, Stefan Sperling wrote: On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote: So, what could be the problem then? Theoretically it did work as of the 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This message: http://marc.info/?l=openbsd-tech&m=130217668909255 seems to verify that it did actually work at one point. It looks as if some ring descriptor data is still being allocated with bus_dmamem_alloc(). That function probably doesn't respect the mapping constraints bce(4) hardware requires. This diff makes bce use the same memory allocation APIs as bwi(4) is using. Some bwi devices have the same 1GB problem and I know the bwi code works fine with such devices. So perhaps applying the same approach to bce will fix your issue. Diff is compile-tested only due to lack of hardware at my end. The machine currently has the 1GB DIMM in it. I tested the patch and it seems to work with <= 1GB RAM. ping -f test returned similar results so performance likely isn't affected. I will put the 2GB DIMMs back in tonight when I can physically access the machine then test again and report results for > 1GB RAM. -- John Merriam
Re: Default pf-ruleset not using /etc/services
My bad, forgot to add bugs@openbsd.org in my reply to Ken, here it is for the record. The default value for 'ssh' in /etc/services would be 22. So you're going to have to remember to change either /etc/pf.conf or /etc/services to avoid the problem. You don't describe enough of your situation to make clear why editing /etc/services would make more sense than editing /etc/pf.conf. I'm not talking about /etc/pf.conf, but the default pf-ruleset loaded during startup (in /etc/rc). Hmm. In that case I'm not sure /etc/services is actually accessible at that time. And what if it is missing? We would not want to make the system come up wide open. But there are 4 other rules using /etc/services already? If you had started with "Other default rules use /etc/services, why not ssh?" there would have been less confusion in the minds of slackers like myself who did not go look at /etc/rc. :-) Ken As Ken perfectly wrote it: "Other default rules use /etc/services, why not ssh?" -- bsv
Re: bce(4) - descriptor error
On 2015/01/22 17:05, Stuart Henderson wrote: > Would presumably be a change in uvm somewhere. (paddr_t)(0x4000 - 1) > is passed as 'high' to uvm_km_kmemalloc_pla -> uvm_pglistalloc and is > meant to constrain the addresses. > > Identifying when (at least which release) it broke might be a good start.. > ...but try stsp's diff first :)
Re: bce(4) - descriptor error
On 2015/01/22 11:34, John Merriam wrote: > On 2015-01-21 18:36, John Merriam wrote: > >On 1/21/2015 1:43 PM, Stefan Sperling wrote: > >>There is supposed to be a bounce buffer in bce to cope with > >>systems with more than 1GB but perhaps it is broken. > >> > > > >I installed the old 1GB DIMM that came with the machine when I > >acquired it, and you are correct, it seems to work fine with <= 1GB > >RAM. > > > >Next question is how to fix it so it works with > 1GB RAM. > > Hmmm. I looked at sys/dev/pci/if_bce.c and it looks to me like this patch: > > http://marc.info/?l=openbsd-tech&m=130183146308043 > > is still in place. > > I then downloaded version 1.35 (dated 4/3/2011) of if_bce.c from > cvsweb.openbsd.org and did a diff against version 1.40 (in -current now) of > if_bce.c and there are hardly any differences. The main change is the call > to m_devget() removing the 5th parameter which was NULL. That first > parameter to m_devget looks funny to me. After thinking about it I think I > know what it's doing but it just looks weird to me. Anyway, the only other > changes besides includes from 1.35 to 1.40 are in the bce_ioctl() function > and they don't look like they would make any difference to me. > > So, what could be the problem then? Theoretically it did work as of the > 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This > message: > > http://marc.info/?l=openbsd-tech&m=130217668909255 > > seems to verify that it did actually work at one point. Would presumably be a change in uvm somewhere. (paddr_t)(0x4000 - 1) is passed as 'high' to uvm_km_kmemalloc_pla -> uvm_pglistalloc and is meant to constrain the addresses. Identifying when (at least which release) it broke might be a good start..
Re: bce(4) - descriptor error
On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote:
> So, what could be the problem then? Theoretically it did work as of the
> 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This
> message:
>
> http://marc.info/?l=openbsd-tech&m=130217668909255
>
> seems to verify that it did actually work at one point.
It looks as if some ring descriptor data is still being allocated with
bus_dmamem_alloc(). That function probably doesn't respect the mapping
constraints bce(4) hardware requires.
This diff makes bce use the same memory allocation APIs as bwi(4) is
using. Some bwi devices have the same 1GB problem and I know the bwi
code works fine with such devices. So perhaps applying the same approach
to bce will fix your issue.
Diff is compile-tested only due to lack of hardware at my end.
Index: if_bce.c
===
RCS file: /cvs/src/sys/dev/pci/if_bce.c,v
retrieving revision 1.40
diff -u -p -r1.40 if_bce.c
--- if_bce.c22 Dec 2014 02:28:51 - 1.40
+++ if_bce.c22 Jan 2015 17:02:05 -
@@ -185,6 +185,13 @@ bce_probe(struct device *parent, void *m
nitems(bce_devices)));
}
+struct uvm_constraint_range bce_constraint = { 0x0, (0x4000 - 1) };
+struct kmem_pa_mode bce_pa_mode = {
+ .kp_align = 0x1000,
+ .kp_constraint = &bce_constraint,
+ .kp_zero = 1
+};
+
void
bce_attach(struct device *parent, struct device *self, void *aux)
{
@@ -194,8 +201,6 @@ bce_attach(struct device *parent, struct
pci_intr_handle_t ih;
const char *intrstr = NULL;
caddr_t kva;
- bus_dma_segment_t seg;
- int rseg;
struct ifnet *ifp;
pcireg_t memtype;
bus_addr_t memaddr;
@@ -255,9 +260,9 @@ bce_attach(struct device *parent, struct
bce_reset(sc);
/* Create the data DMA region and maps. */
- if ((sc->bce_data = (caddr_t)uvm_km_kmemalloc_pla(kernel_map,
- uvm.kernel_object, (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES, 0,
- UVM_KMF_NOWAIT, 0, (paddr_t)(0x4000 - 1), 0, 0, 1)) == NULL) {
+ sc->bce_data = (caddr_t)km_alloc((BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES,
+ &kv_intrsafe, &bce_pa_mode, &kd_nowait);
+ if (sc->bce_data == NULL) {
printf(": unable to alloc space for ring");
return;
}
@@ -267,8 +272,8 @@ bce_attach(struct device *parent, struct
1, BCE_NRXDESC * MCLBYTES, 0, BUS_DMA_NOWAIT | BUS_DMA_ALLOCNOW,
&sc->bce_rxdata_map))) {
printf(": unable to create ring DMA map, error = %d\n", error);
- uvm_km_free(kernel_map, (vaddr_t)sc->bce_data,
- (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES);
+ km_free(sc->bce_data, (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES,
+ &kv_intrsafe, &bce_pa_mode);
return;
}
@@ -276,9 +281,9 @@ bce_attach(struct device *parent, struct
if (bus_dmamap_load(sc->bce_dmatag, sc->bce_rxdata_map, sc->bce_data,
BCE_NRXDESC * MCLBYTES, NULL, BUS_DMA_READ | BUS_DMA_NOWAIT)) {
printf(": unable to load rx ring DMA map\n");
- uvm_km_free(kernel_map, (vaddr_t)sc->bce_data,
- (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES);
bus_dmamap_destroy(sc->bce_dmatag, sc->bce_rxdata_map);
+ km_free(sc->bce_data, (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES,
+ &kv_intrsafe, &bce_pa_mode);
return;
}
@@ -287,9 +292,9 @@ bce_attach(struct device *parent, struct
1, BCE_NTXDESC * MCLBYTES, 0, BUS_DMA_NOWAIT | BUS_DMA_ALLOCNOW,
&sc->bce_txdata_map))) {
printf(": unable to create ring DMA map, error = %d\n", error);
- uvm_km_free(kernel_map, (vaddr_t)sc->bce_data,
- (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES);
bus_dmamap_destroy(sc->bce_dmatag, sc->bce_rxdata_map);
+ km_free(sc->bce_data, (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES,
+ &kv_intrsafe, &bce_pa_mode);
return;
}
@@ -298,10 +303,10 @@ bce_attach(struct device *parent, struct
sc->bce_data + BCE_NRXDESC * MCLBYTES,
BCE_NTXDESC * MCLBYTES, NULL, BUS_DMA_WRITE | BUS_DMA_NOWAIT)) {
printf(": unable to load tx ring DMA map\n");
- uvm_km_free(kernel_map, (vaddr_t)sc->bce_data,
- (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES);
bus_dmamap_destroy(sc->bce_dmatag, sc->bce_rxdata_map);
bus_dmamap_destroy(sc->bce_dmatag, sc->bce_txdata_map);
+ km_free(sc->bce_data, (BCE_NTXDESC + BCE_NRXDESC) * MCLBYTES,
+ &kv_intrsafe, &bce_pa_mode);
return;
}
@@ -315,26 +320,14 @@ bce_attach(struct device *parent, struct
* XXX PAGE_SIZE is wasteful; we only need 1KB + 1KB, but
Re: bce(4) - descriptor error
On 2015-01-21 18:36, John Merriam wrote: On 1/21/2015 1:43 PM, Stefan Sperling wrote: There is supposed to be a bounce buffer in bce to cope with systems with more than 1GB but perhaps it is broken. I installed the old 1GB DIMM that came with the machine when I acquired it, and you are correct, it seems to work fine with <= 1GB RAM. Next question is how to fix it so it works with > 1GB RAM. Hmmm. I looked at sys/dev/pci/if_bce.c and it looks to me like this patch: http://marc.info/?l=openbsd-tech&m=130183146308043 is still in place. I then downloaded version 1.35 (dated 4/3/2011) of if_bce.c from cvsweb.openbsd.org and did a diff against version 1.40 (in -current now) of if_bce.c and there are hardly any differences. The main change is the call to m_devget() removing the 5th parameter which was NULL. That first parameter to m_devget looks funny to me. After thinking about it I think I know what it's doing but it just looks weird to me. Anyway, the only other changes besides includes from 1.35 to 1.40 are in the bce_ioctl() function and they don't look like they would make any difference to me. So, what could be the problem then? Theoretically it did work as of the 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This message: http://marc.info/?l=openbsd-tech&m=130217668909255 seems to verify that it did actually work at one point. -- John Merriam
Re: Default pf-ruleset not using /etc/services
On 2015/01/22 09:12, Kenneth Westerback wrote: > > The default value for 'ssh' in /etc/services would be 22. So you're > going to have to remember to change either /etc/pf.conf or > /etc/services to avoid the problem. You don't describe enough of your > situation to make clear why editing /etc/services would make more > sense than editing /etc/pf.conf. /etc/pf.conf is possibly slightly easier, as it isn't blown away at upgrade time...
Re: Default pf-ruleset not using /etc/services
On 22 January 2015 at 07:59, wrote:
> Hello,
>
> I recently lost access to a co-located server, because I used a non-standard
> port for ssh access.
>
> The default pf-ruleset (in /etc/rc) had kicked in.
>
> Would it be more correct to have the rulset in /etc/rc use /etc/services
> instead of hardcoding port 22 into the rule?
>
> Something like this;
>
> 326,327c326,327
> < RULES="$RULES\npass in proto tcp from any to any port 22 keep state"
> < RULES="$RULES\npass out proto { tcp, udp } from any to any port 53
> keep state"
> ---
>>
>> RULES="$RULES\npass in proto tcp from any to any port ssh keep
>> state"
>> RULES="$RULES\npass out proto { tcp, udp } from any to any port
>> domain keep state"
>
>
>
> --
> Kind regards
> Brian Vangsgaard
>
The default value for 'ssh' in /etc/services would be 22. So you're
going to have to remember to change either /etc/pf.conf or
/etc/services to avoid the problem. You don't describe enough of your
situation to make clear why editing /etc/services would make more
sense than editing /etc/pf.conf.
Ken
Default pf-ruleset not using /etc/services
Hello,
I recently lost access to a co-located server, because I used a
non-standard port for ssh access.
The default pf-ruleset (in /etc/rc) had kicked in.
Would it be more correct to have the rulset in /etc/rc use
/etc/services instead of hardcoding port 22 into the rule?
Something like this;
326,327c326,327
< RULES="$RULES\npass in proto tcp from any to any port 22 keep
state"
< RULES="$RULES\npass out proto { tcp, udp } from any to any port
53 keep state"
---
RULES="$RULES\npass in proto tcp from any to any port ssh keep
state"
RULES="$RULES\npass out proto { tcp, udp } from any to any port
domain keep state"
--
Kind regards
Brian Vangsgaard
