[LARTC] (null) in ip route get

2006-12-19 Thread Radek Vokál
1460 advmss 64 -- Radek Vokál <[EMAIL PROTECTED]> Base OS Engineering - Team Lead Office: +420 543 422 235 Red Hat Inc. http://www.redhat.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-

[LARTC] Hardcoded /usr/lib dir

2006-09-19 Thread Radek Vokál
tc.c has the following line snprintf(buf, sizeof(buf), "/usr/lib/tc/q_%s.so", str); the libdir should not be hardcoded but it should be detected at build time. Radek -- Radek Vokál <[EMAIL PROTECTED]> Base OS Engineering Office: +420 543 422

[LARTC] [PATCH] missing flags for ip link

2006-08-21 Thread Radek Vokál
There's a flag 1 that is not recognized by iproute. The kernel uses #define IFF_LOWER_UP0x1 /* driver signals L1 up */ #define IFF_DORMANT 0x2 /* driver signals dormant */ -- Radek Vokál <[EMAIL PROTECTED]> --- iproute2-2.6.1

[LARTC] no PROMISC mode ..

2006-08-02 Thread Radek Vokál
Hi, I'm not convinced I'm facing a bug, I was reading some code and also reading some threads and finally reached this conclusion, please let me know if it's not clear enough and also if you don't agree : - The case it shows the flag with iproute is because it's using a single flag set.

[LARTC] no PROMISC mode in ip link show

2006-07-28 Thread Radek Vokál
to work even with newer kernels (I'm on 2.6.17 now with the latest iproute package) I found these links about the issue http://www.tcpdump.org/lists/workers/2001/01/msg00184.html http://lists.virus.org/bugtraq-0207/msg00363.html Radek -- Radek Vokál <[EMAIL P

[LARTC] ip route doesn't not work with virtual inferfaces

2005-12-05 Thread Radek Vokál
eth0, not the IP of eth0:1 as one would expect. What's strange to me is that ip route list dev eth0:1 shows same output as ip route list dev eth0 is this expected behavior or is there a bug? Radek -- Radek Vokál <[EMAIL PROTECTED]> signature.asc Description: This is a digit

Re: [LARTC] ip tunnel doesn't show warning or error

2005-10-31 Thread Radek Vokál
On Mon, 2005-10-31 at 08:59 +0100, Radek Vokál wrote: > This is really strange behavior .. > > [EMAIL PROTECTED] ~# ip tunnel add testing123 mode ipip remote 192.168.1.1 > local 192.168.1.12 > [EMAIL PROTECTED] ~# ip tunnel show > .. > testing123: ip/ip remote 192.168.1.

[LARTC] ip tunnel doesn't show warning or error

2005-10-31 Thread Radek Vokál
remote 192.168.1.1 local 192.168.1.12 [EMAIL PROTECTED] ~# echo $? 0 [EMAIL PROTECTED] ~# ip tunnel show .. testing123: ip/ip remote 192.168.1.1 local 192.168.1.12 ttl inherit I guess the second tunnel add should end up with an error, but ioctl doesn't report anything on this .. -- Radek

[LARTC] Bug in ip -6?

2005-10-26 Thread Radek Vokál
refix 001b is the unicast global address range assigned by IANA, and all other unicast address rage is 'unassigned'. But 'unassigned' does not mean illegal. It's only administrative purpose. Implementation should not get such restriction. Is he correct? Should this be f

Re: [LARTC] buffer overflow in ip

2005-10-06 Thread Radek Vokál
ATA(tb[RTA_PREFSRC]), host_len/8); } if (filter.rdst.family && inet_addr_match(&dst, &filter.rdst, filter.rdst.bitlen)) host_len should be divided by 8, as it's units is bits, where memcpy is using bytes units. On Thu, 2005-10-06 at 15:37 +0200, Radek Vokál

[LARTC] buffer overflow in ip

2005-10-06 Thread Radek Vokál
t;argc" is not available. ) at iproute.c:1219 #8 0x08049579 in do_cmd (argv0=0xbfa69b34 "route", argc=6, argv=0xbfa6816c) at ip.c:84 #9 0x08049a90 in main (argc=7, argv=0xbfa68168) at ip.c:225 #10 0x0087cd5f in __libc_start_main () from /lib/libc.so.6 #11 0x08049431 in _start () -- Ra