little-dude / netlink

netlink libraries for rust
Other
329 stars 89 forks source link

Why is the route table index limited to u8 in RouteAddRequest? #181

Open jamesmcm opened 3 years ago

jamesmcm commented 3 years ago

The table method of RouteAddRequest accepts only a u8 ID, but from the ip route manpage it seems a u32 should be accepted?

Route tables: Linux-2.x can pack routes into several routing tables identified by a number in the range from 1 to 2^32-1 or by name from the file /etc/iproute2/rt_tables By default all normal routes are inserted into the main table (ID 254) and the kernel only uses this table when calculating routes. Values (0, 253, 254, and 255) are reserved for built-in use.

Is there a reason why this only accepts u8? I'm not an expert on Linux networking at all, I was just trying to convert some scripts and unfortunately they used higher table indices.

little-dude commented 2 years ago

Hey @jamesmcm

Sorry for the late reply.

According to the rtnetlink man page this is indeed an u8 (for historic reasons I guess):

struct rtmsg {
                  unsigned char rtm_family;   /* Address family of route */
                  unsigned char rtm_dst_len;  /* Length of destination */
                  unsigned char rtm_src_len;  /* Length of source */
                  unsigned char rtm_tos;      /* TOS filter */
                  unsigned char rtm_table;    /* Routing table ID;
                                                 see RTA_TABLE below */
                  unsigned char rtm_protocol; /* Routing protocol; see below */
                  unsigned char rtm_scope;    /* See below */
                  unsigned char rtm_type;     /* See below */

                  unsigned int  rtm_flags;
              };

However, as you said it's not unusual to have higher table IDs. To do that, you need to use an extra attribute:

          RTA_TABLE       int                   Routing table ID; if set, rtm_table is ignored

This corresponds to the netlink_packet_route::rtnl::route::nlas::Nla::Table

I didn't pay attention to this earlier but this is indeed a bit problematic. I think there are multiple things we can do improve things: