Open rajkosto opened 1 year ago
OMCI_VEIP_SLOT_ID DOES control the veip entityID ! but the description is woefully incomplete.
first off, the value should be set to the MSB of the wanted entityId, so for 0x0e01 it should be 0x0e or 14 (flash set will only accept decimal)
second, the feature that actually applies the hack is not enabled by default, to enable it you must set bit 0x100 in OMCI_CUSTOM_ME to enable the cf_apply_customized_veip_slot_id
feature, the default value in SFU firmwares for OMCI_CUSTOM_ME is 65536, so set it to 65792 to enable the feature.
( for more description of various features, see https://github.com/Anime4000/RTL960x/issues/41#issuecomment-1320564871 )
before:
# omcicli mib get 329
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VEIP
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityId: 0x0601
AdminState: 1
OperState: 1
InterDomainName: 0x00000000000000000000000000000000000000000000000000
TcpUdpPtr: 0x0000
IansAssignPort: 0
CustomizedSlotId: 0xff
=================================
after:
# omcicli mib get 329
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VEIP
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityId: 0x0e01
AdminState: 1
OperState: 1
InterDomainName: 0x00000000000000000000000000000000000000000000000000
TcpUdpPtr: 0x0000
IansAssignPort: 0
CustomizedSlotId: 0x0e
=================================
great finding! how you get VEIP from stock ONT? mine just from Huawei XML file
omci log opened in wireshark and look for veip
Hi @rajkosto, your finding could be related with "ODI firmware ignore mib 171 VLAN remap"?
In a working ODI stick with IGD 220916 firmware those are the values:
OMCI_CUSTOM_BDP="136" OMCI_CUSTOM_RDP="0" OMCI_CUSTOM_MCAS="0" OMCI_CUSTOM_ME="32832" OMCI_VEIP_SLOT_ID="255"
there is something to test in 220923 SFU firmware to check if mib 171 VLAN can be remapped as IGD firmware?
You are able to use treated VLAN in IGD firmware ? Which one ? In both IGD and SFU firmware, with VEIP entityid unchanged (0x601) or changed (0xe01), i HAVE to use the "weird" untreated VLAN and not the normal one my ISP ONT uses, in IGD both in bridged mode and even if the stick itself is doing PPP via wan configuration, i cannot use treated vlan id on the other side of the bridge or inside the webgui, only weird vlan (obviously if i check the port mapping in IGD or use the PVID option in SFU firmware, then its no longer tagged but untagged, but i still have to enter the weird VLAN id there, not the normal one). the values you posted are the default for IGD firmware, as i explained in my features gist. you can enable the VEIP entityId change in IGD by setting OMCI_CUSTOM_ME to 32832 and OMCI_VEIP_SLOT_ID to your appropriate one
Not an expert like you but my problem seems to be similar, if you want to check more https://github.com/Anime4000/RTL960x/issues/90 In my case case ISP VLAN is 835, Treatment Inner 3310, IGD firmware is working with VLAN 835, SFU with VLAN 3310. I can do some tests with latest SFU firmware.
My problem is that treatment is not working with any firmware, IGD or SFU If you create wan config in IGD firmware can you see it link/get ip of PPPoE/DHCP with the treated (IGD) VLAN id ? or you have to use raw vlan id there too ?
Never tried to get PPPoE to the ODI SFP, always to the router but confident that will work
the IGD firmware changes DEVICE_TYPE to 0 (bridge) if you have no wan connections defined in it, otherwise DEVICE_TYPE is 1 (router)... you cant be sure it works on the device if it only works with no WAN connections defined
couple of tests with SFU firmware;
EntityId: 0xff01 AdminState: 1 OperState: 1 InterDomainName: 0x00000000000000000000000000000000000000000000000000 TcpUdpPtr: 0x0000 IansAssignPort: 0 CustomizedSlotId: 0xff `
try the one i suggested and seen in both Nokia and Huawei ONU, OMCI_VEIP_SLOT_ID = 14
OMCI_WAN_QOS_QUEUE_NUM what it means?
OMCI_VEIP_SLOT_ID = 14
No changes here
https://github.com/Anime4000/RTL960x/blob/main/Docs/FLASH_GETSET_INFO.md#omci_veip_slot_id here it implies that it controls the VEIP entityId, and that you should set it to 0x0E01 if that's the entityId of your original ONU, but when this value is read it is read as an uint8 so it can only be 0-255, and it also does NOT control the VEIP entityId, which is always 0x0601 (instead it controls a custom option inside the veip MIB data, which we have no idea what it does, as its not part of standard VEIP mib)