# can I use the icmp\_reply function (/net/ipv4/icmp.c) for creating an icmp query request?

- From: Tobias Koeck \<hidden\>
- Date: 2008-07-16 23:57:42 
- List: netdev
- Page: https://ratatoskr.run/netdev/2008/07/10803775

```text
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 [ref]:
> Quoting "Patrick McHardy" [ref]:
>
>> Jussi Kivilinna wrote:
>>>
>>> Quoting "Patrick McHardy" [ref]:
>>>
>>>>
>>>> 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
>
```
