segmentation fault on 1.8.21
Hi list, I can reproduce a segmentation fault on HAProxy 1.8.21. No problem with 1.8.20, 1.9.10 or 2.0.5. Is there anything else I can provide or test on my environment? -- haproxy.cfg: ... frontend f mode http ... filter spoe engine modsecurity config /etc/haproxy/spoe-modsecurity.conf ... backend spoe-modsecurity mode tcp timeout connect 5s timeout server 5s server modsec-spoa0 192.168.100.99:12345 ... -- spoe-modsecurity.conf: [modsecurity] spoe-agent modsecurity-agent messages check-request option var-prefix modsec timeout hello 11s timeout idle28s timeout processing 39s use-backend spoe-modsecurity spoe-message check-request args unique-id method path query req.ver req.hdrs_bin req.body_size req.body event on-frontend-http-request -- Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x55f747657c3c in spoe_encode_message (s=s@entry=0x55f7485bf320, ctx=ctx@entry=0x55f7485bf740, msg=msg@entry=0x55f7484ba680, dir=dir@entry=0, buf=buf@entry=0x7ffe4fb78088, end=end@entry=0x55f7485d7910 "") at src/flt_spoe.c:2190 2190src/flt_spoe.c: No such file or directory. (gdb) bt #0 0x55f747657c3c in spoe_encode_message (s=s@entry=0x55f7485bf320, ctx=ctx@entry=0x55f7485bf740, msg=msg@entry=0x55f7484ba680, dir=dir@entry=0, buf=buf@entry=0x7ffe4fb78088, end=end@entry=0x55f7485d7910 "") at src/flt_spoe.c:2190 #1 0x55f7476585f5 in spoe_encode_messages (type=, dir=0, messages=0x55f7484ba4a0, ctx=0x55f7485bf740, s=0x55f7485bf320) at src/flt_spoe.c:2233 #2 spoe_process_messages (s=0x55f7485bf320, ctx=0x55f7485bf740, messages=, dir=dir@entry=0, type=type@entry=1) at src/flt_spoe.c:2616 #3 0x55f74765a145 in spoe_process_event (ev=, ctx=, s=) at src/flt_spoe.c:2703 #4 spoe_chn_pre_analyze (s=, filter=, chn=0x55f7485bf330, an_bit=) at src/flt_spoe.c:3129 #5 0x55f7476c1595 in flt_pre_analyze (s=s@entry=0x55f7485bf320, chn=chn@entry=0x55f7485bf330, an_bit=an_bit@entry=16) at src/filters.c:805 #6 0x55f74764dfd5 in process_stream (t=t@entry=0x55f7485bf680) at src/stream.c:1906 #7 0x55f7476d5844 in process_runnable_tasks () at src/task.c:229 #8 0x55f747683214 in run_poll_loop () at src/haproxy.c:2419 #9 run_thread_poll_loop (data=) at src/haproxy.c:2489 #10 0x55f7475e261c in main (argc=, argv=) at src/haproxy.c:3092
RE: Help required ehhe
Thanks a lot man, i'll take a look at that ! really appreciate it :) i'll come back to you if needed, but the help was great! :) -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 11:14 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Am 23-08-2019 02:04, schrieb andy.anthoine@opt.nc: > REALLY SORRY ABOUT THAT lo > > I'll copy paste my bad :D > > admin@sld-loadb-01-prd-cit:~$ curl -v -o /dev/null --max-time 5 > --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time > 5 --http1.0 http://10.154.2.29:8080/eoc/login > -bash: curl: command not found > > Ok, i'll separate the commands next time :) > > The lb i m working on is the production one, i'll check, but can't > really do anything like installing on it. Okay. > Telnet works :) if it's enough for you ? should work. > admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.29 8080 Trying > 10.154.2.29... > Connected to 10.154.2.29. > Escape character is '^]'. > > >> So on the back ends are the check ports reachable and you get a 200 >> back. > > server sli-ecmapp-01-prd-cit 10.154.2.29:8443 server > sli-ecmapp-02-prd-cit 10.154.2.31:8443 > > admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.29 8443 Trying > 10.154.2.29... > telnet: Unable to connect to remote host: No route to host That's the problem! The test was wrong. you make a telnet to 8443 but the check port is 8080 Try this. echo -e 'GET /iws/ HTTP/1.0\n\r\n\r'|telnet 10.154.2.29 8080 > admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.31 8443 Trying > 10.154.2.31... > Connected to 10.154.2.31. > Escape character is '^]'. > ^CConnection closed by foreign host. That's another one. echo -e 'GET /iws/ HTTP/1.0\n\r\n\r'|telnet 10.154.2.31 8080 > Seems like i got one of my answer Yes looks like. >> Is there any firewall in between the LB & BE? > Yes there is one Are both ports (8080 & 8443) open from LB top both BE? Looks like not a haproxy issue. Regards Aleks > -Message d'origine- > De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 > août 2019 10:57 À : ANTHOINE Andy (EXT) Cc > : haproxy@formilux.org Objet : Re: Help required ehhe > > Hi. > > Am 23-08-2019 01:43, schrieb andy.anthoine@opt.nc: > >> Hi, >> >> I can't launch the command from the LB > > I love screenshots! It's so easy to copy paste from them 8-/ > > do you have any other tool which you can use to check if the > connection is possible from LB to Backend? > > nc? > telnet? > ...? > >> But from the server he is what i get >> >> [root@sli-ecmapp2-prd ~]# curl -v -o /dev/null --max-time 5 --http1.0 >> http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 >> --http1.0 http://10.154.2.29:8080/eoc/login > > Please one curl AFTER the other, the next time, just separate the > commands with ;. > > curl -v -o /dev/null --max-time 5 --http1.0 > http://10.154.2.29:8080/iws/ ; curl -v -o /dev/null --max-time 5 > --http1.0 http://10.154.2.29:8080/eoc/login > >> * About to connect() to 10.154.2.29 port 8080 (#0) >> * Trying 10.154.2.29... > ... >> 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- >>0* Connected to 10.154.2.29 (10.154.2.29) port 8080 (#0) >> >>> GET /iws/ HTTP/1.0 >>> User-Agent: curl/7.29.0 >>> Host: 10.154.2.29:8080 >>> Accept: */* >>> >> >> < HTTP/1.1 200 OK >> < Server: Apache-Coyote/1.1 > > [snipp] > >> curl: (28) Resolving timed out after 5515 milliseconds > > That looks strange, but maybe not the issue for now. > >> * About to connect() to 10.154.2.29 port 8080 (#2) >> * Trying 10.154.2.29... >> * Connected to 10.154.2.29 (10.154.2.29) port 8080 (#2) >> >>> GET /eoc/login HTTP/1.0 >>> User-Agent: curl/7.29.0 >>> Host: 10.154.2.29:8080 >>> Accept: */* >>> >> >> < HTTP/1.1 200 OK >> < Server: Apache-Coyote/1.1 > > [snipp] > >> * Closing connection 2 > > So on the back ends are the check ports reachable and you get a 200 > back. > Is there any firewall in between the LB & BE? > > What's your haproxy version? > > haproxy -vv > > >> Best regards >> >> Andy >> >> -Message d'origine- >> De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi >> 23 août 2019 10:33 À : ANTHOINE Andy (EXT) >> Cc >> : haproxy@formilux.org Objet : Re: Help required ehhe >> >> Am 23-08-2019 00:49, schrieb andy.anthoine@opt.nc: >> >>> Hi, >> >>> >> >>> Ehhe not an external ip don't worry, or i would have deleted it hehe >> >>> >> >>> No change, the problem seems to be there since before i m here, and >> >>> they now need it to be fixed >> >>> >> >>> I don't see anything in particular in the logs, beside that kind of >> >>> thing which is normal since the server is rebooted at this time ;) >> >>> >> >>> Aug 22 05:00:23 sld-loadb-01-prd-cit local1.alert haproxy[2244]: >> >>> Server ecmapp-prd-be-8443/sli-ecmapp-01-prd-cit is DOWN, reason: >> >>> Layer4 connection problem, info: "Connection refused at step 1 of >> >>> tcp-check (connect
Re: Help required ehhe
Am 23-08-2019 02:04, schrieb andy.anthoine@opt.nc: REALLY SORRY ABOUT THAT lo I'll copy paste my bad :D admin@sld-loadb-01-prd-cit:~$ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login -bash: curl: command not found Ok, i'll separate the commands next time :) The lb i m working on is the production one, i'll check, but can't really do anything like installing on it. Okay. Telnet works :) if it's enough for you ? should work. admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.29 8080 Trying 10.154.2.29... Connected to 10.154.2.29. Escape character is '^]'. So on the back ends are the check ports reachable and you get a 200 back. server sli-ecmapp-01-prd-cit 10.154.2.29:8443 server sli-ecmapp-02-prd-cit 10.154.2.31:8443 admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.29 8443 Trying 10.154.2.29... telnet: Unable to connect to remote host: No route to host That's the problem! The test was wrong. you make a telnet to 8443 but the check port is 8080 Try this. echo -e 'GET /iws/ HTTP/1.0\n\r\n\r'|telnet 10.154.2.29 8080 admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.31 8443 Trying 10.154.2.31... Connected to 10.154.2.31. Escape character is '^]'. ^CConnection closed by foreign host. That's another one. echo -e 'GET /iws/ HTTP/1.0\n\r\n\r'|telnet 10.154.2.31 8080 Seems like i got one of my answer Yes looks like. Is there any firewall in between the LB & BE? Yes there is one Are both ports (8080 & 8443) open from LB top both BE? Looks like not a haproxy issue. Regards Aleks -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 10:57 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Hi. Am 23-08-2019 01:43, schrieb andy.anthoine@opt.nc: Hi, I can't launch the command from the LB I love screenshots! It's so easy to copy paste from them 8-/ do you have any other tool which you can use to check if the connection is possible from LB to Backend? nc? telnet? ...? But from the server he is what i get [root@sli-ecmapp2-prd ~]# curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login Please one curl AFTER the other, the next time, just separate the commands with ;. curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ ; curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login * About to connect() to 10.154.2.29 port 8080 (#0) * Trying 10.154.2.29... ... 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.154.2.29 (10.154.2.29) port 8080 (#0) GET /iws/ HTTP/1.0 User-Agent: curl/7.29.0 Host: 10.154.2.29:8080 Accept: */* < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 [snipp] curl: (28) Resolving timed out after 5515 milliseconds That looks strange, but maybe not the issue for now. * About to connect() to 10.154.2.29 port 8080 (#2) * Trying 10.154.2.29... * Connected to 10.154.2.29 (10.154.2.29) port 8080 (#2) GET /eoc/login HTTP/1.0 User-Agent: curl/7.29.0 Host: 10.154.2.29:8080 Accept: */* < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 [snipp] * Closing connection 2 So on the back ends are the check ports reachable and you get a 200 back. Is there any firewall in between the LB & BE? What's your haproxy version? haproxy -vv Best regards Andy -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 10:33 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Am 23-08-2019 00:49, schrieb andy.anthoine@opt.nc: Hi, Ehhe not an external ip don't worry, or i would have deleted it hehe No change, the problem seems to be there since before i m here, and they now need it to be fixed I don't see anything in particular in the logs, beside that kind of thing which is normal since the server is rebooted at this time ;) Aug 22 05:00:23 sld-loadb-01-prd-cit local1.alert haproxy[2244]: Server ecmapp-prd-be-8443/sli-ecmapp-01-prd-cit is DOWN, reason: Layer4 connection problem, info: "Connection refused at step 1 of tcp-check (connect port 8080)", check duration: 0ms. 1 active and 0 backup servers left. 62 sessions active, 0 requeued, 0 remaining in queue. this looks to me that the loadbalancer can't connect to the backend check port, is something listen on the backend server on port 8080? Please can you try the following command from the loadbalancer. curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login The same for 10.154.2.31 What do you mean by that ? I have shorten the config to reduce the size of the mail. mode http [snip
RE: Help required ehhe
REALLY SORRY ABOUT THAT lo I'll copy paste my bad :D admin@sld-loadb-01-prd-cit:~$ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login -bash: curl: command not found Ok, i'll separate the commands next time :) The lb i m working on is the production one, i'll check, but can't really do anything like installing on it. Telnet works :) if it's enough for you ? admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.29 8080 Trying 10.154.2.29... Connected to 10.154.2.29. Escape character is '^]'. So on the back ends are the check ports reachable and you get a 200 back. server sli-ecmapp-01-prd-cit 10.154.2.29:8443 server sli-ecmapp-02-prd-cit 10.154.2.31:8443 admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.29 8443 Trying 10.154.2.29... telnet: Unable to connect to remote host: No route to host admin@sld-loadb-01-prd-cit:~$ telnet 10.154.2.31 8443 Trying 10.154.2.31... Connected to 10.154.2.31. Escape character is '^]'. ^CConnection closed by foreign host. Seems like i got one of my answer Is there any firewall in between the LB & BE? Yes there is one -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 10:57 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Hi. Am 23-08-2019 01:43, schrieb andy.anthoine@opt.nc: > Hi, > > I can't launch the command from the LB I love screenshots! It's so easy to copy paste from them 8-/ do you have any other tool which you can use to check if the connection is possible from LB to Backend? nc? telnet? ...? > But from the server he is what i get > > [root@sli-ecmapp2-prd ~]# curl -v -o /dev/null --max-time 5 --http1.0 > http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 > --http1.0 http://10.154.2.29:8080/eoc/login Please one curl AFTER the other, the next time, just separate the commands with ;. curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ ; curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login > * About to connect() to 10.154.2.29 port 8080 (#0) > * Trying 10.154.2.29... ... > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- >0* Connected to 10.154.2.29 (10.154.2.29) port 8080 (#0) > >> GET /iws/ HTTP/1.0 >> User-Agent: curl/7.29.0 >> Host: 10.154.2.29:8080 >> Accept: */* >> > > < HTTP/1.1 200 OK > < Server: Apache-Coyote/1.1 [snipp] > curl: (28) Resolving timed out after 5515 milliseconds That looks strange, but maybe not the issue for now. > * About to connect() to 10.154.2.29 port 8080 (#2) > * Trying 10.154.2.29... > * Connected to 10.154.2.29 (10.154.2.29) port 8080 (#2) > >> GET /eoc/login HTTP/1.0 >> User-Agent: curl/7.29.0 >> Host: 10.154.2.29:8080 >> Accept: */* >> > > < HTTP/1.1 200 OK > < Server: Apache-Coyote/1.1 [snipp] > * Closing connection 2 So on the back ends are the check ports reachable and you get a 200 back. Is there any firewall in between the LB & BE? What's your haproxy version? haproxy -vv > Best regards > > Andy > > -Message d'origine- > De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 > août 2019 10:33 À : ANTHOINE Andy (EXT) Cc > : haproxy@formilux.org Objet : Re: Help required ehhe > > Am 23-08-2019 00:49, schrieb andy.anthoine@opt.nc: > >> Hi, > >> > >> Ehhe not an external ip don't worry, or i would have deleted it hehe > >> > >> No change, the problem seems to be there since before i m here, and > >> they now need it to be fixed > >> > >> I don't see anything in particular in the logs, beside that kind of > >> thing which is normal since the server is rebooted at this time ;) > >> > >> Aug 22 05:00:23 sld-loadb-01-prd-cit local1.alert haproxy[2244]: > >> Server ecmapp-prd-be-8443/sli-ecmapp-01-prd-cit is DOWN, reason: > >> Layer4 connection problem, info: "Connection refused at step 1 of > >> tcp-check (connect port 8080)", check duration: 0ms. 1 active and 0 > >> backup servers left. 62 sessions active, 0 requeued, 0 remaining in > >> queue. > > this looks to me that the loadbalancer can't connect to the backend > check port, is something listen on the backend server on port 8080? > > Please can you try the following command from the loadbalancer. > > curl -v -o /dev/null --max-time 5 --http1.0 > http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 > --http1.0 http://10.154.2.29:8080/eoc/login > > The same for 10.154.2.31 > >> What do you mean by that ? > > I have shorten the config to reduce the size of the mail. > >>> mode http > >> > >> [snip more config] > >> > >> -Message d'origine- > >> De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi >> 23 > >> août 2019 09:41 À : ANTHOINE Andy (EXT) Cc > >> : haproxy@formilux.org Objet : Re: Help required ehhe > >> > >> Hi. > >> > >> Am 23-08-2019 00:28, schrieb andy.anthoine@opt.nc: > >> > >>> Hi,
Re: Help required ehhe
Hi. Am 23-08-2019 01:43, schrieb andy.anthoine@opt.nc: Hi, I can't launch the command from the LB I love screenshots! It's so easy to copy paste from them 8-/ do you have any other tool which you can use to check if the connection is possible from LB to Backend? nc? telnet? ...? But from the server he is what i get [root@sli-ecmapp2-prd ~]# curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login Please one curl AFTER the other, the next time, just separate the commands with ;. curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ ; curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login * About to connect() to 10.154.2.29 port 8080 (#0) * Trying 10.154.2.29... ... 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.154.2.29 (10.154.2.29) port 8080 (#0) GET /iws/ HTTP/1.0 User-Agent: curl/7.29.0 Host: 10.154.2.29:8080 Accept: */* < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 [snipp] curl: (28) Resolving timed out after 5515 milliseconds That looks strange, but maybe not the issue for now. * About to connect() to 10.154.2.29 port 8080 (#2) * Trying 10.154.2.29... * Connected to 10.154.2.29 (10.154.2.29) port 8080 (#2) GET /eoc/login HTTP/1.0 User-Agent: curl/7.29.0 Host: 10.154.2.29:8080 Accept: */* < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 [snipp] * Closing connection 2 So on the back ends are the check ports reachable and you get a 200 back. Is there any firewall in between the LB & BE? What's your haproxy version? haproxy -vv Best regards Andy -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 10:33 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Am 23-08-2019 00:49, schrieb andy.anthoine@opt.nc: Hi, Ehhe not an external ip don't worry, or i would have deleted it hehe No change, the problem seems to be there since before i m here, and they now need it to be fixed I don't see anything in particular in the logs, beside that kind of thing which is normal since the server is rebooted at this time ;) Aug 22 05:00:23 sld-loadb-01-prd-cit local1.alert haproxy[2244]: Server ecmapp-prd-be-8443/sli-ecmapp-01-prd-cit is DOWN, reason: Layer4 connection problem, info: "Connection refused at step 1 of tcp-check (connect port 8080)", check duration: 0ms. 1 active and 0 backup servers left. 62 sessions active, 0 requeued, 0 remaining in queue. this looks to me that the loadbalancer can't connect to the backend check port, is something listen on the backend server on port 8080? Please can you try the following command from the loadbalancer. curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login The same for 10.154.2.31 What do you mean by that ? I have shorten the config to reduce the size of the mail. mode http [snip more config] -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 09:41 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Hi. Am 23-08-2019 00:28, schrieb andy.anthoine@opt.nc: Hi, I got that email on this site, not sure if it's still working etc https://www.slideshare.net/haproxytech/haproxy-best-practice [snipp] What's your haproxy version? haproxy -vv Application load balancing & high availability v8.5.7 (8546) That's not the full output of the command line call haproxy -vv . Thanks a lot for the answer man ! Thanks ! Andy Regards Aleks Ce message et toutes les pièces jointes (ci-après le « message ») sont à l'attention exclusive des destinataires désignés. Il peut contenir des informations confidentielles. Si vous le recevez par erreur, merci d'en informer immédiatement l'émetteur et de le détruire. Toute utilisation, diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation. Tout message électronique étant susceptible d'altération, l'OPT NC décline toute responsabilité au titre de ce message dans l'hypothèse où il aurait été modifié. This message and any attachments (the « message ») are intended solely for the addresses. It may contain privileged information. If you receive this message in error, please immediately notify the sender and delete it. Any use, dissemination or disclosure, either whole or partial, is prohibited unless formal approval. Emails are susceptible to alteration; OPT NC shall not therefore be liable for the message if modified. Pensez à l'environnement, n'imprimez que si nécessaire.
RE: Help required ehhe
Hi,
I can't launch the command from the LB
[cid:image001.png@01D5599F.9D2D6E10]
But from the server he is what i get
[root@sli-ecmapp2-prd ~]# curl -v -o /dev/null --max-time 5 --http1.0
http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0
http://10.154.2.29:8080/eoc/login
* About to connect() to 10.154.2.29 port 8080 (#0)
* Trying 10.154.2.29...
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Connected to 10.154.2.29 (10.154.2.29) port 8080 (#0)
> GET /iws/ HTTP/1.0
> User-Agent: curl/7.29.0
> Host: 10.154.2.29:8080
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Accept-Ranges: bytes
< ETag: W/"1283-1552374458000"
< Last-Modified: Tue, 12 Mar 2019 07:07:38 GMT
< Content-Type: text/html
< Content-Length: 1283
< Date: Thu, 22 Aug 2019 23:42:28 GMT
< Connection: close
<
{ [data not shown]
100 1283 100 12830 0 632k 0 --:--:-- --:--:-- --:--:-- 1252k
* Closing connection 0
0 00 00 0 0 0 --:--:-- 0:00:04 --:--:-- 0*
Resolving timed out after 5515 milliseconds
0 00 00 0 0 0 --:--:-- 0:00:06 --:--:-- 0
* Closing connection 1
curl: (28) Resolving timed out after 5515 milliseconds
* About to connect() to 10.154.2.29 port 8080 (#2)
* Trying 10.154.2.29...
* Connected to 10.154.2.29 (10.154.2.29) port 8080 (#2)
> GET /eoc/login HTTP/1.0
> User-Agent: curl/7.29.0
> Host: 10.154.2.29:8080
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Date: Thu, 22 Aug 2019 23:42:34 GMT
< Cache-Control: no-cache
< Cache-Control: no-store
< Cache-Control: max-age=0
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1
< Set-Cookie: JSESSIONID=hr-UQa5y1CpyiQvYjONLkNyf; Path=/eoc
< Content-Type: text/html;charset=UTF-8
< Content-Length: 4398
< Connection: close
<
Login
var cwWebappPrefix='/eoc';var cwComma=",";var
cwDecimal=".";var cwSessionTimeout=3000;var cwSessionTimeoutWarning=0;var
cwHtEsc=false;var cwEnumHtEsc=true;var cwSkinnedWarnDialog = false;var
formCount=0;var startLoading=false;function finishLoading(id){if(window[id] !=
null) {startLoading = false; return true;} else return false;}function
loading(){return startLoading;}function
increaseFormCount(){formCount++;}function decreaseFormCount(){formCount--;}var
cwDefaultDialogMaskOpacity = 0;;var cwUE0311='Invalid date value. Valid format
is ';
var cwUE0328='Start date must occur BEFORE End Date. Please correct
the\n\t\t\tcriteria.';
var cwUE0116='This document contains errors and will not be saved.';
var cwUU0313='Warning';
var cwUU0315=' could not be matched to the display format: ';
var cwUU0316=' row(s) fetched (more exist but are not shown).';
var cwUU0317=' row(s) fetched.';
var cwUU0059='Please wait, operation in progress...';
var cwUU0318='Cancel';
var cwUU0319='Save';
var cwUU0322='No items found.';
var cwUU0324=' row(s) fetched out of ';
var cwUU0325=' row(s) found in total ';
var cwUU0326=' page(s).';
var isomorphicDir="/eoc/isomorphic/";var
cwDir="../";
if(window.Browser.isIE){window.isc.Canvas.addClassProperties({$42a:
"margin:0px;border:0px;padding:0px;background-color:transparent;background-image:none;",neverUsePNGWorkaround
: true});window.isc.Canvas.addProperties({$r9:false});}
if(window.Browser.isIE){isc.defineClass("MyResultSet",
"ResultSet").addProperties({fetchRemoteDataReply : function (dsResponse, data,
request) {if (dsResponse.httpResponseCode == 12152)
{isc.RPCManager.handleError(dsResponse, request);} else {return
this.Super("fetchRemoteDataReply",
arguments);}}});isc.DataSource.addProperties({resultSetClass :
"MyResultSet"});window.isc.RPCManager.addClassProperties({handleError :
function (response, request) {Log.logWarn("httpResponseCode: " +
response.httpResponseCode);if (response.httpResponseCode == 12152)
{window.isc.RPCManager.suspendTransaction(response.transactionNum);window.isc.Timer.setTimeout(function
()
{window.isc.RPCManager.resendTransaction(response.transactionNum);});}}});}
var $cwCurrentCss = '/css/ui_common.css'
isc.setAutoDraw(false);
* Closing connection 2
Best regards
Andy
-Message d'origine-
De : Aleksandar Lazic [mailto:al-hapr...@none.at]
Envoyé : vendredi 23 août 2019 10:33
À : ANTHOINE Andy (EXT)
Cc : haproxy@formilux.org
Objet : Re: Help required ehhe
Am 23-08-2019 00:49, schrieb
andy.anthoine@opt.nc:
> Hi,
>
> Ehhe not an external ip don't worry, or i would have deleted it hehe
>
> No change, the problem seems to be there since before i m here, and
> they now need it to be fixed
>
> I don't see anything in particular in the logs, beside that kind of
> thing which
Re: Help required ehhe
Am 23-08-2019 00:49, schrieb andy.anthoine@opt.nc: Hi, Ehhe not an external ip don't worry, or i would have deleted it hehe No change, the problem seems to be there since before i m here, and they now need it to be fixed I don't see anything in particular in the logs, beside that kind of thing which is normal since the server is rebooted at this time ;) Aug 22 05:00:23 sld-loadb-01-prd-cit local1.alert haproxy[2244]: Server ecmapp-prd-be-8443/sli-ecmapp-01-prd-cit is DOWN, reason: Layer4 connection problem, info: "Connection refused at step 1 of tcp-check (connect port 8080)", check duration: 0ms. 1 active and 0 backup servers left. 62 sessions active, 0 requeued, 0 remaining in queue. this looks to me that the loadbalancer can't connect to the backend check port, is something listen on the backend server on port 8080? Please can you try the following command from the loadbalancer. curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/iws/ curl -v -o /dev/null --max-time 5 --http1.0 http://10.154.2.29:8080/eoc/login The same for 10.154.2.31 What do you mean by that ? I have shorten the config to reduce the size of the mail. mode http [snip more config] -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 09:41 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Hi. Am 23-08-2019 00:28, schrieb andy.anthoine@opt.nc: Hi, I got that email on this site, not sure if it's still working etc https://www.slideshare.net/haproxytech/haproxy-best-practice [snipp] What's your haproxy version? haproxy -vv Application load balancing & high availability v8.5.7 (8546) That's not the full output of the command line call haproxy -vv . Thanks a lot for the answer man ! Thanks ! Andy Regards Aleks
RE: Help required ehhe
Hi, Ehhe not an external ip don't worry, or i would have deleted it hehe No change, the problem seems to be there since before i m here, and they now need it to be fixed I don't see anything in particular in the logs, beside that kind of thing which is normal since the server is rebooted at this time ;) Aug 22 05:00:23 sld-loadb-01-prd-cit local1.alert haproxy[2244]: Server ecmapp-prd-be-8443/sli-ecmapp-01-prd-cit is DOWN, reason: Layer4 connection problem, info: "Connection refused at step 1 of tcp-check (connect port 8080)", check duration: 0ms. 1 active and 0 backup servers left. 62 sessions active, 0 requeued, 0 remaining in queue. What do you mean by that ? > mode http [snip more config] -Message d'origine- De : Aleksandar Lazic [mailto:al-hapr...@none.at] Envoyé : vendredi 23 août 2019 09:41 À : ANTHOINE Andy (EXT) Cc : haproxy@formilux.org Objet : Re: Help required ehhe Hi. Am 23-08-2019 00:28, schrieb andy.anthoine@opt.nc: > Hi, > > I got that email on this site, not sure if it's still working etc > https://www.slideshare.net/haproxytech/haproxy-best-practice > > I'm having some issue with a service (white page sometimes for a > webservice), and i m not totally sure it has anything to do with issue > on my load balancer (i'm not the one who configured it, just having to > work on it, guy gone, no documentation left etc…) > > When i started looking, i noticed that only this service had so many > warnings and errors, so i thought « maybe » it can have something to > do with it… Was any changes in the setup which cloud be the reason for the the behaviour or you just recognizes it and it's "normal"? What's in the logs? > backend ecmapp-prd-be-8443 > acl kerberos hdr_beg(Authorization) -m beg Negotiate http-request > replace-header Authorization (.*) "Basic " if kerberos Ähm I hope this is not an U:P which is external visible > mode http [snip more config] > Here is the configuration of the service, i m able to read half of it, > chechking the documentation to find more information > > Thanks a lot of you can help, if not have a great day J What's your haproxy version? haproxy -vv Application load balancing & high availability v8.5.7 (8546) Thanks a lot for the answer man ! > Thanks ! > > Andy > > Ce > message et toutes les pièces jointes (ci-après le « message ») sont à > l'attention exclusive des destinataires désignés. Il peut contenir des > informations confidentielles. Si vous le recevez par erreur, merci > d'en informer immédiatement l'émetteur et de le détruire. Toute > utilisation, diffusion ou toute publication, totale ou partielle, est > interdite, sauf autorisation. Tout message électronique étant > susceptible d'altération, l'OPT NC décline toute responsabilité au > titre de ce message dans l'hypothèse où il aurait été modifié. > This message and any attachments (the « > message ») are intended solely for the addresses. It may contain > privileged information. If you receive this message in error, please > immediately notify the sender and delete it. Any use, dissemination or > disclosure, either whole or partial, is prohibited unless formal > approval. Emails are susceptible to alteration; OPT NC shall not > therefore be liable for the message if modified. > > Pensez à l'environnement, n'imprimez que si nécessaire. Always the same crap footer from the "enterprise" Companies to public mailing lists. Regards Aleks Ce message et toutes les pièces jointes (ci-après le « message ») sont à l'attention exclusive des destinataires désignés. Il peut contenir des informations confidentielles. Si vous le recevez par erreur, merci d'en informer immédiatement l'émetteur et de le détruire. Toute utilisation, diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation. Tout message électronique étant susceptible d'altération, l'OPT NC décline toute responsabilité au titre de ce message dans l'hypothèse où il aurait été modifié. This message and any attachments (the « message ») are intended solely for the addresses. It may contain privileged information. If you receive this message in error, please immediately notify the sender and delete it. Any use, dissemination or disclosure, either whole or partial, is prohibited unless formal approval. Emails are susceptible to alteration; OPT NC shall not therefore be liable for the message if modified. Pensez à l'environnement, n'imprimez que si nécessaire.
Re: Help required ehhe
Hi. Am 23-08-2019 00:28, schrieb andy.anthoine@opt.nc: Hi, I got that email on this site, not sure if it's still working etc https://www.slideshare.net/haproxytech/haproxy-best-practice I'm having some issue with a service (white page sometimes for a webservice), and i m not totally sure it has anything to do with issue on my load balancer (i'm not the one who configured it, just having to work on it, guy gone, no documentation left etc…) When i started looking, i noticed that only this service had so many warnings and errors, so i thought « maybe » it can have something to do with it… Was any changes in the setup which cloud be the reason for the the behaviour or you just recognizes it and it's "normal"? What's in the logs? backend ecmapp-prd-be-8443 acl kerberos hdr_beg(Authorization) -m beg Negotiate http-request replace-header Authorization (.*) "Basic " if kerberos Ähm I hope this is not an U:P which is external visible mode http [snip more config] Here is the configuration of the service, i m able to read half of it, chechking the documentation to find more information Thanks a lot of you can help, if not have a great day J What's your haproxy version? haproxy -vv Thanks ! Andy Ce message et toutes les pièces jointes (ci-après le « message ») sont à l'attention exclusive des destinataires désignés. Il peut contenir des informations confidentielles. Si vous le recevez par erreur, merci d'en informer immédiatement l'émetteur et de le détruire. Toute utilisation, diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation. Tout message électronique étant susceptible d'altération, l'OPT NC décline toute responsabilité au titre de ce message dans l'hypothèse où il aurait été modifié. This message and any attachments (the « message ») are intended solely for the addresses. It may contain privileged information. If you receive this message in error, please immediately notify the sender and delete it. Any use, dissemination or disclosure, either whole or partial, is prohibited unless formal approval. Emails are susceptible to alteration; OPT NC shall not therefore be liable for the message if modified. Pensez à l'environnement, n'imprimez que si nécessaire. Always the same crap footer from the "enterprise" Companies to public mailing lists. Regards Aleks
Help required ehhe
Hi, I got that email on this site, not sure if it's still working etc https://www.slideshare.net/haproxytech/haproxy-best-practice I'm having some issue with a service (white page sometimes for a webservice), and i m not totally sure it has anything to do with issue on my load balancer (i'm not the one who configured it, just having to work on it, guy gone, no documentation left etc...) When i started looking, i noticed that only this service had so many warnings and errors, so i thought < maybe > it can have something to do with it... [cid:image001.png@01D55994.DCB307D0] backend ecmapp-prd-be-8443 acl kerberos hdr_beg(Authorization) -m beg Negotiate http-request replace-header Authorization (.*) "Basic dXBhZG1pbjp1cGFkbWlu" if kerberos mode http log global option httplog balance roundrobin option forwardfor #cookie SERVERID insert indirect nocache cookie ReqClientId prefix nocache option tcp-check tcp-check connect port 8080 tcp-check send GET\ /iws/\ HTTP/1.0\r\n tcp-check send \r\n tcp-check expect string 200 tcp-check connect port 8080 tcp-check send GET\ /eoc/login\ HTTP/1.0\r\n tcp-check send \r\n tcp-check expect string 200 timeout client 5s server sli-ecmapp-01-prd-cit 10.154.2.29:8443 ssl cookie s1 weight 20 check port 8080 inter 1 server sli-ecmapp-02-prd-cit 10.154.2.31:8443 ssl cookie s2 weight 20 check port 8080 inter 1 Here is the configuration of the service, i m able to read half of it, chechking the documentation to find more information Thanks a lot of you can help, if not have a great day :) Thanks ! Andy Ce message et toutes les pi?ces jointes (ci-apr?s le < message >) sont ? l'attention exclusive des destinataires d?sign?s. Il peut contenir des informations confidentielles. Si vous le recevez par erreur, merci d'en informer imm?diatement l'?metteur et de le d?truire. Toute utilisation, diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation. Tout message ?lectronique ?tant susceptible d'alt?ration, l'OPT NC d?cline toute responsabilit? au titre de ce message dans l'hypoth?se o? il aurait ?t? modifi?. This message and any attachments (the < message >) are intended solely for the addresses. It may contain privileged information. If you receive this message in error, please immediately notify the sender and delete it. Any use, dissemination or disclosure, either whole or partial, is prohibited unless formal approval. Emails are susceptible to alteration; OPT NC shall not therefore be liable for the message if modified. Pensez ? l'environnement, n'imprimez que si n?cessaire.
Re: [RFC] setting the backend SNI from the client's authority TLV, when the target address was forwarded
On Thu, Aug 22, 2019 at 04:33:13PM +0200, Geoff Simmons wrote: > On 8/22/19 14:40, Willy Tarreau wrote: > > > >> I would suggest naming it something like fc_authority or > >> fc_pp_authority, to be specific about where it came from. > > Since you used fc_pp_authority in an example further down, I'll take > that as the choice (unless somebody yells). Seems better to me, since > just "authority" could refer to a number of things. OK. > All right, I think we've covered enough that I can take another go at > coding it up. And I believe I can mail a patch next time, if there are > no objections. Since the patch will be adding a fetch, I'd say the > regression risk is MINOR, as no one could have ever used it before. If it's really *that* minor (we'll see in the end), we could even think about backporting it to 2.0. We do occasionally backport a few sample fetches and converters when they are totally harmless. And if your work on Varnish is about to be completed, you could benefit from the full support from a stable version. > Willy, thanks again for the feedback, the first impression about working > with haproxy development has been very pleasant. Thanks. Willy
Re: [RFC] setting the backend SNI from the client's authority TLV, when the target address was forwarded
On 8/22/19 14:40, Willy Tarreau wrote: > >> I would suggest naming it something like fc_authority or >> fc_pp_authority, to be specific about where it came from. Since you used fc_pp_authority in an example further down, I'll take that as the choice (unless somebody yells). Seems better to me, since just "authority" could refer to a number of things. > You don't need to have the extra boolean because our sample fetch functions > already return this information for you. The "-m found" match method > indicates whether or not the requested information was present, regardless > of its possible emptiness. > >> I assume the fetch for the authority TLV should return the empty string >> if none was read; correct? > > No it returns a "not found" (return 0 technically speaking). Ah, OK thx. >> - Use a dedicated memory pool to allocate the name from TLV, if there is >> one in the proxy header. > > Yep. Please name it "authority" then. At least if we need an authority > anywhere else we know we can share it. OK All right, I think we've covered enough that I can take another go at coding it up. And I believe I can mail a patch next time, if there are no objections. Since the patch will be adding a fetch, I'd say the regression risk is MINOR, as no one could have ever used it before. Willy, thanks again for the feedback, the first impression about working with haproxy development has been very pleasant. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstraße 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de signature.asc Description: OpenPGP digital signature
Re: [RFC] setting the backend SNI from the client's authority TLV, when the target address was forwarded
On Thu, Aug 22, 2019 at 11:36:00AM +0200, Geoff Simmons wrote: > Spot on, that's the PR that I'm working on with my colleague Nils. Mine > is a PR to his PR, if that makes any sense; after review (assuming he > approves), the part about setting the authority TLV will go into the > Varnish PR. OK, thanks for the context. > I suspect that there are other ways that the authority TLV can be useful > for haproxy besides the specific Varnish case. Someone connecting via > TLS, for example, might want to send the TLV to "override" the SNI for > certain backends. It's definitely useful for other cases, which is why I'm interested in seeing it addressed properly. Right now we do emit a few fields in the PPv2 but we ignore them on receipt, which is a bit sad. For example, if you use multi-process to chain two haproxy instances, one with TLS offloading, passing to the next level using PPv2, you currently lose the SNI information. With your change it would finally work. > I thought there could be an objection to special-casing just the one > class of TLV, since there's a variety of them. A general solution might > be to have the field point to a table of TLVs read from the connection, > if there were any. That would complicate the allocation, though. > > My instinct is to not generalize from a single use case, especially if > it introduces new complexities before it's clear whether anyone wants to > use them. If haproxy users find that they like accessing the authority > TLV and want more, that can be accommodated when the time comes. I totally agree with this, let's just create a pool for this one at the moment, and who knows what we'll see next. > I would suggest naming it something like fc_authority or > fc_pp_authority, to be specific about where it came from. If it's > available as a fetch, then SNI doesn't have to be its only purpose. Hmmm you're totally right. I remind a conversation, I think it was with Amos Jeffries of Squid, who was insisting on the fact that we name it authority and not SNI because authority is the functional description and is always valid regardless of the underlying protocol, while SNI is only the technical way to convery the authority over TLS. Thus I agree with this, it's just that I didn't remember the field's name in the PP :-) > Conceivably someone could use it to set a Host header, define an ACL, or > do other things we haven't considered yet. Absolutely. > And I think there would have to be a boolean like fc_rcvd_authority, to > find out if the TLV had been sent at all. That way, the fallback logic > can be made explicit in the config: set SNI from fc_authority if > present, otherwise set it from fc_sni. You don't need to have the extra boolean because our sample fetch functions already return this information for you. The "-m found" match method indicates whether or not the requested information was present, regardless of its possible emptiness. > I assume the fetch for the authority TLV should return the empty string > if none was read; correct? No it returns a "not found" (return 0 technically speaking). If used to set a textual value somewhere, this will be turned to an empty string, but as much as possible it will indicate "no value" and will lead to some operations not being performed. Typically if you use "sni fc_pp_authority" and this authority is not there, then no SNI will be sent. > > Also one thing I think we're missing is fc_has_pp() or something like > > this to indicate that the front connection used the proxy protocol. > > And in this case it can prove very useful. > > Isn't that what fc_rcvd_proxy says? I didn't remember about it and I responded without reading the doc :-) > So to summarize my takeaways thus far: > > - Use a dedicated memory pool to allocate the name from TLV, if there is > one in the proxy header. Yep. Please name it "authority" then. At least if we need an authority anywhere else we know we can share it. > - Introduce a fetch to use it in configuration. Yes. > - I suggest naming the fetch to identify it specifically as the > authority TLV from PP, Yes. > and also introducing a boolean fetch that says > whether any such was read. Not needed as indicated above. > Thanks again, this has been an encouraging start. %^) You're welcome, thanks for your pretty clear approach. Willy
Re: [RFC] setting the backend SNI from the client's authority TLV, when the target address was forwarded
On 8/21/19 21:50, Willy Tarreau wrote: > > Thus welcome to the list :-) Thanks for the informative and welcoming response. %^) > Just to know a bit more about your use case, thus your client speaks > in clear to haproxy by prepending a PPv2 header and lets haproxy serve > as a TLS "onloader" if I can call it like this, that's it ? If so, this > is pretty close to what is also being done in Varnish to allow it to > use haproxy to gateway to TLS servers : > > https://github.com/varnishcache/varnish-cache/pull/2957 Spot on, that's the PR that I'm working on with my colleague Nils. Mine is a PR to his PR, if that makes any sense; after review (assuming he approves), the part about setting the authority TLV will go into the Varnish PR. I suspect that there are other ways that the authority TLV can be useful for haproxy besides the specific Varnish case. Someone connecting via TLS, for example, might want to send the TLV to "override" the SNI for certain backends. >> It seemed to make sense to use a memory pool for the allocation, but it >> also felt like overkill to add a new memory pool just for this feature. > > No it's not overkill, pools are extremely cheap and they are fused when > they have very close sizes. I just had a quick look and saw that appctx > is 248 bytes si it will end up being fused with your pool, so by adding > a pool, your entries will cost exactly zero. So really, don't be shy on > this. > >> Maybe define a >> dedicated pool after all? > > Yep :-) All right then, a new memory pool will be introduced. I thought there could be an objection to special-casing just the one class of TLV, since there's a variety of them. A general solution might be to have the field point to a table of TLVs read from the connection, if there were any. That would complicate the allocation, though. My instinct is to not generalize from a single use case, especially if it introduces new complexities before it's clear whether anyone wants to use them. If haproxy users find that they like accessing the authority TLV and want more, that can be accommodated when the time comes. > So I'm having a small disagreement on the way to configure this, but > there is a nice solution that should not change much of what you've > done. [...] > > But the solution is actually very simple. The current "sni" directive > takes a sample expression. You "just" have to write a sample fetch to > return the SNI extracted from the PP header. Just call it "fc_sni", we > already have a number of other "fc_*" sample fetch functions for stuff > extracted from the front connection. I agree, the fetch looks like the better solution. I would suggest naming it something like fc_authority or fc_pp_authority, to be specific about where it came from. If it's available as a fetch, then SNI doesn't have to be its only purpose. Conceivably someone could use it to set a Host header, define an ACL, or do other things we haven't considered yet. And I think there would have to be a boolean like fc_rcvd_authority, to find out if the TLV had been sent at all. That way, the fallback logic can be made explicit in the config: set SNI from fc_authority if present, otherwise set it from fc_sni. I assume the fetch for the authority TLV should return the empty string if none was read; correct? > Also one thing I think we're missing is fc_has_pp() or something like > this to indicate that the front connection used the proxy protocol. > And in this case it can prove very useful. Isn't that what fc_rcvd_proxy says? So to summarize my takeaways thus far: - Use a dedicated memory pool to allocate the name from TLV, if there is one in the proxy header. - Introduce a fetch to use it in configuration. - I suggest naming the fetch to identify it specifically as the authority TLV from PP, and also introducing a boolean fetch that says whether any such was read. Thanks again, this has been an encouraging start. %^) Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstraße 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de signature.asc Description: OpenPGP digital signature
