On 11/05/2011 14:59, Simon Kelley wrote:
>
> CAP_NETADMIN is already in use for the DHCP side, so that's not a problem.
> Libnetfilter_conntrac dependency is a bit of a problem, but should be OK.
>
I hadn't noticed that subtlety that it needs to depend on conntrack...
However, superb if it's po
"richardvo...@gmail.com" wrote:
>On Wed, May 11, 2011 at 4:03 AM, Ed W wrote:
>> On 11/05/2011 01:32, richardvo...@gmail.com wrote:
Note that it's the nf_mark we will be setting. But:
get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
>>> That allows you to set a mark for your outgoin
On Wed, May 11, 2011 at 4:03 AM, Ed W wrote:
> On 11/05/2011 01:32, richardvo...@gmail.com wrote:
>>> Note that it's the nf_mark we will be setting. But:
>>> get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
>> That allows you to set a mark for your outgoing packets, and find out
>> what mark is
On 11/05/2011 01:32, richardvo...@gmail.com wrote:
> There's still a large piece of the puzzle missing, namely finding out
> what mark is carried by incoming requests, since this determines that
> mark that goes on the forwarded query (when it cannot be answered from
> cache).
Just to phrase my l
On 11/05/2011 01:32, richardvo...@gmail.com wrote:
>> Note that it's the nf_mark we will be setting. But:
>>get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
> That allows you to set a mark for your outgoing packets, and find out
> what mark is in effect on outgoing packets.
>
> There's still a
> Note that it's the nf_mark we will be setting. But:
> get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
That allows you to set a mark for your outgoing packets, and find out
what mark is in effect on outgoing packets.
There's still a large piece of the puzzle missing, namely finding out
what
On 10/05/2011 09:53, Simon Kelley wrote:
> There's two stages to think about. One: a requestor sends a UDP request
> to dnsmasq. All of these are received by dnsmasq through the same
> listening socket, or a best through a very few sockets.
I'm not 100% sure, but given that dnsmasq can ensure tha
Ed W wrote:
> On 10/05/2011 13:19, Simon Kelley wrote:
>
>> From src/config.h, yo can edit and re-compile if you need to.
>>
>> #define FORWARD_TEST 50 /* try all servers every 50 queries */
>> #define FORWARD_TIME 20 /* or 20 seconds */
>
> Aha - that looks superb
>
> Do you foresee any issues
On 10/05/2011 13:19, Simon Kelley wrote:
> From src/config.h, yo can edit and re-compile if you need to.
>
> #define FORWARD_TEST 50 /* try all servers every 50 queries */
> #define FORWARD_TIME 20 /* or 20 seconds */
Aha - that looks superb
Do you foresee any issues with settings around say th
Ed W wrote:
> Hi
>
>> Jan's answer is completely correct. The only thing to add is that
>> the changes in 2.53 don't make --all-servers the default, they
>> change the behaviour when there is more than one server for a
>> particular domain:
>>
>> --server=/example.net/1.2.3.4 --server=/example.ne
Jan Seiffert wrote:
> 2011/5/10 Ed W :
>> Slightly related - I see that --all-servers might have become the default
>> now?
>>
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q2/003942.html
>>
>> Is there some way to disable this and use "known to be up"? The reason is
>>
2011/5/10 Ed W :
> Slightly related - I see that --all-servers might have become the default now?
>
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q2/003942.html
>
> Is there some way to disable this and use "known to be up"? The reason is that
> I'm seeing a large ICMP "unr
Slightly related - I see that --all-servers might have become the default now?
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q2/003942.html
Is there some way to disable this and use "known to be up"? The reason is that
I'm seeing a large ICMP "unreachable" response generat
Ed W wrote:
> On 10/05/2011 08:06, Simon Kelley wrote:
>> Yes, I would consider such a feature request, and in principle, passing
>> information over from incoming DNS requests to outgoing DNS requests is
>> quite simple. The pointer to Squid is good, it gives API examples which
>> show that thi
On 10/05/2011 08:06, Simon Kelley wrote:
> Yes, I would consider such a feature request, and in principle, passing
> information over from incoming DNS requests to outgoing DNS requests is
> quite simple. The pointer to Squid is good, it gives API examples which
> show that this is quite easy. H
On 10/05/11 00:03, Ed W wrote:
Hi, I have a slightly peculiar requirement to track very accurate *per
user* traffic for a small remote bunch of users. The internet
connections these users have available will be some kind of satellite
telephone with non trivial bandwidth costs and we want to attr
Hi, I have a slightly peculiar requirement to track very accurate *per
user* traffic for a small remote bunch of users. The internet
connections these users have available will be some kind of satellite
telephone with non trivial bandwidth costs and we want to attribute very
exact costs back on a
17 matches
Mail list logo
