Support for ICMP Time Exceeded in REJECT target ?

Support for ICMP Time Exceeded in REJECT target ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Hi everybody,

I'm trying to add some layer 3 functionalities to a Linux-based layer 2 
bridge.

The goal is to enumerate the bridges between two endpoints using the 
traceroute command. As the Linux bridge code routes frames at the ethernet 
level, the IP TTL is not decremented and no ICMP Time Exceeded reply is sent, 
making the bridge transparent.

I experimented with iptables and found out that I can decrement the TTL in the 
PREROUTING chain (mangle table) with

iptables -t mangle -A PREROUTING -j TTL --ttl-dec 1

To generate an ICMP Time Exceeded reply when the TTL reaches zero, I tried the 
REJECT target in the FORWARD chain (filter table). The REJECT target doesn't 
support ICMP Time Exceeded, but it was pretty straightforward to fix this.

Adding

iptables -t filter -A FORWARD -m ttl --ttl-eq 0 -j REJECT --reject-with 
icmp-time-exceeded

the bridges show up in the traceroute output.

Why doesn't REJECT support ICMP Time Exceeded ? Is there a good reason, or is 
it just that nobody has needed it yet ? Should I submit a patch (Linux kernel 
netfilter + userspace iptables) ?

I know that my application breaks the OSI model and creates some kind of 
hybrid "layer 2.5" device. I'm open to suggestions regarding a better way to 
implement bridges enumeration between two ethernet hosts, but using the 
traceroute command is a customer requirement which could only be changed with 
strong valid reasons.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Support for ICMP Time Exceeded in REJECT target ?

[Gáspár Lajos]

Laurent Pinchart írta:

...

> I know that my application breaks the OSI model and creates some kind of 
> hybrid "layer 2.5" device. I'm open to suggestions regarding a better way to 
> implement bridges enumeration between two ethernet hosts, but using the 
> traceroute command is a customer requirement which could only be changed with 
> strong valid reasons.
>   
I'm really curios why would anyone need to enumerate the bridging host?
Could you explain?

Swifty

Re: Support for ICMP Time Exceeded in REJECT target ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Thursday 10 January 2008 09:38, Gáspár Lajos wrote:
> Laurent Pinchart írta:
>
> ...
>
> > I know that my application breaks the OSI model and creates some kind of
> > hybrid "layer 2.5" device. I'm open to suggestions regarding a better way
> > to implement bridges enumeration between two ethernet hosts, but using
> > the traceroute command is a customer requirement which could only be
> > changed with strong valid reasons.
>
> I'm really curios why would anyone need to enumerate the bridging host?
> Could you explain?

Our customer needs IP connectivity between two computers in the engines at 
each end of the train. Each carriage will have an embedded routing device, 
and connecting the carriages together creates a chain that ensures IP 
connectivity.

The customer's application requires enumerating the carriages. One easy 
solution was to enumerate the routing devices in the chain, either using 
their MAC or IP address. Configuring the devices as layer 3 routers would be 
really complex, as all routing tables must be automatically updated whenever 
a carriage is added or removed. Using layer 2 bridges is much easier, but we 
then loose layer 3 route tracing. This is why we thought about making some 
kind of hybrid device that acts as a layer 2 bridge except that it decrements 
the IP TTL and sends an ICMP Time Exceeded message when the TTL reaches 0.

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]