Option 132 for voice VLAN doen’t work on Microtik & Grandstream GXP1625

RouterOS General
1

Such a problem, it is necessary to put phones in a separate vlan. it is created “vid 20” It is bound to the bridge and has a separate dhcp with address pool, lldp and cdp are turned off on the phone and microt, etc. … On the main DHCP I set 132 option s’20’. and nothing, on the logs dhcp can see that the phone requests this option and DHCP server gives it to the phone, but nothing happens and the phone receives IP from the main network.

BUT! if you manually write 802.1Q/VLAN Tag 20 in the phone, everything works fine, the phone enters the 20th vlan and gets the necessary iP.

2

Why is it needed to define option 132 on the DHCP? What are you trying to achieve - untagging, tagging, something else? An export of the config would also be greatly appreciated:

/export file=anynameyouwish (minus sensitive info like serial numbers, public IPs, passwords, etc.)

3

Maybe the type is wrong in the option you sending string and the phone maybe needs a int ?

You maybe have like a example of isc dhcp server config file to share and we can convert that to mikrotik dhcp option code.

4

Maybe s’20’ is not the “right” format, see:

The phones might want It as numeric value or in hex (as opposed to decimal).

5

in option value try insert s’20’, ’20’, s’0x14’, ’0x14’, 0x14

and nothing…

Screenshot_3
Screenshot_31179×834 103 KB

Screenshot_4
Screenshot_41222×821 43.3 KB

mikrotik dhcp answer to phone with value s’20’

Screenshot_2
Screenshot_21746×883 362 KB

6

Yes, I also think that the phone does not understand the value of option 132 received from the server.

7

try to remove prefix “s” just put “20” we don’t know it might work :slight_smile: i’m just thinking aloud

9

I tried s’20’, ’20’, s’0x14’, ’0x14’, 0x14

10

RTFM :slight_smile:

https://www.grandstream.com/hubfs/Product_Documentation/DHCP_Options_Guide_Linux.pdf
See page: 17
The 132 options should be send with string=text not value like hex or decimal int.
And when I read the page 2, it says your device(GXP16XX) is not supporting options 132, maybe this is not related now, maybe with newer firmware, I don’t know.

11

On the other thread the working string (for VLAN30) was:

/ip dhcp-server option
add code=132 name=option132 value="s'0x1e'"

So you should try for VLAN20:

/ip dhcp-server option
add code=132 name=option132 value="s'0x14'"

enclosed in double quotes, the OP there stated that also without the s’ it worked on Grandstream, but maybe that depends on the model.

13

No, this is an old manual. new firmware for 16XX supports this function. here is a screenshot from the GXP16xx manual.

изображение
изображение1075×763 138 KB

14

I read the docs as saying both 132 and 133 have to be present for the vlan setting to be applied… Debatable but worth a try?

15

изображение
изображение1413×604 22.6 KB

here is a description of this option from help.mikrotik.com. According to the description mikrotik ALWAYS sends hex.
And the phone doesn’t like it

16

I tried, but nothing happens. the phone apparently can not properly recognize what the mikrotik sent.

17

Based on your previous Wireshark captuire, what is sent is:
Option 132 0x3230 (string “20”)
Option 133 0x00 (string “\nul”)

I would suggest sending 0x36 for 133. If the phone expects a ascii string for 132, it seems to me logical that the same would be expected for 133.

18

send this

изображение
изображение707×816 12.4 KB

Nothing happens ( What values I have not tried to enter . I guess the phone does not understand (
If possible, I will try to connect a phone of another manufacturer and see the result.

19

I have no experience with your phone or any of its relatives, but what your screenshot shows does not support your conclusion.

What it shows is that while you have (in my mind) correctly configured both option132 and option133, then chose to send only option132 (twice? what is that even supposed to accomplish?)

20

No, not twice, option 133 was sent there, I just took a screenshot early)).

21

Out of ideas, then. I tried… :frowning:

22

What is DHCP Option 132?

  • RFC Standard: Option 132 is defined in RFC 3584 and RFC 3679 as:

“Ethernet VLAN ID (132): 802.1Q VLAN Identifier (integer value from 0 to 4095)”

  • So, This means it is a 4-byte integer (in practice, often 1 or 2 bytes are used depending on the DHCP server implementation) that directly represents the VLAN ID.
  • If Grandstream follow the RFC.

So if you get this in wireshark it’s wrong it sending “20” as string.
echo -n “20” | hexdump
0000000 3032
0000002

So maybe you have to send 4 bytes, 0x00000014