Ray/Chuck,
Thanks for all your help. Let me try a new approach, I have been vague on the details because I thought my problem was very simple......here is a detailed decryption of my problem...
I have developed a network driver for a custom fibre channel card. Though the physical interface is FC, according to Linux, I have selected Ethernet for the device classification....
The Fibre channel device is a PCI card with 2 interfaces.
The cabling setup is as follows....
********************* * Box #1 (RH 7.2) * ********************* * (fc0) * (fc1) | | | | |-------------| fc cable
The ifconfig information is as follows: fc0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr: 172.172.16.1 Bcast:172.172.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
fc1 Link encap:Ethernet HWaddr yy:yy:yy:yy:yy:yy inet addr: 172.172.17.1 Bcast:172.172.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
To avoid initial routing problems, I have disabled ARP, by using the IFF_NOARP flag. Since I know the HW Addr of both channels, I temporarily set the hw addr to the opposite channel, when a packet asks for it.
then a try to ping... > ping -c 1 -I fc0 172.172.17.1
By putting debug messages inside the IP stack and an external network analyzer, I notice the following happen in order....
1. Packet is transmitted out fc0 2. Packet is received physically on fc1 3. netif_rx is called on fc1 4. ip_input_route_slow is called on fc1 5. fib_validate_source is called on fc1 6. fib_lookup is called on fc1 7. fib_lookup returns, updated res 8. res.type is RTN_LOCAL 9. fib_validate_source returns e_inval_res is res.type != RTN_UNICAST
>From that point on the functions fail all the way back through the stack.....it seems that the fib_lookup figures out the the destination and source addresses are local, which screws up everything....
I know this is related to routing, possibly rules.......
If you need anymore information, let me know..
Is the entry in step 4, possibly, a typo for "ip_route_input_slow" (I can't find a function called "ip_input_route_slow")?
All this source is not the easiest stuff to read, but my best guess is that you are running into the kernel's anti-spoofing protection. Since fib_lookup() identifies the packet's source address as local (RTN_LOCAL), it "knows" that it cannot be coming in from what appears to be an external source. Hence the source address is spoofed, the packet represents a possible attack, and it gets discarded.
If this is the cause of your problem ... and, really, it is only an educated guess on my part ... it *might* suffice to turn off anti-spoofing in the kernel. I think you do this by cat'ing a 0 to /proc/sys/net/ipv4/conf/*/rp_filter (replacing * with an interface name).
All the relevant source for this stuff is in ./linux/net/ipv4 . You might find it worth examining more closely than I was willing to for these purposes.
- To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs
