netdev - can I use the icmp_reply function (/net/ipv4/icmp.c) for creating an icmp query request?

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>] [day] [month] [year] [list]

Date:	Thu, 17 Jul 2008 01:57:39 +0200
From:	"Tobias Koeck" <tobias.koeck@...il.com>
To:	netdev@...r.kernel.org
Cc:	john.tormento@...il.com
Subject: can I use the icmp_reply function (/net/ipv4/icmp.c) for creating an icmp query request?

I'm writing on an experimental icmp-query function and need to know If
i can use the icmp_reply function (/net/ipv4/icmp.c) for creating an
icmp query request?

The icmp_send function is after reading the source code only for error
icmp packets. The name icmp_reply implies it's only for query replies?

Greetings and thanks
Tobias

2008/7/17 Jussi Kivilinna <jussi.kivilinna@...et.fi>:
> Quoting "Patrick McHardy" <kaber@...sh.net>:
>
>> Jussi Kivilinna wrote:
>>>
>>> Quoting "Patrick McHardy" <kaber@...sh.net>:
>>>
>>>>
>>>> I thought you were going to make this a generic qdisc feature.
>>>> Why is configuration still qdisc specific?
>>>>
>>>
>>> I was thinking keeping scope of this patch within hfsc, as done  with
>>> rest of rate table qdiscs. So it would be better to have they  all to use
>>> generic size table instead of duplicating rtab code.
>>
>> Well, to use this feature consistently (meaning sizes propagate
>> down to inner qdiscs) it needs to be a generic feature.
>>
>>>> I was thinking of something like this:
>>>>
>>>> - add generic attributes for configuring size tables for any
>>>>  qdisc, handle those in sch_api
>>>>
>>>> - add qdisc_enqueue() wrapper that calculates the size and
>>>>  stores it in skb->cb, convert direct calls of sch->enqueue
>>>>  to use it
>>>>
>>>> - change direct uses of skb->len to use the size from the cb
>>>>
>>>> The second step might need a bit more thought to make sure
>>>> qdiscs don't get confused when the dequeued packet is larger
>>>> than the enqueued one, but I think they usually don't care.
>>>>
>>>
>>> I guess I'll start over using your size table patch as base then.
>>
>> I'm not sure that part is correct in my patch :)
>>
>
> Here's first version of generic size table feature. Didn't get chance to
> test too much yet but hfsc&sfq seems to be ok.
>
>  - Jussi
>
--
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