Date: Sat, 10 Jun 2006 17:36:31 -0700 (PDT) From: "Shaun Colley" <shaun@rsc.cx> To: freebsd-net@freebsd.org Subject: Unexpected behavior after altering inetsw[] switch table Message-ID: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx>
next in thread | raw e-mail | index | archive | help
------=_20060610173631_26678
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Hi list.
My system is:
---
FreeBSD 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005
root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386
---
I'm writing a kernel module whose job is to modify the inetsw[] switch
table for the IPPROTO_TCP protocol. The pr_output hook for TCP needs to
be changed, such that my own custom tcp_output function will be called
when transmitting TCP packets. The reason for doing this is so that I can
do some modification on TCP packets before they are transmitted, but the
semantics of this are not important.
The part of the module of interest is:
---
switch (what) {
case MOD_LOAD: /* kldload */
uprintf("Skeleton KLD loaded.\n");
old_handler = inetsw[ip_protox[IPPROTO_TCP]].pr_output;
inetsw[ip_protox[IPPROTO_TCP]].pr_output = (pr_output_t *)my_tcp_output;
break;
case MOD_UNLOAD:
uprintf("Skeleton KLD unloaded.\n");
inetsw[ip_protox[IPPROTO_TCP]].pr_output = old_handler;
break;
default:
err = EINVAL;
break;
}
---
my_tcp_output is a hacked version of tcp_output.
When the module is built and loaded, the modification to the switch table
seems to have no effect whatsoever. That is, my custom routine does not
seem to be called when outputting TCP packets. This can be demonstrated
fully by changing the modification line to:
inetsw[ip_protox[IPPROTO_TCP]].pr_output = (pr_output_t *)0x0; - no kernel
panic occurs in this case. This ultimately leads me to believe that the
hook is not being called, even though it should be (I am attempting to
send TCP packets, so my function should be getting called).
This is very odd, because when I instead modify the pr_input hook, my
custom function *does* get called (i.e. when incoming packets are passed
up). For example, by inserting the line
'inetsw[ip_protox[IPPROTO_TCP]].pr_input = (pr_input_t
*)my_input_handler;', and then receiving TCP packets from below,
my_input_handler *is* entered, whereas if the corresponding TCP pr_output
hook is modified, that function does not get called (the regular
tcp_output() function seems to get used as normal).
I've attached a testcase module which demonstrates the behavior. If the
hook replacement works correctly, you'll have a TCP output hook which
essentially does nothing (i.e. doesn't pass packet down to next layer),
hence your TCP stack shouldn't work properly (so to speak). However, that
doesn't happen (at least on my system), as I've said. A makefile is also
attached.
Note, I'm not saying this is a bug. I'm just wondering what is going
wrong. My information (i.e. the way I'm trying to do this) may be out of
date, for example. I'm wondering if someone can cast some light on what
the problem might be.
Also attached is a kernel module that alters the pr_input hook of TCP to a
dummy function, similarly to the pr_input one. Loading this one will
leave you with a dummy input function, rendering your TCP stack not able
to process packets until you unload the module. Note that unloading both
of the modules will leave you good to go again.
cheers,
Shaun
------=_20060610173631_26678
Content-Type: application/octet-stream; name="Makefile.1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Makefile.1"
U1JDUz1wcl9vdXRwdXQuYwpLTU9EPXByX291dHB1dAoKLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgo=
------=_20060610173631_26678
Content-Type: application/octet-stream; name="Makefile.2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Makefile.2"
U1JDUz1wcl9pbnB1dC5jCktNT0Q9cHJfaW5wdXQKCi5pbmNsdWRlIDxic2Qua21vZC5taz4K
------=_20060610173631_26678
Content-Type: application/octet-stream; name="pr_input.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pr_input.c"
I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL21vZHVsZS5oPgojaW5jbHVkZSA8
c3lzL3N5c3RtLmg+ICAvKiB1cHJpbnRmICovIAojaW5jbHVkZSA8c3lzL2Vycm5vLmg+CiNpbmNs
dWRlIDxzeXMvcGFyYW0uaD4gIC8qIGRlZmluZXMgdXNlZCBpbiBrZXJuZWwuaCAqLwojaW5jbHVk
ZSA8c3lzL2tlcm5lbC5oPiAvKiB0eXBlcyB1c2VkIGluIG1vZHVsZSBpbml0aWFsaXphdGlvbiAq
LwojaW5jbHVkZSA8c3lzL3Byb3Rvc3cuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1
ZGUgPHN5cy90aW1lLmg+CiNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiNpbmNsdWRlIDxzeXMvc3lz
bG9nLmg+CiNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiNpbmNsdWRlIDxzeXMvZG9tYWluLmg+CiNp
bmNsdWRlIDxzeXMvbG9jay5oPgojaW5jbHVkZSA8c3lzL21hYy5oPgojaW5jbHVkZSA8c3lzL21i
dWYuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXR2YXIuaD4KI2luY2x1ZGUgPHN5cy9tdXRleC5oPgoK
I2luY2x1ZGUgPG5ldC9wZmlsLmg+CiNpbmNsdWRlIDxuZXQvaWYuaD4KI2luY2x1ZGUgPG5ldC9p
Zl90eXBlcy5oPgojaW5jbHVkZSA8bmV0L2lmX3Zhci5oPgojaW5jbHVkZSA8bmV0L2lmX2RsLmg+
CiNpbmNsdWRlIDxuZXQvcm91dGUuaD4KI2luY2x1ZGUgPG5ldGluZXQvdGNwX2ZzbS5oPgojaW5j
bHVkZSA8bmV0aW5ldC90Y3Bfc2VxLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgojaW5jbHVk
ZSA8bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8bmV0aW5ldC9pbl9zeXN0bS5oPgojaW5jbHVkZSA8
bmV0aW5ldC9pbl92YXIuaD4KI2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KI2luY2x1ZGUgPG5ldGlu
ZXQvdGNwX3RpbWVyLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcF92YXIuaD4KLy8jaW5jbHVkZSA8
bmV0aW5ldC90Y3BpcC5oPgojaW5jbHVkZSA8bmV0aXBzZWMvaXBzZWMuaD4KI2luY2x1ZGUgPG5l
dGluZXQvaW5fcGNiLmg+Ci8vI2luY2x1ZGUgPG5ldGluZXQvaXBfdmFyLmg+CiNpbmNsdWRlIDxu
ZXRpbmV0L2lwX2ljbXAuaD4KI2luY2x1ZGUgPG1hY2hpbmUvaW5fY2tzdW0uaD4KCmV4dGVybiAg
c3RydWN0IHByb3Rvc3cgaW5ldHN3W107CmV4dGVybiB1X2NoYXIgaXBfcHJvdG94W107CnZvaWQg
Km9sZF9oYW5kbGVyOwppbnQgbW9vKHN0cnVjdCB0Y3BjYiAqdHApOwovKiAKICogTG9hZCBoYW5k
bGVyIHRoYXQgZGVhbHMgd2l0aCB0aGUgbG9hZGluZyBhbmQgdW5sb2FkaW5nIG9mIGEgS0xELgog
Ki8KaW50IG1vbyhzdHJ1Y3QgdGNwY2IgKnRwKSB7CnJldHVybiAwOwp9CgpzdGF0aWMgaW50CnNr
ZWxfbG9hZGVyKHN0cnVjdCBtb2R1bGUgKm0sIGludCB3aGF0LCB2b2lkICphcmcpCnsKICBpbnQg
ZXJyID0gMDsKICAKICBzd2l0Y2ggKHdoYXQpIHsKICBjYXNlIE1PRF9MT0FEOiAgICAgICAgICAg
ICAgICAvKiBrbGRsb2FkICovCiAgICB1cHJpbnRmKCJTa2VsZXRvbiBLTEQgbG9hZGVkLlxuIik7
CiAgICBvbGRfaGFuZGxlciA9IGluZXRzd1tpcF9wcm90b3hbSVBQUk9UT19UQ1BdXS5wcl9pbnB1
dDsKICAgIGluZXRzd1tpcF9wcm90b3hbSVBQUk9UT19UQ1BdXS5wcl9pbnB1dCA9IChwcl9pbnB1
dF90ICopbW9vOwogICAgYnJlYWs7CiAgY2FzZSBNT0RfVU5MT0FEOgogICAgdXByaW50ZigiU2tl
bGV0b24gS0xEIHVubG9hZGVkLlxuIik7CiAgICBpbmV0c3dbaXBfcHJvdG94W0lQUFJPVE9fVENQ
XV0ucHJfaW5wdXQgPSBvbGRfaGFuZGxlcjsKICAgIGJyZWFrOwogIGRlZmF1bHQ6CiAgICBlcnIg
PSBFSU5WQUw7CiAgICBicmVhazsKICB9CiAgcmV0dXJuKGVycik7Cn0KCi8qIERlY2xhcmUgdGhp
cyBtb2R1bGUgdG8gdGhlIHJlc3Qgb2YgdGhlIGtlcm5lbCAqLwoKCnN0YXRpYyBtb2R1bGVkYXRh
X3Qgc2tlbF9tb2QgPSB7CiAgInNrZWwiLAogIHNrZWxfbG9hZGVyLAogIE5VTEwKfTsgIAoKREVD
TEFSRV9NT0RVTEUoc2tlbGV0b24sIHNrZWxfbW9kLCBTSV9TVUJfS0xELCBTSV9PUkRFUl9BTlkp
Owo=
------=_20060610173631_26678
Content-Type: application/octet-stream; name="pr_output.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pr_output.c"
I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL21vZHVsZS5oPgojaW5jbHVkZSA8
c3lzL3N5c3RtLmg+ICAvKiB1cHJpbnRmICovIAojaW5jbHVkZSA8c3lzL2Vycm5vLmg+CiNpbmNs
dWRlIDxzeXMvcGFyYW0uaD4gIC8qIGRlZmluZXMgdXNlZCBpbiBrZXJuZWwuaCAqLwojaW5jbHVk
ZSA8c3lzL2tlcm5lbC5oPiAvKiB0eXBlcyB1c2VkIGluIG1vZHVsZSBpbml0aWFsaXphdGlvbiAq
LwojaW5jbHVkZSA8c3lzL3Byb3Rvc3cuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1
ZGUgPHN5cy90aW1lLmg+CiNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiNpbmNsdWRlIDxzeXMvc3lz
bG9nLmg+CiNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiNpbmNsdWRlIDxzeXMvZG9tYWluLmg+CiNp
bmNsdWRlIDxzeXMvbG9jay5oPgojaW5jbHVkZSA8c3lzL21hYy5oPgojaW5jbHVkZSA8c3lzL21i
dWYuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXR2YXIuaD4KI2luY2x1ZGUgPHN5cy9tdXRleC5oPgoK
I2luY2x1ZGUgPG5ldC9wZmlsLmg+CiNpbmNsdWRlIDxuZXQvaWYuaD4KI2luY2x1ZGUgPG5ldC9p
Zl90eXBlcy5oPgojaW5jbHVkZSA8bmV0L2lmX3Zhci5oPgojaW5jbHVkZSA8bmV0L2lmX2RsLmg+
CiNpbmNsdWRlIDxuZXQvcm91dGUuaD4KI2luY2x1ZGUgPG5ldGluZXQvdGNwX2ZzbS5oPgojaW5j
bHVkZSA8bmV0aW5ldC90Y3Bfc2VxLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgojaW5jbHVk
ZSA8bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8bmV0aW5ldC9pbl9zeXN0bS5oPgojaW5jbHVkZSA8
bmV0aW5ldC9pbl92YXIuaD4KI2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KI2luY2x1ZGUgPG5ldGlu
ZXQvdGNwX3RpbWVyLmg+CiNpbmNsdWRlIDxuZXRpbmV0L3RjcF92YXIuaD4KLy8jaW5jbHVkZSA8
bmV0aW5ldC90Y3BpcC5oPgojaW5jbHVkZSA8bmV0aXBzZWMvaXBzZWMuaD4KI2luY2x1ZGUgPG5l
dGluZXQvaW5fcGNiLmg+Ci8vI2luY2x1ZGUgPG5ldGluZXQvaXBfdmFyLmg+CiNpbmNsdWRlIDxu
ZXRpbmV0L2lwX2ljbXAuaD4KI2luY2x1ZGUgPG1hY2hpbmUvaW5fY2tzdW0uaD4KCmV4dGVybiAg
c3RydWN0IHByb3Rvc3cgaW5ldHN3W107CmV4dGVybiB1X2NoYXIgaXBfcHJvdG94W107CnZvaWQg
Km9sZF9oYW5kbGVyOwppbnQgbW9vKHN0cnVjdCB0Y3BjYiAqdHApOwovKiAKICogTG9hZCBoYW5k
bGVyIHRoYXQgZGVhbHMgd2l0aCB0aGUgbG9hZGluZyBhbmQgdW5sb2FkaW5nIG9mIGEgS0xELgog
Ki8KaW50IG1vbyhzdHJ1Y3QgdGNwY2IgKnRwKSB7CnJldHVybiAwOwp9CgpzdGF0aWMgaW50CnNr
ZWxfbG9hZGVyKHN0cnVjdCBtb2R1bGUgKm0sIGludCB3aGF0LCB2b2lkICphcmcpCnsKICBpbnQg
ZXJyID0gMDsKICAKICBzd2l0Y2ggKHdoYXQpIHsKICBjYXNlIE1PRF9MT0FEOiAgICAgICAgICAg
ICAgICAvKiBrbGRsb2FkICovCiAgICB1cHJpbnRmKCJTa2VsZXRvbiBLTEQgbG9hZGVkLlxuIik7
CiAgICBvbGRfaGFuZGxlciA9IGluZXRzd1tpcF9wcm90b3hbSVBQUk9UT19UQ1BdXS5wcl9vdXRw
dXQ7CiAgICBpbmV0c3dbaXBfcHJvdG94W0lQUFJPVE9fVENQXV0ucHJfb3V0cHV0ID0gKHByX291
dHB1dF90ICopbW9vOwogICAgYnJlYWs7CiAgY2FzZSBNT0RfVU5MT0FEOgogICAgdXByaW50Zigi
U2tlbGV0b24gS0xEIHVubG9hZGVkLlxuIik7CiAgICBpbmV0c3dbaXBfcHJvdG94W0lQUFJPVE9f
VENQXV0ucHJfb3V0cHV0ID0gb2xkX2hhbmRsZXI7CiAgICBicmVhazsKICBkZWZhdWx0OgogICAg
ZXJyID0gRUlOVkFMOwogICAgYnJlYWs7CiAgfQogIHJldHVybihlcnIpOwp9CgovKiBEZWNsYXJl
IHRoaXMgbW9kdWxlIHRvIHRoZSByZXN0IG9mIHRoZSBrZXJuZWwgKi8KCgpzdGF0aWMgbW9kdWxl
ZGF0YV90IHNrZWxfbW9kID0gewogICJza2VsIiwKICBza2VsX2xvYWRlciwKICBOVUxMCn07ICAK
CkRFQ0xBUkVfTU9EVUxFKHNrZWxldG9uLCBza2VsX21vZCwgU0lfU1VCX0tMRCwgU0lfT1JERVJf
QU5ZKTsK
------=_20060610173631_26678--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52706.81.107.58.115.1149986191.squirrel>