undefined | Better HN

0 pointsskuhn5y ago0 comments

Yeah, that's coming from these four Fastly VCL variables:

conn_speed: https://developer.fastly.com/reference/vcl/variables/geoloca...

conn_type: https://developer.fastly.com/reference/vcl/variables/geoloca...

proxy_desc: https://developer.fastly.com/reference/vcl/variables/geoloca...

proxy_type: https://developer.fastly.com/reference/vcl/variables/geoloca...

conn_type is interesting to me, I'm not sure how you would distinguish wifi vs. wired based on HTTP header data.

0 comments

donavanm5y ago

I haven’t worked in the space in a while but I’d doubt it’s via anything like HTTP headers. From a total guess I’d look at packet inter frame gaps & jitter to imply client csmacd or l2 behavior. Maaaaybe MTU and TTLs to infer intermediate routed networks or devices like the tunnel. And of course various TCP options and behavior, like say timestamps and dsack, to fingerprint the client or intervening ip proxies.

benjojo125y ago

There is a good chance it's just https://dev.maxmind.com/geoip/geoip2/geoip2-connection-type-...

cagenut5y ago

it used to be, for years, thats the older stuffin the "geoip.<key>" namespace.

the stuff in the "client.geo.<key>" space is from a newer/better/higher-tier service (they say, i forget the name). also I think some of it is mixed in with other sources and some of the info is self-sourced.

jaywalk5y ago

Whatever it's using for conn_type, it's not accurate. I get "wifi" on all of my computers, wired or wireless.

j / k navigate · click thread line to collapse