tinc - Dec 2003 - ping: Bad Code: 6

Still experimenting with the automesh function.  In the midst of that, I 
encountered a new problem.

Of the 6 linux boxes in my tinc VPN, 3 were RedHat 9, 1 was Suse 9 Pro, 
1 was Fedora Core 1, and one was RedHat 8.0.  All was well.  They were 
running a mix of the static binary and locally compiled-from-source 
binaries.  I updated two of the RedHat 9 boxes to Fedora Core 1, about 3 
days apart.  After the first update, no problem with the tinc tunnels.  
Now, after the second, there is.  The two boxes I've updated cannot talk 
directly to each other through the tunnels.  When I try to ping, I get 
Bad Code:  6.  I can't figure out what that means.  It seems that I can 
get from one linux host to machines on the LAN behind the second linux 
host, but ping times reveal it's not going straight through (automesh 
problem again).  I have ConnectTo statements for all boxes on all 
boxes.  Exactly the same config and hosts files worked just fine before 
I redid the boxes.

I imagine it's something I'm doing on these two Fedora boxes.  The 1, 
original Fedora box is not really under my direct administration, so it 
probably escaped my unintentional wrath.

I figured I'd open this up to the group so, if nothing else, perhaps 
someone could explain what Bad Code 6 is.

As always, thanks.

- Jeff

Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/

On Mon, Dec 01, 2003 at 10:02:09AM -0500, Jeff Pyle wrote:
> Still experimenting with the automesh function.  In the midst of that, I 
> encountered a new problem.
> 
> Of the 6 linux boxes in my tinc VPN, 3 were RedHat 9, 1 was Suse 9 Pro, 
> 1 was Fedora Core 1, and one was RedHat 8.0.  All was well.  They were 
> running a mix of the static binary and locally compiled-from-source 
> binaries.  I updated two of the RedHat 9 boxes to Fedora Core 1, about 3 
> days apart.  After the first update, no problem with the tinc tunnels.  
> Now, after the second, there is.  The two boxes I've updated cannot
talk
> directly to each other through the tunnels.  When I try to ping, I get 
> Bad Code:  6.  I can't figure out what that means.
The standard ping command on Linux is a little bit retarded, and doesn't
know about some very valid ICMP codes, instead claims they are "Bad".
Code 6 means: destination net unknown. It is generated by tinc if you
try to send packets to an IP address for which no Subnet is known.
Either because there really is no such Subnet specified, or because the
tinc daemon which owns that Subnet is not running.

You can do "tincd -n <netname> -kusr2" to let tinc log a list of
all
Subnets it knows about.
> It seems that I can 
> get from one linux host to machines on the LAN behind the second linux 
> host, but ping times reveal it's not going straight through (automesh 
> problem again).  I have ConnectTo statements for all boxes on all 
> boxes.  Exactly the same config and hosts files worked just fine before 
> I redid the boxes.
I wouldn't trust ping times, use tcpdump or increase tinc's logging
verbosity to see if the packets really go straight or not. For example,
start tinc with "tincd -n <netname> -d5 -D".

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus@sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://brouwer.uvt.nl/pipermail/tinc/attachments/20031201/bc53863c/attachment.pgp