Ready for the next chapter?  Ok here goes.  We got all but 3 APs (of 46) up and running last night.  Turned off all the switches overnight so they don't blow plaster dust through them unnecessarily.  Turned on the switches this morning and only a handful of the APs reappeared with most showing PoE drawn on the switch port but no link light.  Every AP has two Cat6a outlets.  One for the 5Gbps ethernet and one for the console cable and both are connected.  Now for the weird bit.  If we remove the console cable connector and reboot the switch the AP comes up just fine.  Can't believe that's the solution but it seems to work.  I hope this isn't documented somewhere.  I don't really understand how just having a cable plugged in to the console port can affect the boot but it is clearly causing problems.  There is no laptop on the end of the console port it's just patched through to the wiriing closet frame. ... View more

Tried a Cat5e patch for the final drop at the AP end and that worked too.  Then it also came up ok when we reconnected the Cat6a patch.  A lot are now connecting just by reseating the AP Cat6a drop cable.  My latest theory is it's not a good idea to leave the outlets patched in a dusty building site environment for weeks before you try and plug the APs in. ... View more

It's starting to look like the installers might not have pushed the RJ45s fully home on the APs.  The Cat6a patch cords are a bit of a monster and the connector needs a bit of a wiggle before it clicks into place.  The ones we took down to stage were the ones we refitted ourselves so connected them properly.  Lesson for the day is if you want something doing properly you have to do it yourself. ... View more

Then stayed that way when I moved them back. ... View more

Don't have a PoE tester (other than confirming its there) and I don't know the length of the cable runs unfortunately but I don't think they're excessive. The strangest thing for me is that they do work fine in those same locations if they've been staged with a short patch lead already. ... View more

The cable test returns "down" when it's clearly not so I'm not sure that's functioning very well in the 9300 range. Unless the test doesn't like the Cat6a cabling somehow. ... View more

Yes they had been plugged in all day. Nothing more than an amber LED. Took a couple down an plugged them straight in to the access layer switch and they upgraded and came on line straight away. ... View more

Thanks.  I did wonder as I couldn't see any reference to it anywhere. 👍 ... View more

I think that's for a splash page?  I'm talking about the "Enterprise with Meraki Cloud Authentication".     ... View more

Testing was with a pair of MR42s by the way. ... View more

Hi, ok I think I may finally have answered this one after many hours testing.  I have tested four clients from scratch with a factory reset of the APs in between each test and using a fresh SSID profile on each client.   Apple iPad Roams between APs with a “reassociation frame” DHCP is updated on roaming LAN connection is maintained   Motorola Moto G6 Roams between APs with a “reassociation frame” DHCP is updated on roaming LAN connection is maintained   Netally Aircheck G2 Roams between APs with a “reassociation frame” DHCP does not update on roaming LAN connection is then blocked from wired to wireless i.e. I could see the ICMP echo from the wireless client on the wired capture and the ICMP reply from the target but this is NOT passed on to the client by the AP   Panasonic FZ-N1 Roams between APs with a fresh “association frame” instead of a reassociation frame. DHCP does not update on roaming LAN connection blocked from wired to wireless completely i.e. I couldn’t see the ICMP echo from the wireless client on the wired capture   So from this I think we can say that mandatory DHCP can be enabled but it is reliant on certain client behaviours.  e.g. roaming with a reassociation frame (which then permits wireless->wired traffic) and also refreshing DHCP when the roam is complete (which then permits wired->wireless traffic). ... View more

Good point about the AP models. I had read that but forgot it soon after so thanks for the memory jog.  I've got a customer who's got a box of MR42s they're not using at the moment while their building is being refurbished and they're upgrading to MR55s when it's done anyway.  I'll be passing close to their site tomorrow so I think it might be a chance to pop in and borrow a couple.  ... View more

Surely I can't be the first person to turn this feature on? ... View more

The production APs are MR33 and MR74. There's no correlation on roaming between similar or different models either. It does the same in my lab which is an MR32 and an MR24. I'm on my third support engineer now and no-one seems to be able to answer in any detail how it's supposed to work. 😒 ... View more

    No ICMP until it roams back to the original AP! ... View more

I've got packet captures from the air and on the LAN.  My tester is pinging the gateway.  As soon as the roam occurs the ICMP packets are not bridged to the LAN by the "roamed to" AP.  And there's no DHCP traffic either so Support seem to have got that one wrong. ... View more

Hi, the SSID is set in bridge mode to the same VLAN on every AP.  It's Meraki Support who have told me that the DHCP should refresh on every roam and like you I'm sure that's not correct.   The bit I don't understand is this:  If manadatory DHCP is enabled on an SSID, how does the "roamed to" AP know that the DHCP exchange happened on the "roamed from" AP?  Either the first AP has to tell all the others about a new client and the fact it has witnessed the DHCP exchange OR the "roamed to" AP has to query the dashboard or other APs about whether the mobile client is good to join from a DHCP perspective.  Either way, that's the bit which seems to be failing and support can't tell me which of these it is!   If I disable mandatory DHCP then it works fine.   If I disconnect and then reconnect to the "roamed to" AP then that works as well.  And from that point on I can roam back to it so it's obviously caching the DHCP status of the client.   I've got another call with support on Friday this week so they can collect yet more logs.  As least I've managed to reproduce it in my lab now and not on the site which is 2.5 hours drive away! 🤣 ... View more