I’ve found an issue with this feature. We use separate management and customer data VLANs which I imagine is part of this issue.
169.254.1.1 always available untagged on the ethernet port has been extremely nice on the ePMP line. I figured it would work exactly the same on PMP450. Well, once the SM comes in session and VLAN goes active, trying to load the GUI via default IP is painfully slow. Pinging my SM, I can get replies with 1500 bytes while it’s scanning. After the session comes up, I have to back off the packet size to 1496, which makes sense because VLAN = 4 bytes.
Would be wonderful if this small issue could be fixed. Our field techs have complained that they can’t access the SM on the default IP after it goes in session and I never really bothered to dig into it until now.
do you check the box to enable it? defaultly it is disabled when the rf session comes up.
{
“userParameters”: {
“networkConfig”: {
“defaultIPAccessEnable”: 1,
}
}
}
It is acting the same way the epmp1000 radios did until 3.5.6. Its just a chabge in the default factory config, but it is so useful when you need to connect to a bridged or routed SM and not be part of the management vlan (which is available on the SM ethernet port when in session, just have a vlan aware laptop and enable vlan to the correct vlan id)
Default LAN1 IP on SM = enabled by our standard config.
With that on, 169.254.1.1 is always on the SM’s ethernet interface, which is what I want.
When the SM is out of session, scanning, etc. then I can ping it with a full 1500 byte packet. GUI loads right up. Once it gains session and gets VLAN enabled by the AP, that’s when I have to back off the packet size by 4 bytes and the GUI then barely responds. The downstream device MTU = 1500, but the SM while in session can only receive up to 1496 bytes. Which is why the GUI is very sluggish or doesn’t respond at all. MTU mismatch basically.
This works perfectly fine on ePMP. I know, different products.
ahh, sometimes im illiterate. that is an odd duck. is this different vlids per ap, or the same ID across the board, like maybe try a different VLID and see if it happens to conflict with the magic mechanism they have in place for the default IP to be present?
No, I understood you, just saying that this is what the epmp radios did until a change in firmware was made.
You could have a radio that needs to be reflashed or replaced. This use to happen with the Canopy radios back in the day. Then again that software was pretty bare in features too compaired to what you have now.
I would check another SM on that AP and see if it is the one SM or it may be the AP itself. Sounds like you have all the right settings enabled.
