From: Arnaud <arnaud.kleinveld@wanadoo.nl>
To: linux-kernel@vger.kernel.org
Subject: PROBLEM: iptunnel: ioctl: Operation not supported
Date: Mon, 16 Feb 2004 18:45:03 +0800 [thread overview]
Message-ID: <40309F2F.9020901@wanadoo.nl> (raw)
Hi All.
Short:
Trying to start a tunnel with iptunnel and module ipip I ran into the
message "ioctl: Operation not supported"
Full description:
Every command on one of my hosts from iptunnel results in "Operation not
supported". Command example: 'iptunnel show'
I built ipip.o for both systems on a development host:
AMD Athlon(TM) XP 2400+
RH 9, kernel 2.4.20-8, gcc 3.2.2
On the following system (A) I can set up the tunnel and a tcpdump on the
second system (B) shows ecapsulated packages comming in:
Pentium MMX
RH 9, kernel 2.4.20-8, gcc 3.2.2
system B:
Cx486DX2
RH7.2, kernel 2.4.19, gcc 2.96
The PROBLEM is on system B. When I start the iptunnel command, no matter
what function, I always get a message "ioctl: Operation not supported".
So I entered some printk statements into ipip.c to see what command this
module is receiving from iptunnel and to see if the module could
register the device 'tunl0'. The registration goes well but the printk
statement I entered into the case statement that handels the ioctl
commands is never called! For me it looks like the ioctl is adressing
the wrong net driver.
I also noticed a difference between the output of a 'strace iptunnel' on
both systems:
system A (goes well):
<snip>
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8927, 0xbfffe7e0) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f0, 0xbfffe7e0) = 0
close(4) = 0
<snip>
system B (goes wrong):
<snip>
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8927, 0xbffff790) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f0, 0xbffff780) = -1 EOPNOTSUPP (Operation not
supported)
<snip>
I see that the command is a private ioctl '89f0' which is equal to
'GETTUNNEL' and that's oke because I did a 'strace iptunnel show' to
create this output. I also see a difference on the reference to the
ifreq struct. On system A it stays the same for all commands done by
iptunnel and on system B only the last command has a different
reference. The struct is private by the routines so they are recreated
every time, so I guess this difference could happen?
I checked the bugfixes between 2.4.19 and 2.4.20 but I didn't find
anything about ioctl adressing wrong drivers.
I would like to debug this further more but I don't know where to go
from this point. Any help is really appreciated. Maybe I am doing
something wrong by compiling on the other system?
Best Regards,
Arnaud
Some addional information on the two systems:
system A (goes well):
MODULES:
ipip
hostap_crypt_wep
hostap_pci
hostap
ppp_synctty
ppp_async
ppp_generic
slhc
8139too
mii
af_packet
ipt_LOG
ipt_state
ipt_MASQUERADE
iptable_nat
ip_conntrack
iptable_filter
ip_tables
ext3
jbd
usb-uhci
usbcore
rtc
system B (goes wrong):
MODULES:
ipip
ipt_state
8139too
mii
ppp_synctty
ppp_async
ppp_generic
slhc
ne2k-pci
8390
3c509
isa-pnp
af_packet
ipt_LOG
ipt_MASQUERADE
iptable_nat
ip_conntrack
iptable_filter
ip_tables
ext3
jbd
rtc
reply other threads:[~2004-02-16 10:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40309F2F.9020901@wanadoo.nl \
--to=arnaud.kleinveld@wanadoo.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox