Hello Friends,
My actual requirement is to insert my own header between Ethernet header and
IP header to all the packets generated at this machine and remove the same
from all the packets meant for this machine.
So Packets leaving from this machine will look like(assume my header is
BlueTooth header)
Ethernet header -- BT header --IPheader--TCP/UDP/ICMP header
I tried to using Netfilter to solve my purpose, but found that I cant get
the packet directly from ethernet. Even the very first hook PRE_ROUTING also
gives from IP layer only.
So if I add my BT header before IP header, IP layer will not accept the
packet when I will call 'set_verdict'.
So I changed my design :(, to do some dirty work like add the copy of IP
header before BT header again.
Now it will look like
IP header--BT header--IP header--TCP/UDP/ICMP header
and at the recieving end it will remove the IP header--BT header leaving the
remaining packet starting with IP header.
For example, say ping command, packet length = 84 bytes, IP header length =
20 bytes, ICMP header length = 8bytes and my BT header length = 5 bytes
so I made the new packet of length 20+5+20+(84-20) = 109 bytes and called
the function set_verdict, with data_len = 109, and this 109 bytes long
payload.
Now at the recieving machine I should get the 109 bytes long packet, but in
fact IP_QUEUE is giving the packet of 84 bytes only, that are in fact first
84 bytes of the 109 bytes long packet.
Note - I have not touched the checksum fields.
So, my questions are :
1) When I am sending 109 bytes, why I am getting only 84 bytes?
2) I tried changing the payload[3] (ie, packet length field) to 109, in that
case the packet never reaches the destination, why?
3) Is this problem due to checksum?
4) Is there any way using netfilter, I can get the packet from ethernet
directly, that will suit my actual design? or any other easy way?
5) How can I verify that the sending machine is actually sending 109 bytes(I
mean not reducing it to 84)?
Please send me your suggestions to find out the solution for this problem
Thanks alot.
Regards
Shiva Raman Pandey
Research Associate, Computer Science -R&D
Sasken Communication Technologies Limited
Bangalore, India
On Thu, 11 Oct 2001, Shiva Raman Pandey wrote:
> For example, say ping command, packet length = 84 bytes, IP header length =
> 20 bytes, ICMP header length = 8bytes and my BT header length = 5 bytes
> so I made the new packet of length 20+5+20+(84-20) = 109 bytes and called
> the function set_verdict, with data_len = 109, and this 109 bytes long
> payload.
> Now at the recieving machine I should get the 109 bytes long packet, but in
> fact IP_QUEUE is giving the packet of 84 bytes only, that are in fact first
> 84 bytes of the 109 bytes long packet.
> Note - I have not touched the checksum fields.
>
> So, my questions are :
> 1) When I am sending 109 bytes, why I am getting only 84 bytes?
You are copying the IP header from an 84 byte packet, so the size is set
to 84 => the IP stack only reads the first 84 bytes.
> 2) I tried changing the payload[3] (ie, packet length field) to 109, in that
> case the packet never reaches the destination, why?
You changed the size field, but didn't recalculate the checksum. The
destination would then reject this packet as having a corrupted header.
> 3) Is this problem due to checksum?
Yes, I think so. That, and the rest of the header.
> 4) Is there any way using netfilter, I can get the packet from ethernet
> directly, that will suit my actual design? or any other easy way?
If you want to send packets over Ethernet, you are implementing your own
protocol. Alternatively, you can tunnel your BlueTooth packets over IP, as
you have been doing (but remember to fix the header fields this time!)
Also, you don't need a second copy of the IP header; one will do. At the
transmission end, insert your BT header between the IP header and payload,
changing the fields in the IP header accordingly (including protocol; with
your BT header in place, it is no longer a TCP/UDP/ICMP packet). At the
receiving end, I take it you want to pass the original packet over
Bluetooth? In which case, swap the headers round (and change the fields in
the IP header back the way they were to start with).
You may need more space after the BT header to store the fields you
displace from the IP header.
> 5) How can I verify that the sending machine is actually sending 109 bytes(I
> mean not reducing it to 84)?
A packet sniffer should help here...
James.
--
"Our attitude with TCP/IP is, `Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks -- nobody can.'"
"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
-- Ken Olson, in Digital News, 1988
Gentlemen,
I have a Sony Vaio PCG-FX215 and use via82cxxx_audio and ac97_codec as
modules to drive the sound. With all kernel versions I can play 8-bit
ISDN u-law files. With 2.4.5 and earlier (back to 2.2.19presomething at
least) I could play MP3s. With 2.4.6 and later I get a "No supported rate
found!" message from mpg123 (version 0.59q). The particular MP3 is
encoded at 128 kbit/s, 44100 Hz joint stereo.
Regards,
- Greg
I have a process (an instance of a find command) that seems to be unkillable (ie
kill -9 <pid> as root doesn't work).
Top shows it's status as R.
Is there anything I can do to kill the thing? It's taking up all unused cpu
cycles (currently at 97.4%).
Thanks,
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Thu, Oct 11, 2001 at 12:48:22PM -0400, Christopher Friesen wrote:
> I have a process (an instance of a find command) that seems to be
> unkillable (ie kill -9 <pid> as root doesn't work).
>
> Top shows it's status as R.
>
> Is there anything I can do to kill the thing? It's taking up all unused cpu
> cycles (currently at 97.4%).
I assume that's kapm-idled. That's normal, it's job is exactly burning
unused cycles.
Ralf
Ralf Baechle wrote:
>
> On Thu, Oct 11, 2001 at 12:48:22PM -0400, Christopher Friesen wrote:
>
> > I have a process (an instance of a find command) that seems to be
> > unkillable (ie kill -9 <pid> as root doesn't work).
> >
> > Top shows it's status as R.
> >
> > Is there anything I can do to kill the thing? It's taking up all unused cpu
> > cycles (currently at 97.4%).
>
> I assume that's kapm-idled. That's normal, it's job is exactly burning
> unused cycles.
Um, no.
As I specified, it is an instance of a "find" command, and it just won't die.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Thu, 11 Oct 2001, Ralf Baechle wrote:
> On Thu, Oct 11, 2001 at 12:48:22PM -0400, Christopher Friesen wrote:
>
> > I have a process (an instance of a find command) that seems to be
> > unkillable (ie kill -9 <pid> as root doesn't work).
> >
> > Top shows it's status as R.
> >
> > Is there anything I can do to kill the thing? It's taking up all unused cpu
> > cycles (currently at 97.4%).
>
> I assume that's kapm-idled. That's normal, it's job is exactly burning
> unused cycles.
No. He said it's an instance of find.
Stuck in R, though - some sort of loop? Christopher, can you attach gdb to
it and see what's happening?
James.
--
"Our attitude with TCP/IP is, `Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks -- nobody can.'"
"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
-- Ken Olson, in Digital News, 1988
James Sutherland wrote:
>
> On Thu, 11 Oct 2001, Ralf Baechle wrote:
>
> > On Thu, Oct 11, 2001 at 12:48:22PM -0400, Christopher Friesen wrote:
> >
> > > I have a process (an instance of a find command) that seems to be
> > > unkillable (ie kill -9 <pid> as root doesn't work).
> > >
> > > Top shows it's status as R.
> > >
> > > Is there anything I can do to kill the thing? It's taking up all unused cpu
> > > cycles (currently at 97.4%).
> >
> > I assume that's kapm-idled. That's normal, it's job is exactly burning
> > unused cycles.
>
> No. He said it's an instance of find.
>
> Stuck in R, though - some sort of loop? Christopher, can you attach gdb to
> it and see what's happening?
Okay, I just tried this, and the pertinant results were:
$ gdb find
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-yellowdog-linux"...(no debugging symbols
found)...
(gdb) attach 31075
Attaching to program: /usr/bin/find, Pid 31075
At this point it hangs and ctrl-C has no effect and I have to kill it from
another console.
Attaching to another program worked fine.
Any other ideas?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Thu, Oct 11, 2001 at 03:18:34PM -0400, Christopher Friesen wrote:
> Okay, I just tried this, and the pertinant results were:
>
> $ gdb find
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "ppc-yellowdog-linux"...(no debugging symbols
> found)...
> (gdb) attach 31075
> Attaching to program: /usr/bin/find, Pid 31075
>
>
>
> At this point it hangs and ctrl-C has no effect and I have to kill it from
> another console.
>
> Attaching to another program worked fine.
>
> Any other ideas?
Look in /proc/31075/fd and see what it has open.
On Thu, 11 Oct 2001, Christopher Friesen wrote:
> Okay, I just tried this, and the pertinant results were:
(gdb hangs, trying to attach)
>
> (gdb) attach 31075
> Attaching to program: /usr/bin/find, Pid 31075
>
> Attaching to another program worked fine.
>
> Any other ideas?
Take a look in /proc/31075 and see what's going on in there, if you can.
Obvious one: what was find doing - where was it looking?
James.
--
"Our attitude with TCP/IP is, `Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks -- nobody can.'"
"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
-- Ken Olson, in Digital News, 1988