Re: openssl s_client gives "called a function you should not call"
Hi Claus, On Fri, Nov 13, 2020 at 06:42:28AM +0100, Claus Assmann wrote: | On Thu, Nov 12, 2020, Paul de Weerd wrote: | | > $ openssl s_client -starttls smtp -connect localhost:587 | | > RCPT TO: | ^ = RENEGOTIATING | | and the syntax is wrong too: NO space after colon, see the fine RFCs. Ah, good one. Fortunately, most (all?) MTAs I've come across while doing manual SMTP (admittedly, this is not my biggest hobby, so not that many) are lenient enough to allow for the space. But I'll keep that in mind. | openssl(1): | When used interactively (which means neither -quiet nor -ign_eof have | been given), the session will be renegotiated if the line begins with an | R; if the line begins with a Q or if end of file is reached, the | connection will be closed down. It's actually documented! Would not have thought to look for this in the manpage .. thank you for the pointer! Cheers, Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: openssl s_client gives "called a function you should not call"
Hi Janne, On Fri, Nov 13, 2020 at 07:59:22AM +0100, Janne Johansson wrote: | I think anything starting with capital R in that case (s_client) gets | parsed as RENEGOTIATING. | As for why openssl complains about it is unknown to me, but that gotcha is | old at least. Wow .. unexpected. But thanks for the clue-by-4, using 'rcpt to:' instead of 'RCPT TO:' allows me to deliver mail without a problem using openssl s_client. Cheers, Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: openssl s_client gives "called a function you should not call"
On Thu, Nov 12, 2020, Paul de Weerd wrote: > $ openssl s_client -starttls smtp -connect localhost:587 > RCPT TO: ^ = RENEGOTIATING and the syntax is wrong too: NO space after colon, see the fine RFCs. openssl(1): When used interactively (which means neither -quiet nor -ign_eof have been given), the session will be renegotiated if the line begins with an R; if the line begins with a Q or if end of file is reached, the connection will be closed down. Use rcpt to: -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: openssl s_client gives "called a function you should not call"
Den tors 12 nov. 2020 kl 22:15 skrev Paul de Weerd : > While trying to debug my smtpd setup, I got the error "called a > function you should not call" from openssl s_client: > > $ openssl s_client -starttls smtp -connect localhost:587 > > EHLO > > RCPT TO: > RENEGOTIATING > > Is this something openssl s_client doesn't support? I notice that > "RENEGOTIATING" only comes after sending the RCPT TO: command to the > server. Futzing around with other commands before sending RCPT TO: > didn't get to RENEGOTIATING. Am I doing something wrong? Should I be > using some other tool? > I think anything starting with capital R in that case (s_client) gets parsed as RENEGOTIATING. As for why openssl complains about it is unknown to me, but that gotcha is old at least. from 2012: https://serverfault.com/questions/336617/postfix-tls-over-smtp-rcpt-to-prompts-renegotiation-then-554-5-5-1-error-no-v -- May the most significant bit of your life be positive.
Re: Strange snmpd issue with 6.7
On Thu, Nov 12, 2020 at 09:51:46AM -, Stuart Henderson wrote: > On 2020-11-09, Winfred Harrelson wrote: > > On Sat, Nov 07, 2020 at 01:53:00PM -, Stuart Henderson wrote: > >> On 2020-11-06, Winfred Harrelson wrote: > >> > I am running OpenBSD 6.7 and am having a strange issue with snmpd(8). > >> > > >> > The issue is that it doesn't have all the arp entries but this was > >> > working before. I don't know exactly when this started happening > >> > but I just noticed today. > >> > > >> > Here is the machine in question and what I get: > >> > > >> > wharrels@styx1:/home/wharrels$ uname -a > >> > OpenBSD styx1 6.7 GENERIC.MP#3 amd64 > >> > > >> > wharrels@styx1:/home/wharrels$ arp -a | wc -l > >> > 985 > >> > > >> > Box is acting as a firewall so that is normal. Actually normal to > >> > have many more than that. But if I do a query from another machine > >> > via snmpwalk I get a completely different number of machines in > >> > the arp table: > >> > > >> > [wharrels@newtron ~]$ snmpwalk -v2c -c public styx1 > >> > ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress | wc -l > >> > 456 > >> > > >> > Not even close to the same number of machines. The above OID translates > >> > to > >> > 1.3.6.1.2.1.4.22.1.2 if you want to try this and see what you get. > >> > > >> > Should I be using a different OID to get the arp table or is there > >> > another way to do this? It might be that this was not working quite > >> > right before but I don't remember it being off like this. > >> > > >> > Any help would be appreciated, thanks. > >> > > >> > Winfred > >> > > >> > > >> > >> If you have set "filter-routes yes" then this is expected as it will > >> stop snmpd from seeing route updates and thus new additions to the > >> ARP table. > > > > I do not have that in my config file. Man page says the default is "no" > > so this should not be it correct? I will try adding the line with a > > "no" just to see if that changes anything though. > > Correct. > > >> If you have not then I'd say this is a bug and best reported to > >> bugs@ rather than misc@. > > > > I am running 6.7 on this box so I may wait until I can get it updated > > to 6.8 before reporting to bugs@. > > Worth doing though I think 6.8 is unlikely to help. > > Does restarting snmpd result in picking up the full arp table again? Yes initially. Unfortunately, after a while they get out of sync again. Gets more out of sync longer it runs though not quickly. I have another box running 6.4 that is also having the same issue. I am not going to bother complaining about that one because it is too old and in more of a need to be updated. Am hoping to update both over the coming holidays. Have been emailing back and forth with Martijn van Duren and he is unable to recreate the issue. > >> BTW you can see this table in a nicer output format: > >> > >> $ snmptable -v2c -c pulic host ip.ipNetToMediaTable > > > > I did not know that, thanks for the info. Doesn't look to be much > > different though. > > Yes, it's just nicer formatting and pulls details from the various oids > that make up the snmp table in one place, it works for various other > tables too. I do like this format very much and will be using it from time to time in the future. May be playing around with that command some more for other tables and see what I can do. :) Winfred
openssl s_client gives "called a function you should not call"
While trying to debug my smtpd setup, I got the error "called a function you should not call" from openssl s_client: $ openssl s_client -starttls smtp -connect localhost:587 EHLO 250- Hello [127.0.0.1], pleased to meet you 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-SIZE 36700160 250-DSN 250-AUTH PLAIN LOGIN 250 HELP AUTH LOGIN 334 VXNlcm5hbWU6 Tm9wZSE= 334 UGFzc3dvcmQ6 cmVkYWN0ZWQ= 235 2.0.0 Authentication succeeded MAIL FROM: 250 2.0.0 Ok RCPT TO: RENEGOTIATING 9754412775936:error:1404C042:SSL routines:ST_OK:called a function you should not call:/usr/src/lib/libssl/ssl_lib.c:2415: Is this something openssl s_client doesn't support? I notice that "RENEGOTIATING" only comes after sending the RCPT TO: command to the server. Futzing around with other commands before sending RCPT TO: didn't get to RENEGOTIATING. Am I doing something wrong? Should I be using some other tool? Thanks for any insights! Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: OBSD 6.8 vlan communication issues
On 11/11/20 3:06 PM, len zaifman wrote:
I am setting up a new system as a firewall using OpenBSD 6.8 current
-uname -a
OpenBSD fw1.lfz.net 6.8 GENERIC.MP#175 amd64.
I have 3 vlans 70,77,79 on the firewall using two em devices, em0 and
em1, in an aggregation to serve these vlans.
There is a Unifi switch which has 2 ports (where em0,em1 are attached)
set up to pass tagged vlans 70,77,79. The switch ip is 10.10.70.3.
I have a linux host setup on vans 70,77,79 and at address 77 -
10.10.70.77, 10.10.77.77,10.10.79.77.
So far i cannot communicate over the vlans. Before I vlanned these
subnets : ie only vlan 1 everywhere - communication worked fine.
So i do not believe there is a physical issue. The issues arose with
the introduction of the vlans. Is there a configuration issue that
anyone can spot?
Thank you for any help you can give.
Evidence:
ping on the firewall works locally
for n in 0 7 9 ; do ping -c 2 10.10.7${n}.1 ; done
PING 10.10.70.1 (10.10.70.1): 56 data bytes
64 bytes from 10.10.70.1: icmp_seq=0 ttl=255 time=0.037 ms
64 bytes from 10.10.70.1: icmp_seq=1 ttl=255 time=0.025 ms
--- 10.10.70.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.025/0.031/0.037/0.006 ms
PING 10.10.77.1 (10.10.77.1): 56 data bytes
64 bytes from 10.10.77.1: icmp_seq=0 ttl=255 time=0.038 ms
64 bytes from 10.10.77.1: icmp_seq=1 ttl=255 time=0.025 ms
--- 10.10.77.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.025/0.031/0.038/0.006 ms
PING 10.10.79.1 (10.10.79.1): 56 data bytes
64 bytes from 10.10.79.1: icmp_seq=0 ttl=255 time=0.038 ms
64 bytes from 10.10.79.1: icmp_seq=1 ttl=255 time=0.025 ms
--- 10.10.79.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.025/0.032/0.038/0.007 ms
ping to the switch does not work
ping -c 2 10.10.70.3
PING 10.10.70.3 (10.10.70.3): 56 data bytes
--- 10.10.70.3 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
ping to the linux host does not work.
ping -c 2 10.10.70.3
PING 10.10.70.3 (10.10.70.3): 56 data bytes
--- 10.10.70.3 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[13:47:04] leonardz@fw1 etc>>for n in 0 7 9 ; do ping -c 2
10.10.7${n}.77 ; done
PING 10.10.70.77 (10.10.70.77): 56 data bytes
--- 10.10.70.77 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
PING 10.10.77.77 (10.10.77.77): 56 data bytes
--- 10.10.77.77 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
PING 10.10.79.77 (10.10.79.77): 56 data bytes
--- 10.10.79.77 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
I did the tests both with pfctl -e (enabled) and pfctl -d (disabled).
It made no difference
The setup is described below
Here is the setup:
= hostname.aggr0
debug
trunkport em0
trunkport em1
up
inet 10.10.70.1/24
alias 10.10.77.1/24
alias 10.10.79.1/24
= hostname.em0
up
= hostname.em1
up
= hostname.vlan70
parent aggr0 vnetid 70
10.10.70.0/24
= hostname.vlan77
parent aggr0 vnetid 77
10.10.77.0/24
= hostname.vlan79
parent aggr0 vnetid 79
10.10.79.0/24
Ifconfig -A shows the vlans are setup
= aggr0
aggr0: flags=8847 mtu 1500
lladdr fe:e1:ba:d0:f4:8c
index 6 priority 0 llprio 7
trunk: trunkproto lacp
trunk id: [(8000,fe:e1:ba:d0:f4:8c,0006,,),
(8000,e0:63:da:8e:78:d7,03E8,,)]
em0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:f4:8c, key
0x6, port pri 0x8000 number 0x1
em0 lacp actor state
activity,aggregation,sync,collecting,distributing
em0 lacp partner system pri 0x8000 mac e0:63:da:8e:78:d7, key
0x3e8, port pri 0x1 number 0x9
em0 lacp partner state
activity,aggregation,sync,collecting,distributing
em0 port active,collecting,distributing
em1 lacp actor system pri 0x8000 mac fe:e1:ba:d0:f4:8c, key
0x6, port pri 0x8000 number 0x2
em1 lacp actor state
activity,aggregation,sync,collecting,distributing
em1 lacp partner system pri 0x8000 mac e0:63:da:8e:78:d7, key
0x3e8, port pri 0x1 number 0xa
em1 lacp partner state
activity,aggregation,sync,collecting,distributing
em1 port active,collecting,distributing
groups: aggr
media: Ethernet autoselect
status: active
inet 10.10.70.1 netmask 0xff00 broadcast 10.10.70.255
inet 10.10.77.1 netmask 0xff00 broadcast 10.10.77.255
inet 10.10.79.1 netmask 0xff00 broadcast 10.10.79.255
= em0
em0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:f4:8c
index 1 priority 0 llprio 3
trunk: trunkdev aggr0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
= em1
em1: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:f4:8c
index 2
Re: uvn_flush: WARNING: changes to page may be lost
On Thu, Nov 12, 2020 at 07:34:41PM +0100, Jurjen Oskam wrote: | On Wed, Nov 11, 2020 at 05:54:36AM -0700, Todd C. Miller wrote: | | > On Wed, 11 Nov 2020 10:20:41 +0100, Jan Stary wrote: | | > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. | > > uvn_flush: WARNING: changes to page may be lost! | | > This happens when /usr/libexec/reorder_kernel runs and your /usr | > is full. If you have upgraded the system multiple times there is | | I ran into this earlier this year, and tried to figure out how a filesystem becoming | full could result in kernel messages such as this. As there are no softupdates | involved, I would have expected the kernel only to return a message about /usr | being 100% full, and the (user space) kernel relinking to simply fail. | | I wasn't able to figure out what was going on. Is the relinking special in some | way? Or is it possible that other situations where a filesystem fills up can | result in messages like this? (Not counting situations where softupdates are | enabled) >From the reply Mark sent me on June 9th[1]: > What you're seeing is what happens when a program writes to a file by > using mmap(2) and there is no disk space available when the kernel > finally decides to write out the modified memory to disk. There's plenty of space available in RAM, so you can create a file that's bigger than the amount of space available on disk. Then trying to write it to disk will fail with the error you got. Cheers, Paul [1]: https://marc.info/?l=openbsd-bugs&m=159170985316978&w=2 -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: uvn_flush: WARNING: changes to page may be lost
On Wed, Nov 11, 2020 at 05:54:36AM -0700, Todd C. Miller wrote: > On Wed, 11 Nov 2020 10:20:41 +0100, Jan Stary wrote: > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > This happens when /usr/libexec/reorder_kernel runs and your /usr > is full. If you have upgraded the system multiple times there is I ran into this earlier this year, and tried to figure out how a filesystem becoming full could result in kernel messages such as this. As there are no softupdates involved, I would have expected the kernel only to return a message about /usr being 100% full, and the (user space) kernel relinking to simply fail. I wasn't able to figure out what was going on. Is the relinking special in some way? Or is it possible that other situations where a filesystem fills up can result in messages like this? (Not counting situations where softupdates are enabled) Regards, Jurjen Oskam
Re: Malloc options
On Thu, Nov 12, 2020 at 05:40:39AM -0600, ed...@pettijohn-web.com wrote: > On Nov 12, 2020 3:06 AM, Stuart Henderson wrote: > > On 2020-11-11, ed...@pettijohn-web.com > wrote: > > Thanks for the quick reply. I'll stick with "s" for now and if its > > unbearably slow I'll try others. > > 'S' not 's', they're case-sensitive (from the manual, "Unless > otherwise > noted uppercase means on, lowercase means off.") > > > Luckily it's a typo in the email. However, I don't recall reading that. > Must have skimmed past it. > Thanks, > Edgar This can be handy when you have e.g. the sysctl set, but want to override: # sysctl vm.malloc_conf=S All processes run with S MALLOC_OPTONS=sC executable Runs this executable without S but with canaries. -Otto
Re: Malloc options
On Nov 12, 2020 3:06 AM, Stuart Henderson wrote: On 2020-11-11, ed...@pettijohn-web.com wrote: > Thanks for the quick reply. I'll stick with "s" for now and if its > unbearably slow I'll try others. 'S' not 's', they're case-sensitive (from the manual, "Unless otherwise noted uppercase means on, lowercase means off.") Luckily it's a typo in the email. However, I don't recall reading that. Must have skimmed past it. Thanks, Edgar
Re: OBSD 6.8 vlan communication issues
Hi Len
Jacob has a point re checking vlan setup first by setting the parent on the
vlans to the em0 or em1 interface first
when you validate your vlan config on the switch
setup the aggr0 interface
what does unifi say about the LACP status / Aggregation status on the
switch UI ?
also can you confirm that you are not doing any DHCP stuff / DHCP guard /
dhcp snooping in Unifi Switch which might affect network connectivity if
you have a dhcp server running on OpenBSD Box
On Thu, 12 Nov 2020 at 02:50, len zaifman wrote:
> Thanks Tom,Aaron: I did 2 things,
>
> 1 re IPs - all ips removed from aggr0 and 1 ip for each vlan
>
> ifconfig -A | grep -A 7 vlan7 | grep -E 'vlan7
> inet' ; ifconfig aggr0 | grep inet
> vlan70: flags=8843 mtu 1500
> inet 10.10.70.1 netmask 0xff00 broadcast 10.10.70.255
> vlan77: flags=8843 mtu 1500
> inet 10.10.77.1 netmask 0xff00 broadcast 10.10.77.255
> vlan79: flags=8843 mtu 1500
> inet 10.10.79.1 netmask 0xff00 broadcast 10.10.79.255
>
>
> Still no luck
>
>
> 2 I went to switch and made vlan70 the native vlan, with vlan 77,79
> still tagged to see if that would help. Still no ping even to the switch
> which is on vlan 70.
>
> Now the switch is back to all 3 vlans are tagged, no native vlan.
>
>
> I am trying to see vlan tags when i ping 10.10.7x.1 with tcpdump -e but
> no luck. I assume loopback interface is being used when i ping locally
> on the firewall so that doesn't work.
>
>
> I will contact switch vendor to see if they can help. But for openbsd,
> does the config look okay now? All ips on the vlan, not the parent
> interface?
>
>
> PS to Aaro'squestion re: sysctl
>
> sysctl for ip forwarding is set
>
> net.inet.ip.forwarding=1
>
>
> On 2020-11-11 7:32 p.m., Tom Smyth wrote:
> > Hi Len,
> > Hi Remove the Ip addresses from the agg0 interfaces
> >
> > put the Ip addresses on the vlan interfaces only
> >
> > ie
> > mg /etc/hostname.vlanxxx
> > up vnetid xxx
> > inet 10.10.xx.1/24
> >
> > if you need to route between the vlans make sure you enable forwarding in
> > the kernel with sysctl
> >
> > when you get it working make sure to post to the Misc List :)
> >
> >
> >
> > Hope this helps,
> >
> >
> >
> >
> >
> >
> > On Thu, 12 Nov 2020 at 00:18, len zaifman wrote:
> >
> >> I am setting up a new system as a firewall using OpenBSD 6.8 current
> >> -uname -a
> >> OpenBSD fw1.lfz.net 6.8 GENERIC.MP#175 amd64.
> >>
> >> I have 3 vlans 70,77,79 on the firewall using two em devices, em0 and
> >> em1, in an aggregation to serve these vlans.
> >>
> >>
> >> There is a Unifi switch which has 2 ports (where em0,em1 are attached)
> >> set up to pass tagged vlans 70,77,79. The switch ip is 10.10.70.3.
> >>
> >> I have a linux host setup on vans 70,77,79 and at address 77 -
> >> 10.10.70.77, 10.10.77.77,10.10.79.77.
> >>
> >>
> >> So far i cannot communicate over the vlans. Before I vlanned these
> >> subnets : ie only vlan 1 everywhere - communication worked fine.
> >>
> >> So i do not believe there is a physical issue. The issues arose with the
> >> introduction of the vlans. Is there a configuration issue that anyone
> >> can spot?
> >>
> >>
> >> Thank you for any help you can give.
> >>
> >> Evidence:
> >>
> >> ping on the firewall works locally
> >>
> >> for n in 0 7 9 ; do ping -c 2 10.10.7${n}.1 ; done
> >> PING 10.10.70.1 (10.10.70.1): 56 data bytes
> >> 64 bytes from 10.10.70.1: icmp_seq=0 ttl=255 time=0.037 ms
> >> 64 bytes from 10.10.70.1: icmp_seq=1 ttl=255 time=0.025 ms
> >>
> >> --- 10.10.70.1 ping statistics ---
> >> 2 packets transmitted, 2 packets received, 0.0% packet loss
> >> round-trip min/avg/max/std-dev = 0.025/0.031/0.037/0.006 ms
> >> PING 10.10.77.1 (10.10.77.1): 56 data bytes
> >> 64 bytes from 10.10.77.1: icmp_seq=0 ttl=255 time=0.038 ms
> >> 64 bytes from 10.10.77.1: icmp_seq=1 ttl=255 time=0.025 ms
> >>
> >> --- 10.10.77.1 ping statistics ---
> >> 2 packets transmitted, 2 packets received, 0.0% packet loss
> >> round-trip min/avg/max/std-dev = 0.025/0.031/0.038/0.006 ms
> >> PING 10.10.79.1 (10.10.79.1): 56 data bytes
> >> 64 bytes from 10.10.79.1: icmp_seq=0 ttl=255 time=0.038 ms
> >> 64 bytes from 10.10.79.1: icmp_seq=1 ttl=255 time=0.025 ms
> >>
> >> --- 10.10.79.1 ping statistics ---
> >> 2 packets transmitted, 2 packets received, 0.0% packet loss
> >> round-trip min/avg/max/std-dev = 0.025/0.032/0.038/0.007 ms
> >>
> >>
> >> ping to the switch does not work
> >>
> >> ping -c 2 10.10.70.3
> >> PING 10.10.70.3 (10.10.70.3): 56 data bytes
> >>
> >> --- 10.10.70.3 ping statistics ---
> >> 2 packets transmitted, 0 packets received, 100.0% packet loss
> >>
> >> ping to the linux host does not work.
> >>
> >> ping -c 2 10.10.70.3
> >> PING 10.10.70.3 (10.10.70.3): 56 data bytes
> >>
> >> --- 10.10.70.3 ping statistics ---
> >> 2 packets transmitted, 0 packets received, 100.0% packet loss
> >> [13:47:04] leonardz@fw1 etc>>for n in 0 7 9 ; do ping -c 2
> >> 10.10.7${n}.77 ; done
> >> PING 10.10.70.77 (10.10.70.77): 56 data bytes
>
Re: Strange snmpd issue with 6.7
On 2020-11-09, Winfred Harrelson wrote: > On Sat, Nov 07, 2020 at 01:53:00PM -, Stuart Henderson wrote: >> On 2020-11-06, Winfred Harrelson wrote: >> > I am running OpenBSD 6.7 and am having a strange issue with snmpd(8). >> > >> > The issue is that it doesn't have all the arp entries but this was >> > working before. I don't know exactly when this started happening >> > but I just noticed today. >> > >> > Here is the machine in question and what I get: >> > >> > wharrels@styx1:/home/wharrels$ uname -a >> > OpenBSD styx1 6.7 GENERIC.MP#3 amd64 >> > >> > wharrels@styx1:/home/wharrels$ arp -a | wc -l >> > 985 >> > >> > Box is acting as a firewall so that is normal. Actually normal to >> > have many more than that. But if I do a query from another machine >> > via snmpwalk I get a completely different number of machines in >> > the arp table: >> > >> > [wharrels@newtron ~]$ snmpwalk -v2c -c public styx1 >> > ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress | wc -l >> > 456 >> > >> > Not even close to the same number of machines. The above OID translates to >> > 1.3.6.1.2.1.4.22.1.2 if you want to try this and see what you get. >> > >> > Should I be using a different OID to get the arp table or is there >> > another way to do this? It might be that this was not working quite >> > right before but I don't remember it being off like this. >> > >> > Any help would be appreciated, thanks. >> > >> > Winfred >> > >> > >> >> If you have set "filter-routes yes" then this is expected as it will >> stop snmpd from seeing route updates and thus new additions to the >> ARP table. > > I do not have that in my config file. Man page says the default is "no" > so this should not be it correct? I will try adding the line with a > "no" just to see if that changes anything though. Correct. >> If you have not then I'd say this is a bug and best reported to >> bugs@ rather than misc@. > > I am running 6.7 on this box so I may wait until I can get it updated > to 6.8 before reporting to bugs@. Worth doing though I think 6.8 is unlikely to help. Does restarting snmpd result in picking up the full arp table again? >> BTW you can see this table in a nicer output format: >> >> $ snmptable -v2c -c pulic host ip.ipNetToMediaTable > > I did not know that, thanks for the info. Doesn't look to be much > different though. Yes, it's just nicer formatting and pulls details from the various oids that make up the snmp table in one place, it works for various other tables too. > >
Re: Fault tolerant BGP and firewall routers on OpenBSD
On 2020-11-11, Dev Op wrote: > Hi all! > > I am looking for a way to build fault tolerant routers with a firewall. We > have an AS num and a /24 network prefix as well as a multihome peering with > two upstream ISPs. To build this solution, I've got 4 machines with OpenBSD > on it: > > Hosts `border1' and `border2'. Each of these routers are connected to its > own provider by eBGP: border1 connects to the ISP1 as well as border2 > connects to the ISP2. There is iBGP between these two border routers (set > nexthop self). To avoid states, I didn't configure the pf. Perhaps I am > wrong and it is possible to configure stateless pf to avoid bgp connection > attempts from a foreign addresses. These two routers are connected to the > downstream internal vlanX and each router has its own IPv4 address from the > announced a /24 network prefix. > > Hosts `fw1' and `fw2' are behind border routers. They have a stateful > packet filter with pfsync (port redirections, binat rule sets and so on), > without any dynamic routing protocols. Their external interfaces are > connected to vlanX and have addresses from the announced network prefix > within AS as well. There's a master-slave CARP between these firewalls. > External CARP address is used as a NAT address for internal services, > there's also internal CARP address used as a default router for internal > downstream services in the 92.168.0.0/16 subnet. > > Q1: How to connect fw1 and fw2 to the borders? Do I need to set up on > internal interfaces of border routers the CARP address (master/slave) which > will act as a default router for the next two fw routers? As I understand, > I can't bring up the IGP between border and fw routers because of the > packet state on fw group. > > Q2: Can asymmetric routing issues arise when connecting via CARP between > border and fw routers? There are several ways to do it. One option is to run ibgp between firewalls and borders and announce local subnets from the firewalls using "set nexthop" pointed at a carp address on the firewalls. Another is to use pfsync with the "defer" option. Another is to use PF with "keep state (sloppy)". > Q3: Do I need to add announced /24 network prefix into blackhole on border > routers by `route add -blackhole' command to avoid reply in case of request > for non-existent address from that network? I think to split /24 into small > subnets for future needs, there may be requests to unused addresses. I use a -reject default route and don't have my full LIR allocation as a route table entry, so packets to addresses which aren't routed will just get a host-unreachable. Your suggestion should work fine too.
Re: Malloc options
On 2020-11-11, ed...@pettijohn-web.com wrote: > Thanks for the quick reply. I'll stick with "s" for now and if its > unbearably slow I'll try others. 'S' not 's', they're case-sensitive (from the manual, "Unless otherwise noted uppercase means on, lowercase means off.")
