Can't open lo: unsupported pysical layer type 0x304

[dmx9595@…]

getting the following error: Can't open lo: unsupported pysical layer type 0x304 <sarcasm>maybe cause pysical is spelt wrong?</sarcasm> this on tcpreplay 3.0beta11 pkg from debian root@box:/tmp# tcpreplay --intf1=lo /tmp/kismet_dump

[aturner]

The error is correct & accurate. Tcpreplay does not support sending packets over loopback interfaces on Linux. This is as limitation of Linux's PF_PACKET API. It's possible that I may be able to work around this, but I don't see any reason to try.

If you can come up with a use case which does make sense (you can't use another interface to accomplish the same task) then I'll look into it. For what it's worth though, sending 802.11 packets over loopback is completely nonsense since loopback interfaces use a completely different layer 2 header. So even if it was possible, your example wouldn't do anything useful.

If you find any spelling errors and they annoy you sufficiently, I would suggest either opening a ticket or stop using software written by me. I can't spell worth shit.

[dmx9595@…]

I see well the usefull situation here that im trying to accomplish and if you search google many other people as well is, im capturing packets to a fifo and then wanting to replay it to lo interface so i could use programs such as dsniff,urlsnarf on lo to capture the data since dsniff,urlsnarf do no support a fifo file but need to be listening live to a interface in this case lo.. curretnly there seems to be no solution (that im aware of or google) for myself and others that are trying to accomplish this would be nice if tcpreplay supported replaying to lo like I assumed it already would have accrodding to some examples found by google..

[dmx9595@…]

oh and as for the spelling I was just busting your balls (you remeber me from the other thread dont ya?) :) I can't spell either.

[aturner]

Well, I'll be honest. I can't control what Google/other people say. The examples you find there may or may not work- especially if the example is for an older version. Honestly, even the list archives will have a lot of out of date info because tcpreplay has been completely rewritten since 2.x.

Anyways, back to loopback. See here's the problem: loopback is for the computer to talk to itself. On Linux, loopback is standard ethernet (DLT_EN10MB), but different OS's use different DLT types. The problem here of course is you want to play 802.11 wireless packets which have a very different header format on that interface. The problem is that dsniff/urlsnarf are going to be expecting ethernet packets but instead are looking at 802.11 packets and it will get confused.

So what you need to do is replay these packets on a wireless NIC, so that the DLT of the interface will match that of the pcap. That or get Doug/etc to fix their tools to read pcap files natively. I suppose you could also wait for #103 to be completed and then convert your 802.11 into ethernet and then use tcpreplay 2.3.5 to send the packets (2.3.5 uses a different method of sending packets on Linux then 3.x does).

But I'm closing this as wontfix, since frankly fixing this is more work then it's worth IMHO. I'd be willing to accept a patch though if you feel so inclined.

[ayman]

802.11 is not an issue here, 802.11 headers can be easily removed using a tool like airdecap, you can even decrypt 802.11 packets using the same tool

[tennis_smith@…]

Hi Aaron,

There are some instances where supporting loopback would be very useful. For example, when testing cellphone handsets its handy because it isn't always possible to connect to a network.

Maybe it isn't really possible to get tcpreplay working on lo. If that's the case, is there any way to mimic the same functionality without having a network present?

[aturner]

(In [2023]) fix issue where --enable-force-* did not work on Linux refs #305 remove ethernet only restriction for PF_PACKET interfaces refs #123

[aturner]

(In [2024]) svn merge -r 2021:2023. fixes #123, #304, #305