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]
Message-ID: <45E7C45F.9080805@candelatech.com>
Date:	Thu, 01 Mar 2007 22:29:51 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	NetDev <netdev@...r.kernel.org>
Subject: Re: ppp and routing table rules.

Ben Greear wrote:
> Hello!
>
> I have a suspicion (but no proof at this time) that a rule like this:
>
> 20:     from all iif ppp400 lookup 10001
>
> is not actually working for ppp interfaces.  Before I go adding printk 
> statements, are there any
> stats that would show if packets are hitting a particular rule or 
> routing table?
Ok, the rule is working and the routing table is being used.  But, 
weirdness abounds.

Here is my setup:

I have ppp401 (11.1.1.3/32) connected to ppp400 (11.1.1.2/32), over a 
cross-over T1 NIC (ie, this is going to the same machine).
Anything coming in on ppp400, uses a particular routing table, whose 
routes look like this:

10.1.1.3 via 172.1.2.2 dev rddVR4
11.1.1.2 via 11.1.1.2 dev ppp400
172.1.2.0/24 via 172.1.2.1 dev rddVR4
172.1.1.0/24 via 172.1.2.2 dev rddVR4
10.0.0.0/8 via 172.1.2.2 dev rddVR4
11.0.0.0/8 via 11.1.1.2 dev ppp400
default via 11.1.1.2 dev ppp400

If all worked as planned, the packets would traverse several other 
routing tables, the final which
has another pair of ppp links in it (ppp200, 10.1.1.2/32  connected to 
ppp201, 10.1.1.3/23).

I am sending udp packets through ppp400, and I see them appear on ppp401 
as expected.

The thing that is bothering me is that all I see on rddVR4 (172.1.2.1) 
is arps for 172.1.2.2, but the 'tell' IP is that of the
originating ppp400 link, not the IP of rddVR4, as I expected:

21:47:16.119640 arp who-has 172.1.2.2 tell 11.1.1.3
21:47:17.119371 arp who-has 172.1.2.2 tell 11.1.1.3
21:47:18.119254 arp who-has 172.1.2.2 tell 11.1.1.3
21:47:19.273118 arp who-has 172.1.2.2 tell 11.1.1.3

Unless I'm missing something dumb, a similar setup with all ethernet-ish 
network devices
works fine.

I have also enabled arp filtering:
# Only answer ARPs if it is for the IP on our own interface.
echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
and for every device used in these routing tables:
echo 1 > /proc/sys/net/ipv4/conf/[dev]/arp_filter

Any idea what I need to do in order to make  the source IP for the ARP 
packet correct?

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com> 
Candela Technologies Inc  http://www.candelatech.com


-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ