I've been busy on these days trying to solve a problem with Postfix that
drove me nuts.
Sporadically (let's say one in hundred e-mails) my Postfix had problems
for delivering messages with ~3 MiB of attachment to some e-mail hosts.
DSN service returned the final notice of delivery to the user and logs
displayed an error like "timed out while sending message body".
These hosts were not of those "difficult" ones like Hotmail, Gmail,
Yahoo! or the like that because to their high volume of traffic implement
additional (and sometimes strambotic) measures to prevent spam and such
"anti-all" systems that may require a different transport definiton in
Postfix to get e-mails delivered.
Moreover, these hosts were not e-mail servers that are behind Cisco PIX
devices or using MS Exchange servers that are also well-known to be
conflictive to "dialogue" with.
Nope, I was having problems for delivering to common, small hosts of mid-
size companies, one of the hosts running a Debian system, like mine. So I
had to run some tests to find out what could be the problem here.
I first tried to define a less conservative values (by increasing the
time) for "smtp_data_done_timeout", "smtp_data_xfer_timeout" and
"smtp_data_init_timeout" but this had no effect at all and again, some e-
mails were still undelivered.
Googling around I found some posts and articles¹ pointing to the MTU
value (my bonded interface was set by default to 1500) and as I had
nothing to lose, I changed this and lowered to 1400.
This turned out to work wonders and since then (that's more than a week
ago) I still had no other DSN delivery errors. Besides, e-mails in
deferred queue that could not be sent in that time, after lowering the
MTU value were also delivered with no apparent problems.
I'm still monitoring this but if this is the "cure" to prevent such
errors, are there any expected drawbacks for lowering MTU "system-wide"?
The server has dual gigabit NIC which are bonded (in backup mode) and
server itself is behind a FTTH gigabit router. The server also hosts a
web server.
Any comments or experiences on this are welcome :-)
¹http://www.hsc.fr/ressources/cours/postfix/doc/faq.html#timeouts
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/pan.2011.08...@gmail.com
(...)
> I'm still monitoring this but if this is the "cure" to prevent such
> errors, are there any expected drawbacks for lowering MTU "system-wide"?
(...)
Mmm, no replies yet...
Does it mean then that there are no gotchas to care about in setting a
MTU value of 1400 for a bonded interface? :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Reply:
Sorry, I do not understand well most what you said even I read three times.
May I ask one thing here,
Last time I tried the icedove but don't know how to set the SMTP for
hotmail one.
Is the icedove a good choice (for me) to grab emails from hotmail and gmail?
Seems Postfix is "heavy" for me?
Thanks,
>
> Does it mean then that there are no gotchas to care about in setting a
> MTU value of 1400 for a bonded interface? :-)
>
> Greetings,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/pan.2011.09...@gmail.com
>
>
--
Best Regards,
lina
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAG9cJmmvf7CE0RxeYbkRpU4E...@mail.gmail.com
Icedove works fine with Gmail. From gmail settings, enable POP3 access and
then in Icedove, set the setttings as given here :
http://mail.google.com/support/bin/answer.py?answer=86400
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201109041724.16...@gmail.com
> On Sun, Sep 4, 2011 at 6:40 PM, Camaleón <noel...@gmail.com> wrote:
>> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>>
>> (...)
>>
>>> I'm still monitoring this but if this is the "cure" to prevent such
>>> errors, are there any expected drawbacks for lowering MTU
>>> "system-wide"?
>>
>> (...)
>>
>> Mmm, no replies yet...
>
> Reply:
>
> Sorry, I do not understand well most what you said even I read three
> times.
Ouch! The thread was just about MTU and I asked if it is fine to adjust
that value with bonded NICs...
> May I ask one thing here,
Well, not here, maybe in a new thread, don't you think? Hijacking other's
postings is not nice ;-)
(editing the subject...)
> Last time I tried the icedove but don't know how to set the SMTP for
> hotmail one.
http://email.about.com/od/accessinghotmail/f/Windows_Live_Hotmail_SMTP_Settings.htm
> Is the icedove a good choice (for me) to grab emails from hotmail and
> gmail?
Yes, why not? :-?
> Seems Postfix is "heavy" for me?
Postfix is an e-mail server (MTA) not an e-mail client (MUA) like
Icedove. It's another kind of beast :-)
>> I'm still monitoring this but if this is the "cure" to prevent such
>> errors, are there any expected drawbacks for lowering MTU "system-wide"?
>
> (...)
>
> Mmm, no replies yet...
>
> Does it mean then that there are no gotchas to care about in setting a
> MTU value of 1400 for a bonded interface? :-)
I don't see any gotchas besides the obvious one: the throughput is
decreased somewhat, since on average more packets are needed to transmit
the same amount of payload.
OTOH, in my experience, when you can work around transmission problems
by lowering the MTU, almost always someone has b0rked his packet filter
and throws away those ultra-evil ICMP packets like "Fragmentation
Needed" or "Time Exceeded in Transit" etc.
If you're sure you're not the one killing ICMP and the problems only
occur with specific sites, it might be helpful to have the
administrators of those sites check their "firewall" configuration.
--
Regards
mks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4E6369AA...@list-post.mks-mail.de
On Sun, Sep 04, 2011 at 10:40:29AM +0000, Camaleón wrote:
> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>
> (...)
>
> > I'm still monitoring this but if this is the "cure" to prevent such
> > errors, are there any expected drawbacks for lowering MTU "system-wide"?
>
> (...)
>
> Mmm, no replies yet...
>
> Does it mean then that there are no gotchas to care about in setting a
> MTU value of 1400 for a bonded interface? :-)
>
> Greetings,
Some router between you and outside have issue, I guess.
It is a bit complicated. My best effort information is here:
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_finding_optimal_mtu
Osamu
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thanks for the URL you provided, actually last time I met this webpage.
Mine windows live email address is a bit different, not ends up with
the traditional one like .hotmail or something like this. It's
associated with some other things.
I will check further and see (mostly the same as last time, not solved
and put aside).
the icedove is smart, the gmail is autoconfigured.
Thanks,
>
>> Is the icedove a good choice (for me) to grab emails from hotmail and
>> gmail?
>
> Yes, why not? :-?
>
>> Seems Postfix is "heavy" for me?
>
> Postfix is an e-mail server (MTA) not an e-mail client (MUA) like
> Icedove. It's another kind of beast :-)
>
> Greetings,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/pan.2011.09...@gmail.com
>
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAG9cJmm6VHgZpfu4k9Dyp8K5...@mail.gmail.com
> On Sun, Sep 4, 2011 at 8:05 PM, Camaleón <noel...@gmail.com> wrote:
(...)
>>> May I ask one thing here,
>>
>> Well, not here, maybe in a new thread, don't you think? Hijacking
>> other's postings is not nice ;-)
> "Hijacking" is a big word for me to afford, sorry to just take a lift
> there.
Don't get it wrong :-)
The term "hijacking" when used for mailing list threads is a common slang
to indicate that someone has replied to a post and changed the main topic:
http://www.urbandictionary.com/define.php?term=thread%20hijacking
>>> Last time I tried the icedove but don't know how to set the SMTP for
>>> hotmail one.
>>
>> http://email.about.com/od/accessinghotmail/f/Windows_Live_Hotmail_SMTP_Settings.htm
>
> Thanks for the URL you provided, actually last time I met this webpage.
>
> Mine windows live email address is a bit different, not ends up with the
> traditional one like .hotmail or something like this. It's associated
> with some other things.
>
> I will check further and see (mostly the same as last time, not solved
> and put aside).
Then you should read the FAQ of your former e-mail server provider for
setting up smtp service :-?
> the icedove is smart, the gmail is autoconfigured.
Yep, but remember you can always use a manual setup to configure your
accounts.
Thanks, I really know so little.
>
>>>> Last time I tried the icedove but don't know how to set the SMTP for
>>>> hotmail one.
>>>
>>> http://email.about.com/od/accessinghotmail/f/Windows_Live_Hotmail_SMTP_Settings.htm
>>
>> Thanks for the URL you provided, actually last time I met this webpage.
>>
>> Mine windows live email address is a bit different, not ends up with the
>> traditional one like .hotmail or something like this. It's associated
>> with some other things.
>>
>> I will check further and see (mostly the same as last time, not solved
>> and put aside).
>
> Then you should read the FAQ of your former e-mail server provider for
> setting up smtp service :-?
They only provided some typical one, last time I also adapt the
thunderbird one,
did not work.
>
>> the icedove is smart, the gmail is autoconfigured.
A bit unexpected, by browser, my gmail for debian mailing list I only
kept recent 1610 emails (around).
but the icedove was busy downloading, reached 6 thousands and more.
Frankly speaking, I removed the icedove again.
and back to check emails on iceweasle.
It's a better choice for me I guess.
Thanks again,
>
> Yep, but remember you can always use a manual setup to configure your
> accounts.
>
> Greetings,
>
> --
> Camaleón
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAG9cJmN3Oaaw_Sk0fwPFLZ_O...@mail.gmail.com
> HI,
>
> On Sun, Sep 04, 2011 at 10:40:29AM +0000, Camaleón wrote:
>> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>>
>> (...)
>>
>> > I'm still monitoring this but if this is the "cure" to prevent such
>> > errors, are there any expected drawbacks for lowering MTU
>> > "system-wide"?
>>
>> (...)
>>
>> Mmm, no replies yet...
>>
>> Does it mean then that there are no gotchas to care about in setting a
>> MTU value of 1400 for a bonded interface? :-)
>
> Some router between you and outside have issue, I guess.
>
> It is a bit complicated. My best effort information is here:
>
> http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_finding_optimal_mtu
Thanks... I should have imagined there must be something about this in
the manual :-)
I was indeed making that kind of tests to value what MTU size was the
best for that specific case and tried first with "1492" but messages were
still left in "deferred" queue. Once I changed to "1400" all of the
pending postings could finally be delivered.
I have now setup the bonded interface to stick to this MTU (1400) as
stated in section "5.8.2. Setting MTU".
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> 04.09.2011 12:40, Camaleón:
>
>>> I'm still monitoring this but if this is the "cure" to prevent such
>>> errors, are there any expected drawbacks for lowering MTU
>>> "system-wide"?
>>
>> (...)
>>
>> Mmm, no replies yet...
>>
>> Does it mean then that there are no gotchas to care about in setting a
>> MTU value of 1400 for a bonded interface? :-)
>
> I don't see any gotchas besides the obvious one: the throughput is
> decreased somewhat, since on average more packets are needed to transmit
> the same amount of payload.
>
> OTOH, in my experience, when you can work around transmission problems
> by lowering the MTU, almost always someone has b0rked his packet filter
> and throws away those ultra-evil ICMP packets like "Fragmentation
> Needed" or "Time Exceeded in Transit" etc. If you're sure you're not the
> one killing ICMP and the problems only occur with specific sites, it
> might be helpful to have the administrators of those sites check their
> "firewall" configuration.
I agree. The best way to sort out these problems is by carrying out
additional tests with the host we were experiencing problems but I've had
not very good experiences when contacting Spanish admins, most of them
just don't reply at all or are not interested in solving this
problematic ;-(
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> On Wed, Aug 31, 2011 at 1:09 PM, Camaleón <noel...@gmail.com> wrote:
>
>> I've been busy on these days trying to solve a problem with Postfix
>> that drove me nuts.
>>
>> Sporadically (let's say one in hundred e-mails) my Postfix had problems
>> for delivering messages with ~3 MiB of attachment to some e-mail hosts.
>> DSN service returned the final notice of delivery to the user and logs
>> displayed an error like "timed out while sending message body".
(...)
>> Googling around I found some posts and articles¹ pointing to the MTU
>> value (my bonded interface was set by default to 1500) and as I had
>> nothing to lose, I changed this and lowered to 1400.
(...)
> You might want to try the postfix mailing list and see if they have any
> ideas.
> Be prepared for cold, hard, terse answers. They don't chat much - busy
> I guess.
:-)
Should I couldn't solve the problem, sure, I would had to post in there.
The fact is I like Postfix so much, I find it very flexible and easy to
deal with but in specific case, I didn't think the app was the culprit
but as Osamu has pointed out, a router or a filter (firewall) in between
our hosts making noise.
> Was the previous MTU of 1500, a value you had set, or the default when
> queried?
1500 was the default MTU value for the bonded interfaces. I thinks is the
system default for ethernet devices nowadays.
> I'm wondering because of a recent experience I had tweaking MTU. I
> wanted to try jumbo frames to improve samba throughput on large video
> files. With MTU set to 9000 on Linux and Windows, throughput increased
> about 8 times. But it caused problems with the web service on Linux,
> which was running a domain under dyndns. I set the MTU on Linux back to
> unspecified, but left the jumbo frame active on Windows side. The
> performance was still very good in large samba file transfers. I might
> remember this wrong, but it seemed it was worse performance when Linux
> side specified 1500, so I left it as unspecified and it has worked well.
> I still get high transfer speeds in samba with unspecified MTU on Linux
> but jumbo of 9000 MTU on Windows side.
That was exactly the kind of problems I would like to avoid :-) But as
you said, lower values for MTU are not prone to errors or conflicts but
higher ones (like jumbo frames). I hope performance is not badly
penalized for having a low value, though...
> BTW, 1492 is a common MTU seen in FAQs. You might get just as good with
> that.
MTU is now set at 1400. The host I was trying to contact seemed to be
fine with that setting so I kept it so.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>>> the icedove is smart, the gmail is autoconfigured.
>
> A bit unexpected, by browser, my gmail for debian mailing list I only
> kept recent 1610 emails (around).
> but the icedove was busy downloading, reached 6 thousands and more.
>
> Frankly speaking, I removed the icedove again.
>
> and back to check emails on iceweasle.
>
> It's a better choice for me I guess.
Before setting up your Gmail account to use it with your e-mail client
you should first "clean up" your inbox/folders because you can have
stored there thousand of messages that can take very long to download.
Were you using POP3 or IMAP to get your Gmail's e-mails in Icedove?
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
inbox/folders ?
I have inbox and different folders ( folders are not in the inbox directory).
clean up?
> stored there thousand of messages that can take very long to download.
>
> Were you using POP3 or IMAP to get your Gmail's e-mails in Icedove?
IMAP.
P.S Before I tried the icedove,
mainly just wanna download thousands of emails from windows live
account to backup (It's kind of "official" email box I used for
years).
Right now I wonder I maybe do backup in different machine, such as use
outlook. will try another time.
Thanks again,
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAG9cJmkJ92mX6yj3zP4bCf3p...@mail.gmail.com
> On Sun, Sep 4, 2011 at 9:57 PM, Camaleón <noel...@gmail.com> wrote:
>> Before setting up your Gmail account to use it with your e-mail client
>> you should first "clean up" your inbox/folders because you can have
>
> inbox/folders ?
Yes. If you have all of your messages stored/archived in your inbox
Icedove will suffer to download/get all that amount of data.
It's better to have sub-folders so you can classify your e-mails and put
in there a small set of messages.
> I have inbox and different folders ( folders are not in the inbox
> directory).
Hum... are that Gmail default folders (sent/all/trash...) or have you
manually created them?
> clean up?
Yep :-)
Gmail has the strange ability to fill up very quickly and we tend to
forget to completely remove e-mails that we don't want anymore. It's the
price we have to pay in this "cloud-based" world: we forget about basic
maintenance and let the provider to do the "dirty" job.
>> stored there thousand of messages that can take very long to download.
>>
>> Were you using POP3 or IMAP to get your Gmail's e-mails in Icedove?
>
> IMAP.
Then arrange your inbox and let Ivecove to gather the data. The first
time will take some time but once it indexes and caches the folder it
will be quicker.
> P.S Before I tried the icedove,
> mainly just wanna download thousands of emails from windows live account
> to backup (It's kind of "official" email box I used for years).
> Right now I wonder I maybe do backup in different machine, such as use
> outlook. will try another time.
I guess Outlook will suffer for the same as Icedove (it will be slow).
But if you want to make a backup for a small set of messages, I think
there are specialized tools to achieve that task (e.g., gmail backup).
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
In Gamil interface ( on browser) it has filters function.
Actually even I only touch the debian less than two years, but last 15
years I spent long time with Windows.
Shame, I still know so little after so many years passed.
>
>> clean up?
>
> Yep :-)
I cleaned nearly all.
>
> Gmail has the strange ability to fill up very quickly and we tend to
> forget to completely remove e-mails that we don't want anymore. It's the
> price we have to pay in this "cloud-based" world: we forget about basic
> maintenance and let the provider to do the "dirty" job.
>
>>> stored there thousand of messages that can take very long to download.
>>>
>>> Were you using POP3 or IMAP to get your Gmail's e-mails in Icedove?
>>
>> IMAP.
>
> Then arrange your inbox and let Ivecove to gather the data. The first
> time will take some time but once it indexes and caches the folder it
> will be quicker.
>
>> P.S Before I tried the icedove,
>> mainly just wanna download thousands of emails from windows live account
>> to backup (It's kind of "official" email box I used for years).
>> Right now I wonder I maybe do backup in different machine, such as use
>> outlook. will try another time.
>
> I guess Outlook will suffer for the same as Icedove (it will be slow).
>
> But if you want to make a backup for a small set of messages, I think
> there are specialized tools to achieve that task (e.g., gmail backup).
Thanks again,
>
> Greetings,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/pan.2011.09...@gmail.com
>
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAG9cJmkn0shSOi_Ay-wetbPZ...@mail.gmail.com
Slightly lower overall performance when communicating with remote hosts.
Almost zero difference on the LAN.
If you want optimal performance, you should enable jumbo frames on all
LAN hosts (9000 bytes) since you're using GbE, and install an edge
router that handles jumbo frames. Then you need not worry about any of
this. Just make sure you find out from your service provider what size
frames they use. Then program the WAN interface on the router with that
frame size (MTU).
Problems such as yours are always caused by MTU mismatches. In most
cases the mismatch is between the customer's edge device and the service
provider equipment. Good routers will handle this just fine as long as
the WAN port MTU is programmed to match the service provider equipment.
Worth noting is that different network technologies use different frame
sizes. For instance, ethernet uses a 1514 octet frame. Fiber channel
uses 2112. FDDI uses 4500. SONET is 2430.
You mentioned a "FTTH gigabit router" previously. Is this SP equipment
or your independent equipment? The MTU mismatch most likely exists
inside that box. If it was provided to you, then someone probably
didn't program it correctly. It should have worked fine with different
MTUs on both sides.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4E65A875...@hardwarefreak.com
> I agree. The best way to sort out these problems is by carrying out
> additional tests with the host we were experiencing problems but I've had
> not very good experiences when contacting Spanish admins, most of them
> just don't reply at all or are not interested in solving this
> problematic ;-(
It's not just Spanish admins. This happens every day with
spam/abuse/other reports to all manner of US entities, whose staff are
often of WASP (White Anglo-Saxon Protestant) heritage.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4E65AB1D...@hardwarefreak.com
> On 9/4/2011 5:40 AM, Camaleón wrote:
>> On Wed, 31 Aug 2011 16:09:23 +0000, Camaleón wrote:
>>
>> (...)
>>
>>> I'm still monitoring this but if this is the "cure" to prevent such
>>> errors, are there any expected drawbacks for lowering MTU
>>> "system-wide"?
>
> Slightly lower overall performance when communicating with remote hosts.
> Almost zero difference on the LAN.
The host is barely accesible from the LAN (just for admin tasks), it's
mostly a 100% standalone and remote server which plays the role of a web
server (very low traffic, it hosts a couple of dedicated sites) and e-
mail services.
> If you want optimal performance, you should enable jumbo frames on all
> LAN hosts (9000 bytes) since you're using GbE, and install an edge
> router that handles jumbo frames. Then you need not worry about any of
> this. Just make sure you find out from your service provider what size
> frames they use. Then program the WAN interface on the router with that
> frame size (MTU).
I prefer to be able to deliver all of the e-mails, performance can go to
background.
Anyway, I dunno if that would be possible. The switch where the server is
attached to does not allow jumbo frames so I would have to completely
diconnect the server from the local LAN and leave it as a purely remote
server and then yes, I can enable jumbo frames for the gigabit card. But
now that I know where the problem is and how can mitigate it, I doubt if
that would be worth of it.
> Problems such as yours are always caused by MTU mismatches. In most
> cases the mismatch is between the customer's edge device and the service
> provider equipment. Good routers will handle this just fine as long as
> the WAN port MTU is programmed to match the service provider equipment.
Yep, for what I've read, a badly configured appliance (firewall/IPS) can
also give such results.
> Worth noting is that different network technologies use different frame
> sizes. For instance, ethernet uses a 1514 octet frame. Fiber channel
> uses 2112. FDDI uses 4500. SONET is 2430.
>
> You mentioned a "FTTH gigabit router" previously. Is this SP equipment
> or your independent equipment?
As of today, it's ISP's device. FTTH was installed this summer (June-
July) in the office and I'm still reluctant to make any change.
> The MTU mismatch most likely exists inside that box. If it was
> provided to you, then someone probably didn't program it correctly. It
> should have worked fine with different MTUs on both sides.
Yep, I also thought so but I couldn't find the manual of the provided
device, just a very brief flyer with specs. It's a Comtrend WAP-5813n and
dunno where the MTU setting is on this router nor how/if I have to tweak
it.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> On 9/4/2011 8:39 AM, Camaleón wrote:
>
>> I agree. The best way to sort out these problems is by carrying out
>> additional tests with the host we were experiencing problems but I've
>> had not very good experiences when contacting Spanish admins, most of
>> them just don't reply at all or are not interested in solving this
>> problematic ;-(
>
> It's not just Spanish admins. This happens every day with
> spam/abuse/other reports to all manner of US entities, whose staff are
Mmm... I had had to contact in many ocassions to admins (mainly located
in USA and UK) and they tend to be -at least- efficent. Maybe they do not
respond in a timely manner but they finally solve the problem quietly.
I'm not talking about big ISP like Hotmail, AOL or Gmail (these ones are
difficult to reach or speak to) but small companies.
Doing something similar here is like a real "siege" (yes, like a battle)
and a waste of time.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org