you wrote:
> There appears to be another problem with ippp, possibly related
> to masquerading, where outgoing packets get source addresses of
> zero (tcpdump on the remote end shows packets from 0.0.0.0 and
> the local /proc/net/rt_cache shows a source of 0x00000000). As far
> as I can tell, if a masqueraded packet opens the link we get a
> good source address (in this case the packet is received by diald
> on its slip link and forwarded to the actual device once it comes
> up). If the link is already up I seem to get the zero address
> problem - ifconfig, ip link and ipchains show the expected addresses
> but rt_cache and what goes out is wrong.
>
> There appear to be zero source addr checks in tcp_v4_rebuild_header.
> These are not printing anything. Nor do the dynaddr checks print
> anything. Perhaps there is a rebuild header missing somewhere? Or
> perhaps the ISDN code is not doing something it should be when the
> link comes up? (N.B. I'm not sure if locally originated packets
> show the same problem. I believe they do at times).
I expirienced this problem too but after I applied some changes on my
setup - I routed packets to the dummy address of ippp0 to lo before - it
was never seen again. The checks in tcp_v4_rebuild_headers are against
the orignal adresses of the socket but not against the new_saddr (=
rt->rt_src) coming from the routing cache. While working on porting the
RST-provoking from 2.0 to 2.1 I added a message for the case it happends
and skip the rewriting. The patch for RST-provoking can be found at
http://www-users.rwth-aachen.de/Michael.Mueller4/dynip.html. The testing
phase of this patch was announced be me on de.alt.comm.isdn4linux.
Malware
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html