[gentoo-user] PMTUD

[gentoo-user] PMTUD

[Grant]

How is PMTUD enabled/disabled on Gentoo?  I've recently been made
aware of the existence of MTU and I'm wondering if mine is set
properly for a cell phone tethered connection.

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 486 bytes --]

On Tuesday 27 Aug 2013 09:10:39 Grant wrote:
> How is PMTUD enabled/disabled on Gentoo?  I've recently been made
> aware of the existence of MTU and I'm wondering if mine is set
> properly for a cell phone tethered connection.
> 
> - Grant

# sysctl -A | grep -i pmtu
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.route.min_pmtu = 552

Use echo to change a value as required and then modify your /etc/sysctl.d/ 
accordingly (first read /etc/sysctl.d/README)

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> How is PMTUD enabled/disabled on Gentoo?  I've recently been made
>> aware of the existence of MTU and I'm wondering if mine is set
>> properly for a cell phone tethered connection.

Thanks Mick.  Can you generally rely on PMTUD to set the MTU optimally
or should this be experimented with when changing connections?

- Grant


> # sysctl -A | grep -i pmtu
> net.ipv4.ip_no_pmtu_disc = 0
> net.ipv4.route.min_pmtu = 552
>
> Use echo to change a value as required and then modify your /etc/sysctl.d/
> accordingly (first read /etc/sysctl.d/README)

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2152 bytes --]

On Sunday 01 Sep 2013 08:40:20 Grant wrote:
> >> How is PMTUD enabled/disabled on Gentoo?  I've recently been made
> >> aware of the existence of MTU and I'm wondering if mine is set
> >> properly for a cell phone tethered connection.
> 
> Thanks Mick.  Can you generally rely on PMTUD to set the MTU optimally
> or should this be experimented with when changing connections?

Short answer:  default Linux machine settings behave properly as network 
devices and acknowledge packets larger than their MTU value with the 
appropriate response.

Longer answer:

Communications between IPv4 end points use PMTUD by setting a Don't Fragment 
(DF) bit in the headers of the outgoing packet.  If a router/server along the 
path has a smaller MTU, it will drop that packet and respond with an ICMP 
'Destination Unreachable -- Fragmentation Needed' packet including its smaller 
MTU value.  Upon receiving this smaller packet value the initiating host will 
dynamically reduce the size of the outgoing packets, until the packet arrives 
at its intended destination.  PMTUD should always be switched on in any well 
behaving network implementation, but here's the rub:  some network nodes, 
firewalls, servers are configured to never respond with *any* ICMP packets 
(because they think that this is a way to avoid DDoS problems and the like).  
Therefore, the initiating host keeps sending large packets never knowing that 
they are dropped on the way.  This network problem is known as a PMTUD black 
hole and is explained better here:

  http://tools.ietf.org/html/rfc2923

Some MSWindows servers were notoriously bad at this, but I think that modern 
configurations have corrected their buggy ways.  Linux machines have PMTUD 
switched on by default and behave properly.


If you are still troubled by the proxy connection stalling problem, have you 
tried transferring large files over the network using scp/sftp to see if you 
are also getting similar symptoms?  This would isolate it to the application 
level (squid) or if the problem remains would point to network configuration 
issues.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> Thanks Mick.  Can you generally rely on PMTUD to set the MTU optimally
>> or should this be experimented with when changing connections?
>
> Short answer:  default Linux machine settings behave properly as network
> devices and acknowledge packets larger than their MTU value with the
> appropriate response.
>
> Longer answer:
>
> Communications between IPv4 end points use PMTUD by setting a Don't Fragment
> (DF) bit in the headers of the outgoing packet.  If a router/server along the
> path has a smaller MTU, it will drop that packet and respond with an ICMP
> 'Destination Unreachable -- Fragmentation Needed' packet including its smaller
> MTU value.  Upon receiving this smaller packet value the initiating host will
> dynamically reduce the size of the outgoing packets, until the packet arrives
> at its intended destination.  PMTUD should always be switched on in any well
> behaving network implementation, but here's the rub:  some network nodes,
> firewalls, servers are configured to never respond with *any* ICMP packets
> (because they think that this is a way to avoid DDoS problems and the like).
> Therefore, the initiating host keeps sending large packets never knowing that
> they are dropped on the way.  This network problem is known as a PMTUD black
> hole and is explained better here:
>
>   http://tools.ietf.org/html/rfc2923
>
> Some MSWindows servers were notoriously bad at this, but I think that modern
> configurations have corrected their buggy ways.  Linux machines have PMTUD
> switched on by default and behave properly.

Got it, thank you.

> If you are still troubled by the proxy connection stalling problem, have you
> tried transferring large files over the network using scp/sftp to see if you
> are also getting similar symptoms?  This would isolate it to the application
> level (squid) or if the problem remains would point to network configuration
> issues.

How can I make this determination?  I'm testing a 50MB scp over hotel
wifi from my laptop to the remote proxy server now (with squid running
in case it matters) and it seems OK.  It oscillates constantly between
0.0KB/s and 80.0KB/s.  As soon as I start browsing via the proxy
server, the upload frequently goes to "stalled" but I suppose that
could be a bandwidth issue.  Browsing still stalls before very long.

- Grant

Re: [gentoo-user] PMTUD

[Grant]

> Communications between IPv4 end points use PMTUD by setting a Don't Fragment
> (DF) bit in the headers of the outgoing packet.  If a router/server along the
> path has a smaller MTU, it will drop that packet and respond with an ICMP
> 'Destination Unreachable -- Fragmentation Needed' packet including its smaller
> MTU value.  Upon receiving this smaller packet value the initiating host will
> dynamically reduce the size of the outgoing packets, until the packet arrives
> at its intended destination.  PMTUD should always be switched on in any well
> behaving network implementation, but here's the rub:  some network nodes,
> firewalls, servers are configured to never respond with *any* ICMP packets
> (because they think that this is a way to avoid DDoS problems and the like).
> Therefore, the initiating host keeps sending large packets never knowing that
> they are dropped on the way.  This network problem is known as a PMTUD black
> hole and is explained better here:

Could ICMP packets not getting through be to blame for my proxy server
problem?  My laptop can't seem to ping anyone (blocked at the firewall
in this hotel I suppose) and certainly the proxy server can't ping my
laptop.

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1251 bytes --]

On Sunday 01 Sep 2013 11:31:10 Grant wrote:

> > If you are still troubled by the proxy connection stalling problem, have
> > you tried transferring large files over the network using scp/sftp to
> > see if you are also getting similar symptoms?  This would isolate it to
> > the application level (squid) or if the problem remains would point to
> > network configuration issues.
> 
> How can I make this determination?  I'm testing a 50MB scp over hotel
> wifi from my laptop to the remote proxy server now (with squid running
> in case it matters) and it seems OK.  It oscillates constantly between
> 0.0KB/s and 80.0KB/s.  As soon as I start browsing via the proxy
> server, the upload frequently goes to "stalled" but I suppose that
> could be a bandwidth issue.  Browsing still stalls before very long.

The oscillation is related to buffering and is normal.  If you are getting 
longer stalling periods where no packets are being transmitted then there 
could be a network problem.  iptraf-ng, ntop and other tools can show if 
packets have stopped moving in either direction.

From what you're describing the problem seems related to the squid 
application, since scp is not seeing similar timeouts.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> > If you are still troubled by the proxy connection stalling problem, have
>> > you tried transferring large files over the network using scp/sftp to
>> > see if you are also getting similar symptoms?  This would isolate it to
>> > the application level (squid) or if the problem remains would point to
>> > network configuration issues.
>>
>> How can I make this determination?  I'm testing a 50MB scp over hotel
>> wifi from my laptop to the remote proxy server now (with squid running
>> in case it matters) and it seems OK.  It oscillates constantly between
>> 0.0KB/s and 80.0KB/s.  As soon as I start browsing via the proxy
>> server, the upload frequently goes to "stalled" but I suppose that
>> could be a bandwidth issue.  Browsing still stalls before very long.
>
> The oscillation is related to buffering and is normal.  If you are getting
> longer stalling periods where no packets are being transmitted then there
> could be a network problem.  iptraf-ng, ntop and other tools can show if
> packets have stopped moving in either direction.
>
> From what you're describing the problem seems related to the squid
> application, since scp is not seeing similar timeouts.

Strangely, the ziproxy application behaves in exactly the same way.

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2721 bytes --]

On Sunday 01 Sep 2013 12:17:28 Grant wrote:
> > Communications between IPv4 end points use PMTUD by setting a Don't
> > Fragment (DF) bit in the headers of the outgoing packet.  If a
> > router/server along the path has a smaller MTU, it will drop that packet
> > and respond with an ICMP 'Destination Unreachable -- Fragmentation
> > Needed' packet including its smaller MTU value.  Upon receiving this
> > smaller packet value the initiating host will dynamically reduce the
> > size of the outgoing packets, until the packet arrives at its intended
> > destination.  PMTUD should always be switched on in any well behaving
> > network implementation, but here's the rub:  some network nodes,
> > firewalls, servers are configured to never respond with *any* ICMP
> > packets (because they think that this is a way to avoid DDoS problems
> > and the like). Therefore, the initiating host keeps sending large
> > packets never knowing that they are dropped on the way.  This network
> > problem is known as a PMTUD blackhole and is explained better here:
> 
> Could ICMP packets not getting through be to blame for my proxy server
> problem?  My laptop can't seem to ping anyone (blocked at the firewall
> in this hotel I suppose) and certainly the proxy server can't ping my
> laptop.

Not all ICMP packets are relevant to detecting the MTU of a node.  A correctly 
implemented node will return an ICMP Fragmentation Needed (Type 3, Code 4) 
packet, with its MTU value.  This kind of ICMP packets should not be blocked 
at firewalls.  Use ping with the do not fragment option to see if packets 
above a certain size time out, i.e. they are dropped by some offending node on 
the way.

  ping -c 6 -n -M do -s 1472 <server_address>

This will send 6 packets to your server's address having set the do not 
fragment bit.  The packet payload size is set at 1472 to allow for 28 bytes 
that are taken up by the IP and ICMP header data.  So the total packet size 
would be 1472+28=1500, the usual ethernet packet size.

If the MTU of the server is less than 1500 bytes, you will get a response 
containing "Frag needed and DF set", otherwise you will get pong responses, 
like e.g.

1480 bytes from XXX.XX.XXX.XXX: icmp_seq=1 ttl=121 time=66.5 ms

If there is a black hole in the circuit you will be getting timeouts.  Start 
reducing the size of the packet if you are getting time outs, say by 10 bytes 
at a time.  When you arrive at or below the corresponding size of the MTU of a 
blackhole you will start getting responses.

Of course, if the hotel's firewall is blocking all outgoing/incoming pings 
this sort of diagnostic test will not be useful.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> Could ICMP packets not getting through be to blame for my proxy server
>> problem?  My laptop can't seem to ping anyone (blocked at the firewall
>> in this hotel I suppose) and certainly the proxy server can't ping my
>> laptop.
>
> Not all ICMP packets are relevant to detecting the MTU of a node.  A correctly
> implemented node will return an ICMP Fragmentation Needed (Type 3, Code 4)
> packet, with its MTU value.  This kind of ICMP packets should not be blocked
> at firewalls.  Use ping with the do not fragment option to see if packets
> above a certain size time out, i.e. they are dropped by some offending node on
> the way.
>
>   ping -c 6 -n -M do -s 1472 <server_address>

I get "Frag needed and DF set (mtu = 1492)" when pinging google.com.
I get normal replies with -s 1464.  ifconfig shows my WAN interface at
MTU 1500 so PMTUD must change the MTU for communication with
google.com if I understand correctly.

> Of course, if the hotel's firewall is blocking all outgoing/incoming pings
> this sort of diagnostic test will not be useful.

I actually only lose pings to my own remote system so I've started a
new thread about that.  I tried down to -s 1 but still 100% packet
loss there.

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1984 bytes --]

On Sunday 01 Sep 2013 14:59:19 Grant wrote:
> >> Could ICMP packets not getting through be to blame for my proxy server
> >> problem?  My laptop can't seem to ping anyone (blocked at the firewall
> >> in this hotel I suppose) and certainly the proxy server can't ping my
> >> laptop.
> > 
> > Not all ICMP packets are relevant to detecting the MTU of a node.  A
> > correctly implemented node will return an ICMP Fragmentation Needed
> > (Type 3, Code 4) packet, with its MTU value.  This kind of ICMP packets
> > should not be blocked at firewalls.  Use ping with the do not fragment
> > option to see if packets above a certain size time out, i.e. they are
> > dropped by some offending node on the way.
> > 
> >   ping -c 6 -n -M do -s 1472 <server_address>
> 
> I get "Frag needed and DF set (mtu = 1492)" when pinging google.com.
> I get normal replies with -s 1464.  ifconfig shows my WAN interface at
> MTU 1500 so PMTUD must change the MTU for communication with
> google.com if I understand correctly.

The hotel's router/modem may be using PPPoE to authenticate with their ISP, 
which has a larger header size and requires an MTU of 1492 (1464+28=1492)

So, although your NIC is configured to the full ethernet MTU size, the router 
drops the size down to 1492 to be able to squeeze it out through the ISP's 
network.  That's all good and proper and will not cause the timeout problem 
you have been experiencing.


> > Of course, if the hotel's firewall is blocking all outgoing/incoming
> > pings this sort of diagnostic test will not be useful.
> 
> I actually only lose pings to my own remote system so I've started a
> new thread about that.  I tried down to -s 1 but still 100% packet
> loss there.

Have you checked that the firewall at your server is not set to drop all ICMP 
packets and that you don't have something like this set up on it:

  net.ipv4.icmp_echo_ignore_all = 0

(use sysctl to check)
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

> The hotel's router/modem may be using PPPoE to authenticate with their ISP,
> which has a larger header size and requires an MTU of 1492 (1464+28=1492)
>
> So, although your NIC is configured to the full ethernet MTU size, the router
> drops the size down to 1492 to be able to squeeze it out through the ISP's
> network.  That's all good and proper and will not cause the timeout problem
> you have been experiencing.

OK, does PMTUD lower the outgoing packet size on my system due to the
hotel router's lower MTU or does the hotel router itself fragment my
1500 byte packets in order to send them out?  Just curious.

> Have you checked that the firewall at your server is not set to drop all ICMP
> packets and that you don't have something like this set up on it:
>
>   net.ipv4.icmp_echo_ignore_all = 0
>
> (use sysctl to check)

I get this which looks OK:

# sysctl -a|grep icmp_echo_ignore_all
net.ipv4.icmp_echo_ignore_all = 0

Nikos mentioned in the other thread that I may need to configure ICMP
on my server's modem/router which I will be able to try tomorrow.

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 527 bytes --]

On Sunday 01 Sep 2013 17:17:37 Grant wrote:

> OK, does PMTUD lower the outgoing packet size on my system due to the
> hotel router's lower MTU or does the hotel router itself fragment my
> 1500 byte packets in order to send them out?  Just curious.

If you are sending out packets with the DF bit set no fragmentation will take 
place - the packet is dropped and an appropriate message is returned to 
sender.  Otherwise the router will fragment them and send them on to the 
recipient address.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> OK, does PMTUD lower the outgoing packet size on my system due to the
>> hotel router's lower MTU or does the hotel router itself fragment my
>> 1500 byte packets in order to send them out?  Just curious.
>
> If you are sending out packets with the DF bit set no fragmentation will take
> place - the packet is dropped and an appropriate message is returned to
> sender.  Otherwise the router will fragment them and send them on to the
> recipient address.

Shouldn't PMTUD change my MTU based on the hotel router's lower MTU?

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1758 bytes --]

On Sunday 01 Sep 2013 18:54:45 Grant wrote:
> >> OK, does PMTUD lower the outgoing packet size on my system due to the
> >> hotel router's lower MTU or does the hotel router itself fragment my
> >> 1500 byte packets in order to send them out?  Just curious.
> > 
> > If you are sending out packets with the DF bit set no fragmentation will
> > take place - the packet is dropped and an appropriate message is
> > returned to sender.  Otherwise the router will fragment them and send
> > them on to the recipient address.
> 
> Shouldn't PMTUD change my MTU based on the hotel router's lower MTU?

Yes, it should.  At the start of the connection the sender sends DF in the 
header to find out what is the MRU that the network nodes will support.  Then 
sends packets of the appropriate size so that they get through with no 
fragmentation.  This is the optimal scenario.

Now, imagine another scenario where some router/firewall/server does not send 
back the correct ICMP packet with its required MRU, or even worse it sends 
back a 1500 (full ethernet) size with DF set, or also drops fragments ... This 
reminds me of MSN IM which was a particularly bad implementation back when.

The sender may eventually try a smaller packet, after initially increasing the 
time it waits for a response, and you could well get something through 30 
seconds later, or even give up and time out.

If you are using Shorewall at your remote server I would expect it to behave 
properly and return the correct ICMP packet when it receives a DF.  However, I 
am not familiar with the Shorewall properties and settings, so if you suspect 
this as the cause of your problem it would be better if you look into it 
properly.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> >> OK, does PMTUD lower the outgoing packet size on my system due to the
>> >> hotel router's lower MTU or does the hotel router itself fragment my
>> >> 1500 byte packets in order to send them out?  Just curious.
>> >
>> > If you are sending out packets with the DF bit set no fragmentation will
>> > take place - the packet is dropped and an appropriate message is
>> > returned to sender.  Otherwise the router will fragment them and send
>> > them on to the recipient address.
>>
>> Shouldn't PMTUD change my MTU based on the hotel router's lower MTU?
>
> Yes, it should.  At the start of the connection the sender sends DF in the
> header to find out what is the MRU that the network nodes will support.  Then
> sends packets of the appropriate size so that they get through with no
> fragmentation.  This is the optimal scenario.
>
> Now, imagine another scenario where some router/firewall/server does not send
> back the correct ICMP packet with its required MRU, or even worse it sends
> back a 1500 (full ethernet) size with DF set, or also drops fragments ... This
> reminds me of MSN IM which was a particularly bad implementation back when.
>
> The sender may eventually try a smaller packet, after initially increasing the
> time it waits for a response, and you could well get something through 30
> seconds later, or even give up and time out.

Here's my layout:

laptop+shorewall (MTU:1500) -> hotel router (MTU:?) -> internet ->
Westell modem/router (MTU:1492) -> desktop+shorewall (MTU:1500)

Shouldn't PMTUD change the desktop's MTU to 1492?  Is the fact that it
doesn't due to a flaw in the Westell's operation?  Should I manually
change the desktop's MTU to 1492 along with that of other systems on
its LAN?

> If you are using Shorewall at your remote server I would expect it to behave
> properly and return the correct ICMP packet when it receives a DF.  However, I
> am not familiar with the Shorewall properties and settings, so if you suspect
> this as the cause of your problem it would be better if you look into it
> properly.

So I'm sure I understand, this doesn't apply if ICMP is dropped at the Westell?

- Grant

Re: [gentoo-user] PMTUD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1796 bytes --]

On Monday 02 Sep 2013 19:34:25 Grant wrote:

> Here's my layout:
> 
> laptop+shorewall (MTU:1500) -> hotel router (MTU:?) -> internet ->
> Westell modem/router (MTU:1492) -> desktop+shorewall (MTU:1500)
> 
> Shouldn't PMTUD change the desktop's MTU to 1492?  

Your desktop's PMTUD will get an ICMP response from Westell as it tries to 
traverse through it and it will adjust the outgoing packet size accordingly.

Ditto with your laptop, when it tries to establish a connection with your 
desktop.


> Is the fact that it
> doesn't due to a flaw in the Westell's operation?  Should I manually
> change the desktop's MTU to 1492 along with that of other systems on
> its LAN?

It won't harm if you do.  However, we don't know for a *fact* that the Westell 
is not returning the appropriate ICMP packets (Type 3, Code 4) to your laptop, 
or your desktop.

You can use tcpdump to see what's being sent back and forth.


> > If you are using Shorewall at your remote server I would expect it to
> > behave properly and return the correct ICMP packet when it receives a
> > DF.  However, I am not familiar with the Shorewall properties and
> > settings, so if you suspect this as the cause of your problem it would
> > be better if you look into it properly.
> 
> So I'm sure I understand, this doesn't apply if ICMP is dropped at the
> Westell?

ICMP echo request may be dropped by Westell's firewall, but ICMP Type 3, Code 
4 could well be returned when a TCP connection is being initiated by your 
laptop.  I don't know how ham-fisted Westell's firewall settings are.

Meanwhile, stating the obvious, have you tried using the desktop squid proxy 
while you are inside your LAN with the same laptop to see if the problem 
remains?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] PMTUD

[Grant]

>> Here's my layout:
>>
>> laptop+shorewall (MTU:1500) -> hotel router (MTU:?) -> internet ->
>> Westell modem/router (MTU:1492) -> desktop+shorewall (MTU:1500)
>>
>> Shouldn't PMTUD change the desktop's MTU to 1492?
>
> Your desktop's PMTUD will get an ICMP response from Westell as it tries to
> traverse through it and it will adjust the outgoing packet size accordingly.
>
> Ditto with your laptop, when it tries to establish a connection with your
> desktop.
>
>
>> Is the fact that it
>> doesn't due to a flaw in the Westell's operation?  Should I manually
>> change the desktop's MTU to 1492 along with that of other systems on
>> its LAN?
>
> It won't harm if you do.  However, we don't know for a *fact* that the Westell
> is not returning the appropriate ICMP packets (Type 3, Code 4) to your laptop,
> or your desktop.
>
> You can use tcpdump to see what's being sent back and forth.

Ah, so PMTUD doesn't actually change the setting reported by ifconfig.
 It's done on-the-fly.

>> > If you are using Shorewall at your remote server I would expect it to
>> > behave properly and return the correct ICMP packet when it receives a
>> > DF.  However, I am not familiar with the Shorewall properties and
>> > settings, so if you suspect this as the cause of your problem it would
>> > be better if you look into it properly.
>>
>> So I'm sure I understand, this doesn't apply if ICMP is dropped at the
>> Westell?
>
> ICMP echo request may be dropped by Westell's firewall, but ICMP Type 3, Code
> 4 could well be returned when a TCP connection is being initiated by your
> laptop.  I don't know how ham-fisted Westell's firewall settings are.
>
> Meanwhile, stating the obvious, have you tried using the desktop squid proxy
> while you are inside your LAN with the same laptop to see if the problem
> remains?

That's a fine idea and I will do so once I get back there.  Thanks for
the education Mick. :)

- Grant