If have set up a pair of virtual ethernet devices veth0 and veth1:
ip link add veth0 type veth peer name veth1
# Bring the interfaces up
sudo ifconfig veth0 up
sudo ifconfig veth1 up
sudo ifconfig veth0 1.1.1.1
sudo ifconfig veth1 1.1.1.2
Inside my application I connect to veth0 using a raw socket. Incoming packets are forwarded to my own TCP/IP stack implementation. Replies from the stack are sent back to the socket.
I also have a simple HTTP server running on my stack. I try to connect to it using the curl:
sudo curl -vvv --interface veth1 1.1.1.1/1/2/10000
* Trying 1.1.1.1...
* Local Interface veth1 is ip 1.1.1.2 using address family 2
* Local port: 0
Now my custom stack receives the SYN, enters the SYN-RECEIVED state and replies a with a SYN-ACK. This is sent down the stack back to the raw socket.
However, it seems that curl is not receiving the SYN-ACK because it keeps retransmitting the original SYN.
According to tcpdump the SYN-ACK does seem to arrive on 1.1.1.2:
$ sudo tcpdump -i veth1 -vv
tcpdump: listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
02:43:41.680087 IP (tos 0x0, ttl 64, id 59135, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.2.41847 > 1.1.1.1.http: Flags [S], cksum 0x0433 (incorrect -> 0x38a4), seq 446675468, win 29200, options [mss 1460,sackOK,TS val 1266013534 ecr 0,nop,wscale 7], length 0
02:43:41.680345 IP (tos 0x0, ttl 64, id 30106, offset 0, flags [DF], proto TCP (6), length 52)
1.1.1.1.http > 1.1.1.2.41847: Flags [S.], cksum 0x0bbe (correct), seq 697874744, ack 446675469, win 65535, options [mss 1460,wscale 5,nop,sackOK,nop,nop], length 0
02:43:42.690344 IP (tos 0x0, ttl 64, id 59136, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.2.41847 > 1.1.1.1.http: Flags [S], cksum 0x0433 (incorrect -> 0x34b2), seq 446675468, win 29200, options [mss 1460,sackOK,TS val 1266014544 ecr 0,nop,wscale 7], length 0
02:43:44.706343 IP (tos 0x0, ttl 64, id 59137, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.2.41847 > 1.1.1.1.http: Flags [S], cksum 0x0433 (incorrect -> 0x2cd2), seq 446675468, win 29200, options [mss 1460,sackOK,TS val 1266016560 ecr 0,nop,wscale 7], length 0
02:43:46.850382 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.1.1.1 tell 1.1.1.2, length 28
02:43:46.850579 ARP, Ethernet (len 6), IPv4 (len 4), Reply 1.1.1.1 is-at 92:c6:e5:d6:03:2f (oui Unknown), length 46
02:43:47.680487 IP (tos 0x0, ttl 64, id 30107, offset 0, flags [DF], proto TCP (6), length 52)
1.1.1.1.http > 1.1.1.2.41847: Flags [S.], cksum 0x0bbe (correct), seq 697874744, ack 446675469, win 65535, options [mss 1460,wscale 5,nop,sackOK,nop,nop], length 0
02:43:48.898343 IP (tos 0x0, ttl 64, id 59138, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.2.41847 > 1.1.1.1.http: Flags [S], cksum 0x0433 (incorrect -> 0x1c72), seq 446675468, win 29200, options [mss 1460,sackOK,TS val 1266020752 ecr 0,nop,wscale 7], length 0
02:43:57.090346 IP (tos 0x0, ttl 64, id 59139, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.2.41847 > 1.1.1.1.http: Flags [S], cksum 0x0433 (incorrect -> 0xfc71), seq 446675468, win 29200, options [mss 1460,sackOK,TS val 1266028944 ecr 0,nop,wscale 7], length 0
02:43:59.680648 IP (tos 0x0, ttl 64, id 30108, offset 0, flags [DF], proto TCP (6), length 52)
1.1.1.1.http > 1.1.1.2.41847: Flags [S.], cksum 0x0bbe (correct), seq 697874744, ack 446675469, win 65535, options [mss 1460,wscale 5,nop,sackOK,nop,nop], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
Wireshark screenshot.
Does anyone know why my SYN-ACK doesn't reach the other side of the TCP connection?
The problem was that veth interfaces are using checksum offload by default so the forwarded packets had a bad checksum and were ignored by the kernel. Running 'ethtool --offload IF_NAME rx off tx off' on veth interfaces (the sender and receiver), you may fix it.
Related
So I wanted to have Unbound use IPv6 transport only and not use IPv4 when doing lookups. (This is for fun. I want to see all the dns look ups done in IPv6 for educationsl purpose.)
My computer has IPv6 connectivity (can do curl -6) so I created an Unbound server.
Thought adding do-ip4: no was enough but I'm not getting anything from dig.
My prediction was that my computer is trying to use systemd-resolved instead of unbound but that has nothing to do with IPv6 so I guess not?
Here are my config files and tcpdump
With IPv4 enabled (working)
$ cat /etc/unbound/unbound.conf.d/myunbound.conf
server:
port: 53
verbosity: 0
num-threads: 2
outgoing-range: 512
num-queries-per-thread: 1024
msg-cache-size: 32m
interface: 0.0.0.0
interface: 2001:myipv6addr:20
rrset-cache-size: 64m
cache-max-ttl: 86400
infra-host-ttl: 60
infra-lame-ttl: 120
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 allow
username: unbound
directory: "/etc/unbound"
use-syslog: no
hide-version: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
# prefer-ip6: no
remote-control:
control-enable: yes
control-port: 953
control-interface: 0.0.0.0
tcpdump -n -vv port 53 -i any
for dig o.com
19:56:49.226291 IP6 (flowlabel 0xa269b, hlim 64, next-header UDP (17) payload length: 54) ::1.39522 > ::1.53: [bad udp cksum 0x0049 -> 0xa5ea!] 35213+ [1au] A? o.com. ar: . OPT UDPsize=4096 (46)
19:56:50.222460 IP (tos 0x0, ttl 64, id 49989, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.52155 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0x7690!] 35213+ [1au] A? o.com. ar: . OPT UDPsize=4096 (46)
19:56:50.222695 IP (tos 0x0, ttl 64, id 47599, offset 0, flags [none], proto UDP (17), length 62)
[myIPv4].41206 > 192.35.51.30.53: [bad udp cksum 0x4644 -> 0x5c52!] 46488% [1au] A? o.com. ar: . OPT UDPsize=4096 DO (34)
19:56:50.292985 IP (tos 0x0, ttl 54, id 26365, offset 0, flags [none], proto UDP (17), length 1153)
192.35.51.30.53 > [myIPv4].41206: [udp sum ok] 46488 NXDomain*- q: A? o.com. 0/8/1 ns: com. SOA a.gtld-servers.net. nstld.verisign-grs.com. 1653044192 1800 900 604800 86400, com. RRSIG, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. Type50, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. RRSIG, TE4S5DTC23DPH5M574GG84GG0Q86T3GM.com. Type50, TE4S5DTC23DPH5M574GG84GG0Q86T3GM.com. RRSIG, 3RL2Q58205687C8I9KC9MV46DGHCNS45.com. Type50, 3RL2Q58205687C8I9KC9MV46DGHCNS45.com. RRSIG ar: . OPT UDPsize=4096 DO (1125)
19:56:50.293239 IP (tos 0x0, ttl 64, id 49997, offset 0, flags [none], proto UDP (17), length 135)
127.0.0.1.53 > 127.0.0.1.52155: [bad udp cksum 0xfe86 -> 0xc2e6!] 35213 NXDomain q: A? o.com. 0/1/1 ns: com. SOA a.gtld-servers.net. nstld.verisign-grs.com. 1653044192 1800 900 604800 86400 ar: . OPT UDPsize=4096 (107)
With IPv4 disabled (not working)
$ cat /etc/unbound/unbound.conf.d/myunbound.conf
server:
port: 53
verbosity: 0
num-threads: 2
outgoing-range: 512
num-queries-per-thread: 1024
msg-cache-size: 32m
interface: 0.0.0.0
interface: 2001:myipv6addr:20
rrset-cache-size: 64m
cache-max-ttl: 86400
infra-host-ttl: 60
infra-lame-ttl: 120
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 allow
username: unbound
directory: "/etc/unbound"
use-syslog: no
hide-version: yes
do-ip4: no
do-ip6: yes
do-udp: yes
do-tcp: yes
# prefer-ip6: no
remote-control:
control-enable: yes
control-port: 953
control-interface: 0.0.0.0
tcpdump
dig k.com
20:02:32.122198 IP6 (flowlabel 0x8897b, hlim 64, next-header UDP (17) payload length: 54) ::1.53805 > ::1.53: [bad udp cksum 0x0049 -> 0x676c!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:33.122126 IP (tos 0x0, ttl 64, id 59754, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.35568 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xb0a8!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:38.126147 IP6 (flowlabel 0x8897b, hlim 64, next-header UDP (17) payload length: 54) ::1.53805 > ::1.53: [bad udp cksum 0x0049 -> 0x676c!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:39.122227 IP (tos 0x0, ttl 64, id 59906, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.35568 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xb0a8!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:44.126099 IP6 (flowlabel 0x8897b, hlim 64, next-header UDP (17) payload length: 54) ::1.53805 > ::1.53: [bad udp cksum 0x0049 -> 0x676c!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:45.122363 IP (tos 0x0, ttl 64, id 60247, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.35568 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xb0a8!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
Needed to add
interface: ::1
to the conf file
I have a problem, which I hope somebody can point me to the right direction.
Problem >>>
A) Our external provider (connects via VPN) needs to access "OpenSuse42.3" to specific ports, which
"nmap" or "ncat" tools shows as "filtered" or "refused".
B) No services are listening on these ports.
C) No firewall is running on this server.
D) Security team opened these ports on firewall with evidence that connection get reset by server
"OpenSuse42.3".
Test runs from "10.10.10.2" to "10.10.10.1" (problem server) from provider VPN connection (from my computer)
Example 1 : from "10.10.10.2"
>>> nmap -sT -p1101,3050 10.10.10.1
>>>
PORT STATE SERVICE
1101/tcp filtered pt2-discover
3050/tcp filtered gds_db
Example 2 : from "10.10.10.2"
nc -z -v 10.10.10.1 1101
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection refused.
nc -z -v 10.10.10.1 3050
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection refused.
Example 3: on server "10.10.10.1"
tcpdump -n -i eth0 port 1101 or port 3050 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:00:28.940582 IP (tos 0x0, ttl 64, id 32383, offset 0, flags [DF], proto TCP (6), length 60)
10.10.10.2.58000 > 10.10.10.1.1101: Flags [S], cksum 0xa3fc (correct), seq 3906215335, win 29200,
options [mss 1460,sackOK,TS val 1388733400 ecr 0,nop,wscale 7], length 0
13:00:28.940662 IP (tos 0x0, ttl 64, id 40440, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.1.1101 > 10.10.10.2.58000: Flags [R.], cksum 0x347b (correct), seq 0, ack 3906215336,
win 0, length 0
13:00:31.263502 IP (tos 0x0, ttl 64, id 60627, offset 0, flags [DF], proto TCP (6), length 60)
10.10.10.2.40830 > 10.10.10.1.3050: Flags [S], cksum 0x8bc2 (correct), seq 3504308280, win 29200,
options [mss 1460,sackOK,TS val 1388735723 ecr 0,nop,wscale 7], length 0
13:00:31.263569 IP (tos 0x0, ttl 64, id 40888, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.1.3050 > 10.10.10.2.40830: Flags [R.], cksum 0x2554 (correct), seq 0, ack 3504308281,
win 0, length 0
BUT
As soon as I put something on the server like - "nc -l 1101" or "nc -l 3050"
problem disappears, which probably makes sense. To my knowledge "nmap" tool usually shows port status as "closed" if port is not firewalled and service is not running and "open" if service is running on this port.
Question
Are ports opened or closed ??? What else do I check, because provider keep insisting that ports are closed on "10.10.10.1" and he cannot continue his work.
Please let me knoe if something is unclear in this situation and I will respond.
Appreciate it !!!!
I have configured L2TP VPN on PfSense 21.05-RELEASE (amd64) and fedora 33 as client, once VPN is connected I can ping remote host but as soon as I tied to hit HTTP traffic VPN stop flowing traffic.
In TCP dump can see outgoing traffic but no incoming traffic coming back after HTTP request seems something related to packer reassemble
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
2: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 10.200.200.0 peer 10.200.0.1/32 scope global ppp0
valid_lft forever preferred_lft forever
14:10:37.880312 IP fedora > b.resolvers.Level3.net: ICMP echo request, id 25, seq 1, length 64
14:10:38.046771 IP b.resolvers.Level3.net > fedora: ICMP echo reply, id 25, seq 1, length 64
14:10:38.880819 IP fedora > b.resolvers.Level3.net: ICMP echo request, id 25, seq 2, length 64
14:10:39.047254 IP b.resolvers.Level3.net > fedora: ICMP echo reply, id 25, seq 2, length 64
14:10:39.880860 IP fedora > b.resolvers.Level3.net: ICMP echo request, id 25, seq 3, length 64
14:10:40.046325 IP b.resolvers.Level3.net > fedora: ICMP echo reply, id 25, seq 3, length 64
14:10:52.048093 IP xcal1.vodafone.co.uk.http > fedora.37900: Flags [.], ack 140, win 123, length 0
14:10:52.050555 IP xcal1.vodafone.co.uk.http > fedora.37900: Flags [.], seq 1:1361, ack 140, win 123, length 1360: HTTP: HTTP/1.1 200 OK
14:10:52.050575 IP fedora.37900 > xcal1.vodafone.co.uk.http: Flags [.], ack 1361, win 502, length 0
14:10:52.050593 IP xcal1.vodafone.co.uk.http > fedora.37900: Flags [.], seq 1361:2721, ack 140, win 123, length 1360: HTTP
14:10:52.050603 IP fedora.37900 > xcal1.vodafone.co.uk.http: Flags [.], ack 2721, win 496, length 0
14:10:52.050605 IP xcal1.vodafone.co.uk.http > fedora.37900: Flags [.], seq 2721:4081, ack 140, win 123, length 1360: HTTP
14:10:52.050608 IP fedora.37900 > xcal1.vodafone.co.uk.http: Flags [.], ack 4081, win 489, length 0
14:10:52.051180 IP xcal1.vodafone.co.uk.http > fedora.37900: Flags [.], seq 4081:5441, ack 140, win 123, length 1360: HTTP
14:10:52.051193 IP fedora.37900 > xcal1.vodafone.co.uk.http: Flags [.], ack 5441, win 481, length 0
14:13:06.781830 IP fedora.38648 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 684941377, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:32.424321 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:32.674485 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:33.469787 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:33.725967 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:35.517903 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:35.773924 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:39.549856 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:39.805863 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:47.741806 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:13:48.253781 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:14:04.125969 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:14:04.637813 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:14:36.381831 IP fedora.38650 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3466381594, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
14:14:36.893792 IP fedora.38652 > 239.237.117.34.bc.googleusercontent.com.https: Flags [S], seq 3214804727, win 65280, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0
If you use visual studio 2015 , and c# 6
you easily get there property name of class.
example:
class Person
{
public string FirstName{get;set;}
}
to get property name
nameof(Person.FirstName);
it will return you "FirstName"
I hope that I understand your question
There was issue with xl2tpd services which was not in running state, starting xl2tpd service will issue
I am using gitlab docker image to deploy a service, and the web port is 8080 on host. After running the gitlab, I can see the port is OK:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b85d87da48df genezys/gitlab:7.5.2 "/bin/sh -c 'gitlab- 25 minutes ago Up 25 minutes 0.0.0.0:2222->22/tcp, 0.0.0.0:8080->80/tcp gitlab_app
The netstat command also diplays OK:
[root#localhost backup]# netstat -nlp | grep 8080
tcp6 0 0 :::8080 :::* LISTEN 12489/docker-proxy
But the web browser can't connect the 8080 successfully (http://10.137.20.112:8080/), and the tcpdump output likes this:
[root#localhost ~]# tcpdump -i enp2s0f1 port 8080 -vv
tcpdump: listening on enp2s0f1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:40:00.808034 IP (tos 0x0, ttl 128, id 4031, offset 0, flags [DF], proto TCP (6), length 52)
perfls15.americas.hpqcorp.net.53178 > 10.137.20.112.webcache: Flags [S], cksum 0x17d1 (correct), seq 997417494, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
02:40:00.808141 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
10.137.20.112.webcache > perfls15.americas.hpqcorp.net.53178: Flags [R.], cksum 0x788a (correct), seq 0, ack 997417495, win 0, length 0
02:40:01.322048 IP (tos 0x0, ttl 128, id 4032, offset 0, flags [DF], proto TCP (6), length 52)
perfls15.americas.hpqcorp.net.53178 > 10.137.20.112.webcache: Flags [S], cksum 0x17d1 (correct), seq 997417494, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
02:40:01.322123 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
10.137.20.112.webcache > perfls15.americas.hpqcorp.net.53178: Flags [R.], cksum 0x788a (correct), seq 0, ack 1, win 0, length 0
02:40:01.821289 IP (tos 0x0, ttl 128, id 4033, offset 0, flags [DF], proto TCP (6), length 48)
......
I can't see why the host always responses RST, could anyone give some debugging clues?
Check output of 'iptables -L -n'. If you do not see port 8080 opened in that ouput, you may need to do so
with RHEL7, you need to use firewall-cmd as below
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload
It depends on the iphdr.saddr field.
When it was set to my own address or a random multicast address, I can see the server replied with the syn/ack packet.
If set to other ips, the server didn't reply.
How to explain it?
The multicast address case:
13:55:08.242535 IP 240.151.224.61.13579 > localhost.5223: Flags [S], seq 123456, win 4096, length 0
E..(g+..#......=....5..g...#....P...$X..
13:55:14.906511 IP 239.151.224.61.13579 > localhost.5223: Flags [S], seq 123456, win 4096, length 0
E..(g+..#......=....5..g...#....P...%X..
13:55:14.906549 IP localhost.5223 > 239.151.224.61.13579: Flags [S.], seq 3502093187, ack 123457, win 43690, options [mss 65495], length 0
E..,..#.#..........=.g5........A...N.......
13:55:15.904599 IP localhost.5223 > 239.151.224.61.13579: Flags [S.], seq 3502093187, ack 123457, win 43690, options [mss 65495], length 0
`
my own address case:
14:14:22.989225 IP slave1.domain.com.13579 > localhost.5223: Flags [S], seq 123456, win 4096, length 0
E..(g+..#......m....5..g...#....P...3...
14:14:22.989236 IP localhost.5223 > slave1.domain.com.13579: Flags [S.], seq 3228604881, ack 123457, win 43690, options [mss 65495], length 0
E..,..#.#..........m.g5..p.....A...A5......
14:14:22.989259 IP slave1.domain.com.13579 > localhost.5223: Flags [.], ack 3228604882, win 4096, length 0
E..(..#.#......m....5..g...A.p..P.......
`
no syn/ack reply case:
14:16:18.719629 IP 223.151.224.61.13579 > localhost.5223: Flags [S], seq 123456, win 4096, length 0
E..(g+..#......=....5..g...#....P...5X..
14:16:46.511299 IP 240.151.224.61.13579 > localhost.5223: Flags [S], seq 123456, win 4096, length 0
E..(g+..#......=....5..g...#....P...$X..
iphdr.saddr represents the source address of the IP packet. I assume that the receiving end of your SYN packet will try to respond with an ACK to whatever source address you provide in the IP packet.