Re: Router fails with Zen Internet

The unnatural thunker mentioned:-
"If it were mined I'd have a full *nix networking utilities setup probing
away..but these days, if all you have is Windoesn't, its a problem to debug."

What utilities are you missing?

I have been doing network troubleshooting with windows
for decades and I have assembled what I consider to be
a decent toolkit. Let me know what you think is absent
and with a bit of luck I may be able to offer a suggestion

bod43 wrote:
> The unnatural thunker mentioned:-
> "If it were mined I'd have a full *nix networking utilities setup probing
> away..but these days, if all you have is Windoesn't, its a problem to debug."
>
> What utilities are you missing?
>
> I have been doing network troubleshooting with windows
> for decades and I have assembled what I consider to be
> a decent toolkit. Let me know what you think is absent
> and with a bit of luck I may be able to offer a suggestion
>
>
>
>
Is because I have linux I don't need them, and I don't have the problem
anyway.

"bod43" <(E-Mail Removed)> wrote in message
news:db40ca95-de6d-4142-a084-(E-Mail Removed)...
> The unnatural thunker mentioned:-
> "If it were mined I'd have a full *nix networking utilities setup probing
> away..but these days, if all you have is Windoesn't, its a problem to
> debug."
>
> What utilities are you missing?
>
> I have been doing network troubleshooting with windows
> for decades and I have assembled what I consider to be
> a decent toolkit. Let me know what you think is absent
> and with a bit of luck I may be able to offer a suggestion

In response to many of the questions raised:

1) I'm testing this router (GetNet GA-524WA) because:

a) It's cheap - see:
http://www.scan.co.uk/products/getne...-4-port-switch

b) It has many of the features I find useful, including: remote management
controlled by ACL allowing several different entries, DDNS, keyhole slots
for wall mounting, load/save configuration facility, etc.

2) The basic test configuration is a PC running Outlook configured with 7
different POP3 accounts. These accounts are unrelated to any ISP and have
their own SMTP servers configured.

3) The router is factory reset and reconfigured using the wizard for each
test. Only the ISP's login credentials are supplied. The firewall is in its
default factory configuration; and the device does not claim to contain any
antivirus or anti-spyware.

4) The only other firewall present is the basic Windows firewall in the test
PC. AVG 2011 runs on the PC.

5) All other routers ever tried have behaved correctly (Vigor, Edimax,
Netgear, 3Com, Dlink, Belkin, etc ...)

6) There is no firmware upgrade available on the manufacturer's website -
but the product is fairly new.

7) As previously explained, the GetNet router works correctly when connected
to an ADSL service provide by Demon or Plusnet. But when connected to an
ADSL service provided by Zen Internet it fails as described below - on three
different lines at three different locations. Two different GetNet routers
(with consecutive serial numbers) have been tried.

8) When connected to Zen, the GetNet router reports ADSL sync (with
appropriate SNR margin and line rate as expected for the line), browses the
web correctly, shows sensible speed test reports consistent with what the
lines are known to achieve, but does not collect email from the POP3
accounts. Monitoring the ethernet traffic between PC and router shows the
POP3 requests going out, but no responses coming in. Curiously, very
occasionally (perhaps 1% of the time) a POP3 request does succeed. A
monitoring tool that would look at the ADSL port might be useful here - it
would show whether the POP3 server is actually sending a response.

9) I have also tested with other PCs (all running Outlook, and a Linux
system running fetchmail). These other test machines show the same problem.

I have not yet discussed the problem with Zen.

--
Graham J

On 09/02/11 11:22, Graham J wrote:

> 8) When connected to Zen, the GetNet router reports ADSL sync (with
> appropriate SNR margin and line rate as expected for the line), browses the
> web correctly, shows sensible speed test reports consistent with what the
> lines are known to achieve, but does not collect email from the POP3
> accounts. Monitoring the ethernet traffic between PC and router shows the
> POP3 requests going out, but no responses coming in. Curiously, very
> occasionally (perhaps 1% of the time) a POP3 request does succeed. A
> monitoring tool that would look at the ADSL port might be useful here - it
> would show whether the POP3 server is actually sending a response.

have you tried a telnet connection to the POP3 servers? That should tell
you whether they are responding.

>
> 9) I have also tested with other PCs (all running Outlook, and a Linux
> system running fetchmail). These other test machines show the same problem.
>
> I have not yet discussed the problem with Zen.

Zen's tech support has been pretty good on the rare occasions I've
needed to use them.


--
Bernard Peek
(E-Mail Removed)

Graham J wrote:
> "bod43" <(E-Mail Removed)> wrote in message
> news:db40ca95-de6d-4142-a084-(E-Mail Removed)...
>> The unnatural thunker mentioned:-
>> "If it were mined I'd have a full *nix networking utilities setup probing
>> away..but these days, if all you have is Windoesn't, its a problem to
>> debug."
>>
>> What utilities are you missing?
>>
>> I have been doing network troubleshooting with windows
>> for decades and I have assembled what I consider to be
>> a decent toolkit. Let me know what you think is absent
>> and with a bit of luck I may be able to offer a suggestion
>
> In response to many of the questions raised:
>
> 1) I'm testing this router (GetNet GA-524WA) because:
>
> a) It's cheap - see:
> http://www.scan.co.uk/products/getne...-4-port-switch
>
> b) It has many of the features I find useful, including: remote management
> controlled by ACL allowing several different entries, DDNS, keyhole slots
> for wall mounting, load/save configuration facility, etc.
>
> 2) The basic test configuration is a PC running Outlook configured with 7
> different POP3 accounts. These accounts are unrelated to any ISP and have
> their own SMTP servers configured.
>
> 3) The router is factory reset and reconfigured using the wizard for each
> test. Only the ISP's login credentials are supplied. The firewall is in its
> default factory configuration; and the device does not claim to contain any
> antivirus or anti-spyware.
>
> 4) The only other firewall present is the basic Windows firewall in the test
> PC. AVG 2011 runs on the PC.
>
> 5) All other routers ever tried have behaved correctly (Vigor, Edimax,
> Netgear, 3Com, Dlink, Belkin, etc ...)
>
> 6) There is no firmware upgrade available on the manufacturer's website -
> but the product is fairly new.
>
> 7) As previously explained, the GetNet router works correctly when connected
> to an ADSL service provide by Demon or Plusnet. But when connected to an
> ADSL service provided by Zen Internet it fails as described below - on three
> different lines at three different locations. Two different GetNet routers
> (with consecutive serial numbers) have been tried.
>

Unless they are LLU offerings, it will in every case be connecting to BT
DSLAM and backhaul.

So its very very strange indeed. If it works AT ALL it must be OK at the
ATM level too.


That leaves IP issues. And very subtle ones at that.



> 8) When connected to Zen, the GetNet router reports ADSL sync (with
> appropriate SNR margin and line rate as expected for the line), browses the
> web correctly, shows sensible speed test reports consistent with what the
> lines are known to achieve, but does not collect email from the POP3
> accounts. Monitoring the ethernet traffic between PC and router shows the
> POP3 requests going out, but no responses coming in. Curiously, very
> occasionally (perhaps 1% of the time) a POP3 request does succeed. A
> monitoring tool that would look at the ADSL port might be useful here - it
> would show whether the POP3 server is actually sending a response.
>

I think this may well be a packet size issue. Its the only thing that
can make large IP transfers fail when small packets work.

Have you tried telnet <pop server> 110?



> 9) I have also tested with other PCs (all running Outlook, and a Linux
> system running fetchmail). These other test machines show the same problem.
>

It is almost inconceivable that one protocol fails whilst others work.
Unless there is some sort of filter on that protocol.



> I have not yet discussed the problem with Zen.
>

[snip]

>> 7) As previously explained, the GetNet router works correctly when
>> connected to an ADSL service provide by Demon or Plusnet. But when
>> connected to an ADSL service provided by Zen Internet it fails as
>> described below - on three different lines at three different locations.
>> Two different GetNet routers (with consecutive serial numbers) have been
>> tried.
>>
> Unless they are LLU offerings, it will in every case be connecting to BT
> DSLAM and backhaul.
>
> So its very very strange indeed. If it works AT ALL it must be OK at the
> ATM level too.
>
> That leaves IP issues. And very subtle ones at that.

Agreed

>> 8) When connected to Zen, the GetNet router reports ADSL sync (with
>> appropriate SNR margin and line rate as expected for the line), browses
>> the web correctly, shows sensible speed test reports consistent with what
>> the lines are known to achieve, but does not collect email from the POP3
>> accounts. Monitoring the ethernet traffic between PC and router shows
>> the POP3 requests going out, but no responses coming in. Curiously, very
>> occasionally (perhaps 1% of the time) a POP3 request does succeed. A
>> monitoring tool that would look at the ADSL port might be useful here -
>> it would show whether the POP3 server is actually sending a response.
>>
>
> I think this may well be a packet size issue. Its the only thing that can
> make large IP transfers fail when small packets work.

MTU currently set to default value =1500

> Have you tried telnet <pop server> 110?

Good thought - will try later ...

>> 9) I have also tested with other PCs (all running Outlook, and a Linux
>> system running fetchmail). These other test machines show the same
>> problem.
>>
> It is almost inconceivable that one protocol fails whilst others work.
> Unless there is some sort of filter on that protocol.

Just tried configuring the GetNet in bridge mode, and using an ethernet
router to send PPPoE through it. Works correctly! So the modem component
is not the cause of the problem. I shouldn't think the modem does any
packet filtering or packet fragmentation so we probably haven't learnt much.

--
Graham J

Graham J wrote:
> [snip]
>
>>> 7) As previously explained, the GetNet router works correctly when
>>> connected to an ADSL service provide by Demon or Plusnet. But when
>>> connected to an ADSL service provided by Zen Internet it fails as
>>> described below - on three different lines at three different locations.
>>> Two different GetNet routers (with consecutive serial numbers) have been
>>> tried.
>>>
>> Unless they are LLU offerings, it will in every case be connecting to BT
>> DSLAM and backhaul.
>>
>> So its very very strange indeed. If it works AT ALL it must be OK at the
>> ATM level too.
>>
>> That leaves IP issues. And very subtle ones at that.
>
> Agreed
>
>>> 8) When connected to Zen, the GetNet router reports ADSL sync (with
>>> appropriate SNR margin and line rate as expected for the line), browses
>>> the web correctly, shows sensible speed test reports consistent with what
>>> the lines are known to achieve, but does not collect email from the POP3
>>> accounts. Monitoring the ethernet traffic between PC and router shows
>>> the POP3 requests going out, but no responses coming in. Curiously, very
>>> occasionally (perhaps 1% of the time) a POP3 request does succeed. A
>>> monitoring tool that would look at the ADSL port might be useful here -
>>> it would show whether the POP3 server is actually sending a response.
>>>
>> I think this may well be a packet size issue. Its the only thing that can
>> make large IP transfers fail when small packets work.
>
> MTU currently set to default value =1500

Try 1400. The magic figure is 1432 IIRC. The max packet that fits in an
ATM frame.


>
>> Have you tried telnet <pop server> 110?
>
> Good thought - will try later ...
>
>>> 9) I have also tested with other PCs (all running Outlook, and a Linux
>>> system running fetchmail). These other test machines show the same
>>> problem.
>>>
>> It is almost inconceivable that one protocol fails whilst others work.
>> Unless there is some sort of filter on that protocol.
>
> Just tried configuring the GetNet in bridge mode, and using an ethernet
> router to send PPPoE through it. Works correctly! So the modem component
> is not the cause of the problem. I shouldn't think the modem does any
> packet filtering or packet fragmentation so we probably haven't learnt much.
>

I think the problem is either with the ATM area or the IP area. If it
synchs at all, the modem will be fine.

The Natural Philosopher wrote:

>>
>> MTU currently set to default value =1500
>
> Try 1400. The magic figure is 1432 IIRC. The max packet that fits in an
> ATM frame.

I thought 1492 was the max ?

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

--
Mark
Please replace invalid and invalid with gmx and net to reply.

www.paras.org.uk

Mark Carver wrote:
> The Natural Philosopher wrote:
>
>>>
>>> MTU currently set to default value =1500
>>
>> Try 1400. The magic figure is 1432 IIRC. The max packet that fits in
>> an ATM frame.
>
> I thought 1492 was the max ?
>
> http://tools.ietf.org/html/rfc2516
>
DSL is generally PPPoA in this country.. IIRC the ATM frame eats into
the other bytes somewhat..

Here is a reasonable crib sheet, and it is certainly worth a try

http://www.kitz.co.uk/adsl/tweak2.htm


Anyyay if you try 1400 and it all springs to life, then you can retune
for better response: the main thing is to establish whether the fault is
MTU related or not.

"The Natural Philosopher" <(E-Mail Removed)> wrote in message
news:iius3j$6rj$(E-Mail Removed)...
> Graham J wrote:
>> [snip]
>>
>>>> 7) As previously explained, the GetNet router works correctly when
>>>> connected to an ADSL service provide by Demon or Plusnet. But when
>>>> connected to an ADSL service provided by Zen Internet it fails as
>>>> described below - on three different lines at three different
>>>> locations. Two different GetNet routers (with consecutive serial
>>>> numbers) have been tried.
>>>>
>>> Unless they are LLU offerings, it will in every case be connecting to BT
>>> DSLAM and backhaul.
>>>
>>> So its very very strange indeed. If it works AT ALL it must be OK at the
>>> ATM level too.
>>>
>>> That leaves IP issues. And very subtle ones at that.
>>
>> Agreed
>>
>>>> 8) When connected to Zen, the GetNet router reports ADSL sync (with
>>>> appropriate SNR margin and line rate as expected for the line), browses
>>>> the web correctly, shows sensible speed test reports consistent with
>>>> what the lines are known to achieve, but does not collect email from
>>>> the POP3 accounts. Monitoring the ethernet traffic between PC and
>>>> router shows the POP3 requests going out, but no responses coming in.
>>>> Curiously, very occasionally (perhaps 1% of the time) a POP3 request
>>>> does succeed. A monitoring tool that would look at the ADSL port might
>>>> be useful here - it would show whether the POP3 server is actually
>>>> sending a response.
>>>>
>>> I think this may well be a packet size issue. Its the only thing that
>>> can make large IP transfers fail when small packets work.
>>
>> MTU currently set to default value =1500
>
> Try 1400. The magic figure is 1432 IIRC. The max packet that fits in an
> ATM frame.

Changing MTU size in the router makes no difference. Neither does changing
the MTU in the PC

I would have thought that the POP3 packets are very small, so packet
fragmentation is unlikely; and MTU size would be irrelevant

>>
>>> Have you tried telnet <pop server> 110?
>>
>> Good thought - will try later ...

telnet
OPEN pop.123-reg.co.uk 110
Connection to pop.123-reg.co.uk...Could not open your connection to the
host, on port 110: Connect failed

.... this after a long delay - perhaps 300 seconds.

Yet:
PING pop.123-reg.co.uk
.... immediate replies

Telnet to a known FTP server using port 21 responds as expected.

--
Graham J