I have a doubt, pls clarify. Suppose I have a System connected like the below,
A -> B -> C -> D
I need to send a packet from A to D, so when a packet moves out of A, it should update the routing information somewhere in the packet or in the skbuff so that packet is routed correctly via B, so that it reaches the destination.
Pls let me know where it is updated in the packet means which header or which parameter in the skbuff..
Thnx in advance..
From your view, you only need the target address D and the first gateway (or router) B. You don't make any modification in the packet, this is done in the router(s). C or any other routers on the way to D are transparent for you.
Normally this happens by updating the source and destination mac address of the packet. This would be found in the ethernet header of the packet (assuming it's travelling over ethernet). In normal UDP or TCP routing, you can do this completely in userspace by modifying the routing tables.
Are you implementing a custom internet protocol? Otherwise, it's unlikely that a custom kernel module / patch is the right place for this.
When the packet is being sent from A to D in this network, A -> B -> C -> D, application on A has a socket to application on D. The IP at A needs to find the next hop through routing, which would be B in this case. This information can be cached in socket as well(as in some versions of Linux, in the socket->sock->dst_cache field). The IP datagram always has destination IP as IP of D. So, B forwards it to C based on routing table and similarly C to D.
Does this answer your question?
Related
I wanted to peek Ipv4Header from a packet, but the system thrown a runtime error as following:
<!> Returning an incomplete chunk is not allowed according to the flags: 0 -- in module (inet::ieee80211::Dcf)
The line of code causing error is:
const auto& ipv4header = packet->peekAtFront<Ipv4Header>();
Thank you in advance!
As far as I see, you are trying to get an Ipv4Header at the link layer (802.11 Dcf). That is not possible. Nobody have ever guarantied that a link layer data packet starts with an IP header. IP packets can (and will) be fragmented if the MTU is smaller than the actual packet size. The first fragment indeed will start with an IP header, but subsequent fragments definitely will NOT.
As a general rule of thumb, if you are trying to access an upper OSI level data structure in a lower OSI level, you are definitely doing it wrong.
I'm working on a server.
Its doing health check to another server, like a simple tcp open connection
Basically my tcpdump says that the packet (the health check tcp sYn packet) is going out of my interface.
But, the Firewall doesnt see anything.
I have doubt if the packet is going outside the server at all, or the problem is on the switch.
Is there a way to be sure about this?
Captured traffic == source of truth
It's possible for tcpdump to have false negatives (i.e. packets are sent but tcpdump doesn't record them). This can be due to hardware (CPU, RAM, disk) being maxed or if tcpdump's buffer size (-B) is too small. Likewise, it's possible your firewall isn't picking it up where it should.
It's highly unlikely for tcpdump to report a false positive. Tcpdump copies bytes from your network interface [0] and summarizes them in a text line (depending on your output options). If firewall rules from e.g. iptables would block traffic, tcpdump won't see the traffic. If tcpdump reports a packet, you can be sure it transited that interface.
[0]: If you're curious how tcpdump works at a lower level, use strace.
Flow-based troubleshooting
Flow-based troubleshooting can be required to figure out where packets get dropped in a network. For your network of server:A <-> B:switch:C <-> D:Firewall, we know that A sends it and D does not receive it. Thus you should check ports B and C to determine where the packet loss occurs. It's also possible that D reports a false negative. You can test both of these things by plugging this server directly into a different firewall that can take packet captures/monitor traffic.
I want to know in RPL networks, after a node sends one packet to another node (for example RPL-Collect/udp-sender), how to know that intended node will forward this packet or not? I think overhearing neighbors transmission is needed, but is the another simple way to implemented this scenario in Contiki/Cooja?
To overhear packets in addition to normal operation you need to do several things:
Ensure that the radio is turned on and in the right channel. If you're using always-on CSMA or ContikiMAC you don't need to do anything special. Same for TSCH minimal schedule. Otherwise for TSCH you need to schedule a Rx cell with the right channel offset and in the right timeslot.
Somehow hack into the MAC layer to print or account packets not addressed to you - normally the MAC layer silently drops such packets.
Ensure hardware frame filtering is turned off (the radio is in promiscious mode).
Example:
radio_value_t radio_rx_mode;
/* Entering promiscuous mode so that the radio accepts all frames */
NETSTACK_RADIO.get_value(RADIO_PARAM_RX_MODE, &radio_rx_mode);
NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, radio_rx_mode & (~RADIO_RX_MODE_ADDRESS_FILTER));
If you just need to overhear packets and don't need the normal operation things and simpler. You can use SenSniff then.
I'm trying to implement S-MAC protocol on waspmote xbee sensors and i know it has its own CSMA/CA. So first of all I need to understand the basic of xBee collision avoidance.
Two senders set up in api mode in libraries and both periodically sending single bytes to a common receiver. I reduce the delay and many changing in libabries to make collision and to see how algorithm works. But when i monitor data at the receiver all looks as expected at the receiver .. byte1, byte 2 .. byte1, byte2.
Do u have any idea how can i make collision?
Are you sniffing the 802.15.4 traffic? That's the only way you'd see a collision.
The XBee module buffers the data you want to send, using the host communication parameters (baud rate, API mode, etc.) and then sends it out over 802.15.4 at 250kbps. The module has all of the collision avoidance built in, and will retransmit as necessary to deliver your message. If it's unable to deliver after some number of transmission attempts, you'll get a Transmit Status frame indicating failure.
On the receiving end, it buffers the data and delivers it to the local host using local serial settings (baud rate and API mode).
If you're trying to implement S-MAC, you need a different radio processor where you have low-level control over the radio. The XBee module provides an application layer and handles the MAC layer itself.
I have to write a vpn module. First of all, I have wrote a kernel module that modifies all the incoming and outgoing TCP packets. It uses netfilter hooks. For the incoming packets, I have modified the bytes between (struct sk_buff)->data and (struct sk_buff)->tail pointers by incrementing them by one. For the outgoing packets, I have modified the bytes between (struct sk_buff)->data and (struct sk_buff)->tail pointers by decrementing them by one.
However, I tried to establish a TCP connection between localhost and localhost (by means of netcat) and I had not succeeded. Can you tell me what I am doing wrong? Need I modify some other fields from the struct sk_buff structure?
Is it possible to implement my simple vpn module only from kernel space?(thus without using special libraies such as libnetfilter_queue)?
Thank you.
Yes, you can do this without using libnetfilter. But given the limited information that you've provided about your project it's hard to give a good recommendation as to how to go about fixing your issue. Here's some references that should help.
1) I would recommend you take a look at the TUN/TAP interface driver APIs. This will allow you to implement your code in application space rather than kernel. See openvpn for a great example of this type of VPN.
If you're interested in doing more advanced kernel space hooking...
2) Check this article out on hooking into netfilter netfilter kernel hooks