Re: how can I modify the network packet payload?

On Oct 24, 7:13 am, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Oct 23, 7:00 am, jimmy <jimmy.ask...@xxxxxxxxx> wrote:

yeah I use the ipq_set_verdict as below:
status = ipq_set_verdict(h, m->packet_id, NF_ACCEPT, 0, NULL);

Umm, no wonder. You modified your copy of the packet data, but never
did anything with the modified data!

I'm wondering whether the ipq_set_mode is the problem since I use
IPQ_COPY_PACKET. I don't know if there are other options.
I use the following the lines in front of the previous codes.
h = ipq_create_handle(0, PF_INET);
if (!h)
die(h);
status = ipq_set_mode(h, IPQ_COPY_PACKET, BUFSIZE);
if (status < 0)
die(h);

Can any one give some hints?

1) You got a copy of the packet.

2) You modified your copy.

3) You didn't do anything with your copy.

Read the docs for ipq_set_verdict carefully.

DS


Sorry. It has some new problem.

The packet data is changed when I send and receive both on the
localhost. The tcp packets are changed, sent and recv all through
127.0.0.1. It works well on the same laptop.

But when I send and recv at different laptop through ad hoc network,
the receiver cannot receive anything. At the sender side, the packets
seem changed and sent out. And after 6 or 7 packets sent out, the
sender seems hanged there and will not send any more packets.

I impose the iptable to capture the OUTPUT tcp packet at the sender
side.

I only change the tcp data with the condition of my defined string,
like the data has a string of "today" (then I change only the "today"
string). I'm not sure whether the capture and modification process
stops any tcp communication packets which help to maintain the tcp
connection.

Anybody has an idea of what may why the receiver cannot receive the
modified packet?
.

Relevant Pages

  • Re: UDP catchall
    ... This is a kind of port knocking. ... Thanks to TCP ... If an RST packet is generated in response to the first TCP SYN packet, ... there might be no retransmission as the sender would think the TCP ...
    (freebsd-net)
  • Re: UDP catchall
    ... This is a kind of port knocking. ... Thanks to TCP ... If an RST packet is generated in response to the first TCP SYN packet, ... there might be no retransmission as the sender would think the TCP ...
    (freebsd-net)
  • Re: Windows Not Respond after calling NDISMIndicateReceivePacket
    ... One certainly would be that the packet data was not actually correct. ... documentation for NdisMIndicateReceivePacket. ... is not returned to the miniport below you - since it did not originate it. ...
    (microsoft.public.development.device.drivers)
  • How to capture and change packet using linux?
    ... How to capture and change packet using linux? ... I know the "Iptables" can do some of this job, ... the packet data I need do a lot of things to reconstruct a valid ...
    (comp.os.linux.networking)
  • Re: libpcap problem (hdr.len vs tcpdump file size)?
    ... >> the file header and each packet header in addition to the packet ... For the packet data, make sure you copy the captured length ... an additional pcap packet header (struct pcap_pkthdr) -- that's ...
    (comp.os.linux.development.apps)