Two odd problems with STABLE-10 r262921

[Karl Denninger]

PS: I am not using "pf"; I AM using ipfw.


On Tue, Mar 11, 2014 at 2:20 PM, Karl Denninger <
tickerguydenninger at gmail.com> wrote:

> Uh, yuck.
>
> [karl at NewFS ~/tmp]$ scp small outsidebox:xxx
> small                                         100%  741     0.7KB/s
> 00:00
> [karl at NewFS ~/tmp]$ scp xxx outsidebox:xxx
> xxx                                             0%    0     0.0KB/s
> --:-- ETAWrite failed: Permission denied
> lost connection
> [karl at NewFS ~/tmp]$
>
> "xxx" is a file containing several megabytes of data.  "outsidebox" is a
> machine for which I have a cert and can scp back and forth.  Coming FROM
> there with a large file is fine.
>
> Something is very broken in the network code and I have nothing showing up
> in the logs or on the console.
>
> It's not sendmail -- it's the system itself.
>
> This is an embedded Intel gigabit chipset (em1) on a Supermicro
> motherboard and was working fine under 9.2.
>
> Ideas?  This one will force me to find a way to roll back if I can't find
> and fix it immediately.
>
>
>
> On Tue, Mar 11, 2014 at 2:13 PM, Mike Tancsa <mike at sentex.net> wrote:
>
>> On 3/11/2014 1:24 PM, Karl Denninger wrote:
>>
>>> Yeah it hasn't changed...... I turned on verbose logging and I'm not
>>> getting anything in the logs on it -- what's even more-odd is that I can
>>> telnet to port 25 on the MX gateway and hand-feed an email in there, and
>>> it
>>> works.  If I turn off the signatures, it ALSO works.
>>> Mar 11 12:13:59 NewFS sm-mta[11023]: s2BGax4D095381: SYSERR(root):
>>> putbody:
>>> write error: Permission denied
>>> Mar 11 12:13:59 NewFS sm-mta[11023]: s2BGax4D095381: SYSERR(root):
>>> timeout
>>> writing message to gmail-smtp-in.l.google.com.: Permission denied
>>>
>>
>> My initial guess is also firewall issue (permission denied).. A tcpdump
>> of the packets after the sending host could help verify that.
>>
>> Perhaps a long shot, but the bug fixed in this commit
>>
>> http://svnweb.freebsd.org/base?view=revision&revision=263029
>>
>> might also point to such behaviour, if states were being prematurely
>> being expired ? I am thinking it would be a pretty busy box.
>>
>> Also, for debugging sendmail issues, I usually crank up on the command
>> line
>>
>> given the Queue ID of
>>
>> Is2BFqO9e075993
>>
>> sendmail -q -qIs2AKaMQp067733 -OLogLevel=15 -v
>>
>>
>>
>>
>>         ---Mike
>>
>>
>> --
>> -------------------
>> Mike Tancsa, tel +1 519 651 3400
>> Sentex Communications, mike at sentex.net
>> Providing Internet services since 1994 www.sentex.net
>> Cambridge, Ontario Canada   http://www.tancsa.com/
>>
>
>