erik@mpx1.UUCP (Erik Murrey) (12/21/87)
If you have ever kicked your machine because uucico times out before
the dialer connects, here is a fix. It works on SCO Xenix V2.1.3, and
should work on others if you can find the alarm() call. You will
need some sort of binary patcher to do the work.
PROBLEM:
The uucico binary sets an alarm() when it forks the dialer
binary. This alarm is soooo short that it usualy times out
when you have a dialer that can redial a busy number. It
is also a problem for pc-pursuit dialers which have a lot
of steps to go through.
My binary is 53993 bytes long. If your's isn't then you will have
to find the alarm() call yourself.
If you have adb, and your binary is 53993 bytes long, then here is
the fix:
adb -w /usr/lib/uucp/uucico (Be sure to copy it first - just in case)
* $x
* 3f:287a
* .,4?ia
0x3f:0x287a: push ax
0x3f:0x287b: call near 0x3f:0x741e
0x3f:0x287e: add sp,02H
0x3f:0x2881: call near 0x3f:0x7af8
*
(At this point, if the above doesn't mach what you got, then
don't continue - you have a different binary)
* 287a?w 9090
* 287b?w 9090
* .+2?w 9090
* .+2?w 9090
* 287a,8?ia
0x3f:0x287a nop
0x3f:0x287b nop
0x3f:0x287c nop
0x3f:0x287d nop
0x3f:0x287e nop
0x3f:0x287f nop
0x3f:0x2880 nop
0x3f:0x2881 call near 0x3f:0x7af8
( This should be your output if it worked )
* $q
You are done!
If you don't have adb, then you could try to use a binary patcher.
I think that you can patch this by changing bytes 291A-2920 (inclusive)
with 0x90's. (Don't take my word for it, this hasn't been tested)
IF YOUR BINARY IS DIFFERENT:
(You should have adb to do this)
Try scanning the code (using adb) for all of the syscall's.
They should be towards the end of the binary. All of
them eventualy do a "call near 0x3f:0x2" (Try
piping adb through grep "0x3f:0x2$") Then examine
all of the code about 15 bytes before the calls. The
alarm() call looks like this:
push bp
mov bp,sp
mov bx,[bp+04H]
mov ax,01bH <-- this is the clue
call near 0x3f:0x2
...
Now try stting a breakpoint on the call (set it after the
mov bx,... call) , and run uucico. At each breakpoint,
do a register dump ($r) and look at "bx". My uucico multiplies
the length of the phone number by 10. i.e. a seven digit
phone number would show up as a alarm of 70 seconds (0x55).
When you see a number like this in bx, do a $c backtrace.
See where it called alarm(). Go back to this spot and put
nop's (0x90) in place if the push ax, call alarm, and
add sp,2 instructions. You are finished.
Hope this helps people with fnacy dialers that redial (like mine...)
It's also great for PC-Pursuit dialers which take a lot of time...
--
Erik Murrey /| // /~~~~/ | /
MPX Data Systems, Inc. / | / / /____/ |/
/ / / / /| Data Systems, Inc.
{ihnp4,bpa,vu-vlsi,cbmvax}!mpx1!erik / / / / |====================davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (12/23/87)
I have SCO/286 v2.1.3 and SCO/386 v2.2.1, and both of them seem to have
the timeouts in the 'dial' program. I have some numbers which take
almost two minutes to connect, going through PBXs, port connectors, and
2nd computers.
I think I'm misunderstanding what this patch does.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me