Re: IPv6 Multicast Listener Discovery - Listing and Disabling Group Membership
Stuart, > Yes the original code was in the original import from KAME. The code > that actually *processed* these queries was removed in the commit I > mentioned (so it seems your main concern is already dealt with), but > I think the interfaces are still joined to the group so will receive > those packets. I too think that the Node Information multicast group is joined when the interface comes up, but could not ascertain this for sure whether the group was being joined or not. Hence my 1st question - How to determine the list of IPv6 multicast groups joined by an interface? "netstat -g" does not return IPv6 multicast groups joined, because I think it deals with multicast routing rather than IPv6 multicast groups. I could not gather much from the results of apropos multicast[1]. Regards, ab [1] - https://man.openbsd.org/?query=multicast=1=0=default=OpenBSD-current -|-|-|-|-|-|-|--
Re: IPv6 Multicast Listener Discovery - Listing and Disabling Group Membership
On 2018/10/03 12:36, Aham Brahmasmi wrote:
> Hi Stuart,
>
> Thank you for your response.
>
> > > 2) How to disable an interface from joining IPv6 Node Information
> > > multicast group (RFC 4620)?
> > > In sys/netinet6/in6.c, the function in6_update_ifa contains the
> > > following lines:
> > >
> > > /*
> > > * join node information group address
> > > */
> > > if (in6_nigroup(ifp, hostname, hostnamelen, ) == 0) {
> > > imm = in6_joingroup(ifp, _addr, );
> > > if (!imm) {
> > > /* XXX not very fatal, go on... */
> > > } else {
> > > LIST_INSERT_HEAD(>ia6_memberships,
> > > imm, i6mm_chain);
> > > }
> > > }
> >
> > Not 100% sure but I think this may have been missed when support for
> > RFC 4620 was removed from the kernel in 2014
> >
> > https://github.com/openbsd/src/commit/43f29087ef2fc515510c43f9dd706f7bbd9e39b7
>
> You may be probably right, although I do not claim to understand IPv6.
> My best guess is that the code block might have been originally present
> in the KAME project.
Yes the original code was in the original import from KAME. The code
that actually *processed* these queries was removed in the commit I
mentioned (so it seems your main concern is already dealt with), but
I think the interfaces are still joined to the group so will receive
those packets.
Re: Some highlights: Emacs 21.4 and 25.3
On Tue, 2 Oct 2018, John M wrote: This may be a bit off-topic but the feature responsible for this is 'electric-indent-mode', which is enabled by default in 24.4 or later. It is not enough to prevent indentation in Tcl mode. (setq tcl-mode-map (make-sparse-keymap)) is not anymore documented and prevents not only indentation. I would stop using emacs, but after so much years using it ... Rodrigo
Re: checking source with pvs-studio
... is it just 750 for a License ? If one were to donate a License ? would that work for the project ? Thanks Tom Smyth On Wed, 3 Oct 2018 at 17:33, Todd C. Miller wrote: > > On Wed, 03 Oct 2018 10:20:45 +0200, Ingo Schwarze wrote: > > > Which is of course trivial to do - you write a script to do a > > checkout, run "sed -i", run the tool, collect the the results, > > and delete the checkout. So the harassment by the author is not > > even effective for his intended purpose. > > The license explicitly prohibits this kinds of behavior, though of > course there's no way for them to tell. If someone really wanted > to use it, a trial license does not have this kind of restriction > though it only lasts for a week IIRC. > > I think it's clear that we're not going to be using pvs-studio which > is a bit of a shame since it does catch real bugs. The way Coverity > deals with open source projects is easier for us to deal with. > > - todd > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: checking source with pvs-studio
On Wed, 03 Oct 2018 17:42:16 +0100, Tom Smyth wrote: > ... is it just 750 for a License ? > If one were to donate a License ? would that work for the project ? No, it would not. Their licensing model simply won't work for us. Even if it did, it's not like we could run it natively on OpenBSD. - todd
Re: checking source with pvs-studio
Hi Todd, I was thinking ... it might be possible to examine a copy of the code out of band on a different OS system ... and deal with the bugs that are flagged as part of the normal OpenBSD development process, if the license is not permissible then I suppose my suggestion was entirely academic :/ PS awesome talk in euroBSD Con :) Thanks anyway Tom Smyth On Wed, 3 Oct 2018 at 18:02, Todd C. Miller wrote: > > On Wed, 03 Oct 2018 17:42:16 +0100, Tom Smyth wrote: > > > ... is it just 750 for a License ? > > If one were to donate a License ? would that work for the project ? > > No, it would not. Their licensing model simply won't work for us. > Even if it did, it's not like we could run it natively on OpenBSD. > > - todd -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: checking source with pvs-studio
On Wed, 03 Oct 2018 18:07:00 +0100, Tom Smyth wrote: > I was thinking ... it might be possible to examine > a copy of the code out of band on a different OS system ... > and deal with the bugs that are flagged > as part of the normal OpenBSD development process, It is possible to generate pre-processed versions of the source for analysis on another system (Linux, macOS, etc). It's not something that fits in well to how OpenBSD development works but it is possible. > if the license is not permissible then I suppose my suggestion > was entirely academic :/ I don't see us being able to use anything that uses per-developer seat licensing. > PS awesome talk in euroBSD Con :) Wrong Todd :-) - todd
Re: Performance impact of PF on APU2
Thanks, I just saw the previous discussion, from late 2017. Do you know where we can follow the work that is being done? I would be more than happy to test early version.
Re: checking source with pvs-studio
On Wed, 03 Oct 2018 10:20:45 +0200, Ingo Schwarze wrote: > Which is of course trivial to do - you write a script to do a > checkout, run "sed -i", run the tool, collect the the results, > and delete the checkout. So the harassment by the author is not > even effective for his intended purpose. The license explicitly prohibits this kinds of behavior, though of course there's no way for them to tell. If someone really wanted to use it, a trial license does not have this kind of restriction though it only lasts for a week IIRC. I think it's clear that we're not going to be using pvs-studio which is a bit of a shame since it does catch real bugs. The way Coverity deals with open source projects is easier for us to deal with. - todd
Re: Performance impact of PF on APU2
Hello, your forwarding performance will vary based on a few things... at the minute Routing is MP safe... but if one of the lan ports lets say em1 was in a bridge... then the forwarding is done by a single core... My testing on OpenBSD 6.3 showed speeds of 750/s - 800Mb/s with default rules usingx86-64 GENERIC (not i386) speeds generally fell when playing with Encapsulation.. I was using a test rig as follows apuc2iperfclient - -- apuc2iperf server I hope this helps TomSmyth On Wed, 3 Oct 2018 at 19:04, Benjamin Petit wrote: > > Thanks, I just saw the previous discussion, from late 2017. > > Do you know where we can follow the work that is being done? I would be more > than > happy to test early version. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: Performance impact of PF on APU2
On 2018-10-03, Benjamin Petit wrote: > Before upgrading to CURRENT, I think routing with or without pf > enabled was around 600Mbit/s, but I would need to reinstall to test > again. Snapshots are usually built with the "pool_debug" kernel option, releases are built without it. This is good for finding some types of bug, but can have an impact, you could try sysctl kern.pool_debug=0 and see if that improves performance. What were you running before (including syspatches if present)? If it was from before mitigations for CPU bugs were added, those are generally expected to slow things down.
Re: Performance impact of PF on APU2
Hello, and thanks for your responses! > My testing on OpenBSD 6.3 showed speeds of 750/s - 800Mb/s > with default rules using x86-64 GENERIC (not i386) Same setup as yours, and I definitely don't reach 750-800Mbits/s (550 at best) When I transfer a big file from one network to another, I clearly see that one core stays pretty much at 100%. I don't have any bridge configured > Snapshots are usually built with the "pool_debug" kernel option, > releases are built without it. This is good for finding some types of > bug, but can have an impact, you could try sysctl kern.pool_debug=0 > and see if that improves performance. No significant impact > What were you running before (including syspatches if present)? > If it was from before mitigations for CPU bugs were added, those are > generally expected to slow things down. All syspatches up-to-date (until Monday at least). BIOS is up-to-date so I suppose that mitigations were already in place? I will reinstall 6.3+latest syspatches and measure again. Currently I see that sometimes iperf3 needs to retries to send some packets. I don't see any dropped packets in sysctl.
Re: Performance impact of PF on APU2
My sysctl output: kern.ostype=OpenBSD kern.osrelease=6.4 kern.osrevision=201811 kern.version=OpenBSD 6.4 (GENERIC.MP) #342: Tue Oct 2 23:23:09 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.M P kern.maxvnodes=22282 kern.maxproc=1310 kern.maxfiles=7030 kern.argmax=262144 kern.securelevel=1 kern.hostname=gw.home.** kern.hostid=0 kern.clockrate=tick = 1, tickadj = 40, hz = 100, profhz = 100, stathz = 100 kern.dnsjackport=0 kern.posix1version=200809 kern.ngroups=16 kern.job_control=1 kern.saved_ids=1 kern.boottime=Wed Oct 3 20:45:34 2018 kern.domainname= kern.maxpartitions=16 kern.rawpartition=2 kern.maxthread=1950 kern.nthreads=48 kern.osversion=GENERIC.MP#342 kern.somaxconn=128 kern.sominconn=80 kern.nosuidcoredump=1 kern.fsync=1 kern.sysvmsg=1 kern.sysvsem=1 kern.sysvshm=1 kern.msgbufsize=98256 kern.malloc.buckets=16,32,64,128,256,512,1024,2048,4096,8192,16384,3276 8,65536,131072,262144,524288 kern.malloc.bucket.16=(calls = 1722 total_allocated = 768 total_free = 393 elements = 256 high watermark = 1280 could_free = 0) kern.malloc.bucket.32=(calls = 4386 total_allocated = 896 total_free = 623 elements = 128 high watermark = 640 could_free = 0) kern.malloc.bucket.64=(calls = 7536 total_allocated = 1472 total_free = 1113 elements = 64 high watermark = 320 could_free = 876) kern.malloc.bucket.128=(calls = 9964 total_allocated = 3296 total_free = 27 elements = 32 high watermark = 160 could_free = 3) kern.malloc.bucket.256=(calls = 4129 total_allocated = 112 total_free = 6 elements = 16 high watermark = 80 could_free = 0) kern.malloc.bucket.512=(calls = 1621 total_allocated = 144 total_free = 6 elements = 8 high watermark = 40 could_free = 0) kern.malloc.bucket.1024=(calls = 2460 total_allocated = 172 total_free = 5 elements = 4 high watermark = 20 could_free = 55) kern.malloc.bucket.2048=(calls = 58 total_allocated = 36 total_free = 0 elements = 2 high watermark = 10 could_free = 0) kern.malloc.bucket.4096=(calls = 2780 total_allocated = 1047 total_free = 2 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.8192=(calls = 394 total_allocated = 216 total_free = 3 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.16384=(calls = 372 total_allocated = 5 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.32768=(calls = 10 total_allocated = 9 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.65536=(calls = 1540 total_allocated = 3 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.131072=(calls = 3 total_allocated = 3 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.262144=(calls = 0 total_allocated = 0 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.524288=(calls = 1 total_allocated = 1 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.kmemnames=free,,devbuf,,pcb,rtableifaddr,soopts,sysctl, counters,,ioctlops,iov,mount,,NFS_req,NFS_mount,,vnodes,namecache,U FS_quota,UFS_mount,shm,VM_map,sem,dirhash,ACPI,VM_pmapfile,file_des c,,proc,subproc,VFS_cluster,,,MFS_node,,,Export_Host,NFS_srvsock,,NFS_d aemon,ip_moptions,in_multi,ether_multi,mrt,ISOFS_mount,ISOFS_node,MSDOS FS_mount,MSDOSFS_fat,MSDOSFS_node,ttys,exec,miscfs_mount,fusefs_mount,, ,,,pfkey_data,tdb,xform_data,,pagedep,inodedep,newblk,,,indirdep,,, ,,VM_swap,,UVM_amap,UVM_aobj,,USB,USB_device,USB_HC,,memdesc,,, crypto_data,,IPsec_credsemuldata,ip6_options,NDP,,,temp,NTF S_mount,NTFS_node,NTFS_fnode,NTFS_dir,NTFS_hash,NTFS_attr,NTFS_data,NTF S_decomp,NTFS_vrun,kqueue,,SYN_cache,UDF_mount,UDF_file_entry,UDF_file_ id,,AGP_Memory,DRM kern.malloc.kmemstat.free=(inuse = 0, calls = 0, memuse = 0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 78644K, spare = 0, sizes = (none)) kern.malloc.kmemstat.devbuf=(inuse = 2071, calls = 3032, memuse = 4663K, limblocks = 0, mapblocks = 0, maxused = 4664K, limit = 78644K, spare = 0, sizes = (16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072)) kern.malloc.kmemstat.pcb=(inuse = 76, calls = 114, memuse = 16K, limblocks = 0, mapblocks = 0, maxused = 17K, limit = 78644K, spare = 0, sizes = (16,32,128,1024)) kern.malloc.kmemstat.rtable=(inuse = 71, calls = 157, memuse = 3K, limblocks = 0, mapblocks = 0, maxused = 3K, limit = 78644K, spare = 0, sizes = (16,32,64,128,256)) kern.malloc.kmemstat.ifaddr=(inuse = 52, calls = 53, memuse = 11K, limblocks = 0, mapblocks = 0, maxused = 11K, limit = 78644K, spare = 0, sizes = (32,64,128,256,4096)) kern.malloc.kmemstat.soopts=(inuse = 0, calls = 0, memuse = 0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 78644K, spare = 0, sizes = (none)) kern.malloc.kmemstat.sysctl=(inuse = 3, calls = 3, memuse = 2K, limblocks = 0, mapblocks = 0, maxused = 2K, limit = 78644K, spare = 0, sizes = (32,128,1024)) kern.malloc.kmemstat.counters=(inuse = 79, calls = 79, memuse = 67K, limblocks = 0,
Re: Performance impact of PF on APU2
Ok so I compared 6.3-release, 6.3-release+syspatches(=stable?) and the latest snapshot from October 2. I measured iperf3 throughput between A and B, like this: PC A <---> APU2 <---> PC B pf rules are the one shipped by default in 6.3: gw# pfctl -sr block return all pass all flags S/SA block return in on ! lo0 proto tcp from any to any port 6000:6010 block return out log proto tcp all user = 55 block return out log proto udp all user = 55 OpenBSD 6.3 RELEASE: - pf enabled: 841 Mbits/sec - pf disabled: 935 Mbits/sec OpenBSD 6.3 + Syspatch: - pf enabled: 803 Mbits/sec - pf disabled: 936 Mbits/sec OpenBSD CURRENT: - pf enabled: 526 Mbits/sec (541 with kern.pool_debug=0) - pf disabled: 934 Mbits/sec So there is a small perf drop when applying all syspatches to 6.3 (not sure which one cause the drop), but the performance drop SIGNIFICANTLY using the latest snapshot. Am I missing something? (I really hope I am)
Re: Performance impact of PF on APU2
can you show us a copy of your sysctl output? check if smt is disabled ... (Hyper Threading ) Im not sure if this would have an effect on the APU2C2 ... but worth checking as it is a change in behaviour between 6.3 and current AFIK Thanks Tom Smyth On Thu, 4 Oct 2018 at 04:58, Benjamin Petit wrote: > > Ok so I compared 6.3-release, 6.3-release+syspatches(=stable?) and the latest > snapshot from October 2. > > I measured iperf3 throughput between A and B, like this: > PC A <---> APU2 <---> PC B > > pf rules are the one shipped by default in 6.3: > > gw# pfctl -sr > block return all > pass all flags S/SA > block return in on ! lo0 proto tcp from any to any port 6000:6010 > block return out log proto tcp all user = 55 > block return out log proto udp all user = 55 > > OpenBSD 6.3 RELEASE: > - pf enabled: 841 Mbits/sec > - pf disabled: 935 Mbits/sec > > OpenBSD 6.3 + Syspatch: > - pf enabled: 803 Mbits/sec > - pf disabled: 936 Mbits/sec > > OpenBSD CURRENT: > - pf enabled: 526 Mbits/sec (541 with kern.pool_debug=0) > - pf disabled: 934 Mbits/sec > > So there is a small perf drop when applying all syspatches to 6.3 (not sure > which one cause the drop), > but the performance drop SIGNIFICANTLY using the latest snapshot. > > Am I missing something? (I really hope I am) -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: Performance impact of PF on APU2
Added my sysctl output in attachement (I never really used distribution lists before...) I don't think the APU2 uses HT, but I tried with sysctl hw.smt=1, no difference in the iperf3 numbers. On Thu, 2018-10-04 at 05:02 +0100, Tom Smyth wrote: > can you show us a copy of your sysctl output? > > check if smt is disabled ... (Hyper Threading ) > > Im not sure if this would have an effect on the > APU2C2 ... but worth checking as it is a change > in behaviour between 6.3 and current AFIK > > Thanks > > Tom Smyth > On Thu, 4 Oct 2018 at 04:58, Benjamin Petit wrote: > > Ok so I compared 6.3-release, 6.3-release+syspatches(=stable?) and > > the latest snapshot from October 2. > > > > I measured iperf3 throughput between A and B, like this: > > PC A <---> APU2 <---> PC B > > > > pf rules are the one shipped by default in 6.3: > > > > gw# pfctl -sr > > block return all > > pass all flags S/SA > > block return in on ! lo0 proto tcp from any to any port 6000:6010 > > block return out log proto tcp all user = 55 > > block return out log proto udp all user = 55 > > > > OpenBSD 6.3 RELEASE: > > - pf enabled: 841 Mbits/sec > > - pf disabled: 935 Mbits/sec > > > > OpenBSD 6.3 + Syspatch: > > - pf enabled: 803 Mbits/sec > > - pf disabled: 936 Mbits/sec > > > > OpenBSD CURRENT: > > - pf enabled: 526 Mbits/sec (541 with kern.pool_debug=0) > > - pf disabled: 934 Mbits/sec > > > > So there is a small perf drop when applying all syspatches to 6.3 > > (not sure which one cause the drop), > > but the performance drop SIGNIFICANTLY using the latest snapshot. > > > > Am I missing something? (I really hope I am) > > kern.ostype=OpenBSD kern.osrelease=6.4 kern.osrevision=201811 kern.version=OpenBSD 6.4 (GENERIC.MP) #342: Tue Oct 2 23:23:09 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP kern.maxvnodes=22282 kern.maxproc=1310 kern.maxfiles=7030 kern.argmax=262144 kern.securelevel=1 kern.hostname=gw.home.** kern.hostid=0 kern.clockrate=tick = 1, tickadj = 40, hz = 100, profhz = 100, stathz = 100 kern.dnsjackport=0 kern.posix1version=200809 kern.ngroups=16 kern.job_control=1 kern.saved_ids=1 kern.boottime=Wed Oct 3 20:45:34 2018 kern.domainname= kern.maxpartitions=16 kern.rawpartition=2 kern.maxthread=1950 kern.nthreads=48 kern.osversion=GENERIC.MP#342 kern.somaxconn=128 kern.sominconn=80 kern.nosuidcoredump=1 kern.fsync=1 kern.sysvmsg=1 kern.sysvsem=1 kern.sysvshm=1 kern.msgbufsize=98256 kern.malloc.buckets=16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288 kern.malloc.bucket.16=(calls = 1722 total_allocated = 768 total_free = 393 elements = 256 high watermark = 1280 could_free = 0) kern.malloc.bucket.32=(calls = 4386 total_allocated = 896 total_free = 623 elements = 128 high watermark = 640 could_free = 0) kern.malloc.bucket.64=(calls = 7536 total_allocated = 1472 total_free = 1113 elements = 64 high watermark = 320 could_free = 876) kern.malloc.bucket.128=(calls = 9964 total_allocated = 3296 total_free = 27 elements = 32 high watermark = 160 could_free = 3) kern.malloc.bucket.256=(calls = 4129 total_allocated = 112 total_free = 6 elements = 16 high watermark = 80 could_free = 0) kern.malloc.bucket.512=(calls = 1621 total_allocated = 144 total_free = 6 elements = 8 high watermark = 40 could_free = 0) kern.malloc.bucket.1024=(calls = 2460 total_allocated = 172 total_free = 5 elements = 4 high watermark = 20 could_free = 55) kern.malloc.bucket.2048=(calls = 58 total_allocated = 36 total_free = 0 elements = 2 high watermark = 10 could_free = 0) kern.malloc.bucket.4096=(calls = 2780 total_allocated = 1047 total_free = 2 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.8192=(calls = 394 total_allocated = 216 total_free = 3 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.16384=(calls = 372 total_allocated = 5 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.32768=(calls = 10 total_allocated = 9 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.65536=(calls = 1540 total_allocated = 3 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.131072=(calls = 3 total_allocated = 3 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.262144=(calls = 0 total_allocated = 0 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.524288=(calls = 1 total_allocated = 1 total_free = 0 elements = 1 high watermark = 5 could_free = 0)
Re: network architecture question
Hi Tom, > The book of PF by Peter M Hansteen is very good, and openBSD Specific > Building Internet firewalls is good also ... Building internet > firewalls book can > be a bit verbose atimes... but it does go through things in detail... Thank you for your recommendation. I apologize for my incomplete question earlier - I am aware of the excellent books from mwlucas and peternmhansteen. > regarding BGP ... > https://www.ssi.gouv.fr/uploads/2016/03/bgp-configuration-best-practices.pdf Thanks, will put these on my to-learn list. Regards, ab -|-|-|-|-|-|-|--
Re: network architecture question
Hi Ingo, Thank you for your response. > i mostly learn by reading reference manuals, standard documents, > and source code. I try to too, but with limited successes. So topology and other higher order concepts are out of my competency area, and hence my question. > I mentioned it to show that the strength of two-tier firewalls has > been well-established in standard textbooks for a long time. Understood. The recommendations for these standard textbooks is what I think I was going for. Regards, ab -|-|-|-|-|-|-|--
Re: IPv6 Multicast Listener Discovery - Listing and Disabling Group Membership
Hi Stuart,
Thank you for your response.
> > 2) How to disable an interface from joining IPv6 Node Information
> > multicast group (RFC 4620)?
> > In sys/netinet6/in6.c, the function in6_update_ifa contains the
> > following lines:
> >
> > /*
> > * join node information group address
> > */
> > if (in6_nigroup(ifp, hostname, hostnamelen, ) == 0) {
> > imm = in6_joingroup(ifp, _addr, );
> > if (!imm) {
> > /* XXX not very fatal, go on... */
> > } else {
> > LIST_INSERT_HEAD(>ia6_memberships,
> > imm, i6mm_chain);
> > }
> > }
>
> Not 100% sure but I think this may have been missed when support for
> RFC 4620 was removed from the kernel in 2014
>
> https://github.com/openbsd/src/commit/43f29087ef2fc515510c43f9dd706f7bbd9e39b7
You may be probably right, although I do not claim to understand IPv6.
My best guess is that the code block might have been originally present
in the KAME project.
Regards,
ab
-|-|-|-|-|-|-|--
Re: checking source with pvs-studio
Hi, Aaron Mason wrote on Wed, Oct 03, 2018 at 09:07:40AM +1000: > Apparently you've got to go through your source code > and plug the product in every single non-header file. Which is of course trivial to do - you write a script to do a checkout, run "sed -i", run the tool, collect the the results, and delete the checkout. So the harassment by the author is not even effective for his intended purpose. If the developer is *that* stupid in such a major respect, it's probably best to ignore the tool outright - that stupidity gives me the prejudice that the tool is likely to be hostile towards free software, greedy for private profit, and even more stupid in other ways, so it's likely a waste of time in the first place. It's not like there aren't lots of other choices, written by smart people for a change. Yours, Ingo
