I am trying to fix a problem in diald (demand dialing tool). The problem is that
somewhen you need to resubmit IP packets to the kernel that were buffered while the
link (PPP in most cases) was down. However, a bit of debugging showed that the method
used in diald does not work. You cannot submit to ppp0 directly because of masq/forwaring
issues. Can somebody give me some hints how to submit packets from a user mode programm.
Andreas
You can use a raw socket:
socket(AF_INET,SOCK_RAW,IPPROTO_RAW);
On 22-Dec-2001 Andreas Kinzler wrote:
> I am trying to fix a problem in diald (demand dialing tool). The problem is
> that
> somewhen you need to resubmit IP packets to the kernel that were buffered
> while the
> link (PPP in most cases) was down. However, a bit of debugging showed that
> the method
> used in diald does not work. You cannot submit to ppp0 directly because of
> masq/forwaring
> issues. Can somebody give me some hints how to submit packets from a user
> mode programm.
>
> Andreas
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
>
Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH
> You can use a raw socket:
> socket(AF_INET,SOCK_RAW,IPPROTO_RAW);
Just tried it. It really submits the packets. However, for the kernel they
are now LOCAL packets, which are not masq'ed. To make that work, they need
to look "remote" (means: received by a device). Any ideas?
> On 22-Dec-2001 Andreas Kinzler wrote:
>> I am trying to fix a problem in diald (demand dialing tool). The problem
>> is
>> that
>> somewhen you need to resubmit IP packets to the kernel that were buffered
>> while the
>> link (PPP in most cases) was down. However, a bit of debugging showed
>> that
>> the method
>> used in diald does not work. You cannot submit to ppp0 directly because
>> of
>> masq/forwaring
>> issues. Can somebody give me some hints how to submit packets from a user
>> mode programm.
[email protected] said:
> However, for the kernel they are now LOCAL packets, which are not
> masq'ed. To make that work, they need to look "remote" (means:
> received by a device). Any ideas?
Use a TUN/TAP device (or ethertap on 2.2).
Jeff
>> However, for the kernel they are now LOCAL packets, which are not
>> masq'ed. To make that work, they need to look "remote" (means:
>> received by a device). Any ideas?
> Use a TUN/TAP device (or ethertap on 2.2).
That is exactly what diald does, but the packets written to such a device have
no effect, they do not seem to make their way through the kernel.
[email protected] said:
> but the packets written to such a device have no effect, they do not
> seem to make their way through the kernel.
Hmmm, well that's exactly what UML does and its packets are treated in
exactly the way you seem to want. They are treated as coming from a totally
different machine (although UML, as a complete machine, has a complete network
stack, network devices with their own IP addresses, etc, so you might just
not be making your packets look "remote" enough).
Jeff