在Windows中使用python将原始套接字绑定到接口

Question

Reading raw packets from a socket bound to a specified interface under Windows, shows also the packets that are received on other interfaces. Is this a limitation under Windows?

import socket as s
HOST = '192.168.1.101' # s.gethostbyname(s.gethostname())
socket = s.socket(s.AF_INET, s.SOCK_RAW)
socket.bind((HOST, 0))

while True:
    print(str(socket.recv(1000)))

The code follows the example given in How to bind a raw socket to a specific interface using python in linux centOS and the docs . If it is possible, how can the expected result be achieved?

Answer 1

I added to your code:

socket.ioctl(s.SIO_RCVALL, s.RCVALL_ON)

Then on Windows 7 using Python 3.5 I ran:

import socket as s

HOSTS = ('169.254.222.66', '10.50.220.132')
for HOST in HOSTS:
    print('---', HOST)
    socket = s.socket(s.AF_INET, s.SOCK_RAW)
    socket.bind((HOST, 0))
    socket.ioctl(s.SIO_RCVALL, s.RCVALL_ON)
    for i in range(10):
        x = socket.recvfrom(65535)
        print(x[1], ' '.join(['%02x' % b for b in x[0]][:20]))
    socket.ioctl(s.SIO_RCVALL, s.RCVALL_OFF)

As output I got:

--- 169.254.222.66
('169.254.222.66', 0) 45 00 00 8d 6e d4 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 07 2d 6e d5 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 09 ad 6e d7 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 0a 3d 6e d9 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 04 3d 6e db 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 00 dd 6e dc 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 07 bd 6e dd 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 08 5d 6e df 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 06 4d 6e e1 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
('169.254.222.66', 0) 45 00 06 cd 6e e3 40 00 80 06 00 00 a9 fe de 42 a9 fe cc 5f
--- 10.50.220.132
('10.50.220.158', 0) 45 00 00 a1 64 18 00 00 01 11 7e 69 0a 32 dc 9e ef ff ff fa
('10.50.220.132', 0) 45 00 00 28 7d 4e 40 00 80 06 e3 cc 0a 32 dc 84 ac d9 06 25
('10.50.220.247', 0) 45 00 00 4e 02 9e 00 00 80 11 66 a6 0a 32 dc f7 0a 32 df ff
('10.50.221.3', 0) 45 00 00 4e 35 57 00 00 80 11 33 e1 0a 32 dd 03 0a 32 df ff
('10.50.220.149', 0) 45 00 00 f1 37 5f 40 00 04 11 67 db 0a 32 dc 95 ef ff ff fa
('10.50.220.149', 0) 45 00 00 f1 b3 04 40 00 40 11 a0 30 0a 32 dc 95 ff ff ff ff
('10.50.220.247', 0) 45 00 00 4e 02 9f 00 00 80 11 66 a5 0a 32 dc f7 0a 32 df ff
('10.50.221.3', 0) 45 00 00 4e 35 58 00 00 80 11 33 e0 0a 32 dd 03 0a 32 df ff
('10.50.220.176', 0) 45 00 00 4e 19 14 00 00 80 11 50 77 0a 32 dc b0 0a 32 df ff
('10.50.221.3', 0) 45 00 00 4e 35 59 00 00 80 11 33 df 0a 32 dd 03 0a 32 df ff

So in my test, there was no mixing of interfaces

Answer 2

This problem may be due to the packets not using the interface you are expecting. You can increase the interface metric on the interface that you do not want to use for routing. This will allow the interface you do want to use to be preferred.

In Windows 7:

1. Goto Control Panel
2. Select Network and Sharing
3. Select Change Adapter Settings
4. Select the interface that is non-preferred for routing
5. Select Internet Protocol Version 4 (TCP/IPv4) from the list
6. Select Advanced
7. Deselect Automatic Metric
8. Add an Interface Metric large enough to allow any other interface to be preferred.