Re: Why not use malloc S by default?
On Tue, Nov 22, 2016 at 10:18:32PM +0100, Benjamin Baier wrote: > On Tue, 22 Nov 2016 19:44:48 +0100 > "minek van" wrote: > > > So why isn't "S" enabled by default? It is the "most secure" solution for > > the > > malloc settings, no? > > Or are there still programs that will crash when "S" is used? > > What are those? > > Adding new printer on the CUPS webinterface does not "like" this > malloc option. It doesn't crash, it just doesn't work. > > Subtle breakage like this might occure when you "set and forget" this > feature. I guess thats why it is labled "for security auditing". > > Greetings Ben > Yes the 'S' setting finds all sorts of problems in ports. Last time I ran into one, gnome-shell crashed on startup and since gdm uses gnome-shell there was no graphical login. If you enable 'S' prepare for debugging complicated third party software on your own.
Re: Why not use malloc S by default?
Otto Moerbeek wrote: >It is not a problem of crashing or not, S does incur a performance hit >that we are not willing accept by default. I've seen this claim several times on this mailing list over the past few years but does anyone have actual data about it? How much of a performance hit is it in practice for, say, some typical tasks (whatever "typical" means)? I'm asking because I've been using S on my 10 year old laptop for 2.5 years now and I don't remember seeing any noticeable difference (or am I just very tolerant of low performance?) Out of curiosity, here's the result of running "time /bin/sh /etc/daily" three times in a row with /etc/malloc.conf -> S: 5m37.69s real 0m48.49s user 0m44.67s system 5m17.96s real 0m48.06s user 0m41.99s system 5m21.30s real 0m49.89s user 0m43.91s system (the faster second and third results are probably due to caching effects) and with no /etc/malloc.conf: 5m04.51s real 0m45.32s user 0m30.61s system 5m07.56s real 0m46.62s user 0m31.22s system 5m05.88s real 0m45.81s user 0m30.47s system So it's a performance hit of about 15 seconds out of more than five minutes, so about 5%. Not great but not something that a human would be likely to notice without actually timing it. Granted, /etc/daily might not be a perfect example because it seems to be mainly I/O bound (and my computer is not really representative of today's machines anyway), but I'd guess that a CPU bound program would probably allocate memory up front and have a low hit in the long run, while a memory intensive program (say, a language interpreter) would probably have its own GC system making the speed of malloc not so much of a problem. Does anyone know of a relatively common program for which S is a human-noticeable performance hit? Cheers, Philippe
Simple question on routing for IPSEC
Hi, Sorry for the dumb question but I'm suffering from config-writer's block ! OpenBSD6 if it makes any difference to the answers. Let's say I've got the following in ipsec.conf on my local gateway : "ike esp from 198.51.100.0/24 to any" Given that "any" is a catch-all, how do I, for example specify to route "203.0.113.0/24" via the ipsec gateway ? e.g. something like the below (where 192.0.2.1 is the remote gateway) doas route add -inet 203.0.113.0/24 192.0.2.1 add net 203.0.113.0/24: gateway 192.0.2.1: Network is unreachable Bob
Re: Why not use malloc S by default?
On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote: > Otto Moerbeek wrote: > >It is not a problem of crashing or not, S does incur a performance hit > >that we are not willing accept by default. > > I've seen this claim several times on this mailing list over the past > few years but does anyone have actual data about it? How much of a > performance hit is it in practice for, say, some typical tasks > (whatever "typical" means)? I'm asking because I've been using S on > my 10 year old laptop for 2.5 years now and I don't remember seeing any > noticeable difference (or am I just very tolerant of low performance?) > > Out of curiosity, here's the result of running "time /bin/sh > /etc/daily" three times in a row with /etc/malloc.conf -> S: > > 5m37.69s real 0m48.49s user 0m44.67s system > 5m17.96s real 0m48.06s user 0m41.99s system > 5m21.30s real 0m49.89s user 0m43.91s system > > (the faster second and third results are probably due to caching effects) > and with no /etc/malloc.conf: > > 5m04.51s real 0m45.32s user 0m30.61s system > 5m07.56s real 0m46.62s user 0m31.22s system > 5m05.88s real 0m45.81s user 0m30.47s system > > So it's a performance hit of about 15 seconds out of more than five > minutes, so about 5%. Not great but not something that a human would > be likely to notice without actually timing it. Granted, /etc/daily > might not be a perfect example because it seems to be mainly I/O bound > (and my computer is not really representative of today's machines > anyway), but I'd guess that a CPU bound program would probably > allocate memory up front and have a low hit in the long run, while a > memory intensive program (say, a language interpreter) would probably > have its own GC system making the speed of malloc not so much of a > problem. Does anyone know of a relatively common program for which S > is a human-noticeable performance hit? > > Cheers, > > Philippe Your assumptions on on memoryb intensive applications doing smart thing re memory is not true in general. If you look at the actual user and system time in the daily runs, you'll see that usertime + systemtime goes from about 77s to 90s. About 16% more cycles are used when S is active. I think that's enough evidence to see that S has a real performeace inpact. Another test (I have C in /etc/malloc.conf so I need to switch it off explicitly) is e.g. building. This we do a lot as developers. On a fast machine with SSD this is CPU bound: $ pwd /usr/src/bin/ksh $ MALLOC_OPTIONS=c time make 5.50 real 4.63 user 0.89 sys $ make clean $ MALLOC_OPTIONS=S time make 9.28 real 5.40 user 3.94 sys Here the difference is even bigger (about 68%). I think that shows enough why S isn't the default (apart from buggy third party software). -Otto
Re: Why not use malloc S by default?
Otto Moerbeek wrote: >Here the difference is even bigger (about 68%). I think that shows >enough why S isn't the default (apart from buggy third party >software). Fair enough. Cheers, Philippe
Re: Why not use malloc S by default?
On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote: > Otto Moerbeek wrote: > >It is not a problem of crashing or not, S does incur a performance hit > >that we are not willing accept by default. > > I've seen this claim several times on this mailing list over the past > few years but does anyone have actual data about it? How much of a > performance hit is it in practice for, say, some typical tasks > (whatever "typical" means)? [...] > Does anyone know of a relatively common program for which S > is a human-noticeable performance hit? I now see that otto already gave the same example, but since I ran the tests, here's some more numbers. In my experience, build times are increased by something between 50% and 100% when I switch from CJ (what I usually run) to S. Here's five consecutive runs of 'make -j4' of GENERIC.MP on my otherwise mostly idle T420 with 4 cores: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 2691.64 MHz. CJ 1m56.34s real 5m28.56s user 1m04.40s system S 4m10.98s real 6m03.39s user 8m45.45s system CJ 1m50.48s real 5m38.03s user 1m03.00s system S 4m06.88s real 5m59.65s user 7m57.17s system none1m41.22s real 5m16.35s user 1m02.65s system
Re: strange behaviour with route-to, default route, and ping -I
On Mon, Nov 21, 2016 at 12:10 PM, Stefan Sperling wrote: > On Mon, Nov 21, 2016 at 10:43:17AM -0500, Kenneth Gober wrote: >> I get the impression that route-to is applied when a packet enters the >> router, >> e.g. as part of a "pass in" rule, and that it is used to forcibly direct the >> packet to a particular interface for "pass out" rather than relying on the >> default routing table for the entry interface. >> >> This means that if the "pass out" rule is the first time you are seeing the >> packet (i.e. because it originated from the router itself) then the routing >> decision has already been made and it is now too late to route again. > > route-to takes effect when a state is created by a matched rule. > It is possible to use route-to on 'pass out' rules (at least, over here, > it works :) Prompted by Stefan, I made some time to test this myself and I can confirm that this works. I started with this rule in pf.conf: pass in log quick on em0 from em0:network to 8.8.8.8 route-to pppoe0 tagged TBD tag FORWARD And "ping 8.8.8.8" from the internal network got redirected to pppoe0 (default route is em2) but the same command issued at the router did not get redirected. I do not show the pass out rule here but I have a later one that will pass out (with NAT) anything tagged FORWARD. Adding this rule as well: pass out log quick on em2 to 8.8.8.8 route-to pppoe0 Caused "ping 8.8.8.8" originating from the router itself to be redirected just like the corresponding internal traffic. -ken
Re: strange behaviour with route-to, default route, and ping -I
Isn't that because your pings aren't originating from em0:network? Your rule need to apply in order to work, and the originating ip of the ping will not be correct in the first place, and neither does the ping come in on em0, as you state in the rule. "if incoming packets on em0 matches addresses em0:network and dest is 8.8.8.8.." and so on. 2016-11-23 15:04 GMT+01:00 Kenneth Gober : > On Mon, Nov 21, 2016 at 12:10 PM, Stefan Sperling wrote: > > On Mon, Nov 21, 2016 at 10:43:17AM -0500, Kenneth Gober wrote: > >> I get the impression that route-to is applied when a packet enters the > >> router, > >> e.g. as part of a "pass in" rule, and that it is used to forcibly > direct the > >> packet to a particular interface for "pass out" rather than relying on > the > >> default routing table for the entry interface. > >> > >> This means that if the "pass out" rule is the first time you are seeing > the > >> packet (i.e. because it originated from the router itself) then the > routing > >> decision has already been made and it is now too late to route again. > > > > route-to takes effect when a state is created by a matched rule. > > It is possible to use route-to on 'pass out' rules (at least, over here, > > it works :) > > Prompted by Stefan, I made some time to test this myself and I can > confirm that this works. > > I started with this rule in pf.conf: > > pass in log quick on em0 from em0:network to 8.8.8.8 route-to pppoe0 > tagged TBD tag FORWARD > > And "ping 8.8.8.8" from the internal network got redirected to pppoe0 > (default route is em2) > but the same command issued at the router did not get redirected. I > do not show the pass out > rule here but I have a later one that will pass out (with NAT) > anything tagged FORWARD. > > Adding this rule as well: > > pass out log quick on em2 to 8.8.8.8 route-to pppoe0 > > Caused "ping 8.8.8.8" originating from the router itself to be > redirected just like the > corresponding internal traffic. > > -ken > > -- May the most significant bit of your life be positive.
Re: Why not use malloc S by default?
On 2016-11-23, Philippe Meunier wrote: > Does anyone know of a relatively common program for which S > is a human-noticeable performance hit? vim with syntax highlighting. As a simple example just opening a file, the visible effect is a small extra delay, and easy to time: $ time (for i in `jot 10`; do vim '+:q!' /usr/ports/infrastructure/mk/bsd.port.mk; done) 0m00.45s real 0m00.34s user 0m00.11s system $ time (for i in `jot 10`; do MALLOC_OPTIONS=S vim '+:q!' /usr/ports/infrastructure/mk/bsd.port.mk; done) 0m01.27s real 0m00.40s user 0m00.85s system For interactive use, deleting lines in such a file (causing it to re-highlight as it goes) becomes very painful.
[FOSDEM] [CFP] FOSDEM 2017 - Distributions Devroom - Extended
FOSDEM 2017 - Distributions Devroom Call for Participation (new deadline) The Distributions devroom will take place 4 February, 2017 at FOSDEM, in room K.4.601 at Université Libre de Bruxelles, in Brussels, Belgium. Distributions are more than just hosted collections of software from various upstreams. Each distribution is responsible for problem-solving in building, testing, and releasing software as well as managing the lifecycle of each application in the collection. Additionally, distributions do very important work in ensuring that various versions of upstream software work well together and can co-exist. Distribution are also, often responsible, for "de-vendoring" upstream software so that security fixes can be applied more quickly. We welcome submissions targeted at contributors interested in issues unique to distributions, especially in the following topics: - Managing Build/Test/Release processes around shared ideas and resources - Lifecycle management, especially in the areas of sandboxing, containerization, vendoring, and bundling - Distribution construction tools and infrastructure development and implementation (building, signing, testing, distribution, etc.) - Cross-distribution collaboration on common issues, eg: content distribution, infrastructure, and documentation - Working with vendors and including them in the community - Building trust and code relationships with the upstream components of a distribution and between distributions - The future of distributions, emerging trends and evolving user demands from the idea of a platform - The place of distributions in today's world (including concepts of containerization, IoT, etc.) - Onboarding new users and mentorship, facilitating technical growth within the contributor base - Solving traditional problems like package management, and content management (eg. rpm/dpkg/ostree/coreos ) - Integration technologies like installers, deployment facilitation ( eg. cloud contextualisation ) - Principals of Rolling Releases, Long Term Supported Releases (LTS), Feature gated releases, and calendar releases Ideal submissions are actionable and opinionated. Submissions may be in the form of 25 or 50 minute talks, panel sessions, round-table discussions, or Birds of a Feather (BoF) sessions. Due to popular demand, We are extending the CFP for the Distributions Devroom until Friday 02-December-2016. We plan to maintain the rest of the schedule (e.g. notification dates) as-is. We look forward to your submissions. Revised Dates -- Submission Deadline: 02-Dec-2016 Acceptance Notification: 5-Dec-2016 Final Schedule Posted: 11-Dec-2016 How to submit -- Visit https://penta.fosdem.org/submission/FOSDEM17 1.) If you do not have an account, create one here 2.) Click 'Create Event' 3.) Enter your presentation details 4.) Be sure to select the Distributions Devroom track! 5.) Submit What to include --- - The title of your submission - A 1-paragraph Abstract - A longer description including the benefit of your talk to your target audience, including a definition of your target audience. - Approximate length / type of submission (talk, BoF, ...) - Links to related websites/blogs/talk material (if any) Administrative Notes We will be live-streaming and recording the Distributions Devroom. Presenting at FOSDEM implies permission to record your session and distribute the recording afterwards. All videos will be made available under the standard FOSDEM content license (CC-BY). If you have any questions, feel free to contact the devroom organizers: distributions-devr...@lists.fosdem.org (https://lists.fosdem.org/listinfo/distributions-devroom) Cheers! Brian Exelbierd (twitter: @bexelbie) and Brian Stinson (twitter: @bstinsonmhk) for and on behalf of The Distributions Devroom Program Committee
VMM with Hapertown?
I have some systems with Hapertown CPUS that support VT-x, but not EPT. Does vmm currently require EPT to work?
unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'
I was using ssh socks5 tunnel (-D) today and I saw many: channel 4: open failed: administratively prohibited: open failed messages. It seems non-resolvable hostnames on my gw (ie. end of ssh socks5 tunnel) is passed to client as "prohibited" event. This seems odd and confusing. GW is an older 6.0-current amd64. j. Firefox with SOCKS5 tunnel (ssh -D $gw). Than I opened an url, ie. wiki.brq.example.com: ~~~ debug1: Connection to port forwarding to socks port 0 requested. debug2: fd 11 setting TCP_NODELAY debug3: fd 11 is O_NONBLOCK debug3: fd 11 is O_NONBLOCK debug1: channel 4: new [dynamic-tcpip] debug2: channel 4: pre_dynamic: have 0 debug2: channel 4: pre_dynamic: have 3 debug2: channel 4: decode socks5 debug2: channel 4: socks5 auth done debug2: channel 4: pre_dynamic: need more debug2: channel 4: pre_dynamic: have 0 debug2: channel 4: pre_dynamic: have 26 debug2: channel 4: decode socks5 debug2: channel 4: socks5 post auth debug2: channel 4: dynamic request: socks5 host wiki.brq.example.com port 80 command 1 debug3: send packet: type 90 debug3: receive packet: type 92 channel 4: open failed: administratively prohibited: open failed ^ debug2: channel 4: zombie debug2: channel 4: garbage collecting debug1: channel 4: free: direct-tcpip: listening port for wiki.brq.example.com port 80, connect from 127.0.0.1 port 30421 to 127.0.0.1 port , nchannels 5 debug3: channel 4: status: The following connections are open: #2 client-session (t4 r0 i0/0 o0/0 fd 7/8 cc -1) #3 direct-tcpip: listening port for www.google.com port 443, connect from 127.0.0.1 port 24731 to 127.0.0.1 port (t4 r1 i0/0 o0/0 fd 10/10 cc -1) ~~~ part of auth.log: ~~~ Nov 23 19:24:04 gw sshd[20891]: error: connect_to wiki.brq.example.com: unknown host (no address associated with name) ~~~ my sshd_config part: ~~~ Match Address 192.168.1.0/24,192.168.2.0/24,192.168.254.0/24,2xx.0.0.0/8,2001:470:::/64 User jirib PasswordAuthentication no AuthenticationMethods publickey AuthorizedKeysFile /etc/ssh/authorized_keys.d/%u AllowTcpForwarding yes PermitTunnel yes AllowAgentForwarding yes GatewayPorts yes X11Forwarding yes ~~~
Re: VMM with Hapertown?
On Wed, Nov 23, 2016 at 01:03:07PM -0500, alexmcwhir...@triadic.us wrote: > I have some systems with Hapertown CPUS that support VT-x, but not EPT. Does > vmm currently require EPT to work? > for the time being, yes.
Making sense of ktrace
Hi all, I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs fine on 5.9 i386. I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't appear to be w^x related. To be sure I've mounted that partition with wxallowed. Here are the last few lines from kdump--would sure appreciate it if someone could shed some light on what's happening. 47868 fastforward CALL mmap(0,0x1000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9049032314880/0x83ae45b5000 47868 fastforward CALL mmap(0,0x1000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9049215606784/0x83aef482000 47868 fastforward CALL mmap(0,0xa000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9047796883456/0x83a9ab82000 47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL munmap(0x83a9ab82000,0xa000) 47868 fastforward RET munmap 0 47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL getthrid() 47868 fastforward RET getthrid 1047868/0xffd3c 47868 fastforward CALL __set_tcb(0x83b14ce3600) 47868 fastforward RET __set_tcb 0 47868 fastforward CALL mmap(0,0x1000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9049102131200/0x83ae884a000 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x3) 47868 fastforward RET mprotect 0 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL sigaction(SIGPIPE,0x7f7cdec0,0) 47868 fastforward STRU struct sigaction { handler=SIG_IGN, mask=0<>, flags=0<> } 47868 fastforward RET sigaction 0 47868 fastforward PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620 trapno=6 47868 fastforward NAMI "fastforward.core" I've re-compiled this also with what I found on the internet to make a core file that gdb can use but that's even more of a mystery to me than ktrace. Is there a better debugger that I can use? Thanks, Jeff Ross
Re: umb(4) connection issues
On Tue, Nov 22, 2016 at 12:06:30PM -0800, Bryan Vyhmeister wrote: > On Tue, Nov 22, 2016 at 06:14:28PM +0100, Ingo Feinerer wrote: > > --8<- > > umb0: flags=8851 mtu 1500 > > index 5 priority 0 llprio 3 > > roaming disabled registration home network > > state up cell-class custom rssi -69dBm speed 5.5Mps up 20.0Mps down > > SIM initialized PIN valid > > subscriber-id 012345678901234 ICC-id 0123456789012345689 provider 3 > > AT > > device KRD 131 30/123 - R1A IMEI 012345689012345 firmware R3C11 > > (Pro), R4A10 (App) > > APN drei.at > > dns 213.94.78.17 213.94.78.16 > > status: active > > inet 10.72.61.158 --> 10.72.61.155 netmask 0xfff8 > > --8<- > > Due to some conflicts with umb(4) and MP safe work going on, a default > route is not automatically created for a umb(4) connection. You have to > do it manually like the following for your example above: > > route add -ifp umb0 default 10.72.61.155 > > I created a shell script to set this up. Thanks for the pointer. Indeed, it works for me when an appropriate (default) route is manually added and the listed DNS entries are manually set in /etc/resolv.conf. Best regards, Ingo
Re: Making sense of ktrace
On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote: > Hi all, > > I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs > fine on 5.9 i386. > > I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't > appear to be w^x related. To be sure I've mounted that partition with > wxallowed. > > Here are the last few lines from kdump--would sure appreciate it if someone > could shed some light on what's happening. > > 47868 fastforward CALL > mmap(0,0x1000,0x3,0x1002,-1,0) > 47868 fastforward RET mmap 9049032314880/0x83ae45b5000 > 47868 fastforward CALL > mmap(0,0x1000,0x3,0x1002,-1,0) > 47868 fastforward RET mmap 9049215606784/0x83aef482000 > 47868 fastforward CALL > mmap(0,0xa000,0x3,0x1002,-1,0) > 47868 fastforward RET mmap 9047796883456/0x83a9ab82000 > 47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1) > 47868 fastforward RET mprotect 0 > 47868 fastforward CALL munmap(0x83a9ab82000,0xa000) > 47868 fastforward RET munmap 0 > 47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1) > 47868 fastforward RET mprotect 0 > 47868 fastforward CALL getthrid() > 47868 fastforward RET getthrid 1047868/0xffd3c > 47868 fastforward CALL __set_tcb(0x83b14ce3600) > 47868 fastforward RET __set_tcb 0 > 47868 fastforward CALL > mmap(0,0x1000,0x3,0x1002,-1,0) > 47868 fastforward RET mmap 9049102131200/0x83ae884a000 > 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1) > 47868 fastforward RET mprotect 0 > 47868 fastforward CALL > mprotect(0x83ae884a000,0x1000,0x3) > 47868 fastforward RET mprotect 0 > 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1) > 47868 fastforward RET mprotect 0 > 47868 fastforward CALL sigaction(SIGPIPE,0x7f7cdec0,0) > 47868 fastforward STRU struct sigaction { handler=SIG_IGN, mask=0<>, > flags=0<> } > 47868 fastforward RET sigaction 0 > 47868 fastforward PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620 > trapno=6 > 47868 fastforward NAMI "fastforward.core" The program is aborted by a SIGSEGV. Thta means it is accessing a memory location that is not allocated by the program. > > I've re-compiled this also with what I found on the internet to make a core > file that gdb can use but that's even more of a mystery to me than ktrace. > Is there a better debugger that I can use? > > Thanks, > > Jeff Ross $ gdb fastforward fastforward.core then type the command bt, should give you some clue, if the stack isn't damaged too much. -Otto
Re: Making sense of ktrace
On 11/23/16 1:16 PM, Otto Moerbeek wrote: On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote: Hi all, I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs fine on 5.9 i386. I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't appear to be w^x related. To be sure I've mounted that partition with wxallowed. Here are the last few lines from kdump--would sure appreciate it if someone could shed some light on what's happening. 47868 fastforward CALL mmap(0,0x1000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9049032314880/0x83ae45b5000 47868 fastforward CALL mmap(0,0x1000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9049215606784/0x83aef482000 47868 fastforward CALL mmap(0,0xa000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9047796883456/0x83a9ab82000 47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL munmap(0x83a9ab82000,0xa000) 47868 fastforward RET munmap 0 47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL getthrid() 47868 fastforward RET getthrid 1047868/0xffd3c 47868 fastforward CALL __set_tcb(0x83b14ce3600) 47868 fastforward RET __set_tcb 0 47868 fastforward CALL mmap(0,0x1000,0x3,0x1002,-1,0) 47868 fastforward RET mmap 9049102131200/0x83ae884a000 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x3) 47868 fastforward RET mprotect 0 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1) 47868 fastforward RET mprotect 0 47868 fastforward CALL sigaction(SIGPIPE,0x7f7cdec0,0) 47868 fastforward STRU struct sigaction { handler=SIG_IGN, mask=0<>, flags=0<> } 47868 fastforward RET sigaction 0 47868 fastforward PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620 trapno=6 47868 fastforward NAMI "fastforward.core" The program is aborted by a SIGSEGV. Thta means it is accessing a memory location that is not allocated by the program. I've re-compiled this also with what I found on the internet to make a core file that gdb can use but that's even more of a mystery to me than ktrace. Is there a better debugger that I can use? Thanks, Jeff Ross $ gdb fastforward fastforward.core then type the command bt, should give you some clue, if the stack isn't damaged too much. -Otto Thank you, Otto! The stack may indeed be too damaged--I get the following but it doesn't look very helpful: jross@luna:/package/mail/sqmail/sqmail-3.2.13 $ sudo gdb /var/qmail/bin/fastforward fastforward.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd6.0"...(no debugging symbols found) Core was generated by `fastforward'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found) Loaded symbols for /var/qmail/bin/fastforward Reading symbols from /usr/lib/libc.so.88.0...done. Loaded symbols for /usr/lib/libc.so.88.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x0115d4803035 in ?? () from /var/qmail/bin/fastforward (gdb) bt #0 0x0115d4803035 in ?? () from /var/qmail/bin/fastforward #1 0x0115d4802545 in ?? () from /var/qmail/bin/fastforward #2 0x0115d48015f2 in ?? () from /var/qmail/bin/fastforward #3 0x in ?? () (gdb) I built fastforward with cc -g -O0 -include /usr/include/errno.h -pipe is there a better incantation? Thanks again! Jeff
Re: umb(4) connection issues
On Wed, Nov 23, 2016 at 08:37:04PM +0100, Ingo Feinerer wrote: > Indeed, it works for me when an appropriate (default) route is manually > added and the listed DNS entries are manually set in /etc/resolv.conf. I forgot to mention about DNS. The script I came up with just grabs the values from the ifconfig output and adds the default route and then puts the DNS entries in place. Bryan
Re: Making sense of ktrace
Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: > The stack may indeed be too damaged--I get the following but it > doesn't look very helpful: More likely the symbols were stripped. Assuming this was installed from sources, edit conf-cc and add -g, then edit conf-ld and remove the -s: $ head -1 conf-cc cc -O2 -g $ head -1 conf-ld cc $ Then recompile and try again (e.g. get a new core file and run gdb again). Andy -- TAI64 timestamp: 4000583654c6
Re: Making sense of ktrace
"Andy Bradford" writes: > Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: > >> The stack may indeed be too damaged--I get the following but it >> doesn't look very helpful: > > More likely the symbols were stripped. > > Assuming this was installed from sources, edit conf-cc and add -g, then > edit conf-ld and remove the -s: > > $ head -1 conf-cc > cc -O2 -g > $ head -1 conf-ld > cc Better add -g here too. > $ > > Then recompile and try again (e.g. get a new core file and run gdb > again). > > Andy -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'
On Wed, Nov 23, 2016 at 01:35:17PM -0500, Jiri B wrote: > I was using ssh socks5 tunnel (-D) today and I saw many: > > channel 4: open failed: administratively prohibited: open failed > > messages. It seems non-resolvable hostnames on my gw (ie. end of ssh > socks5 tunnel) is passed to client as "prohibited" event. > > This seems odd and confusing. GW is an older 6.0-current amd64. The code in sshd where the response is composed doesn't know what the reason for the failure is. I suspect thid dates back to the original Protocol 1 code becuase Protocol 1 didn't (I think) have a reason field. This passes the reason back up the stack and sends it to the client. Index: channels.c === RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.356 diff -u -p -r1.356 channels.c --- channels.c 18 Oct 2016 17:32:54 - 1.356 +++ channels.c 24 Nov 2016 04:36:58 - @@ -3038,7 +3038,7 @@ channel_input_port_open(int type, u_int3 } packet_check_eom(); c = channel_connect_to_port(host, host_port, - "connected socket", originator_string); + "connected socket", originator_string, NULL, NULL); free(originator_string); free(host); if (c == NULL) { @@ -3995,7 +3995,8 @@ channel_connect_ctx_free(struct channel_ /* Return CONNECTING channel to remote host:port or local socket path */ static Channel * -connect_to(const char *name, int port, char *ctype, char *rname) +connect_to(const char *name, int port, char *ctype, char *rname, int *reason, +char **errmsg) { struct addrinfo hints; int gaierr; @@ -4036,7 +4037,12 @@ connect_to(const char *name, int port, c hints.ai_family = IPv4or6; hints.ai_socktype = SOCK_STREAM; snprintf(strport, sizeof strport, "%d", port); - if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop)) != 0) { + if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop)) + != 0) { + if (errmsg != NULL) + *errmsg = ssh_gai_strerror(gaierr); + if (reason != NULL) + *reason = SSH2_OPEN_CONNECT_FAILED; error("connect_to %.100s: unknown host (%s)", name, ssh_gai_strerror(gaierr)); return NULL; @@ -4076,7 +4082,8 @@ channel_connect_by_listen_address(const return permitted_opens[i].downstream; return connect_to( permitted_opens[i].host_to_connect, - permitted_opens[i].port_to_connect, ctype, rname); + permitted_opens[i].port_to_connect, ctype, rname, + NULL, NULL); } } error("WARNING: Server requests forwarding for unknown listen_port %d", @@ -4093,7 +4100,8 @@ channel_connect_by_listen_path(const cha if (open_listen_match_streamlocal(&permitted_opens[i], path)) { return connect_to( permitted_opens[i].host_to_connect, - permitted_opens[i].port_to_connect, ctype, rname); + permitted_opens[i].port_to_connect, ctype, rname, + NULL, NULL); } } error("WARNING: Server requests forwarding for unknown path %.100s", @@ -4103,7 +4111,8 @@ channel_connect_by_listen_path(const cha /* Check if connecting to that port is permitted and connect. */ Channel * -channel_connect_to_port(const char *host, u_short port, char *ctype, char *rname) +channel_connect_to_port(const char *host, u_short port, char *ctype, +char *rname, int *reason, char **errmsg) { int i, permit, permit_adm = 1; @@ -4128,9 +4137,10 @@ channel_connect_to_port(const char *host if (!permit || !permit_adm) { logit("Received request to connect to host %.100s port %d, " "but the request was denied.", host, port); + *reason = SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED; return NULL; } - return connect_to(host, port, ctype, rname); + return connect_to(host, port, ctype, rname, reason, errmsg); } /* Check if connecting to that path is permitted and connect. */ @@ -4162,7 +4172,7 @@ channel_connect_to_path(const char *path "but the request was denied.", path); return NULL; } - return connect_to(path, PORT_STREAMLOCAL, ctype, rname); + return connect_to(path, PORT_STREAMLOCAL, ctype, rname, NULL, NULL); } void Index: channels.h === RCS file: /cvs/src/usr.bin/ssh/channels.h,v retrieving revision 1.120 diff -u -p -r1
relayd with multiple pools
Hello list, following relayd setup exists in prod: relay int_health_check { listen on 127.0.0.1 port 78 protocol http_relay forward to port 80 mode roundrobin check http "/" code 200 forward to port 80 mode roundrobin check http "/" code 503 forward to port 80 mode roundrobin check http "/" code 301 forward to port 9800 mode roundrobin check http "/" code 503 } table { 192.168.10.31 parent 1, 192.168.10.32 parent 2, \ 192.168.10.33 parent 3, 192.168.10.34 parent 4, \ 192.168.10.35 parent 5, 192.168.10.36 parent 6 \ } table { 10.2.128.34 parent 9, 10.2.128.35 parent 10, \ 10.2.128.36 parent 11, 10.2.128.37 parent 12, \ 10.2.128.38 parent 13, 10.2.128.39 parent 14 \ } table { 192.168.10.83 parent 7, 192.168.10.84 parent 8 } The dance above, if unclear, is done to eliminate number of health checks per relay and copy the state of machines into each relay using those pools. We have several relays. Below is one of those. relay se_m_tls { listen on $VIP22 port 443 tls listen on $VIP23 port 443 tls protocol tls_accel forward to port 80 mode roundrobin check http "/" code 200 forward to port 80 mode roundrobin check tcp forward to port 80 mode roundrobin check tcp } The idea here is obvious, is to fall through until client reaches . With relay above, status is following: m_vm_pool is enabled m_hw_pool is disabled fallback_copy is enabled We decided to test fallback_copy and thus I disabled m_vm_pool as well. Expected result is that all traffic should end up in fallback_copy and display very simple index.html. Actual result is that relay continued to operate as usual, eg. serving PHP generated content. This test was done from a different location so no prev. states existed in PF. Eg. disable first, then surf. Is this expected behavior ? I also noted, that if I disable parent table, eg for example , hosts within the pool never get status UNKNOWN and thus appear UP in all child tables (). My understanding is that if table is disabled, relayd will stop checking hosts within table and those eventually should switch status to UNKNOWN. As well as the rest on child tables using this parent table. As in the test above, disabling child table should override status of hosts within the table and those should become UNKNOW, which should prevent usage of this child table. Any clarification regarding this scenario is appreciated. P.S. This is 6.0-stable Br //mxb