Todor Genov wrote:
Julian Elischer wrote:
Todor Genov wrote:
Hi Julian,
let me rephrase that..
p2p links do not support netmasks. That's all p2p links.. ppp, slip,
tun, ng, gre, etc.
If you what a virtual ethernet interface you may try tap(4) but you will
need to have an appropriatly capable
Julian Elischer wrote:
> Todor Genov wrote:
>> Hi Julian,
> let me rephrase that..
> p2p links do not support netmasks. That's all p2p links.. ppp, slip,
> tun, ng, gre, etc.
>
> If you what a virtual ethernet interface you may try tap(4) but you will
> need to have an appropriatly capable piece o
Todor Genov wrote:
Hi Julian,
Julian Elischer wrote:
Todor Genov wrote:
Hi everyone,
I may have found a routing bug relating to GRE tunnels. Could somebody
try and replicate this?
As per the setup below GRE-encapsulated traffic to 194.31.254.148
should be going out via tun1, but a tcpdump
Hi Julian,
Julian Elischer wrote:
> Todor Genov wrote:
>> Hi everyone,
>>
>> I may have found a routing bug relating to GRE tunnels. Could somebody
>> try and replicate this?
>>
>> As per the setup below GRE-encapsulated traffic to 194.31.254.148
>> should be going out via tun1, but a tcpdump sh
Todor Genov wrote:
Hi everyone,
I may have found a routing bug relating to GRE tunnels. Could somebody
try and replicate this?
As per the setup below GRE-encapsulated traffic to 194.31.254.148
should be going out via tun1, but a tcpdump shows the traffic leaving
via tun0. Any other traffic (i
Hi everyone,
I may have found a routing bug relating to GRE tunnels. Could somebody
try and replicate this?
As per the setup below GRE-encapsulated traffic to 194.31.254.148
should be going out via tun1, but a tcpdump shows the traffic leaving
via tun0. Any other traffic (icmp, tcp etc) destine
