> You can lower MSS instead of lowering MTU - it's much safer option.
How do you lower MSS and not lower MTU?
Thanks,
Petr
>
> Yes. Are they on? If so then turn them off and see if that fixes the
> problem.
I turned them off but it made no difference. On the other hand I decided to
lower the MTU even more, to 800 and guess what.. some of the lost mail
started getting through. Unfortunately with a setting
:On Sun, 16 Nov 2008 08:13:34 Matthew Dillon wrote:
:> If hardware checksumming is turned on on the interface, try turning it
:> off. Broken checksum offloading can cause packets to be dropped by
:> routers as well as end-points.
:>
:
:Is hardware checksuming the options in ifconfig:
On Sun, 16 Nov 2008 08:13:34 Matthew Dillon wrote:
> If hardware checksumming is turned on on the interface, try turning it
> off. Broken checksum offloading can cause packets to be dropped by
> routers as well as end-points.
>
Is hardware checksuming the options in ifconfig: hwcsum a
If hardware checksumming is turned on on the interface, try turning it
off. Broken checksum offloading can cause packets to be dropped by
routers as well as end-points.
-Matt
Matthew Dillon
On Sat, 15 Nov 2008 22:39:26 Sepherosa Ziehau wrote:
> Several segments (203.16.214.214 -> 202.76.131.108) are never seen by
> the driver.
>
> 17:48:34.952792 IP 202.76.131.108.25 > 203.16.214.214.41558: . ack 145 win
> 58400
>
> Application seems to use 5min timeout. The question is why
> 203.16.
On Sat, Nov 15, 2008 at 6:17 PM, Petr Janda
<[EMAIL PROTECTED]> wrote:
>> window scaling shift 0 is allowed. It just mean we support window
>> scaling, but the shift is 0.
>> From the dump, it looks like the other side is a Linux box.
>>
>> > Could Sephe give a suggestion about what is the problem
> window scaling shift 0 is allowed. It just mean we support window
> scaling, but the shift is 0.
> From the dump, it looks like the other side is a Linux box.
>
> > Could Sephe give a suggestion about what is the problem here and how I
> > can solve it?
>
> As Joerg has suggested, window scaling
On Sat, Nov 15, 2008 at 4:21 PM, Petr Janda
<[EMAIL PROTECTED]> wrote:
> How is it possible that the sender uses wscale 2^7 and the receiver 2^0? Is
> this a problem?
window scaling shift 0 is allowed. It just mean we support window
scaling, but the shift is 0.
>From the dump, it looks like the o
On Sat, Nov 15, 2008 at 07:21:19PM +1100, Petr Janda wrote:
> How is it possible that the sender uses wscale 2^7 and the receiver 2^0? Is
> this a problem?
One side says it can do window scaling and the other can't. That is not
necessarily a problem, it can happen depending on the maximum TCP win
How is it possible that the sender uses wscale 2^7 and the receiver 2^0? Is
this a problem?
Could Sephe give a suggestion about what is the problem here and how I can
solve it?
Thanks,
Petr
> Stupid network admistrators that consider all ICMP traffic evil and
> block it. But IMO it should be active by default.
>
> Joerg
I really hate the fact there is so many stupid admins who would block ICMP
because they think its evil, while they dont see the overwhelming goodness in
a protocol
> It might help.
>
> Joerg
Ive had it on for like 6 hours now but i dont think it made a difference.
Thanks anyway.
Im welcome to more suggestions.
Petr
On Fri, Nov 14, 2008 at 11:05:00PM +0200, Jordan Gordeev wrote:
> Is there a technical reason (e.g. related to where the Path MTU is
> stored), for having it off till now?
Stupid network admistrators that consider all ICMP traffic evil and
block it. But IMO it should be active by default.
Joerg
Joerg Sonnenberger wrote:
On Sat, Nov 15, 2008 at 04:31:55AM +1100, Petr Janda wrote:
Is net.inet.tcp.path_mtu_discovery=1?
Joerg
No, it was set to 0. is it supposed to be set to 1? If so, should the default
be 1? As far as documentation goes Ive read most of modern UNIX systems have
On Sat, Nov 15, 2008 at 04:31:55AM +1100, Petr Janda wrote:
> > Is net.inet.tcp.path_mtu_discovery=1?
> >
> > Joerg
>
> No, it was set to 0. is it supposed to be set to 1? If so, should the default
> be 1? As far as documentation goes Ive read most of modern UNIX systems have
> it turned on by d
> Is net.inet.tcp.path_mtu_discovery=1?
>
> Joerg
No, it was set to 0. is it supposed to be set to 1? If so, should the default
be 1? As far as documentation goes Ive read most of modern UNIX systems have
it turned on by default.
Cheers,
Petr
On Fri, Nov 14, 2008 at 08:15:04PM +1100, Petr Janda wrote:
> Supposedly the problem here is that the sending machine has got a firewall
> in front of it thats blocking ICMP MUST FRAGMENT.
Is net.inet.tcp.path_mtu_discovery=1?
Joerg
Hi all,
I have got reports about lost mail(not received, im the receiver not the
sender) recently and trying to find out whats going on seems to be beyond me.
Basically a lot of email is lost with "timeout after DATA"
For example:
timeout after DATA (0 bytes) from mail.securepay.com.au[203.89.21
19 matches
Mail list logo
