VOIP OBI202 Issue with SWOS?

Just getting my RG260GS working consistently with 2.9 thus far.
Right now connected to eth3 on my RG450Gx4 (trunk type port (vlans 30 and 70 on the bridge)
Switch
eth1 TRUNK from router,
eth2 same settings as eth1 goes to an unmanaged switch feeding several devices NO ISSUES
eth3 setup to vlan 70 for vidcamhub (vidcam has no capacity for tagging etc) and it gets a VLANIP no problem and works transparently no different from non-vlan use) NO ISSUES
eth4 setup same as vlan 70 (for OBI202 modem) HOWEVER, the phone connection light light never stays lit and although there is a dial tone, unable to call in but people can reach the Provider (as I am able to leave a message and the message is then sent automatically to my email). Outgoing calls dont work. ex. to my cell phone says unable to reach provider (although another family members cell phone can call my cell phone)

I am wondering why in one case Vidcamhub, I can change over to vlans without issue, but in the case of the VOIP modem, its not working.
Of interesting note my router obviously received a connection attempt as it offers a DHCP vlan 70 Ip address to the modem but obviously not accepted.
I triple checked the big four ip address, pool, dhcp-server, dhcp-server network and all are good.
The oBi202 works great in normal LAN.
I thought it would be better security to hive off the VOIP away from the normal house lan for security purposes.

I think my SwOS setup may need tweaking.

Okay I reviewed all my settings.
I now have trunk port1, port 2 is going to unmanaged switch, port 3 vlanxx going to vidcam hub, port4 vlanyy to voip modem, and port5 vlanzz going to NAS.

I have configured ports 3,4,5 identically only difference being vlan number.
Ports 3 and 5 work great but port 4 attached to the obi202 still no joy! :frowning:
I can see that the router attempted to assign it a proper vlan IP but not accepted.

I plug the modem into a basic lan port on the unmanaged switch and it gets a LANIP and works great.
I am perplexed why sticking this modem on a vlan is effing up the deal.

your port 4 [obi202] is untagged and a member of which tagged port?

Hi mozerd, SwOS is very unconventional…
Port 1 - comes from router - Think of this as a trunk port.
Port 2 - goes to unmanaged switch to various devices (like a trunk port but not carrying any vlans, other than default)
Port 3 - goes to Netgear ARLO Hub using vlan xx (access type port)
Port 4 - goes to voip modem using vlan yy (access type port)
Port 5- goes to NAS box using vlan zz (access type port)
Note: None of the devices on ports 3,4,5 vlan generate or recognize vlan tags.

VLAN Settings
Ingress
VLAN Mode:
Port 1 - Enabled Port 2 - Enabled Port 3 - Strict Port 4 - Strict Port 5 - Strict
VLAN Receive: All port set to “any”
Default VLAN ID:
Port 1 - 1 Port 2 - 1 Port 3 - xx Port 4 - yy Port 5 - zz
Force Vlan ID: none selected

Egress
VLAN HEADER:
Port 1 - Leave as is Port 2 - Leave as is Port 3 - Always strip Port 4 - Always strip Port 5 - Always strip

VLANS Settings
…Port1 Port2 Port3 Port4 Port5
vlan1…LaIs LaIs NotaM NotaM NotaM
vlanxx…LaIs NotaM LaIs NotaM NotaM
vlanyy…LaIs NotaM NotaM LaIs NotaM
vlanzz…LaIs NotaM NotaM NotaM LaIs

Leave as is = LaIs, Not a Member = NotaM

With the setup above, the devices on ports 3,5 work great but the VOIP modem attached to port 4 does not work.
As soon as I attach the modem to the lan network (to the unmanaged switch for example) it works right away.

I’m not SwOS user, so just guessing:

  • on true access ports (port3, port4 and port5) the egress VLAN header setting should be set to “always strip”. As you wrote: the equipment there has no notion of VLANs, but might choke on unexpected ethertype value … it might expect to see 0x0800 (IPv4) or 0x86DD (IPv6), but chokes on received 0x8100 (VLAN C-tag) as it doesn’t know how to strip VLAN (what?) tag to get to supported frame type.
  • on the very same ports the ingress property “VLAN Receive” correct setting would be “only-untagged” as it is not expected that equipment will tag frames (if some tagged frame arrives, the this might indicate foul play).

Obviously equipment hooked to port3 and port5 mangles packets the way (desktop) windows does: strips VLAN headers before anybody notices anything strange so things appear to work correctly even if switch is (slightly) mis-configured.

Can you please post pictures of your SWOS TABS as follows:

  1. VLAN menu
  2. VLANs menu

Your response to my question is far too complicated for me :slight_smile: I like pictures better.
The following pictures is what I am after:
swosvlan2.png
swosvlans.png
swosvlan.png

Okay mkx, will try that out later today, easy enough to test without impacting the rest of the network.

*********I think what you are saying is that there may be a case that packets coming from the Voip Modem may have some tagged frames in the mix (originating) and these of course in my setup would get stripped due to the STRICT ingress setting.

Enabled: Drop packets with VLAN tag ID that is not present in VLAN table. Packets without VLAN tag are treat as tagged packets with Default VLAN ID
Strict: Same as enable, but also checks VLAN support for inbound interface (drop packets with VLAN tag ID and ingress port that are not present in VLAN table)

Enabled: Means, any packet arriving (ingress at that port) with a vlan tag not noted anywhere on the switch will be dropped. Packets without any vlan tags will be treated as tagged packets with default vlanID:1 So if any devices have some packets with a vlan tag non existant anywhere on the switch they are dropped.
Strict: Means take that same view but narrow it down from (anywhere on the switch) to that particular ingress port.

So if we had vlantags 2,3,4,5,6 on the switch and only vlan 4 identified for port 4
Then ENABLE would allow 2,3,4,5,6 to be passed through ingressed on port 4, whereas STRICT would stop/drop 2,3,5,6.

In theory all vlan1 default packets would get through except that we have give the default IDs to the (access ports) such that
Switch will treat both untagged and “Default VLAN ID” tagged ingress packets as they are tagged with this VLAN ID. It is also used to untag egress traffic if packet’s VLAN ID matches “Default VLAN ID”. Acts kinda like pVID.

********** All to say is that if the VOIP modem was putting out some packets with vlan tags not on the SwOS table they would be dropped by strict for sure and probably enable and thus the communication between devices is sufficiently corrupted to not permit the connectivity communication desired/required.

Thus I concur that ingress is the issue!
However, your take is that to prevent the tagged packets from the VOIP modem to even reach the switch, at the ingress point you deny entry to any tagged packets thus the switch will only see untagged packets or vlanid1 packets and TAG them all with PVIDyy of that port.

I fail to see how this will help in that if vlan tagged packets were dropped by my strict ingress setting and thus incomplete packet sets causes the issue, we will see the same effect by your method. Packets will not be allowed into the port and thus we will have a corrupted stream.

Okay truth be told, this is all a big guess on my part. Just trying to make sense of the logic.
I think it comes down to me not understanding what you mean about mangled packets coming from the device (originating from the device).

Mozerd, you are looking at the wrong user manual LOL.
https://wiki.mikrotik.com/wiki/SwOS/CSS106

Is the correct one. Once you hae the correct UG in front of you,
my elegant non-picture post will be much clearer (if you can write scripts, this is not complicated)

By the way I did open up the Obi202, when working on the LAN and it does get a proper 192.168.x.xx for both the LANIP from my router perspective, and for the modem for its WANIP address. Internally it seems to assign a LAN address is the 192.168.10.x but thats it for settings. I dont see any vlan settings per se.
It must be strictly for an internal VOIP server to obi client communication.

Sorry about that … But you can still post pictures of your vlan and vlans tabs … Are you using swOS version 2.9? IMO your switch is not configured properly so once I see the pics all secrets will be revealed :slight_smile:

There is absolutely no need to make ANY changes of whatsoever nature on your Obi202. The problem lies with the switch and your Router.
The following Link is IMO 100% better than the one you relied on above:
https://wiki.mikrotik.com/wiki/SwOS/Router-On-A-Stick

Good to know on the Obi, I figured as much.
By the way the link you gave is okay but it needs to have an updated first diagram for VLAN tab (new 260GS), and I note it does for the VLANS tab.
What is missing on the first diagram is a ROW after VLAN Mode and before Default VLAN ID, entitled VLAN RECEIVE, which Mkx noted

All other selections that I see on the two diagrams VLAN (not quite the right version) and VLANS (the second corrrect version) match up with my settings (albeit, missing the item noted above).
The only difference I can see is that in VLAN, under EGRESS, the VLAN HEADER entry for port1 states “ADD IF MISSING” whereas I have “Leave As Is”. I see no reason why the trunk port on the SwOS switch should add any tags to traffic going to the router so in my view that is an error on the config shown on that link. Strip is appropriate for packets egressing the access ports back to the devices as shown.

I used the other link which after careful perusing is also full of errors… where is the QC???
https://wiki.mikrotik.com/wiki/SwOS/SWOS-802.1Q-TrunkTwoSwitches

as I noted here but MT has failed to yet respond!!!
http://forum.mikrotik.com/t/rb260gs-software-manual-example-errors-maybe/127493/1

Okay the only change I made to the switch was to change the VLAN Receive (ingress setting) to untagged only for 3,4,5 ports.
My vidcam and NAS continued to work fine with this change.
Unfortunately I am still not having success with port4 the Obi2 voip modem which refuses to get a good connection via the VLAN route.
I plug it back into the LAN side and presto it works without a hitch.
Going back to double check all my vlan settings for this vlan.
Interface vlan - check
Interface member list - check
Bridge ports - check
Bridge vlans - check
Ip address - check
ip dhcp pool - check
ip dhcp-server - check
ip dhcp-server network check
ip firewall list…

.OOPSY.


I had WAN selected correctly but mistakenly selected in-interface-list, vice OUT-interface-list.
Now off to see if that is the magic bullet.
Confirmed up and running without a hitch!

Very glad that YOU found the .OOPSY. … rock on !!! :laughing: