Sniproxy logging

[evrynet1]

Hey,

I enabled logging as follows:

listener 80 { proto http bad_requests log access_log {

Same options as error_log

    filename /var/log/sniproxy.log
}

}

listener 443 { proto tls bad_requests log access_log {

Same options as error_log

    filename /var/log/sniproxy.log
}

and in the logs I see:

2014-07-14 10:13:21 [::ffff:78.139.26.XXX]:44932 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.001 seconds 2014-07-14 10:13:21 [::ffff:78.139.26.XXX]:44933 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.000 seconds 2014-07-14 10:17:36 [::ffff:78.139.26.XXX]:38864 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.001 seconds 2014-07-14 10:17:36 [::ffff:78.139.26.XXX]:38865 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.000 seconds 2014-07-14 10:18:22 [::ffff:78.139.26.XXX]:38890 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.003 seconds 2014-07-14 10:18:23 [::ffff:78.139.26.XXX]:38891 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.000 seconds

How can I see what domain redirects fails?

Thanks

[evrynet1]

It seems I'm having the same issue as #46

Any resolution for that?

[evrynet1]

I'm using Roku. Netflix working fine here but Hulu+ doesn't. If Netflix works then SNI should be supported I guess.

[dlundquist]

@evrynet1 If you enable debug error logging, and bad request logging you can determine if the Hulu client is include SNI extensions in its requests.

error_log {
   filename /tmp/sniproxy.log
  priority debug
}

listener 443 {
   bad_requests log
}

[evrynet1]

@dlundquist thanks. I think this is the case.

Do you have any word on what @whalleyboi asked?

"Is there a way to abort the proxy without dropping the connection and let it pass through the normal network if this error occurs? If not how would I go about modifying the code myself? The reason it is failing is because Hulu is sending the video to me here on my PS3 Nov 18 01:06:26 VPS-SNI-Proxy-Server sniproxy: Request from 72.13.173.218:63574 did not include a hostname

I figure if I let it through without the need of proxying the video all should be good since the login is complete"

Thanks

[evrynet1]

Interesting. I restarted sniproxy and it still shows the same:

pidfile /var/tmp/sniproxy.pid user daemon

listener 80 { proto http bad_requests log access_log {

Same options as error_log

    filename /var/log/sniproxy.log

priority debug

}

}

listener 443 { proto tls bad_requests log access_log {

Same options as error_log

    filename /var/log/sniproxy.log

priority debug } }

table {

2014-07-14 13:41:38 [::ffff:78.139.26.175]:32952 -> [::]:80 -> 184.26.143.178:80 [m.hulu.com] 6137/6137 bytes tx 749/749 bytes rx 14.601 seconds 2014-07-14 13:41:40 [::ffff:78.139.26.175]:41658 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.000 seconds 2014-07-14 13:41:40 [::ffff:78.139.26.175]:41659 -> [::]:443 -> NONE [] 7/7 bytes tx 0/58 bytes rx 0.000 seconds

[dlundquist]

To answer @whalleyboi's question, once SNIProxy accepts a connection it has participated in the TCP three way handshake, it is not possible pass the connection off to another host without coordination with the host which the connection is being migrated to. So this wouldn't work as a fallback mechanism. Since the TCP handshake has been completed, we can't simply drop the connection without the client knowing something answered.

Edit: @whalleyboi's suggestion will not work for another reason: since the client opened a connection to the IP which sniproxy was listening rather the original request, the information (which IP the client would have sent the request to if hadn't been directed to sniproxy) is lost and without an SNI extension or host header there is no way to determine which server to send the request to.

Thanks for the output, but it looks like you are still missing the error log. Can you add the following the global context of your config (outside of either listener):

error_log {
   filename /tmp/sniproxy.log
  priority debug
}

I'm happy to provide basic help with sniproxy, but I don't want to get involved in the specifics of proxying video content to circumvent GeoIP restrictions. If it works for you, that's not what I had in mind when I wrote sniproxy, but good for you. If you find a bug with sniproxy, let me know, but I can't fix video client nor do I want to get involved.

[evrynet1]

I do understand this. Thank you for all the help. Really appreciate.