netdev - Re: return of ip_rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Aug 2011 06:37:48 -0700
From:	Tom London <selinux@...il.com>
To:	Julian Anastasov <ja@....bg>
Cc:	Dave Jones <davej@...hat.com>, netdev@...r.kernel.org
Subject: Re: return of ip_rt_bug()

On Fri, Aug 5, 2011 at 6:30 AM, Tom London <selinux@...il.com> wrote:
> On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@...il.com> wrote:
>> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@....bg> wrote:
>>>
>>>        Hello,
>>>
>>> On Thu, 4 Aug 2011, Tom London wrote:
>>>
>>>> So, my router is just giving my wired NIC different addresses....
>>>>
>>>> More I can provide?
>>>
>>>        Thanks! Can you check in dmesg or in another log
>>> about the first IP address in such line:
>>>
>>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>>
>>>        Is it now 192.168.2.6 ?
>>>
>>> Regards
>>>
>>> --
>>> Julian Anastasov <ja@....bg>
>>>
>>
>> Sorry, don't see those messages.  I guess I'll have to reboot with
>> 'debug' to see that.
>>
>> Before I do that, I booted this time with the RFKILL switch set to
>> kill the radio (both BT and WIFI), and reran the above tests.
>>
>> Here is what 'ip monitor' said:
>>
>> [root@...ndon ~]# ip monitor
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> ff02::fb via ff02::fb dev eth0  metric 0
>>    cache
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>>
>> Here is what 'inotail -f /var/log/messages' said:
>>
>>
>> Aug  5 06:12:21 tlondon kernel: [  536.727187] usb 3-1: new full speed
>> USB device number 2 using uhci_hcd
>> Aug  5 06:12:21 tlondon kernel: [  537.315296] usb 3-1: New USB device
>> found, idVendor=04b8, idProduct=010a
>> Aug  5 06:12:21 tlondon kernel: [  537.315308] usb 3-1: New USB device
>> strings: Mfr=1, Product=2, SerialNumber=0
>> Aug  5 06:12:21 tlondon kernel: [  537.315317] usb 3-1: Product: Perfection1640
>> Aug  5 06:12:21 tlondon kernel: [  537.315323] usb 3-1: Manufacturer: EPSON
>> Aug  5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
>> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
>> Aug  5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>>
>> So, no WARN_ON messages.
>>
>> I'd like to conclude that this is due to UDP casting on the wlan.
>> I'll reboot with the radio on and in debug mode to see what happens.
>>
>> tom
>> --
>> Tom London
>>
>
> Hmmm, first attempt at recreating in debug mode didn't actually
> produce any WARN_ON reports.
>
> 'ip monitor' did say:
>
> [root@...ndon ~]# ip monitor
> 239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
>    link/ether
> ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
> ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
> ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
>    link/ether
>
> Will try one more time.
>
> tom
>
> --
> Tom London
>

Can't seem to reproduce this when I boot with 'debug' on the boot line.

Here is what 'ip monitor' says:

[root@...ndon ~]# ip monitor
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether

tom
-- 
Tom London
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html