Mark Butler wrote:
James Lentini wrote:
On Tue, 21 Mar 2006, Jason Gunthorpe wrote:
On Tue, Mar 21, 2006 at 03:56:17PM -0800, Stephen Hemminger wrote:
Okay, but there are number of other places in iproute2 that call
ll_addr_a2n() with ifr.ifr_hwaddr.sa_data. And that is 14 bytes.
On Tue, 21 Mar 2006, Jason Gunthorpe wrote:
> On Tue, Mar 21, 2006 at 03:56:17PM -0800, Stephen Hemminger wrote:
>
> > Okay, but there are number of other places in iproute2 that call
> > ll_addr_a2n() with ifr.ifr_hwaddr.sa_data. And that is 14 bytes.
> > If you want to fix those it will be
On Tue, Mar 21, 2006 at 03:56:17PM -0800, Stephen Hemminger wrote:
> Okay, but there are number of other places in iproute2 that call ll_addr_a2n()
> with ifr.ifr_hwaddr.sa_data. And that is 14 bytes. If you want to fix those
> it will be harder since it would increase the sizeof(struct sockaddr)
On Thu, 16 Mar 2006 17:24:41 -0500 (EST)
James Lentini <[EMAIL PROTECTED]> wrote:
>
> The ip(8) command has a bug when dealing with IPoIB link layer
> addresses. Specifically it does not correctly handle the addition of
> new entries in the neighbor/arp table. For example, this command will
>
The ip(8) command has a bug when dealing with IPoIB link layer
addresses. Specifically it does not correctly handle the addition of
new entries in the neighbor/arp table. For example, this command will
fail:
ip neigh add 192.168.0.138 lladdr
00:00:04:04:fe:80:00:00:00:00:00:00:00:01:73:00:00:
