On 4/15/2019 9:37 AM, Igor Ryzhov wrote:
> Hi Ferruh,
>
> To be absolutely sure, I performed a test using the test application.
>
> When I send pings from an interface:
> 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:c8:79:c6 brd ff:ff:ff:ff:ff:ff
>
> Here is what's in sockaddr_ll:
> $2 = {sll_family = 0x11, sll_protocol = 0x8, sll_ifindex = 0x2, sll_hatype
> = 0x1, sll_pkttype = 0x0, sll_halen = 0x6, sll_addr = {
> 0x52, 0x54, 0x0, 0xc8, 0x79, 0xc6, 0x0, 0x0}}
>
> So everything works as expected – the address in sll_addr is correct.
> Last two bytes are zero because the length of sll_addr is 8, however,
> Ethernet length is 6.
Perfect, thanks for confirming, I am OK with the patch.
For my case sll_halen = 0x6 but only first 4 byte of the sll_addr was the valid,
so it was not the issue of size of sll_addr being 8, anyway it was quick dirty
app, something should be wrong, I believe not need to dig it more.
>
> Igor
>
> On Fri, Apr 12, 2019 at 8:15 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote:
>
>> On 4/12/2019 6:12 PM, Igor Ryzhov wrote:
>>> Hi Ferruh,
>>>
>>> I didn't test it with any special application, but FRR's ISIS works for
>> me after
>>> the patch, and it didn't work before.
>>
>> That is good enough, and by work you mean that you are able to get correct
>> value
>> on 'sll_addr', right?
>>
>>>
>>> Igor
>>>
>>> On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit <ferruh.yi...@intel.com
>>> <mailto:ferruh.yi...@intel.com>> wrote:
>>>
>>> On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
>>> > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
>>> >> It allows applications running packet sockets over KNI interfaces
>> to get
>>> >> source Ethernet addresses of packets received using recvfrom
>> function.
>>> >>
>>> >> Signed-off-by: Igor Ryzhov <iryz...@nfware.com <mailto:
>> iryz...@nfware.com>>
>>> >
>>> > Acked-by: Ferruh Yigit <ferruh.yi...@intel.com
>>> <mailto:ferruh.yi...@intel.com>>
>>> >
>>> >
>>> > Hi Igor,
>>> >
>>> > I tested this with a quick application on top of kni interfaces,
>> that
>>> reads and
>>> > prints the 'sll_halen', but the last two bytes of the mac address
>> are always
>>>
>>> I mean 'sll_addr', 'sll_halen' is right (6).
>>>
>>> > zero, it is quite possible that something is not right in the test
>> app, but
>>> > before spending any time on it, can you please confirm this is
>> working
>>> fine for you?
>>> >
>>>
>>
>>
