Re: Frame Relay & tail -f hanging
On Sat, Aug 02, 2003 at 10:53:00AM +1000, Brian May wrote:
> > cat'ing /var/log/messages (or any file of significant size) will also freeze
> > things up. What about scp'ing or ftp'ing a file over the connection?
>
> Need to investigate scp. It seems to somehow depend on the actual data,
> but that doesn't make sense.
I just noticed, I think it only happens when the majority (if not all) of lines
output from tail are iptables firewall log messages, these lines are
rather long...
cat /var/log/messages will also crash it.
> 10:40:35.924737 192.168.100.129.1052 > 192.168.100.130.ssh: P 2120:2168(48) ack 3024 win 10304 <nop,nop,timestamp 23403791 397564587> (DF) [tos 0x10]
> 10:40:35.927567 192.168.100.130.ssh > 192.168.100.129.1052: P 3024:3104(80) ack 2168 win 9648 <nop,nop,timestamp 397565078 23403791> (DF) [tos 0x10]
> 10:40:35.928257 192.168.100.130.ssh > 192.168.100.129.1052: . 3104:4552(1448) ack 2168 win 9648 <nop,nop,timestamp 397565078 23403791> (DF) [tos 0x10]
> 10:40:36.024864 192.168.100.129.1052 > 192.168.100.130.ssh: . ack 3104 win 10304 <nop,nop,timestamp 23403802 397565078> (DF) [tos 0x10]
> 10:40:36.024959 192.168.100.130.ssh > 192.168.100.129.1052: P 4552:5008(456) ack 2168 win 9648 <nop,nop,timestamp 397565088 23403802> (DF) [tos 0x10]
> 10:40:36.242676 192.168.100.129.1052 > 192.168.100.130.ssh: . ack 3104 win 10304 <nop,nop,timestamp 23403823 397565078,nop,nop,sack sack 1 {4552:5008} > (DF) [tos 0x10]
> [crash about here]
> 10:40:36.361786 192.168.100.130.ssh > 192.168.100.129.1052: . 3104:4552(1448) ack 2168 win 9648 <nop,nop,timestamp 397565122 23403823> (DF) [tos 0x10]
> 10:40:37.041781 192.168.100.130.ssh > 192.168.100.129.1052: . 3104:4552(1448) ack 2168 win 9648 <nop,nop,timestamp 397565190 23403823> (DF) [tos 0x10]
> 10:40:38.401786 192.168.100.130.ssh > 192.168.100.129.1052: . 3104:4552(1448) ack 2168 win 9648 <nop,nop,timestamp 397565326 23403823> (DF) [tos 0x10]
> 10:40:41.121782 192.168.100.130.ssh > 192.168.100.129.1052: . 3104:4552(1448) ack 2168 win 9648 <nop,nop,timestamp 397565598 23403823> (DF) [tos 0x10]
> 10:40:46.561790 192.168.100.130.ssh > 192.168.100.129.1052: . 3104:4552(1448) ack 2168 win 9648 <nop,nop,timestamp 397566142 23403823> (DF) [tos 0x10]
Maybe something is filtering out large packet sizes, but isn't MTU
negotiating suppost to kick in when this happens???
I can't see any evidence of any negotiating being done here.
On the sending side:
auckland2:~# ip address
[...]
5: wp1_fr16: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ppp 00:10 peer 00:00
inet 192.168.100.130 peer 192.168.100.129/30 scope global
wp1_fr16
On the receiving side:
melbourne1:~# ip address
[...]
7: wp2mfr16: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/dlci 00:10 peer 00:01
inet 192.168.100.129 peer 192.168.100.130/30 scope global wp2mfr16
Is a 1448 data TCP packet + overhead under the MTU of 1500?
I would have thought so?
Does the fact tcpdump shows the packet mean it is definitely getting
sent, or could it be dropped after tcpdump shows it but before it is
sent?
Would there be any point in reducing the MTU and seeing what happens?
LATER: I tried a stupid MTU of 100, and while expectedly inefficient,
it seems to work OK. So I guess this leaves the question of why MTU
negotiating is not working???
--
Brian May <bam@snoopy.apana.org.au>
Reply to: