Re: tftpd server S not responding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, Apr 12, 2018 at 2:25 AM, peter.winterflood <
peter.winterflood@xxxxxxxxxx> wrote:

>
> have you checked that tftp is added to hosts.allow.
> syslog may be reporting libwrap errors, libwrap is trcpwrappers
> regards peter
>
>
>
yes hosts.allow is wide open and I did test with tcpdmatch and it says
granted



>
> On 11 April 2018 16:57:04 "Asif Iqbal" <vadud3@xxxxxxxxx> wrote:
>
> On Thu, Mar 29, 2018 at 12:48 PM, Asif Iqbal <vadud3@xxxxxxxxx> wrote:
>>
>> >
>> >
>> > On Thu, Mar 29, 2018 at 7:21 AM, Steven Tardy <sjt5atra@xxxxxxxxx>
>> wrote:
>> >
>>
>>> > A STATEFUL firewall with “ip any any” can and will still block
>>> asymmetric
>>> > communications due to the firewall keeping track of state (hence tha
>>> name
>>> > stateful firewall).
>>> >
>>> > Tcpdump on your servers /other/ NICs and you’ll see the tftp traffic
>>> > leaving your server on some other NIC (probably on with the default
>>> > route).
>>> >
>>>
>> >
>> > A (192.168.1.10)
>> > S (192.168.1.20)
>> >
>> > I do not see tftp traffic is leaving from S
>> >
>> > A:~$ tftp
>> > (to) 192.168.1.20
>> > tftp> get file
>> > Transfer timed out.
>> >
>> > As you can see no pkt is leaving. If it were leaving S, but A were not
>> > receiving then I would think firewall
>> > is dropping it.
>> >
>> > [ S ~]$ sudo tcpdump -A -nniany host 192.168.1.10
>> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> > listening on any, link-type LINUX_SLL (Linux cooked), capture size
>> 262144
>> > bytes
>> >
>> > 16:40:08.390939 IP 192.168.1.10.35553 > 192.168.1.20.69:  16 RRQ "file"
>> > netascii
>> > E..,J1@.>..n./...oAt...E..#...file.netascii...................
>> > 16:40:13.391133 IP 192.168.1.10.35553 > 192.168.1.20.69:  16 RRQ "file"
>> > netascii
>> > E..,N.@.>..../...oAt...E..#...file.netascii...................
>> > 16:40:18.391220 IP 192.168.1.10.35553 > 192.168.1.20.69:  16 RRQ "file"
>> > netascii
>> > E..,QK@.>..T./...oAt...E..#...file.netascii...................
>> > 16:40:23.391373 IP 192.168.1.10.35553 > 192.168.1.20.69:  16 RRQ "file"
>> > netascii
>> > E..,T^@.>..@./...oAt...E..#...file.netascii...................
>> > 16:40:28.391469 IP 192.168.1.10.35553 > 192.168.1.20.69:  16 RRQ "file"
>> > netascii
>> > E..,X.@.>..../...oAt...E..#...file.netascii...................
>> >
>> >
>> >
>> I still like some help on this
>>
>>
>> >
>> >
>>
>>> >
>>> > The upstream firewall will then block the tftp response if it never saw
>>> > the
>>> > tftp request (due to asymmetry).
>>> > _______________________________________________
>>> > CentOS mailing list
>>> > CentOS@xxxxxxxxxx
>>> > https://lists.centos.org/mailman/listinfo/centos
>>> >
>>>
>> >
>> >
>> >
>> >
>> --
>> Asif Iqbal
>> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> Sent with AquaMail for Android
> https://www.mobisystems.com/aqua-mail
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>



-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux