EDIT : I was wrong in the following post. The real need is to be able to mark outgoing DHCP client packets with a DSCP value. The reason stays the same, the isp Orange need it to answer DHCP requests.

And then, since Orange use a VLAN, we need a DSCP=>CoS mapping which would work for dhcp packets going out a vlan interface.

Original post :

Hi,

In France, the number one ISP, Orange, need to receive DHCP Request with a COS of 6, otherwise, no answer is given.

This is a very big problem for the french users of RouterOS.Since DHCP use raw socket, you can't change the priority with a mangle queue. I've read some ideas about setting up a bridge, but using bridge firewall, bridge nat, etc, is not a real solution.

Before they put the CoS obligation, is was working just by creating a vlan832 and a dhcp client with some specific options like this :

/interface vlan
add interface=ether8 name=vlan832-orange vlan-id=832 mtu=1500 arp=enabled use-service-tag=no


/ip dhcp-client option
add code=77 name=userclass value=0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833
add code=90 name=authsend value=0x0000000000000000000000006674692fmylogininhexa
add code=60 name=vendor-class-identifier value=0x736167656d

Now, without CoS, no response.



Some wireshark captures (Livebox is the Orange router) :

DHCP Discover (Livebox -> Orange, vlan 832, CoS 6)

Frame 81: 380 bytes on wire (3040 bits), 380 bytes captured (3040 bits) on interface 0
Ethernet II, Src: Sagemcom_xx:xx:xx (00:37:b7:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 6, CFI: 0, ID: 832
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0cc032e9
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: Sagemcom_xx:xx:xx (00:37:b7:xx:xx:xx)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (55) Parameter Request List
Length: 11
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (51) IP Address Lease Time
Parameter Request List Item: (58) Renewal Time Value
Parameter Request List Item: (59) Rebinding Time Value
Parameter Request List Item: (90) Authentication
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (120) SIP Servers
Option: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
Option: (90) Authentication
Length: 22
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: fti/xxxxxx
Option: (255) End
Option End: 255



DHCP Offer (Orange -> Livebox, vlan 832, CoS 7)

Frame 82: 426 bytes on wire (3408 bits), 426 bytes captured (3408 bits) on interface 0
Ethernet II, Src: Alcatel-_dc:fc:eb (84:26:2b:dc:fc:eb), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 7, CFI: 0, ID: 832
Internet Protocol Version 4, Src: 86.245.184.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67 (67), Dst Port: 68 (68)
Bootstrap Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0cc032e9
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 86.245.xxx.xxx
Next server IP address: 80.10.247.176
Relay agent IP address: 80.10.237.69
Client MAC address: Sagemcom_xx:xx:xx (00:37:b7:xx:xx:xx)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.176
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (86400s) 1 day
Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.248.0
Option: (3) Router
Length: 4
Router: 86.245.184.1
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 80.10.246.136
Domain Name Server: 81.253.149.6
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (69200s) 19 hours, 13 minutes, 20 seconds
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (43200s) 12 hours
Option: (28) Broadcast Address
Length: 4
Broadcast Address: 86.245.191.255
Option: (15) Domain Name
Length: 9
Domain Name: orange.fr
Option: (120) SIP Servers
Length: 42
SIP Server Encoding: Fully Qualified Domain Name (0)
SIP Server Name: sbct3g.PUT.access.orange-multimedia.net
Option: (90) Authentication
Length: 27
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: dhcpliveboxfr250
Option: (255) End
Option End: 255


DHCP Request (Livebox -> Orange, vlan 832, CoS 6)


Frame 83: 392 bytes on wire (3136 bits), 392 bytes captured (3136 bits) on interface 0
Ethernet II, Src: Sagemcom_xx:xx:xx (00:37:b7:xx:xx:xx), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 6, CFI: 0, ID: 832
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0cc032e9
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: Sagemcom_xx:xx:xx (00:37:b7:xx:xx:xx)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 86.245.xxx.xxxx
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.176
Option: (55) Parameter Request List
Length: 11
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (51) IP Address Lease Time
Parameter Request List Item: (58) Renewal Time Value
Parameter Request List Item: (59) Rebinding Time Value
Parameter Request List Item: (90) Authentication
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (120) SIP Servers
Option: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
Option: (90) Authentication
Length: 22
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: fti/xxxxxxx
Option: (255) End
Option End: 255

DHCP ACK (Orange -> Livebox, vlan 832, CoS 7)


Frame 84: 426 bytes on wire (3408 bits), 426 bytes captured (3408 bits) on interface 0
Ethernet II, Src: Alcatel-_dc:fc:eb (84:26:2b:dc:fc:eb), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 7, CFI: 0, ID: 832
Internet Protocol Version 4, Src: 86.245.184.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67 (67), Dst Port: 68 (68)
Bootstrap Protocol (ACK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0cc032e9
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 86.245.xxx.xxx
Next server IP address: 80.10.247.176
Relay agent IP address: 80.10.237.69
Client MAC address: Sagemcom_xx:xx:xx (00:37:b7:xx:xx:xx)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (ACK)
Length: 1
DHCP: ACK (5)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.176
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (86400s) 1 day
Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.248.0
Option: (3) Router
Length: 4
Router: 86.245.184.1
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 80.10.246.136
Domain Name Server: 81.253.149.6
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (69200s) 19 hours, 13 minutes, 20 seconds
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (43200s) 12 hours
Option: (28) Broadcast Address
Length: 4
Broadcast Address: 86.245.191.255
Option: (15) Domain Name
Length: 9
Domain Name: orange.fr
Option: (120) SIP Servers
Length: 42
SIP Server Encoding: Fully Qualified Domain Name (0)
SIP Server Name: sbct3g.PUT.access.orange-multimedia.net
Option: (90) Authentication
Length: 27
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: dhcpliveboxfr250
Option: (255) End
Option End: 255


Thx a Lot

For the record, an ERL user (Ubiquity / EdgeOS) patched the open source dhclient by adding this 2 lines :

int val = 6;
setsockopt(sock, SOL_SOCKET, SO_PRIORITY, &val, sizeof (val));


(sock being used by raw sockets)

I know RouteurOS is different, but...

I think the reason there's no option for COS on dhcp packets is because strictly speaking, there's no such thing.

COS is a field in 802.1q vlan headers, which really don't have anything to do with the payload of the frames - if the payload is IP as opposed to Appletalk, NetBeui, NetBios, IPX, IPv6, ARP, etc), then many switches have rules to inspect IP TOS/DSCP values and map them onto the 8 COS priority values.

Obviously Orange is requiring vlan-tagged traffic from their customers' devices, so that means there can be a COS value - but from the perspective of an IP service, there's no way to say "Set COS" as such because there's no COS parameter in IP - only TOS/DSCP/IP Priority (it's the IP priority that's closest to COS, but it's not the same thing either). So an IP service (like DHCP could in fact set the TOS value of outbound packets, but only a layer2 function (such as a switch, an 802.1q vlan interface, bridge, router QoS policy, etc.) can set the COS field.

I know we're working on this in another thread so I'm going to end this here, but since this thread is a little different in tone, I felt I should chime in with a down-and-dirty explanation of why there isn't a simple "set the COS value" option for IP services. Of course, the user interface can present such a blank and then do the necessary setup under the hood, but I think Mikrotik's design is intended to be as close to raw access to packets and frames as possible, which means that you kind of have to wire it up yourself with the tools at hand. I do think it would be nice if the dhcp process didn't do an end-run around the mangle table, though.

Still, solutions exists in other products The solution for EdgeOS was done by a amateur who has a Orange access too, he compiled the new dhclient himself...

generally its much better to make ISP respect standards instead.
relying on 802.1x-2010 instead, for example(and MacSec, PortSec and other stuff in it), instead.

generally its much better to make ISP respect standards instead.
relying on 802.1x-2010 instead, for example(and MacSec, PortSec and other stuff in it), instead.

I agree, but they are the number one ISP in France so they sort of do what they want But anyway, other *nux/nix based solution have a workaround. Not RouterOS yet.

Honestly, I don't want to buy an ERL under EdgeOS just for that :/

Not RouterOS yet.

Especially for programmers confirmed that should not be too complicated to do so

(Sorry for my English)

I think the reason there's no option for COS on dhcp packets is because strictly speaking, there's no such thing.

COS is a field in 802.1q vlan headers, which really don't have anything to do with the payload of the frames - if the payload is IP as opposed to Appletalk, NetBeui, NetBios, IPX, IPv6, ARP, etc), then many switches have rules to inspect IP TOS/DSCP values and map them onto the 8 COS priority values.

Obviously Orange is requiring vlan-tagged traffic from their customers' devices, so that means there can be a COS value - but from the perspective of an IP service, there's no way to say "Set COS" as such because there's no COS parameter in IP - only TOS/DSCP/IP Priority (it's the IP priority that's closest to COS, but it's not the same thing either). So an IP service (like DHCP could in fact set the TOS value of outbound packets, but only a layer2 function (such as a switch, an 802.1q vlan interface, bridge, router QoS policy, etc.) can set the COS field.

That is true when you look at things from a packet content perspective, but note that a service accesses the network
not with only packet content, but has also extra channels to push parameters along with that.
The DHCP client uses a socket, and as shown above it can set an option for the socket that any IP packet it sends over that socket will be queued with a certain priority value. The VLAN layer will then put this priority value in the 802.1q header.

For example, in a mangle rule you can set this priority value (to a fixed value, or to a value generated from TOS/DSCP).
That also ends up in this same field.

So I don not agree that there can be no option in the DHCP client to (try to) set the COS field. It could have the form of a "priority" field that is just passed to that setsockopt in the code, and it will work as long as the final output is via a VLAN.
Similarly, there could be a "DSCP" field that gets copied into the IP header should someone require that.
(I saw some other discussion where someone required that for SNMP, maybe fields like this could be added to all services and clients)

Well I really hope it will be implemented somehow. For now I switched to PPPoE, but there is some overhead, and, soon Orange will only allow DHCP and I'll be screwed...

- I corrected the first post and the subject -

+1, IMHO, DHCP traffic should probably be marked as high-priority regardless of (kinda stupid) ISP requirement.

Some *nix dhcp clients work at the ip level, not raw socket level. It could be one solution if I'm not mistaken.

I would suggest that, at the same time that you try to convince MikroTik that they should support this DSCP setting,
you try to convince your ISP that they should not perform needless checking.
Fine if they give out modems that send DHCP at higher priority, but why would you check in the server that this has
been done? That has no advantage, as far as I can see... (other than trying to lockout foreign equipment)

I would suggest that, at the same time that you try to convince MikroTik that they should support this DSCP setting,
you try to convince your ISP that they should not perform needless checking.
Fine if they give out modems that send DHCP at higher priority, but why would you check in the server that this has
been done? That has no advantage, as far as I can see... (other than trying to lockout foreign equipment)

Well, I don't think I can convince Orange to change their infrastructure
But I agree with you on principle.

I would suggest that, at the same time that you try to convince MikroTik that they should support this DSCP setting,
you try to convince your ISP that they should not perform needless checking.
Fine if they give out modems that send DHCP at higher priority, but why would you check in the server that this has
been done? That has no advantage, as far as I can see... (other than trying to lockout foreign equipment)

Well, I don't think I can convince Orange to change their infrastructure
But I agree with you on principle.

you can !! you always CAN !!
but i never say it will be Easy or quick enough to do it w/o moral support.

I hope the DHCP will use "ip" and not raw sockets in V7... or that the v7 will be able to work with raw socket... "The real need is to be able to mark outgoing DHCP client packets with a DSCP value. The reason stays the same, the isp Orange need it to answer DHCP requests.

And then, since Orange use a VLAN, we need a DSCP=>CoS mapping which would work for dhcp packets going out a vlan interface."

I hope the DHCP will use "ip" and not raw sockets in V7... or that the v7 will be able to work with raw socket... "The real need is to be able to mark outgoing DHCP client packets with a DSCP value. The reason stays the same, the isp Orange need it to answer DHCP requests.

And then, since Orange use a VLAN, we need a DSCP=>CoS mapping which would work for dhcp packets going out a vlan interface."

I was reading some unrelated material on a Linux blog, and it states the reason why DHCP client must bind a raw socket - the kernel does not process IP packets on an interface without an IP address configured on it. So the client has to implement UDP and DHCP itself.

Finally there's a solution with current RouterOS :
- define a new VLAN interface, let's say vlan832 with VLAN ID 832 (the ISP VLAN) ;
- set DHCP client to run on vlan832 ;
- add a switch rule on "switch1 cpu" port, UDP protocol, destination port 67, etc... and new-vlan-priority 6.

This will work at hardware level, so no performance impact

Finally there's a solution with current RouterOS :
- define a new VLAN interface, let's say vlan832 with VLAN ID 832 (the ISP VLAN) ;
- set DHCP client to run on vlan832 ;
- add a switch rule on "switch1 cpu" port, UDP protocol, destination port 67, etc... and new-vlan-priority 6.

This will work at hardware level, so no performance impact

This does not work on CCR2116-12G-4S+ (whatever version we use, currently 7.9) ... Why ? Because switch rules are only applied on ingress for "CRS3xx, CRS5xx series switches, CCR2116, CCR2216". Source : https://help.mikrotik.com/docs/display/ ... es-Summary).

It may still be an option to go back to Orange, as nowadays it is EU-mandatory for providers to allow other manufacturer's equipment on their network.
In the past, many ISPs implemented things like this to silently lockout other routers than what they provide themselves, and other manufacturers were often convinced to implement extra features to work around that (e.g. setting the MAC address, or sending nonstandard options).
But that is no longer allowed, and when Orange still do it you can complain about it at the French consumer authority.