The timestamps in the two logs don't match up.

  Feb  3 02:42:41 HAL pppd[757]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc08f13fc> <pcomp> <accomp>]

It sends many LCP ConfReq packets, and gets no input.  So, it could be
that the ISP is set up to behave differently (some sort of
username/password login before doing PPP), but you say things work
with FreeBSD.  So, you may be having serial port or modem troubles.

Your ConfReq packets look pretty normal.  Guessing wildly, I wonder if
the ISP has some rules about asyncmap and compression and ignores
packets that it doesn't like (rather than sending a ConfRej like it
should).  Compare to a known working dialup logs.

I would do the following:

  watch the modem lights while it is sending ConfReq.  If the receive
  lights don't blink after each blink of the transmit lights, that
  looks like a problem at the ISP (or a disagreeement about what
  protocol to speak).  If they do, the problem may be in your modem or
  cabling.

  watch the CD light and see if the remote side hangs up before the
  local side gives up on ConfReq.

  set the modem to not require RTS from the computer (it could be
  receiving data and not sending it).

  Boot freebsd if you still can, and turn on all the debugging and
  bring ppp up and down.

  Get a serial line analyzer with LEDs for all the lines.

  'pstat -t', which might show something useful.

(I use ppp all the time, but between two NetBSD systems, and run pppd
from login, rather than raw.  I have normal US Robotics modems, and
full serial cables with modem control pins.)

I do have in /etc/ttys on the host that dials:

tty00   "/usr/libexec/getty std.9600"   unknown off secure rtscts

and on the one that answers:

tty00   "/usr/libexec/getty std.9600"   unknown off secure rtscts


-- 
        Greg Troxel <gdt@ir.bbn.com>