其实SYSOP手段也不是万能的,今天被迫动了一下dnsmasq的源码

今天发现电信通拦截DNS请求,把热门流量导向其内部 squid 缓存服务器。今天主要发现有两个,一个是新浪微博的 css 文件所在的域名 timg.sjs.sinajs.cn 被指向了 124.207.162.88 ,另一个是……查看某个视频的时候,浏览器状态栏提示从 124.207.162.83 下载数据,跟新浪微博被拦截的域名指向同一个 IP 段。但是页面里并没有写是从哪个域名下载视频的。于是乎,我想从公司网关的 dnsmasq 上取得数据,却意外的发现 –log-queries 参数无效,开启该参数后,按文档说明发 USR1 信号给 dnsmasq ,syslog 里却没看到 cache dump。

找了一台 Debian 看了看,是可以的。于是我立即习惯性的阴暗的认为是 RedHat 的软件质量问题。找了一套原装正品源码,编译后发现行为也是一样的。无奈了,SYSOP 手段也不是万能的,只好开始看源码。

源码里搜索 log-queries 找到 getopt 这个步骤,找到其内部名字 OPT_LOG。然后在源码文件里找这个,发现了 cache.c 文件里的 cache_dump 函数中,关于 dump cache 功能的逻辑,这一句是这么写的:

if ((daemon->options & (OPT_DEBUG | OPT_LOG)))

回头找一下 OPT_DEBUG,发现是 –no-daemon 参数。也就是说,只有这俩参数同时用,才能 dump cache,这样不符合 manpage 的描述。于是把 OPT_DEBUG 去掉。编译再试,发现还是不行。又

在 src/cache.c 文件的 cache_dump 函数中,发现几句 my_syslog 函数的 log facilty 有问题,改掉,就 OK 了。btw:加语句调试的过程中,觉得这个 my_syslog 长得很像 fprintf。

重新回去放视频,dump cache,终于在日志里看到了这么一句:
[root@dl360g5 log]# tail -f messages|grep 124.207
Nov 16 17:02:39 dl360g5 dnsmasq[24252]: img.uu1001.cn                            124.207.162.83                 4F        Tue Nov 16 17:07:37 2010

已经报了bug。经与作者讨论,发现自己原文中关于 if 语句判断条件的内容是错误的,故修正。真正原因是 dnsmasq 把 cache dump 输出到了 LOG_DEBUG,而 CentOS 的 syslog 默认不记录 *.debug

124.207.162.88
This entry was posted in 默认分类 and tagged , , , , . Bookmark the permalink.

3 Responses to 其实SYSOP手段也不是万能的,今天被迫动了一下dnsmasq的源码

  1. Pingback: 电信通污染专线客户的 DNS 请求,真是太无耻了 | 七月的夏天

  2. suchasplus says:

    很赞啊, beyond sa!

  3. queniao says:

    人家就是一个日志级别问题嘛,你丫的太久没搞代码了

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.