My Core One is connected (bridged) to a Huawei Fiber system. The default config in the ISP supplied ONT uses VLAN’s and DHCP. My replacement ONT’s (Ubiquiti) will happily connect this way too, configured as the end router device with a VLAN.
But the Peplink refuses to connect up in bridge mode using a VLAN value. It connects OK without VLAN value, but not with a VLAN set.
I have captured the WAN1 packets via the support page, and can see the DHCP Discover / Offer packets all there and going back and forth. But the Peplink refuses to accept to Offer (which is identical with or without VLAN setting). In VLAN mode the Peplink prefixes the 4 byte 802.1q vlan header to the request, but the dhcp offer packet has no vlan ID header. Is that the issue? Is the Peplink refusing to accept the DHCP offer because the vlan id is missing?
Can you please share the packet capture and the WAN interface setting screenshots here ? It’s not standard if WAN running using VLAN but receiving packet that missing the VLAN fields.
Its too many screen shots to show so, here are the filtered .pcap files, so you can load them and inspect.
In both cases, I release the the current DHCP binding, then attempt a reconnect. (this is required as the Peplink will not log packets starting with a non-connected WAN).
One file with VLAN10, and the other without VLAN. Identical except in VLAN10 file the Peplink refuses to use the Offer provided.
Edit by SitLoongs : removed the packet capture download link.
The issue is related to the VLAN WAN that the uplink device sending DHCP reply without the VLAN tag. This is not a expected/standard behavior that the uplink router is replying the DHCP request without the VLAN tag for the VLAN WAN.
This is not the firmware issue and cannot be fix based on the non standard behavior. If the VLAN WAN behavior changed based on the non standard behavior, it will break the other feature such as Virtual WAN and other.
Your answer is not acceptable, or realistic. Allow me to elaborate.
You have many devices that connect with cellular systems, but as we both know, the standards are often a little inconsistent here too. But Peplink manages to make exceptions and correction and adjustments in its code base, for different cellular systems, because if you did not, Peplink would look stupid and not sell enough devices.
So you make exceptions for standards in cellular systems in the interests of “just make it work”, but you refuse to do the same about a DHCP request within a VLAN, for NO valid reason.
There is no written standard that says DHCP conversations has to be within the same VLAN - you are just interpreting an unwritten rule, and making it up. Even more absurd, is that your device is the ONLY one present on the network node, and the only device capable of requesting and creating address on the node, so no other device is affected and the only device that suffers, is yours.
The suggested “fix” someone made was to insert another device into the node, thereby doing the job that the Peplink is incapable of doing itself.
Your refusal to fix your connection failures, is both hypocritical and ludicrous.
To further highlight the invalid position that Peplink has taken on this issue, I give you: ARP.
When a new layer 2 connection is made (plug in the wire), ARP is the first protocol to establish who’s who. Now with a Peplink with a preset WAN with Static IP and VLAN, the Peplink tries to do ARP though 802.1Q VLAN. Of course no device on the other end is going to engage is such invalid VLAN nonsense at this time. The other end ignores the VLAN part and responds with a valid ARP response, which the Peplink ignores, and repeats the request and ignores the answer, over and over and…
ARP is a layer 2 protocol, while VLAN is an addition and not part of the standard for ARP.
So thanks to Peplink’s invalid use of insisting VLAN take precedence over everything (including ARP), the Peplink cannot even establish the basics of layer 3 settings.
I remind you… other devices can connect in all these same places and same conditions… therefore, please fix you bug Peplink.