How to fix packet destination address before RFC1122 dropping takes place?

[Paulo Matias]

Hi,

I own a mobile phone that connects to my computer via PPP, but its IP
stack is broken, so it sends me packets with "127.0.0.1" as
destination address, although I setup PPP this way: "pppd /dev/ttyU0
115200 10.0.0.1:10.0.0.2 netmask 255.0.0.0 noauth silent local
persist"

As I can't fix it in the device, I must fix the destination address of
the packets at the computer, but I don't know the best way to do this
under NetBSD.

Under Linux, I could do it using an iptables rule: "iptables -t nat -A
PREROUTING -d 127.0.0.1 -i ppp0 -j DNAT --to 10.0.0.1".

But under NetBSD (and under OpenBSD and FreeBSD too), perhaps dropping
takes place before ipf/pf can change its destination address.

At sys/net_inet/ip_input.c line 553, the packet is dropped:

/* 127/8 must not appear on wire - RFC1122 */
if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET ||
(ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) {


But only at line 651 the pfil hooks run:

if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif,
PFIL_IN) != 0)


There is any way I can fix this destination address before packets are
dropped (without changing kernel source code)?

There is a simpler solution than capturing the packets via bpf,
changing their destination manually at an userspace program, then
sending them to a TUN interface?


Thanks,
Paulo Matias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Paulo Matias
Hi,
I own a mobile phone that connects to my computer via PPP, but its IP
stack is broken, so it sends me packets with "127.0.0.1" as
destination address, although I setup PPP this way: "pppd /dev/ttyU0
115200 10.0.0.1:10.0.0.2 netmask 255.0.0.0 noauth silent local
persist"
As I can't fix it in the device, I must fix the destination address of
the packets at the computer, but I don't know the best way to do this
under NetBSD.
...
But under NetBSD (and under OpenBSD and FreeBSD too), perhaps dropping
takes place before ipf/pf can change its destination address.

On these platforms, pfil is being used as part of the security mechanisms
for networking. Packets should not be entering the system from outside
with 127/8 as either the source or destination address.

But if you're using BSD, there's no reason you can't comment out the
lines (around 553) that prevent you from getting your phone to work
with your kernel. I just think it would be difficult to convince anyone
that such a change is suitable for all.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paulo Matias]

I just think it would be difficult to convince anyone that such
a change is suitable for all.

Sure. It's the reason I asked if there was a solution that could be
done without changing the code.

So I think the best solution will be to develop a little program for
capturing the packets via bpf, modifying them, and sending them to a
TUN interface.

Unfortunately, changing the kernel code is not a good choice in my
case, because I'm developing a set of scripts for helping users of
these mobile phones under BSD and Linux, and I must make it the
simplest possible to the end-user.

Thanks, now I know the solution I thought about (using bpf) was not a
hack, but the way out for doing it under BSD solid TCP/IP stack.


Thanks,
Paulo Matias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Quentin Garnier]

Post by Paulo Matias

I just think it would be difficult to convince anyone that such
a change is suitable for all.

Sure. It's the reason I asked if there was a solution that could be
done without changing the code.
So I think the best solution will be to develop a little program for
capturing the packets via bpf, modifying them, and sending them to a
TUN interface.
Unfortunately, changing the kernel code is not a good choice in my
case, because I'm developing a set of scripts for helping users of
these mobile phones under BSD and Linux, and I must make it the
simplest possible to the end-user.
Thanks, now I know the solution I thought about (using bpf) was not a
hack, but the way out for doing it under BSD solid TCP/IP stack.

You might have a way through hacking on pppd; possibly using a plug-in.
I'm not 100% sure, but it's an idea.

[Paulo Matias]

I finally got the best solution.

It was using net/userppp from pkgsrc. It has integrated NAT, and can
translate the packets destination address before they go to networking
stack. So "nat addr 10.0.0.1 127.0.0.1" solved my problem.

Post by Quentin Garnier
You might have a way through hacking on pppd; possibly using a plug-in.
I'm not 100% sure, but it's an idea.

It was a very good idea. I've tried it too, before trying net/userppp.
Unfortunately, it was not possible.

There is a hook called "snoop_recv_hook" that pppd provides to its
plugins, and allows received packets to be modified, but I only could
receive packets in my hook when the connection was being established.

The explanation comes from pppd documentation: "IP packets go directly
to the kernel network code. So once pppd has negotiated the link, it
in practice lies completely dormant until you want to take the link
down, when it negotiates a graceful disconnect."


I hope this message can serve as future reference for someone.

Thanks a lot to all you at tech-net.

--
Paulo Matias

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Paulo Matias

I just think it would be difficult to convince anyone that such
a change is suitable for all.

Sure. It's the reason I asked if there was a solution that could be
done without changing the code.
So I think the best solution will be to develop a little program for
capturing the packets via bpf, modifying them, and sending them to a
TUN interface.
Unfortunately, changing the kernel code is not a good choice in my
case, because I'm developing a set of scripts for helping users of
these mobile phones under BSD and Linux, and I must make it the
simplest possible to the end-user.
Thanks, now I know the solution I thought about (using bpf) was not a
hack, but the way out for doing it under BSD solid TCP/IP stack.

There was one other change that crossed my mind:
introduce a sysctl to turn off loopback filtering at that point,
something like a
net.inet.ip.dropforeignloopback
which defaults to 1 but i'm not sure it is really that attractive.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de