Am 5. Februar 2017 07:46:43 MEZ schrieb jungle boogie
<jungleboog...@gmail.com>:
> On 02/04/2017 07:17 PM, Philip Guenther wrote:
> >> Is this it?
> >>
> >> "Trying 129.128.5.191...
> > ...
> >> 80377 ftp CALL connect(3,0xaf766dd0bf0,16)
> >> 80377 ftp STRU struct sockaddr { AF_INET, 129.128.5.191:80 }
> >> 80377 ftp RET connect -1 errno 22 Invalid argument
> >
> > It dumped the sockaddr and didn't complain about it being invalid,
> > so it made it into soconnect(). That puts the problem somewhere in the
> > network stack or network config. To quote connect(2):
> >
> > [EINVAL] A TCP connection with a local broadcast, the
all-ones
> > or a multicast address as the peer was attempted.
> >
> > Double/triple check your network configuration, routing table, etc.
> > Good luck!
> >
>
> AH! I think it was a pf rule. I deleted some pf rules, rebooted and
> now
> it works!
> […]
I like adding a "log (to pflogX)" to my "block all"
rule for debugging. Running tcpdump on the
pflog device makes it easy to spot things you
don't want blocked.
At least when you somewhat know what you're
looking for. If not the tcpdump filter expression
can get rather big on a noisy network.
Regards, Florian
