1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

pixelserv compiled to run on router WRT54G

Discussion in 'Tomato Firmware' started by Jedis, Sep 5, 2009.

  1. HunterZ

    HunterZ Networkin' Nut Member

    Update on HZ10:

    I finally got it building, and the binaries are each a little over 200 bytes larger (probably due to the fact that some extra work is performed to break the child processing into a separate function, and because the child processing no longer gets to inherit main()'s variables for free). That's not bad at all.

    The source is now split up as follows:
    • pixelserv.c contains the main() function, minus almost all of the stuff that happens inside the fork()'d child processes.
    • socket_handler.c contains a socket_handler() function that implements almost all of the logic (everything but closing a couple of file handles) that used to be inside the ford()'d child process. It also contains the static response strings as variables that are global to that file.
    • socket_handler.h contains the public interface to socket_handler().
    • util.c contains the volatile sig_atomic_t stats variables and almost all of the functions other than main() and socket_handler() - most notably signal_handler(), get_version(), get_stats(), etc. I may move all functions that are only used by socket_handler() to socket_handler.c so that they move out of scope of main().
    • util.h contains all of the #define's, system header #include's, response enum, public (extern) interface to the volatile sig_atomic_t stats variables, public interfaces to util.c functions, and changelog comments.

    The only part that still feels a bit yucky is that everything that can be configured via the command line has to be passed on to socket_handler(). There's really no way around this, though. I've thought about encapsulating it all in a struct so that I can just pass that around and so that I could also move command line processing out of main(), but that's probably overkill at this point.

    Still, I feel a lot better about the integrity of the code with it being split up a bit. This will make it harder for bugs to creep in as new features are added.

    Tomorrow I will do a final cleanup pass (probably just moving some stuff from util.c to socket_handler.c) and then start looking into non-blocking pipe I/O.
     
  2. jerrm

    jerrm Addicted to LI Member

    OpenVPN listens on all interfaces/addresses by default.

    Adding "local 123.123.123.123" (with the appropriate IP) to the VPN custom config will bind OpenVPN to a specific IP.

    This can be a little problematic if the WAN IP is dynamic. Tomato's "automatic" and "external" firewall rule options aren't very good if you want to use the LAN IP and will require tweaks.
     
    Last edited: Sep 9, 2014
  3. mstombs

    mstombs Network Guru Member

    To back up other replies, default is now ports 80 and 443 to avoid the need for a DNAT. If you already have a program listening on 443 this pixelserv will fail to start. To only listen on port 80 as per previous versions you must specify "-p 80" on the pixelserv command line, then use your DNAT as before.

    By the way - I think I saw an ad trying to use port 81 the other day, 8080 and 8090 are official alternate http ports, but it seems that 81, 82, are sometimes used. These ports can be added from the command line, but if become more popular (adservers avoiding blocks on port 80?) could change defaults!
     
    Last edited: Sep 10, 2014
  4. Almaz

    Almaz Reformed Router Member


    You are absolutely right. That's what I was having problem with. Pixelserv would fail to start on 443. It would be great to be able to use other ports but using DNAT shouldn't make it any difference.
     
  5. HunterZ

    HunterZ Networkin' Nut Member

    It would actually be nice if pixelserv could just listen to all ports on its IP, but from what little I've found it seems like this is not possible. However, you could probably use an iptables rule to direct all TCP connections on the pixelserv IP to port 80.

    On the other hand, this may make non-HTTP/SSL connections fail more slowly than the default reject-with tcp-reset behavior that I believe adblock sets up for unrecognized ports.
     
  6. leandroong

    leandroong Addicted to LI Member

    My stats update, in case you want some info
    /media/optware/adblock/pixelserv version: V35.HZ8 compiled: Sep 5 2014 20:05:40 from pixelserv.c
    904 req, 0 err, 0 tmo, 12 cls, 0 nou, 0 pth, 95 nfe, 701 ufe, 0 gif, 1 bad, 0 txt, 0 jpg, 0 png, 0 swf, 1 ico, 0 ssl, 3 sta, 0 stt, 91 rdr
     
  7. jerrm

    jerrm Addicted to LI Member

    It can effectively be done via iptables, redirecting all traffic to the desired port.
     
  8. HunterZ

    HunterZ Networkin' Nut Member

    leandroong: Thanks, I was mostly interested in HZ10 reports to see if I could figure out what was causing the slowness for people, but I think it was just weirdness with blocking pipe reads. I'm going to implement non-blocking pipe reads in HZ10, which should hopefully clear up the issue.

    jerrm: That's what I said in the second sentence of your quote :p
     
  9. koitsu

    koitsu Network Guru Member

    ...or you could have just gone with mmap like I told ya. ;) (Sorry, I couldn't resist, haha)
     
  10. HunterZ

    HunterZ Networkin' Nut Member

    That would be complicated because multiple child processes could try to write data at the same time, and the parent could try to read at the same time as the children are writing. The pipe works like a thread safe queue, which makes it comparatively simple.
     
  11. koitsu

    koitsu Network Guru Member

    Sort of -- that's what semaphores/mutexes are for. pipe(2) with O_NONBLOCK would be sufficient, sort of -- you need to watch out for edge cases like when write(2) only does a partial write due to the pipe buffer becoming full (errno=EAGAIN). With O_NONBLOCK and writes exceeding PIPE_BUF (I can't tell per pipe(7) if on Linux this is 65536, 4096, or 512 -- really I can't), you end up with interspersed/interleaved written data, at which point you might as well just implement a basic global mutex/semaphore. *grunts* Yay programming... Haha :)
     
  12. HunterZ

    HunterZ Networkin' Nut Member

    lol well we'll see how it goes. I'm only writing and reading a single int over the pipe for each browser connection that is handled, so it would be surprising to see a pipe buffer overflow.

    On the other hand, a mutex would simplify things because I could store all the stats in shared memory and let the child processes/threads queue up to directly increment the stat counters, instead of using the current method of looking at the exit codes of the child processes in a signal handler to figure out which counter to increment. Edit: It would also eliminate the possible ugliness of the pipe read and stats update needing to occur in the main thread, which steals some time away from dispatching incoming socket connections to child processes.
     
  13. mstombs

    mstombs Network Guru Member

    Presumably the static version was compiled 1 second after the dynamic? Here's what mine currently reports

    Code:
    /pixelserv version: V35.HZ8 compiled: Sep 5 2014 20:05:39 from pixelserv.c
    16408 req, 0 err, 1377 tmo, 34 cls, 0 nou, 0 pth, 937 nfe, 7877 ufe, 215 gif, 384 bad, 0 txt, 2 jpg, 3 png, 55 swf, 9 ico, 4269 ssl, 24 sta, 0 stt, 1222 rdr
    Must find out what device(s) generating most of the timeouts!
     
  14. HunterZ

    HunterZ Networkin' Nut Member

    Yes, I modified build.sh to pop out host, standard, static, and tiny binaries.
     
  15. HunterZ

    HunterZ Networkin' Nut Member

    Testing HZ10 now, with pipe I/O being monitored by the same select() call that waits for socket connections in multiport mode. Pipe reads are handled in main() at a lower priority than dispatching socket connections to handler processes. I also made a small optimization of building the select() file descriptor set only once instead of prior to every select() call.

    Before I release it (sometime tomorrow hopefully), does anyone have any objection with the redirect feature being enabled by default? I will probably make the -r parameter do nothing, and add -R for *disabling* redirect, so that I don't break people's launcher scripts (e.g. adblock.sh).

    I'm also thinking of adding an pixelserv uptime dump to the stats report. I'm not sure if calling clock() from time.h is the best way to do it, versus just using system time deltas (koitsu question I guess?), as clock() has some funny language about processor time consumed, which I'm worried may mean that it could get thrown off by idle-versus-busy time or by forking.
     
  16. mstombs

    mstombs Network Guru Member

    Not sure this works, the sets can be modified by the select call, and I just copied some example code from somewhere. But thinking about it, I am not sure we currently handle multiple sockets becoming readable at same time, so resetting the sets may lose connections? This is also the select that needs that retry macro, and I was also unsure about the first parameter, some examples use a big number, others +1 on the last file descriptor. I think I tried most combinations before...

    Fine by me, code seems robust (I didn't crash it!) but can't yet handle all Google ad links, so development to be encouraged!

    I'm sure many examples in the Tomato source, I'm sure I've seen gettimeofday used, shouldn't be an issue if only looking at the seconds part, but you will need to add code comment about fact that the 32 bit time is going to rollover in 2038..
     
  17. jerrm

    jerrm Addicted to LI Member

    I'd vote for it being default too. Greatly improves the adblock experience IMO.
     
  18. Goggy

    Goggy LI Guru Member

    I am too voting for -r as default ...
     
  19. HunterZ

    HunterZ Networkin' Nut Member

    I found some other example code that generates the set once and then makes a copy at the start of the loop for select to operate on. It seems to work.

    I'm assuming that when multiple descriptors are ready but we only read from one of them, select will return immediately on the next call, as the remaining descriptors should still be ready for reading. The only potential danger is probably an increased chance of timeout, but that's probably a low risk in this application.

    Still, I will probably put in some logic to remove FDs from the working copy set as I handle them, and then skip the select call on subsequent loop iterations when the set is not empty. When the set becomes empty I will just re-copy the master set to the working set and make another call to select. This will have the advantage of avoiding the wasted time of unneeded select calls while also preventing newer connections from getting priority over old ones.
     
  20. Beast

    Beast LI Guru Member

    I vote yes to enable -r by default. HZ put a lot of work into getting it to work and as far as I can see, all of us want it to work.
     
  21. AndreDVJ

    AndreDVJ Connected Client Member

    I vote yes, to enable redirection by default.
     
  22. HunterZ

    HunterZ Networkin' Nut Member

    So I had what appeared to be a temporary hang during a stats request, which lasted for a minute or two and manifested as a spinning page load icon in Firefox. Syslog showed that the socket write failed with a broken pipe status while servicing the stats request, which apparently indicates that the socket was closed before or during the write. Unfortunately I don't see a better way to handle this (fortunately rare) situation, especially since the code is already pretty paranoid and handles each socket connection in a fork process.

    I'm still hemming and hawing over the best way to get program uptime (i.e., elapsed time since program start), as there isn't an obvious facility for it (especially in the 2.4 kernel). It would be nice if it weren't affected by system clock time changes, in case pixelserv is started before the system time is set on boot.

    Edit: I got redirect enabled by default this morning in my local copy, with -r now ignored (but not generating errors, for backwards compatibility) and -R recognized as a request to disable redirect. I should probably move the command line handling to a separate function or two for readability purposes, but I want to get HZ10 out first.
     
    Last edited: Sep 14, 2014 at 2:17 AM
  23. koitsu

    koitsu Network Guru Member

    If you're needing this within the program itself, the easiest way to do it is to use clock_gettime(), but it really depends on what you're trying to track/accomplish. I'm always wary of mentioning that function to people, because people end up doing things like using it while() loops without sleep() or other conditionals and with certain params it can cause a major performance hit on the kernel. (Here's an example of some mainstream nosql database crap that uses select() as a course timer instead of clock_gettime(), the result being the daemon chews up 7-10% CPU at all times. MongoDB, what a pile...)

    Another possible solution is to look at the mtime of /proc/{pid}/stat (meaning the "file" itself). That shouldn't change unless the process is actually restarted (while most other files in /proc/{pid} will show present time). I read one post somewhere from some dude that said the time is sometimes wrong of /proc/{pid}/stat, but I haven't seen any sign of that on my RT-N66U -- ls -l /proc/[0-9]*/stat looks correct to me. The rest would be simple math, but you'd probably need to call gettimeofday() (which can be expensive sometimes), and that just circles back around to discussing clock_gettime() again.

    The other solution is to read the 22nd field of /proc/{pid}/stat. See proc(5) for the format of that file and the format of that field (be aware that it's a 64-bit unsigned number). On Linux 2.6 you have to divide the number by sysconf(_SC_CLK_TCK), since the number is represented in clock ticks. On Linux 2.4 the number is represented in jiffies, and you may have to parse /proc/timer_list to figure that out (I'm really not familiar with jiffies... frickin' made-up time units, gee thanks...)

    Hope this helps in some manner!
     
  24. HunterZ

    HunterZ Networkin' Nut Member

    Thanks.

    How expensive is it to look at /proc stuff versus making time.h calls?

    Do I have to access /proc stuff by opening it as a file, or is there a C API for it that works well enough on K24?

    Edit: To clarify, I just want to be able to calculate the time in seconds since the program was started. I'm not interested in processor utilization times or any of that voodoo.
     
  25. koitsu

    koitsu Network Guru Member

    In True UNIX Fashion(tm), almost everything under /proc is a file, meaning you treat them just as you would a standard file on a filesystem. You can absolutely call stat(2) on something in /proc and get details about it just as you would a normal file outside of /proc. No need for an API -- that's the beauty of /proc on Linux.

    It's not expensive at all to look at /proc/{pid}/something. You know what your own process pid is (through getpid()), so:

    Code:
    char mystatfile[PATH_MAX];
    struct stat sb;
    pid_t mypid = getpid();
    
    /* Maybe %d not %u; can't remember if pid_t is signed or unsigned */
    /* Also add code to make sure snprintf() copied enough data */
    snprintf(mystatfile, sizeof(mystatfile), "/proc/%u/stat", mypid);
    
    /* Make sure to handle error scenarios where stat() fails (ex. == -1). */
    /* It shouldn't, but never assume everything works.  :) */
    /* Brain isn't working right now, maybe this should be stat(&mystatfile, &sb); */
    stat(mystatfile, &sb);
    
    printf("process started: %s\n", ctime(&sb.st_mtime));
    
    (Now if only the BSD guys would follow suit and stop with this sysctl nonsense... ;) So sad to see Linux people jumping on that ship too)

    You can figure out the offset/how many seconds the thing has been running by doing simple math between a couple clock fields. If you're going to do time differential, however, make sure you use things that go off of localtime and not gmtime -- if I remember right the time stored is localtime, not gmtime.

    The only question I'd have is: how often do you need to know the uptime of the process? Is it something you need every second? Or is it only returned if, say, someone polls a status port the process listens on, etc.? If the latter, then doing the math only when queried isn't that bad. If it's something you need constantly, then calling clock-related function (ex. gettimeofday(2)) can be expensive, and you may want to look into using clock_gettime() instead (those return timespec structs with time_t tv_sec which is what you'd want)

    P.S. -- I hate time_t. It's one of the *IX typedefs that is utterly ridiculous because on some platforms it's an unsigned long, other it's a signed long, and on (many) it's a signed long long. Figuring out how to print this as a decimal/integer number is a PITA because you have to force cast -- yet you don't know what to cast because it varies per arch... *sigh* :)
     
  26. HunterZ

    HunterZ Networkin' Nut Member

    So /proc/{pid}/stat is created when the program starts, and its modification timestamp is never changed?

    It's only going to be called when a TCP client requests statistics, and possibly when the program is terminated. This means that it should happen fairly rarely unless someone is doing a denial-of-service attack test, in which case they deserve whatever behavior they get.


    I should point out that the following quote from gettimeofday()'s man page scares me in regards to what I want to use it for:
    This is potentially problematic because the lack of RTC on routers means that it's conceivable that the time may jump from something like POSIX epoch to current time *after* pixelserv is started.

    clock_gettime(CLOCK_MONOTONIC, ...) sounds better, but can still me messed up by NTP. Unfortunately CLOCK_MONOTONIC_RAW is not available in Linux 2.4.

    I guess I'll run clock_gettime(CLOCK_MONOTONIC) early in main() to capture something close to a startup time, then call it again as needed and calculate the difference to get the elapsed uptime of the program.


    Edit: I wonder how the Linux 'uptime' command is implemented? I couldn't grok it from reading the source that I dug up because there were too many API layers. I suppose I could also just snapshot that at start of main() and then read it again as needed and take a difference.
     
    Last edited: Sep 14, 2014 at 7:48 AM
  27. mstombs

    mstombs Network Guru Member

    miniupnpd uses time and uptime at start - but presumably is vulnerable to big clock changes after start, and only seems to use to schedule rule cleanings

    see for example
    http://repo.or.cz/w/tomato.git/blob/HEAD:/release/src/router/miniupnpd/miniupnpd.c#l326
    http://repo.or.cz/w/tomato.git/blob/HEAD:/release/src/router/miniupnpd/miniupnpd.c#l1025
     
  28. koitsu

    koitsu Network Guru Member

    Correct. As mentioned I have seen only one post/comment from some random Internet dude saying his changed (while the program was running), and that is something I have never seen in my entire life. The mtime should not (will not) change. Forked children would get their own PIDs, so the parent PID's mtime (for /proc/{parentpid}/stat}) would remain the same. Pretty simple.

    Worrying about how Linux "uptime" is implemented I don't think is relevant -- that's all kept track of and managed in the kernel, where you have direct/easy access to timecounters (tied into interrupts; like on an x86 PC you'd probably have TSC, ACPI, or HPET available to keep track of time at a consistent interval). You're in userland, so you're limited to what libc and syscalls provide.
     
  29. HunterZ

    HunterZ Networkin' Nut Member

    I implemented some code to take a clock_gettime(CLOCK_MONOTONIC, ...) reading at program start, and then it takes another whenever stats are generated and does a difftime().

    Also, I think you mentioned earlier not being sure what the pipe() buffer size is. On my RT-N66U, PIPE_BUF is 4096 bytes.
     
  30. HunterZ

    HunterZ Networkin' Nut Member

    HZ10 released (finally!): https://github.com/HunterZ/pixelserv/releases/tag/V35.HZ10

    Tons of under-the-hood changes, but here is what may be noticeable to end-users:
    • Redirect is now enabled by default:
      • -r no longer does anything (but doesn't generate an error either).
      • -R has been added to *disable* redirect if desired.
    • Uptime (in seconds) of the program is now reported in the stats.
    • Binary sizes are a bit larger for various reasons.
      • If this is problematic for anyone, it's still possible to reduce size by building without some features.
    • A new binary flavor is included, pixelserv.fast, which is optimized for performance (-O3) instead of the standard size optimization (-Os).

    Functionally, the biggest under-the-hood change is that the same code used to watch for incoming socket connections also watches for reception size data from child processes. This means that it no longer has to *expect* pipe data from each child process, but can instead just process whatever comes in whenever it comes in. If this works better for people, I may eventually move all stats reporting to the pipe mechanism, as I think it may be a bit cleaner than the current system of catching child process exit status in a signal handler.

    Edit: Also, pipe reads/writes are non-blocking in an attempt to further avoid hangs.


    I've also broken up the code into multiple files (as I mentioned previously), which I believe makes the code more maintainable and easier to follow. There are probably other opportunities to break it down further, but it's probably not worth the bother at this time.

    Sorry for the long wait. I kept thinking of new things to add or tweak.
     
    Goggy likes this.
  31. leandroong

    leandroong Addicted to LI Member

    /media/optware/adblock/pixelserv version: V35.HZ10 compiled: Sep 14 2014 22:08:47
    22 uts, 1 req, 0 avg, 0 rmx, 0 err, 0 tmo, 0 cls, 0 nou, 0 pth, 0 nfe, 0 ufe, 0 gif, 0 bad, 0 txt, 0 jpg, 0 png, 0 swf, 0 ico, 0 ssl, 1 sta, 0 stt, 0 rdr

    Still same loading of youtube main page under win7, https://www.youtube.com/

    I did some stupid experimentation of cgi script and adblock:
    1. No more sources downloading, I did it manually
    2. combine all sources into blocklist format (manually also)
    3. modify adblock.sh, almost remove all, it just need to monitor action for stop,restart.
    3. CGI script only has actions for "restart", "stop" and "log erase"
    All this changes result in faster loading, less than 2 secs.
     
    Last edited: Sep 15, 2014 at 9:44 AM
  32. leandroong

    leandroong Addicted to LI Member

    anyway, I consider it perfect enough, I don't mind waiting for youtube loading for 1 min. Thanks again
     
  33. leandroong

    leandroong Addicted to LI Member

    @HunterZ, my slow youtube main page downloads due to ads "ad.doubleclick.net" has been solved by my router. Padavan FW has firewall->URL Filter, after adding that, opening of main youtube become spontaneous.
    Now, I'm so happy.
     
  34. HunterZ

    HunterZ Networkin' Nut Member

    That's good to hear!

    I'm also curious to know whether anyone on Tomato has good or bad experiences with HZ10, compared to HZ8 and HZ9.
     
  35. leandroong

    leandroong Addicted to LI Member

    ad.doubleclick.net is handle by padavan FW using iptable, if i'm not mistaken

    Chain urllist (1 references)
    target prot opt source destination
    REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 webstr: url ad.doubleclick.net reject-with tcp-reset

    In terms of speed HZ10 seems to be faster. Here is my stats
    /media/optware/adblock/pixelserv version: V35.HZ10 compiled: Sep 14 2014 22:08:47
    19865 uts, 482 req, 317 avg, 1096 rmx, 0 err, 0 tmo, 3 cls, 0 nou, 0 pth, 17 nfe, 311 ufe, 1 gif, 0 bad, 0 txt, 0 jpg, 0 png, 0 swf, 1 ico, 137 ssl, 9 sta, 0 stt, 3 rdr
     
  36. HunterZ

    HunterZ Networkin' Nut Member

    Hmm, looks like your pixelserv is serving mostly JavaScript (ufe) and SSL (ssl) responses.

    It looks like Youtube uses SSL (HTTPS) connections for ad.doubleclick.net stuff. I wonder if that's somehow related to your slowdowns, and whether it's also related to something in Padavan versus Tomato.

    You may want to try the old way of having iptables reject *all* port 443 traffic on the pixelserv IP with a tcp-reset, instead of letting it go to pixelserv. It may be faster for your setup.
     
  37. leandroong

    leandroong Addicted to LI Member

    https://www.youtube.com/
    ad.doubleclick.net is the reason of slow page loading, waiting for 1 min before proceed loading the rest of photos.
    How do I enter that in iptables? I can test

    edit2: with the added iptables, waiting time is reduce to almost 0 sec
     
    Last edited: Sep 15, 2014 at 6:26 PM
  38. mstombs

    mstombs Network Guru Member

    No slowdowns here with HZ8 or previous pixleserv with Chrome+adblock or IE on Win7. I wouldn't have thought iptables alone would work - see the big thread on trying block https with access restrictions! I can only see one link to ad.doubleclick.net a long url including a big random number. If I click on that on its own in Chrome immediately get "Certificate-based authentication failed" as expected.

    To check if a host (or domain) is blocked from a win7 cmd window :-

    Code:
    C:\Users\>nslookup ad.doubleclick.net
    Server:  rtn66u.lan
    Address:  192.168.66.1
    
    Name:    ad.doubleclick.net
    Address:  192.168.66.254
    if that doesn't resolve to the pixelserv IP its not a problem with this thread!
     
    jerrm likes this.
  39. HunterZ

    HunterZ Networkin' Nut Member

    What about HZ10?
     
  40. mstombs

    mstombs Network Guru Member

    Not yet downloaded...

    have now...

    off with the old, on with the new

    Code:
    Sep 6 11:26:45 rtn66u daemon.info pixelserv[31742]: /mnt/usb4gb/pixelserv version: V35.HZ8 compiled: Sep 5 2014 20:05:39 from pixelserv.c
    Sep 6 11:26:45 rtn66u daemon.notice pixelserv[31744]: Listening on :192.168.66.254:80
    Sep 6 11:26:45 rtn66u daemon.notice pixelserv[31744]: Listening on :192.168.66.254:443
    ...
    Sep 15 21:19:23 rtn66u daemon.info pixelserv[31744]: 24455 req, 0 err, 1985 tmo, 58 cls, 0 nou, 0 pth, 1217 nfe, 11570 ufe, 283 gif, 500 bad, 0 txt, 2 jpg, 4 png, 58 swf, 10 ico, 7191 ssl, 26 sta, 0 stt, 1551 rdr
    Sep 15 21:19:23 rtn66u daemon.notice pixelserv[31744]: exit on SIGTERM
    Sep 15 21:20:10 rtn66u daemon.info pixelserv[2455]: /mnt/usb4gb/pixelserv.fast version: V35.HZ10 compiled: Sep 14 2014 22:08:48
    Sep 15 21:20:10 rtn66u daemon.notice pixelserv[2457]: Listening on :192.168.66.254:80
    Sep 15 21:20:10 rtn66u daemon.notice pixelserv[2457]: Listening on :192.168.66.254:443
    
    working fine, no slowdowns, also noticed my process IDs have looped, uptime 28 days.

    Code:
    /mnt/usb4gb/pixelserv.fast version: V35.HZ10 compiled: Sep 14 2014 22:08:48
    700 uts, 146 req, 282 avg, 1626 rmx, 0 err, 2 tmo, 0 cls, 0 nou, 0 pth, 9 nfe, 19 ufe, 4 gif, 0 bad, 0 txt, 0 jpg, 0 png, 0 swf, 0 ico, 105 ssl, 5 sta, 0 stt, 2 rdr
    playing pixelserv bingo, I can't generate err or txt, can anyone?

    Code:
    /mnt/usb4gb/pixelserv.fast version: V35.HZ10 compiled: Sep 14 2014 22:08:48
    3333 uts, 452 req, 364 avg, 2191 rmx, 0 err, 41 tmo, 1 cls, 1 nou, 1 pth, 22 nfe, 134 ufe, 12 gif, 9 bad, 0 txt, 1 jpg, 1 png, 1 swf, 1 ico, 190 ssl, 16 sta, 4 stt, 15 rdr
     
    Last edited: Sep 15, 2014 at 10:17 PM
  41. strictlyfocused

    strictlyfocused Network Newbie Member

    Ive been running HZ10 since it was released this morning and I think it's easily the best version yet. Everything I've tested has worked great (youtube, redirects, etc). This is on an e3200 running the latest (121) build from Shibby.
    Code:
    /mnt/sda1/adblock/pixelserv version: V35.HZ10 compiled: Sep 14 2014 22:08:47
    26702 uts, 1375 req, 343 avg, 1823 rmx, 0 err, 32 tmo, 0 cls, 0 nou, 0 pth, 32 nfe, 129 ufe, 1 gif, 3 bad, 0 txt, 0 jpg, 1 png, 0 swf, 2 ico, 899 ssl, 3 sta, 0 stt, 273 rdr
    
     
  42. vincom

    vincom Addicted to LI Member

    HunterZ you should start a new thread for this
    question, newb howto instructions on getting this installed for the ac66u
    i do have adblock w/piexlserv v34 running now from the script-clean-lean-and-mean-adblocking thread
     
  43. HunterZ

    HunterZ Networkin' Nut Member

    vincom: My pixelserv V35.HZ10 should work as a drop-in replacement for pixelserv v34.
     
  44. vincom

    vincom Addicted to LI Member

    so i just copy pixelserv, pixelserv.fast, pixelserv.static, and pixelserv.tiny to my adblock folder where adblock.sh and my current pixelserv are located
     
    Last edited: Sep 16, 2014 at 8:58 PM
  45. AndreDVJ

    AndreDVJ Connected Client Member

    Honestly I did not experience such issues with slowdowns...

    About the build, you can pick one of them. I compiled the "fast" version and I am using it now. You should not have space issues.
     
  46. HunterZ

    HunterZ Networkin' Nut Member

    Just use pixelserv, or rename pixelserv.fast to pixelserv if you want to go for performance over size.
     
  47. AndreDVJ

    AndreDVJ Connected Client Member

    HunterZ,

    Happened with me the same issue as leandroong. Thumbnails take ages to load on YouTube.

    I got this from syslog
    Code:
    Sep 16 20:07:07 WNR3500L daemon.err pixelserv[7247]: attempt to send response for status=22 resulted in send() error: Connection reset by peer
    Sep 16 20:07:07 WNR3500L daemon.warn pixelserv[7247]: connection handler exiting with EXIT_FAILURE status
    Sep 16 20:07:07 WNR3500L daemon.err pixelserv[7248]: attempt to send response for status=20 resulted in send() error: Connection reset by peer
    Sep 16 20:07:07 WNR3500L daemon.warn pixelserv[7248]: connection handler exiting with EXIT_FAILURE status
    Sep 16 20:07:07 WNR3500L daemon.err pixelserv[7249]: attempt to send response for status=20 resulted in send() error: Connection reset by peer
    Sep 16 20:07:07 WNR3500L daemon.warn pixelserv[7249]: connection handler exiting with EXIT_FAILURE status
    Sep 16 20:07:07 WNR3500L daemon.err pixelserv[7250]: attempt to send response for status=22 resulted in send() error: Connection reset by peer
    Sep 16 20:07:07 WNR3500L daemon.warn pixelserv[7250]: connection handler exiting with EXIT_FAILURE status
    Sep 16 20:07:07 WNR3500L daemon.err pixelserv[7251]: attempt to send response for status=22 resulted in send() error: Connection reset by peer
    Sep 16 20:07:07 WNR3500L daemon.warn pixelserv[7251]: connection handler exiting with EXIT_FAILURE status
    
    The following have been blocked around that time...
    Code:
    Sep 16 20:07:07 192.168.1.100 www.googletagservices.com
    Sep 16 20:07:07 192.168.1.100 www.google-analytics.com
    Sep 16 20:07:07 192.168.1.100 cdn.mxpnl.com
    Sep 16 20:07:05 192.168.1.100 gg.google.com
    Sep 16 20:07:05 192.168.1.100 ad.doubleclick.net
    I also noticed that pixelservip/servstats (http://192.168.1.254/servstats) wasn't working. The page with the stats refused to load. I restarted pixelserv and cleared the issue.

    If you need I can provide my dnsmasq/syslog logs (I save all kinds of logs on a USB flash drive).
     

Share This Page