Query: Respond with same tos/dscp value as incoming request tos/dscp value
Hi, I have a use case where i need http response from haproxy with same tos/dscp value as incoming packet. I found the set-tos in haproxy but no option to dynamically set the same as incoming request. Is there any way to do the same in haproxy. Thanks in advance. Regards, Nikhil Agrawal -- *-* *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* *Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organization. Any information on shares, debentures or similar instruments, recommended product pricing, valuations and the like are for information purposes only. It is not meant to be an instruction or recommendation, as the case may be, to buy or to sell securities, products, services nor an offer to buy or sell securities, products or services unless specifically stated to be so on behalf of the Flipkart group. Employees of the Flipkart group of companies are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to organizational policy and outside the scope of the employment of the individual concerned. The organization will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising.* *Our organization accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information *provided,* unless that information is subsequently confirmed in writing. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* _-_
Re: BUG/MAJOR: dns: overflowed dns name start position causing invalid dns error
Great, Thanks . May you backport the fix to 1.7 too? On Fri, Dec 21, 2018 at 4:07 PM Willy Tarreau wrote: > On Fri, Dec 21, 2018 at 03:40:53PM +0530, Nikhil Agrawal wrote: > > Hi Willy, > > > > Thanks for response and correcting the mistake. > > > > Its OK for you to fix this. > > marking this as MEDIUM is also fine :). > > OK thanks, now merged. It will be included into next 1.8 ASAP. > > Willy >
Re: BUG/MAJOR: dns: overflowed dns name start position causing invalid dns error
Hi Willy, Thanks for response and correcting the mistake. Its OK for you to fix this. marking this as MEDIUM is also fine :). Regards, Nikhil Agrawal On Fri, Dec 21, 2018 at 2:58 PM Willy Tarreau wrote: > Hi, > > On Fri, Dec 21, 2018 at 11:02:24AM +0530, Nikhil Agrawal wrote: > > Dear Haproxy Maintainers, > > > > In dns_read_name() when dns name is used with name compression and start > > position of name is greater than 255, name is read from incorrect > position > > ( actual position%256). This causes "Invalid dns error" and backend is > > marked as down permanently. > > eg: hexadecimal value at start of dns "0xc1 1b". "0xc" specifies name > > compression being used. in this scenario only "1b" (27) is taken as the > > start of the name but actual name starts from "11b" (283). > > > > > > This is a regression scenario starting from version 1.7.0 and is present > in > > current version. > > > > Resolution: > > Include nibble from byte used for checking compression. i.e take "11b" as > > start position of dns name. > > > > i am attaching patch to fix this bug. > > It's indeed a bug, however after checking RFC1035, your patch is still > bogus as it only includes 4 of the 6 bits : > > https://tools.ietf.org/html/rfc1035#section-4.1.4 > > The pointer takes the form of a two octet sequence: > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | 1 1|OFFSET | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > ^ ^ > | | > | +- your patch starts here > +--- the standard says the length starts here > > If you're OK with this I can simply fix it, just let me know. Also I'd > relabel it as medium, as it's an annoyance that requires some efforts to > be worked around, but not a major loss of functionality. > > Thanks for the test case by the way ;-) > > Willy >
BUG/MAJOR: dns: overflowed dns name start position causing invalid dns error
Dear Haproxy Maintainers, In dns_read_name() when dns name is used with name compression and start position of name is greater than 255, name is read from incorrect position ( actual position%256). This causes "Invalid dns error" and backend is marked as down permanently. eg: hexadecimal value at start of dns "0xc1 1b". "0xc" specifies name compression being used. in this scenario only "1b" (27) is taken as the start of the name but actual name starts from "11b" (283). This is a regression scenario starting from version 1.7.0 and is present in current version. Resolution: Include nibble from byte used for checking compression. i.e take "11b" as start position of dns name. i am attaching patch to fix this bug. haproxy config to reproduce bug : .. resolvers dns-server nameserver dnsmasq 8.8.8.8:53 hold valid 300s global stats socket /var/run/haproxy-admin.sock mode 600 level admin ssl-server-verify none defaults mode http timeout connect 3ms timeout client 3ms timeout server 3ms frontend http-in default_backend servers bind *:80 backend servers http-request set-header Host southeastasia.api.cognitive.microsoft.com server southeastasia.api.cognitive.microsoft.com southeastasia.api.cognitive.microsoft.com:443 ssl check resolvers dns-server resolve-prefer ipv4 .. Please let me know if any more information is needed for the same. Thanks and Regards, Nikhil Agrawal dns-name-error.patch Description: Binary data
