vigor users

[Andy Burns]

Any FTTC users with draytek routers here?

With my present HH5a/openWRT I had to enable baby-jumbo frames on the
DSL interface so that the IP MTU with PPPoE would still be 1500 bytes,
same as over ethernet.

C:\Users\Andy>ping -l 1472 -f 8.8.8.8

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1472) time=12ms TTL=117

do the vigor routers manage this with their internal modem? when using
an external v130 modem?

additionally, anyone using the vigor router as the "root" node for a
vigorAP mesh network?

[Bob Eager]

On Wed, 11 Aug 2021 20:02:11 +0100, Andy Burns wrote:

> additionally, anyone using the vigor router as the "root" node for a
> vigorAP mesh network?

I tried, but realised it wouldn't work. Reason: between the Vigor router
and the four node VigorAP mesh is a firewall. I suppose I could try to
forward the broadcast frames, but most can be managed from the root node
anyway.

[Graham J]

Draytek 2860, connected to FTTC on WAN1 (internal modem).

MTU set at 1450 for no reason that I can remember - perhaps it is the
default? I tried the Path MTU discovery option, it reduces from 1500
and fails until it gets down to 1450.

ping -l 1472 -f 8.8.8.8 replies but says "Packet needs to be fragmented
but DF set".

WAN2 has a V130 connected to ADSL. This is a backup connection so only
packets for one specific Plusnet subnet go out this way.

MTU also set at 1450. Path MTU discovery shows success at 1450.
ping -l 1472 -f 212.159.6.9 - similar message about DF.

Both WAN1 and WAN2 allow the maximum MTU at 1500. I could change it on
mine but I suspect it means rebooting the router which I don't want to
do at present. Let me know and I could try it later.

Surely the optimum is to allow packets to fragment as required?

Hope this helps.

I've not used its mesh AP facility.

--
Graham J

[Brian Gregory]

On 11/08/2021 21:55, Graham J wrote:
> Surely the optimum is to allow packets to fragment as required?

TCP can be left to fragment and will work fine but the absolute most
efficient way is to set the MTU correctly so that you're using the
minimum number of packets to send a given amount of data.

But UDP is a different matter, if you allow fragmentation and it occurs
then there is a chance things will get garbled if the fragments happen
to arrive at the destination in the wrong order.

Therefore UDP will normally be sent with DF set so that an error packet
needs to be fragmented message comes back if you send a packets that's
too big and you have to try again with a smaller packet.

--
Brian Gregory (in England).

[Andy Burns]

Graham J wrote:

> Draytek 2860, connected to FTTC on WAN1 (internal modem).
>
> MTU set at 1450 for no reason that I can remember - perhaps it is the
> default?  I tried the Path MTU discovery option, it reduces from 1500
> and fails until it gets down to 1450.
>
> ping -l 1472 -f 8.8.8.8 replies but says "Packet needs to be fragmented
> but DF set".

Thanks, what I'd expect without baby-jumbo.

> WAN2 has a V130 connected to ADSL.  This is a backup connection so only
> packets for one specific Plusnet subnet go out this way.
>
> MTU also set at 1450.  Path MTU discovery shows success at 1450.
> ping -l 1472 -f 212.159.6.9 - similar message about DF.
>
> Both WAN1 and WAN2 allow the maximum MTU at 1500.  I could change it on
> mine but I suspect it means rebooting the router which I don't want to
> do at present.  Let me know and I could try it later.

If there's ever a convenitent time ...

> Surely the optimum is to allow packets to fragment as required?

For efficiency, if fragmentation can be avoided, then avoid it?

Also, it may be few and far between, and it may be a long time ago, but
I *have* come across the occasional misbehaving server that doesn't
respond to packets other than ethernet sized MTU.

[Chris Green]

Andy Burns <use...@andyburns.uk> wrote:
> Any FTTC users with draytek routers here?
>
> With my present HH5a/openWRT I had to enable baby-jumbo frames on the
> DSL interface so that the IP MTU with PPPoE would still be 1500 bytes,
> same as over ethernet.
>
> C:\Users\Andy>ping -l 1472 -f 8.8.8.8
>
> Pinging 8.8.8.8 with 1472 bytes of data:
> Reply from 8.8.8.8: bytes=68 (sent 1472) time=12ms TTL=117
>
> do the vigor routers manage this with their internal modem? when using
> an external v130 modem?
>

My 2860n+ is on FTTC WAN1, the MTU is 1520. I've not done anything
special to the WAN interface, just gave it the required name/password
and left it to it.

chris@esprimo$ ping -l 1472 -f 8.8.8.8
ping: cannot set preload to value greater than 3: 1472
chris@esprimo$

My ping is different from your ping! :-)

root@esprimo# ping -s 1472 cheddar.halon.org.uk
PING cheddar.halon.org.uk (93.93.131.118) 1472(1500) bytes of data.
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=1 ttl=55 time=18.1 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=2 ttl=55 time=14.9 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=3 ttl=55 time=14.8 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=4 ttl=55 time=14.9 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=5 ttl=55 time=14.9 ms

That's better! :-)

I tried 8.8.8.8 but got no response at all.



--
Chris Green
·

[Andy Burns]

Brian Gregory wrote:

> TCP can be left to fragment and will work fine but the absolute most
> efficient way is to set the MTU correctly so that you're using the
> minimum number of packets to send a given amount of data.

Some people seem obsessed* with blocking ICMP, in blocking ping
request/reply, they sometimes block "unreachables" too, so path MTU
discovery breaks.


[*] yes in the past fragmented and christmas tree packets have caused
problems, but I'd rather have basic diagnostics enabled.

[Graham J]

Andy Burns wrote:
> Graham J wrote:
>
>> Draytek 2860, connected to FTTC on WAN1 (internal modem).
>>
>> MTU set at 1450 for no reason that I can remember - perhaps it is the
>> default?  I tried the Path MTU discovery option, it reduces from 1500
>> and fails until it gets down to 1450.
>>
>> ping -l 1472 -f 8.8.8.8 replies but says "Packet needs to be
>> fragmented but DF set".
>
> Thanks, what I'd expect without baby-jumbo.

I can't see a setting on the Vigor which is described as baby-jumbo.
Do they been simply setting MTU at 1500?

>
>> WAN2 has a V130 connected to ADSL.  This is a backup connection so
>> only packets for one specific Plusnet subnet go out this way.
>>
>> MTU also set at 1450.  Path MTU discovery shows success at 1450.
>> ping -l 1472 -f 212.159.6.9 - similar message about DF.
>>
>> Both WAN1 and WAN2 allow the maximum MTU at 1500.  I could change it
>> on mine but I suspect it means rebooting the router which I don't want
>> to do at present.  Let me know and I could try it later.
>

> If there's ever a convenient time ...

>
>> Surely the optimum is to allow packets to fragment as required?
>
> For efficiency, if fragmentation can be avoided, then avoid it?
>
> Also, it may be few and far between, and it may be a long time ago, but
> I *have* come across the occasional misbehaving server that doesn't
> respond to packets other than ethernet sized MTU.

I have a vague recollection of some VPN connections not working with
other than MTU=1450. It may be that the debugging hints suggested
setting MTU=1450 first ...

I will try setting to 1500 sometime in the next hour, and reboot if
necesary.


--
Graham J

[Andy Burns]

Chris Green wrote:

> My ping is different from your ping!:-)

Yes windows vs linux, "-l" becomes "-s"

> root@esprimo# ping -s 1472 cheddar.halon.org.uk
> PING cheddar.halon.org.uk (93.93.131.118) 1472(1500) bytes of data.
> 1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=1 ttl=55 time=18.1 ms

but also "-f" becomes "-Mdo" otherwise you're allowing fragmentation,
compare outputs for one byte larger packets

ping -s 1473 cheddar.halon.org.uk

ping -s 1473 -Mdo cheddar.halon.org.uk

[Andy Burns]

Bob Eager wrote:

> I tried, but realised it wouldn't work. Reason: between the Vigor router
> and the four node VigorAP mesh is a firewall.

Does that imply you distrust/dislike the vigor's firewall?

[Graham J]

Andy Burns wrote:

[snip]

>
> If there's ever a convenient time ...

OK so both WAN1 and WAN2 set for MTU=1500. The V2860 warns that the
PPPoE server might not work with this setting.

WAN1

ping -l 1472 -f 8.8.8.8

... returns 4 replies with no warnings about fragmentation
... reply times are longer, about 16mS rather than 11mS without the
explicit buffer size switch

WAN2 (this only carries traffic to a specific Plusnet subnet)

ping -l 1472 -f 212.159.6.9

... 4 good replies
... reply times are longer, about 55mS rather than 28mS without the
explicit buffer size switch

I suspect the longer reply times indicate that the bigger packets are
actually fragmented on the way to/from the responding server, or perhaps
there's an extra overhead of packet size negotiaton away from the default.

Syslog with messages enabled from WAN log shows nothing unexpected. All
my VPN connections work.

I can leave the MTU=1500 setting on both WANs for the moment to see if
anything breaks. A straw poll of commonly viewed websites all work OK.

Hope this helps.


--
Graham J

[Bob Eager]

I already had a firewall when I got the 2860. I wasn't about to change
everything. And mine is probably more functional.

As it happens, they'd only just introduced the firewall when I got the
2860. It was badly broken. It blocked stuff *even when disabled*. I had a
lot of trouble with blocked zone transfers from my primary DNS server. To
be fair, they supplied fixed firmware within a week, but I had to use the
packet tracing facility at my ISP to nail down the problem.

[Andy Burns]

Graham J wrote:

> WAN1
> ping -l 1472 -f 8.8.8.8
> ... returns 4 replies with no warnings about fragmentation
> ... reply times are longer, about 16mS rather than 11mS without the
> explicit buffer size switch
>
> WAN2 (this only carries traffic to a specific Plusnet subnet)
> ping -l 1472 -f 212.159.6.9
> ... 4 good replies
> ... reply times are longer, about 55mS rather than 28mS without the
> explicit buffer size switch

Hmmm, I only see a marginal difference between response times of 1 byte
and 1472 byte pings, i.e.

90% of short packets are 15ms with the occasional 16ms

50% of long packets are 16ms with 40% 15ms and the occasional 17ms

all plusnet.

Thanks.

[Graham J]

My V2860 has beta firmware: r87824_beta

This was to try to find out why the V2860 was less good at maintaining
the VDSL connection than the Technicolor TG588 router supplied by Zen.
It would never keep a connection up for more than a few days, while the
TG588 maintained to for a month at a time. I have a long line (about
1.1km) to the green cab so it could have been fighting almost any sort
of noise or diode-like junctions.

SEG (Draytek agents in the UK) were initially helpful and I sent
diagnostic info, and r87824_beta was one of their responses. Initially
it broke my LAN-to-LAN VPN connections to older Vigor models which had
something to do with the order in which it negotiated the security
settings (which is where I remember the MTU=1450 requirement), but
changing the order in the VPN setup resolved that. I think the beta
firmware also affects the modem.

I also tested the V130 on the FTTC connection, and that was similarly
unreliable even with beta firmware; which implies a logical error in the
modem design.

Then Covid-19 struck and the R&D people in Taiwan stopped responding.

So my test results with MTU=1500 might be quite unrepresentative.

What is the underlying problem that you are trying to resolve?


--
Graham J

[Andy Burns]

Graham J wrote:

[snip]

> What is the underlying problem that you are trying to resolve?

In particular with 1500 byte MTU, I might be needlessly trying to avoid
a problem that has only bitten lightly in the past, but why allow
VDSL/PPPoE to go backwards from ADSL/PPPoA?

But more generally, as mentioned I use a BT HH5a with openWRT firmware,
worked well enough with v17/18/19, though I'm aware it has a CPU
bottleneck on wifi that's a little lower than my line speed, supposedly
fixed in v21 but I've found other, more serious issues* with v21 release
candidates, and bug reports have gone ignored, so I think it's time to
jump ship, I could go back to v19 from v21-rc4 but where's the fun in that?

Also within a year or two I'll need a mesh solution, so might as well
test the waters now. Have been round a loop of candidates, asus?
draytek? mikrotik? and now back to draytek.



[*] 5GHz radio exits the bridge after a few days uptime, 2.4GHz radio
seems to shun my older chromecasts and wifi thermostats, possible
DHCP/DNS issues to wired devices.

[Roger]

On Wed, 11 Aug 2021 21:55:28 +0100, Graham J
<nob...@nowhere.co.uk> wrote:

>
>Andy Burns wrote:
>> Any FTTC users with draytek routers here?
>>
>> With my present HH5a/openWRT I had to enable baby-jumbo frames on the
>> DSL interface so that the IP MTU with PPPoE would still be 1500 bytes,
>> same as over ethernet.
>>
>> C:\Users\Andy>ping -l 1472 -f 8.8.8.8
>>
>> Pinging 8.8.8.8 with 1472 bytes of data:
>> Reply from 8.8.8.8: bytes=68 (sent 1472) time=12ms TTL=117
>>
>> do the vigor routers manage this with their internal modem?  when using
>> an external v130 modem?
>>
>> additionally, anyone using the vigor router as the "root" node for a
>> vigorAP mesh network?
>
>Draytek 2860, connected to FTTC on WAN1 (internal modem).
>
>MTU set at 1450 for no reason that I can remember - perhaps it is the
>default? I tried the Path MTU discovery option, it reduces from 1500
>and fails until it gets down to 1450.

Purchased 2762 whilst still on ADSL. Decided to set it up ready
for VDSL should I ever switch. Read somewhere that VDSL MTU
should be 1492 that's what I set it to. Switched over in March
this year and haven't had to change anything.

ping packet size of 1465 fails; 1464 succeeds.

I just tried the MTU discovery and it succeeded at 1492. I
wonder whether your setting of 1450 is the reason the MTU
discovery shows 1450. Try changing it to 1492 and see if
the MTU discovery goes up to 1492.
--
Roger

[Graham J]

Roger wrote:

[snip]

>
> I just tried the MTU discovery and it succeeded at 1492. I
> wonder whether your setting of 1450 is the reason the MTU
> discovery shows 1450. Try changing it to 1492 and see if
> the MTU discovery goes up to 1492.

On the V2860 the MTU discovery tries 3 times, subtracting 8 each time.
It also needs an IP to test, so I used 8.8.8.8. With MTU set at 1450:

start 1500, fails at 1476
start 1476, fails at 1452

start 1450 succeeds at 1450

But with NTU set at 1500 it succeeds immediately. So the test is
restricted by the MTU limit set in the router, which is not what I would
have expected.

All it would do is to identify that a specific host can only support a
lower MTU. But if this were the case presumably that host would
negotiate a lower MTU anyway, and packets would be fragmented accordingly.

So I don't understand its purpose.

--
Graham J

[Graham J]

Andy Burns wrote:
> Graham J wrote:
>
> [snip]
>
>> What is the underlying problem that you are trying to resolve?
>
> In particular with 1500 byte MTU, I might be needlessly trying to avoid
> a problem that has only bitten lightly in the past, but why allow
> VDSL/PPPoE to go backwards from ADSL/PPPoA?

What was that problem?

> Also within a year or two I'll need a mesh solution, so might as well
> test the waters now.  Have been round a loop of candidates, asus?
> draytek? mikrotik? and now back to draytek.

I hear good reports of Ubiquiti but have not used them myself.


--
Graham J

[Chris Green]

Hmmmmm....

root@esprimo# ping -s 1473 cheddar.halon.org.uk
PING cheddar.halon.org.uk (93.93.131.118) 1473(1501) bytes of data.
^C
--- cheddar.halon.org.uk ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3079ms

root@esprimo# ping -s 1472 cheddar.halon.org.uk
PING cheddar.halon.org.uk (93.93.131.118) 1472(1500) bytes of data.

1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=1 ttl=55 time=15.3 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=2 ttl=55 time=15.3 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=3 ttl=55 time=15.3 ms
1480 bytes from cheddar.halon.org.uk (93.93.131.118): icmp_seq=4 ttl=55 time=15.2 ms
^C
--- cheddar.halon.org.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 15.193/15.280/15.343/0.061 ms
root@esprimo# ping -s 1473 -Mdo cheddar.halon.org.uk
PING cheddar.halon.org.uk (93.93.131.118) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
^C
--- cheddar.halon.org.uk ping statistics ---
6 packets transmitted, 0 received, +6 errors, 100% packet loss, time
5120ms


--
Chris Green
·

[Tony Mountifield]

In article <inismq...@mid.individual.net>,

Brian Gregory <void-invalid...@email.invalid> wrote:
> On 11/08/2021 21:55, Graham J wrote:
> > Surely the optimum is to allow packets to fragment as required?
>
> TCP can be left to fragment and will work fine but the absolute most
> efficient way is to set the MTU correctly so that you're using the
> minimum number of packets to send a given amount of data.

If TCP Path MTU Discovery is working, then there will be no need to fragment at
the IP layer, as TCP will discover the maximum packet size that does not need
fragmenting over that particular path.

> But UDP is a different matter, if you allow fragmentation and it occurs
> then there is a chance things will get garbled if the fragments happen
> to arrive at the destination in the wrong order.

That's not correct. If a UDP datagram larger than the MTU is sent, it will be
fragmented at the IP layer, which is perfectly capable of collecting all the
fragments and re-assembling them in the correct order before delivering the
datagram up to the UDP layer. I have looked at this a lot over the last year in
relation to the Jamulus program (https://jamulus.io), which uses UDP
exclusively, and relies on large datagrams being fragmented and re-assembled,
when sending long lists or servers or clients.

It is at the UDP layer itself that the order of packets is not guaranteed.

> Therefore UDP will normally be sent with DF set so that an error packet
> needs to be fragmented message comes back if you send a packets that's
> too big and you have to try again with a smaller packet.

That's what happens with path MTU discovery in TCP. With UDP, it's up to the
application whether it requests the DF bit or not. Jamulus does not.

Cheers
Tony
--
Tony Mountifield
Work: to...@softins.co.uk - http://www.softins.co.uk
Play: to...@mountifield.org - http://tony.mountifield.org

[Andy Burns]

Roger wrote:

> Read somewhere that VDSL MTU
> should be 1492 that's what I set it to.

it "should" be, if the modem can't do jumbo frames, the 1492 allowing
for the extra 8 bytes overhead, but if it can use 1508 byte frames, the
MTU can be 1500 bytes

<https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet#MTU/MRU>

[Andy Burns]

Graham J wrote:

> What was that problem?

Servers that only replied to clients using "full size" ethernet frames,
yes the servers were broken, and it's probably years since I encountered
one like it.

> I hear good reports of Ubiquiti but have not used them myself.

They were on the list at one point, but then they seemed to ditch
support for a bunch of "not very old looking" kit.

[Brian Gregory]

I don't understand. If there was some mechanism to unambiguously
determine the correct order of assorted UDP fragments that arrive in the
wrong order why has it been written into the IPv6 spec that setting DF
for UDP is compulsory.

[Tony Mountifield]

In article <inn7g5...@mid.individual.net>,

It is not "UDP fragments", it is "IP fragments". The fragmentation of IP
packets happens below the UDP layer, and may even happen in transit. It is
independent of whatever higher protocol is being carried over IP (which
could be TCP, UDP, or something else). Reassembly by the receiving host is
completed before it ever passes the complete datagram up to the UDP layer.

Setting the DF bit tells the IP protocol layer that it must not do such
fragmentation, and should instead return an error to the sender via ICMP.

> why has it been written into the IPv6 spec that setting DF
> for UDP is compulsory.

I wasn't aware of that - do you have a reference? It is of particular
interest to me at the moment, as I am working on making the Jamulus
program able to work over IPv6, and since Jamulus currently relies on
large UDP datagrams being fragmented and reassembled correctly, that
restriction, if true, would be a show-stopper.

[Tony Mountifield]

In article <sfb8bd$ij8$1...@softins.softins.co.uk>, I wrote:
> In article <inn7g5...@mid.individual.net>,
> Brian Gregory <void-invalid...@email.invalid> wrote:
> >
> > why has it been written into the IPv6 spec that setting DF
> > for UDP is compulsory.
>
> I wasn't aware of that - do you have a reference? It is of particular
> interest to me at the moment, as I am working on making the Jamulus
> program able to work over IPv6, and since Jamulus currently relies on
> large UDP datagrams being fragmented and reassembled correctly, that
> restriction, if true, would be a show-stopper.

OK, thanks for the heads-up. I found the following references:

* [Evaluating IPv4 and IPv6 packet fragmentation](https://blog.apnic.net/2016/01/28/evaluating-ipv4-and-ipv6-packet-frangmentation/)
* [Fragmenting IPv6](https://blog.apnic.net/2016/05/19/fragmenting-ipv6/)
* [Broken packets: IP fragmentation is flawed](https://blog.cloudflare.com/ip-fragmentation-is-broken/)
* https://en.wikipedia.org/wiki/IPv6_packet

So to be more precise, there is no DF bit in IPv6, and any required IP
fragmentation needs to be done by the sending host, not by any intermediate
node. This is not specific to UDP, but to all upper-layer protocols. For TCP,
Path MTU Discovery should typically remove the need for IP fragments.

I will have to do some experiments to determine whether it is indeed a
show-stopper for Jamulus-over-IPv6, or if the UDP protocol layer can handle it
for us automatically.

[Richard Tobin]

In article <sfb8bd$ij8$1...@softins.softins.co.uk>,

Tony Mountifield <to...@mountifield.org> wrote:

>> why has it been written into the IPv6 spec that setting DF
>> for UDP is compulsory.

>I wasn't aware of that - do you have a reference? It is of particular
>interest to me at the moment, as I am working on making the Jamulus
>program able to work over IPv6, and since Jamulus currently relies on
>large UDP datagrams being fragmented and reassembled correctly, that
>restriction, if true, would be a show-stopper.

As I understand it the idea is that IPv6 *routers* should never have
to fragment or reassemble packets; instead the source host uses MTU
discovery to determine the maximum packet size that can be sent, and
does any necessary fragmentation itself, with reassembly by the
destination host.

However the Wikipedia page https://en.wikipedia.org/wiki/IP_fragmentation
seems to say that IPv6 destinations are not required to be able to
reassemble packets bigger than 1500 bytes.

-- Richard

[Andy Burns]

Andy Burns wrote:

> I had to enable baby-jumbo frames on the
> DSL interface so that the IP MTU with PPPoE would still be 1500 bytes,
> same as over ethernet.
>

> do the vigor routers manage this with their internal modem?

I bought the 2865ac, it arrived set to 1492 MTU, just to confirm it does
work with 1500 MTU (in fact after upgrading to 4.3.2_BT firmware, it
offers to go up to 1520, but I haven't tried that)

Pleased with it so far, it wrings an extra few Mbps out of my line
compared to the HH5a, and it doesn't have a WiFi/CPU bottleneck like the
HH5a. Also working with my Huawei E3372s 4G stick in PPP mode.

I notice from their documentation that a 2865ax (i.e. WiFi6) version is
on the way soon ...

[grinch]

Have a look at OR sin 498 all the information you could possibly want <g>

[Andy Burns]

grinch wrote:

> Have a look at OR sin 498 all the information you could possibly want <g>

Yes, I'm aware of that bedtime reading, I don't think I'll want to sent
packets larger than I could on standard ethernet ...

[Andy Burns]

Andy Burns wrote:

> I bought the 2865ac

And today it was joined by a VAP903 mesh node, and the setup of *that*
was about the most frustrating device I have ever known, but it's now
running ok too.

[Bob Eager]

Really? I found them very smooth.

[Andy Burns]

Bob Eager wrote:

> Andy Burns wrote:
>
>> And today it was joined by a VAP903 mesh node, and the setup of *that*
>> was about the most frustrating device I have ever known
>

> Really? I found them very smooth.

I'd have done better to not watch the presentation on the 903, the
draktek staffer giving it had clearly never seen the device, the
presentation was a total mismatch from the manual, the web interface
and the android app, and the manual was equally a mismatch from the
reality of the device!

Even though the default IPs of the router (192.168.1.1) and mesh node
(192.168.1.2) are different, the mesh node would only respond to 3 pings
after a reboot before "dropping off" the LAN unless the router was
unplugged from the PoE switch, so forcing a scan found nothing.

Maybe it was a clash between router F/W version and mesh F/W version? I
did upgrade the mesh and was about to give up when I thought, why not
try it from Chrome instead of Firefox and then it worked, I doubt it was
actually related to the browser, but for now I'm not about to tear it
all down and try from scratch.

The mesh node does seem happy to talk to a pair of slightly oddball
802.11b devices, which the router would not pass traffic to/from,
despite them showing as properly associated stations, in the ARP table,
but could not be pinged or accessed on http via the router.