Modify

Opened 9 years ago

Closed 7 years ago

#5210 closed defect (fixed)

Socat still crashes in xioinitialize

Reported by: anonymous Owned by: jow
Priority: normal Milestone: Backfire 10.03
Component: packages Version: Trunk
Keywords: Cc:

Description

I get this on socat startup:

socat: xioinitialize.c: 41: xioinitialize: Assertion `3 << opt_crdly.arg3 == 0003000' failed.

Please see r5588 (#964) and r13934 (#4410) for reference.
Also it would be nice if this would be fixed without disabling termios. Currently I'm using stty before I use socat on the serial port.

Attachments (2)

504-xioinitialize.patch (1.6 KB) - added by heil 7 years ago.
504-xioinitialize.patch
socat_1.7.1.3.patch (745 bytes) - added by bartusch@… 7 years ago.
this will Update and FIX it

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by jsceballos@…

Same here.

comment:2 Changed 9 years ago by anonymous

Hi, I've found this patch:

http://svn.nslu2-linux.org/svnroot/slugos/trunk/slugos/openembedded/packages/socat/socat-1.3.2.1/xioinitialize.patch

It seems like socats asserts are not endian safe. A better patch would make them safe.

comment:3 Changed 8 years ago by Klaus Bueker <k_bueker@…>

HW-Platform: Asus WL-G 500 Deluxe;
OS: Backfire 10.03 - brcm-2.4;
Package: socat - 1.6.0.1-2;
Error Message:
socat: xioinitialize.c: 41: xioinitialize: Assertion `3 << opt_crdly.arg3 == 0003000' failed.

Is there any chance to get a backfire compatible .ipk of socat without termio?

Changed 7 years ago by heil

504-xioinitialize.patch

comment:4 Changed 7 years ago by heil

using socat results in

socat
socat: xioinitialize.c: 41: xioinitialize: Assertion `3 << opt_crdly.arg3 == 0003000' failed.
Aborted

socat should work again with 504-xioinitialize.patch

comment:5 Changed 7 years ago by heil

  • Milestone changed from Kamikaze to Backfire 10.03.1

comment:6 Changed 7 years ago by heil

  • Milestone changed from Backfire 10.03.1 to Backfire 10.03
  • Resolution set to worksforme
  • Status changed from new to closed

comment:7 Changed 7 years ago by jow

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:8 Changed 7 years ago by jow

  • Owner changed from developers to jow
  • Status changed from reopened to accepted

I will look into the patch.

comment:9 Changed 7 years ago by zoz2000

Any news about the patch?
Is it works or not?

comment:10 Changed 7 years ago by michael@…

Just tested the patch on an ar71xx platform and it fixed my problem.

comment:11 Changed 7 years ago by anonymous

This persists on brcm63xx. I flashed both rc4 and trunk. tried binary from trunck packege, trunck rc5 package, and backfire rc4 package. none of them works. got the same error as the OP reported.

comment:12 Changed 7 years ago by anonymous

Many people like me use socat to do quick dirty bi-directional port-forwarding. I wonder if termio has much to do with this. if not could the team just build a working version without full terminal support, just like the ncat and ncat-ssl ? Thank you in advance.

Changed 7 years ago by bartusch@…

this will Update and FIX it

comment:13 Changed 7 years ago by anonymous

socat was bugged for ages now. It does compile, so probably no one
noticed. While running through its configure script, the build process
complains about some missing variables and gives a hint, that the user
should supply them manually. This does ONLY happen in a cross compiling
environment, otherwise the configure script guesses them right. I don't
know the purpose of these variables exactly, but they seem to be OS
dependent and NOT hardware dependent. I tested this on various
architectures and they were all the same, as long as linux is involved.
So I think its safe to specify them in the Makefile.

The point why they're important, is simply that socat compiles, but
exits with some sort of error right after invocation, if they weren't
present at compile time. There are numerous tickets around concerning
this bug. Newer Versions of socat won't even compile if they're missing,
maybe thats why it's kinda outdated by now.

However, this little patch should fix it.

comment:14 Changed 7 years ago by swalker

  • Resolution set to fixed
  • Status changed from accepted to closed

Fixed in r26728.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.