similar to: [PATCH] Trusted IRIX Support

http://bugzilla.mindrot.org/show_bug.cgi?id=1043 Summary: Trusted IRIX Support Product: Portable OpenSSH Version: 4.0p1 Platform: MIPS OS/Version: IRIX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: bitbucket at mindrot.org ReportedBy: josterm at raytheon.com sshd

The following patch appears to fix the BUS error received on Solaris 8. This problem manifests as an immediate disconnect with no apparent cause immediately after authentication with the host. --- Darren Tucker <dtucker at zip.com.au> wrote: > Date: Tue, 30 Sep 2003 09:35:26 +1000 > From: Darren Tucker <dtucker at zip.com.au> > Subject: Re: Bus Error with OpenSSH 3.7.1p2 on

I compiled openssh 3.7.1p1 on Solaris 9 with the Forte compiler in 64-bit mode. After authentication, a forked child of sshd dies with a Bus Error in `read_etc_default_login' (session.c). The reason is the use of `sscanf' with control string "%5lo" on a `mode_t' value. On Solaris in 64-bit mode, `mode_t' is an `unsigned int' (32 bits), whereas `long' is 64

Hi, below is a patch which simply removes a Cygwin-specific piece of code from OpenSSH. Input from a system admin educated me how useful this option could be on Cygwin as well. However, way back when the call to read_etc_default_login got disabled on Cygwin hardcoded in session.c, rather than just setting --disable-etc-default-login when building the Cygwin version of OpenSSH. So, here's

openssh 3.7p1 sshd on Solaris 8 / sparcv9: sshd runs fine, and starts to allow the login. However, when reading from /etc/default/login, I get a bus error. I am able to get sshd to work by commenting out these lines in session.c: 1015,1018c1015 < # ifdef HAVE_ETC_DEFAULT_LOGIN < read_etc_default_login(&env, &envsize, pw->pw_uid); < path =

On 6 March 2015 at 03:47, James Bottomley <James.Bottomley at hansenpartnership.com> wrote: > From: James Bottomley <JBottomley at Parallels.com> > > The current string_get_size() overflows when the device size goes over > 2^64 bytes because the string helper routine computes the suffix from > the size in bytes. However, the entirety of Linux thinks in terms of >

On 6 March 2015 at 03:47, James Bottomley <James.Bottomley at hansenpartnership.com> wrote: > From: James Bottomley <JBottomley at Parallels.com> > > The current string_get_size() overflows when the device size goes over > 2^64 bytes because the string helper routine computes the suffix from > the size in bytes. However, the entirety of Linux thinks in terms of >

I have a small program that I am broadcasting out on port 36 and attempting to receive information back. Using "tcpdump port 36" I can see 2 devices responding to me but I get no data. The response my program gets is: Size IP Address Subnet MAC Address ID 20 0.0.0.0 0.0.0.0 00-00-00-00-00-00 Does someone know what I might not be doing

http://bugzilla.mindrot.org/show_bug.cgi?id=252 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #212 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-08-22 14:14 -------

I had a problem much like the one that Matthias Koeppe experienced. I would only get the BUS error when running in a YASSP-modified system, though. The binary worked fine on a non-YASSP host. I applied his change to use a long for the mask, and it works now. Cheers, -Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search

From: Matt Fleming <matt.fleming at linux.intel.com> The usage of open_file() is wrong in core/fs/pxe/pxe.c. Any non-negative return value indicates success, not just a return value of zero. This bug was introduced in commit ba4fefa9b52b "core: change load_config() to open_config()". The bug causes pxelinux to fail to open configuration files. Signed-off-by: Matt Fleming

Hi all, I'm new here so bear with me. I am working on a project at work where we are replacing 1000+ Dell servers. When a new Dell server is delivered to one of our remote offices it will PXE boot off of the existing Dell server and install openSuse and then configure itself. We also PXE boot windows PCs in the remote offices so we needed a way to assign a large range of MAC addresses to a

I built OpenSSH as a 64-bit binary on Solaris 9, using gcc 3.3.2, OpenSSL 0.9.7c and zlib 1.2.1. sshd starts up normally, and will begin the login session, however, some time after it reads /etc/default/login, it faults and kills the connection. There are no error messages logged to syslog (with LogLevel set to DEBUG) or with the -ddd option. Here's a truss of the failure: 8132:

The story of this problem, AFAIK, is that Solaris 8 YASSP and JASS and vigilant/paranoid sysadmins have been known to set a restricitve umask in /etc/default/login. OpenSSH compatibility for Solaris 8 has been spotty at times for sparcv9 targets. This time, when a sparcv9 binary tries to sscanf(3C) the numeric umask as a long octal and put it in a mode_t, SIGBUS happens. What this looks like in

Hi Tom On Mon, Oct 19, 2020 at 09:31:15AM -0700, trix at redhat.com wrote: > From: Tom Rix <trix at redhat.com> > > A break is not needed if it is preceded by a return or break > > Signed-off-by: Tom Rix <trix at redhat.com> Looks good and builds with no warnings. One of the diffs made me - "oh this looks wrong". But after I looked again it was right and

Hi folks, I've been a trixbox user for a few years now but I'm thinking about jumping ship. Trixbox is great, but it's missing two features out of the box which are really important to me: outbound faxing (hylafax) and imap voicemail. I see no indication that they will be included anytime in the near future, so I have a choice to make - I've looked around at Elastix,

From: Tom Rix <trix at redhat.com> clang static analysis flags this problem hw.c:271:12: warning: The left operand of '>=' is a garbage value if (pv.M1 >= pll_lim.vco1.min_m ... ~~~~~ ^ This is mostly not a problem because an early check in nouveau_hw_fix_bad_vpll() if (nvbios_pll_parse(bios, pll, &pll_lim)) return; nouveau_hw_get_pllvals(dev, pll,

On 10/17/20 10:43 PM, Greg KH wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: >> From: Tom Rix <trix at redhat.com> >> >> This is a upcoming change to clean up a new warning treewide. >> I am wondering if the change could be one mega patch (see below) or >> normal patch per file about 100 patches or somewhere half way by

On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > > > clang has a number of useful, new warnings see > > >

On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote: > From: Tom Rix <trix at redhat.com> > > This is a upcoming change to clean up a new warning treewide. > I am wondering if the change could be one mega patch (see below) or > normal patch per file about 100 patches or somewhere half way by collecting > early acks. Please break it up into