<[email protected]> wrote:
Gisle Vanem <address@hidden> wrote:
> > I've ported lwIP on Windows
There's already a win32 port for lwIP in the contrib module. Is there anything
wrong with that port or why did you create your own port?
Actually Simon wrote that.
This is, I think, quite superior than the WinPcap driver. The TAP is
real interface for Windows that is assuming that it is talking to a
real network. The "Network Bridge" will correctly switch the packet
based on there physical address.
Okay, I can see why you method could be more versatile. I.e. I have
a VPN connection to the outside; for this to work, Windows creates
a virtual adapter (WAN (PPP/SLIP) Interface). In my case it has the name:
\Device\NPF_{75451EE7-5145-471A-BAF5-124BE8439D10}. The downside
is that this is not writeable by any WinPcap/libpcap based programs. So
if a "virtual bridge" as you describe it could allow lwIP based programs to
talk over a VPN, it would be very nice. Remains to be tested.
This could be improved by adding a
spawning tree support in the link layer. Also, this is designed for
actual use and not dev, so the IO are fully asynchrone. The main issue
is that we have a lot of user/kernel switches as the TAP interface
don't have filter capacity (AFAIK).
> And how does all this "work around Windows TCP/IP stack limitation" for an
> arbitrary program like nmap?
Once started, the program is really seen on the network as a full
physical host like an independent computer. The limitation of Winsock
are irrelevant as we bypass it completly. This is impressive to see
your fake Ethernet MAC populating ARP list of computer around yours.
Laurent
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
