Very Computer

> I've got one of the Alcatel Speed Touch Home units and have tried a
> number of Linux based firewalls. I started with a RH6.2/ipchains
> machine, when I found that up2date was* I tried upgrading to
> RH7.3/iptables, when this exhibited the same problem I tried
> implementing IPCop.  All have the same problem.  I decided to just cut
> over and update my machines manually, once I cut over I found that
> outbound sendmail is giving me trouble as well (yes I configured
> sendmail correctly and once in a while a few messages do manage to get
> through but the bulk are like the examples at the end of this post).
> To ensure that the problem is not with my Linux configs I put a spare
> disk in the OBSD firewall on the AT&T side and installed IPCop with
> the same patches and setting as on the BellSouth side, it works
> flawlessly, sendmail and up2date get through as does everything else.
> The only differences between the two connections are as follows:

> Good:
> p133 32megs with IPCop 0.1.1p6<->ne2k clone<->Toshiba Cable
> modem<->attbi.com

> Bad:
> p233 80megs with IPCop 0.1.1p6<->ne2k clone<->Alcatel Speed Touch
> Home<->bellsouth.net

> It seems to me that there must be something up with the Alcatel or the
> wiring on the BellSouth side, although I am open to any reasonable
> suggestion and would rather try unreasonable stuff here than try to
> get do battle with BellSouth about these two apps.

> In both the up2date and sendmail cases the connection is established
> then stops.  I have some more detailed output below, please read on if
> you can help.  I have also found that up2date run as an application on
> the RedHat firewall machines themselves has the same problem.  I can
> however alter the default route of the RedHat firewall attached to the
> BellSouth pipe to point to the ip of the firewall on the AT&T pipe and
> get a good update. I have tried dropping all of the firewalling rules
> (actually rebooting and bringing up PPPoE (current release of Roaring
> Penguin) with no firewalling enabled at all) and trying the up2date
> that way, same symptom.  I suspect that getting up2date working may
> well take care of my sendmail problems as well since the symptoms are
> so similar (connection establishes then hangs).  I am thinking of
> putting a hub in line between the firewall and the ADSL modem to do
> some sniffing but am not sure if this will do any good or what to look
> for.  Any thoughts would be appreciated.

> With up2date the program starts but never gives any standard output,
> eventually it fails with this message:

> # up2date -vui --nox
> Error communicating with server.  The message was:
> Connection aborted by the user
> Error communicating with server.  The message was:
> EOF
> #

> While it's running I can see the connection in the output of netstat:

> # netstat -a|grep redhat tcp        0   2589 gryphon:43989          
> # xmlrpc.rhn.redhat:https ESTABLISHED
> #

> And the firewall shows the connection properly masqueraded:

> TCP  149:33.40 192.168.1.1          216.148.218.165      43989 (61061) ->
> 443

> In the case of sendmail jobs go into the queue fine but get deferred:

> # sendmail -bp
>                 /var/spool/mqueue (3 requests)
> ----Q-ID---- --Size-- -----Q-Time-----
> ------------Sender/Recipient------------

>                  (Deferred: Connection reset by mx06.mail.bellsouth.net.)


>                  (reply: read error from mx06.mail.bellsouth.net.)


>                  (reply: read error from mx07.mail.bellsouth.net.)

> #

> If I try to run the queue manually here's what I get (FWIW each of the
> hangs depicted below lasts for about 10-15 minutes before losing the
> connection):

> # sendmail -v -q

> Running /var/spool/mqueue/g6LDinu01736 (sequence 1 of 3)
> g6LDinu01736: locked

> Running /var/spool/mqueue/g6LDoY001808 (sequence 2 of 3)

> 421 imf17bis.bellsouth.net connection refused from [67.33.179.119]
>>>> QUIT


> 220 mail.bellsouth.net ESMTP server (InterMail vM.5.01.04.19
> 201-253-122-122-119-20020516) ready Sun, 21 Jul 2002 17:20:40 -0400
>>>> EHLO gryphon.myth.bellsouth.net
> 250-imf01bis.bellsouth.net
> 250-HELP
> 250-PIPELINING
> 250-DSN
> 250-8BITMIME
> 250 SIZE 10485760




>>>> DATA
> 354 Ok Send data ending with <CRLF>.<CRLF>
>>>> .

> [15 minute hang]

> 421 imf01bis.bellsouth.net Lost connection to [67.33.179.119]
>>>> QUIT

> 220 mail.bellsouth.net ESMTP server (InterMail vM.5.01.04.19
> 201-253-122-122-119-20020516) ready Sun, 21 Jul 2002 17:25:41 -0400
>>>> EHLO gryphon.myth.bellsouth.net
> 250-imf09bis.bellsouth.net
> 250-HELP
> 250-PIPELINING
> 250-DSN
> 250-8BITMIME
> 250 SIZE 10485760




>>>> DATA
> 354 Ok Send data ending with <CRLF>.<CRLF>
>>>> .

> [15 minute hang]

> 421 imf09bis.bellsouth.net Lost connection to [67.33.179.119]
>>>> QUIT


>>>> QUIT
> 220 mail.bellsouth.net ESMTP server (InterMail vM.5.01.04.19
> 201-253-122-122-119-20020516) ready Sun, 21 Jul 2002 17:30:41 -0400
>>>> EHLO gryphon.myth.bellsouth.net
> 250-imf05bis.bellsouth.net
> 250-HELP
> 250-PIPELINING
> 250-DSN
> 250-8BITMIME
> 250 SIZE 10485760




>>>> DATA
> 354 Ok Send data ending with <CRLF>.<CRLF>
>>>> .
> 421 imf05bis.bellsouth.net Lost connection to [67.33.179.119]
>>>> QUIT