Skip to contentSkip to conversation

TAP (and TUN?) devices not working after resume

Suspend-devel Rafael J. Wysocki 4 participants 8 messages Jul 14, 2008 – Nov 29, 2008 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 20080714154720.791f6640@symphony

Rafael J. Wysocki

author
#1 lore raw
Quoted 1 line · James Le Cuirot

Hi,

Hi,

Quoted 9 lines

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

This is a kernel problem, adding kernel-related CCs.

Thanks,
Rafael

#2 lore raw
Quoted 11 lines · Rafael J. Wysocki
Quoted 9 lines · James Le Cuirot

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

Quoted 1 line

This is a kernel problem, adding kernel-related CCs.

Oh, hmm. I noticed this about a year ago after a kernel upgrade, and threw the below into /etc/acpi/resume.d/91-openvpn.sh to fix the issue on resume. It was supposed to be temporary until I could track down whether this was a kernel issue or whatnot, but then I sorta, uhm, forgot to report it. But yeah, I see the same issue -- after resume, the TUN device has disappeared, and openvpn needs to be told to close and reopen for it to work again.

#!/bin/sh

# poke openvpn to rebuild the tunnel
if pidof openvpn > /dev/null; then
	killall -SIGHUP openvpn
fi

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08

#3 lore raw
In reply to Rafael J. Wysocki
Quoted 11 lines · Rafael J. Wysocki
Quoted 9 lines · James Le Cuirot

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

Quoted 1 line

This is a kernel problem, adding kernel-related CCs.

Oh, hmm. I noticed this about a year ago after a kernel upgrade, and threw the below into /etc/acpi/resume.d/91-openvpn.sh to fix the issue on resume. It was supposed to be temporary until I could track down whether this was a kernel issue or whatnot, but then I sorta, uhm, forgot to report it. But yeah, I see the same issue -- after resume, the TUN device has disappeared, and openvpn needs to be told to close and reopen for it to work again.

#!/bin/sh

# poke openvpn to rebuild the tunnel
if pidof openvpn > /dev/null; then
	killall -SIGHUP openvpn
fi
#4 lore raw
In reply to Rafael J. Wysocki
Quoted 15 lines · Rafael J. Wysocki
Quoted 1 line · James Le Cuirot

Hi,

Hi,

Quoted 9 lines

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

Quoted 1 line

This is a kernel problem, adding kernel-related CCs.

I bet it's flow control related. I've fixed a bug in flow control handling for persistent devices recently.
btw Does it still happen with >= 2.6.26 ?

I'll play with some test code on my laptop and see if I can reproduce this issue.

Max

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

#5 lore raw
Quoted 14 lines · On Thu, 24 Jul 2008 20:50:32 -0700 Max Krasnyansky <[email protected]> wrote:
Quoted 13 lines · James Le Cuirot
Quoted 12 lines

Hi,

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

Quoted 8 lines

I bet it's flow control related. I've fixed a bug in flow control handling for persistent devices recently.
btw Does it still happen with >= 2.6.26 ?

I'll play with some test code on my laptop and see if I can reproduce this issue.

Max

Sorry about the crazy delay here, I didn't need to use QEMU for ages and I don't like firing up Windows unless I have too. :D I'm not sure about 2.6.26 but this appears to be fixed in 2.6.27.

Thanks,
James

#6 lore raw
In reply to Max Krasnyansky
Quoted 14 lines · On Thu, 24 Jul 2008 20:50:32 -0700 Max Krasnyansky <[email protected]> wrote:
Quoted 13 lines · James Le Cuirot
Quoted 12 lines

Hi,

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

Quoted 8 lines

I bet it's flow control related. I've fixed a bug in flow control handling for persistent devices recently.
btw Does it still happen with >= 2.6.26 ?

I'll play with some test code on my laptop and see if I can reproduce this issue.

Max

Sorry about the crazy delay here, I didn't need to use QEMU for ages and I don't like firing up Windows unless I have too. :D I'm not sure about 2.6.26 but this appears to be fixed in 2.6.27.

Thanks,
James

#7 lore raw
In reply to Rafael J. Wysocki
Quoted 15 lines · Rafael J. Wysocki
Quoted 1 line · James Le Cuirot

Hi,

Hi,

Quoted 9 lines

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

Quoted 1 line

This is a kernel problem, adding kernel-related CCs.

I bet it's flow control related. I've fixed a bug in flow control handling for persistent devices recently.
btw Does it still happen with >= 2.6.26 ?

I'll play with some test code on my laptop and see if I can reproduce this issue.

Max

author
#8 lore raw
In reply to a message not in the archive
Quoted 1 line · James Le Cuirot

Hi,

Hi,

Quoted 9 lines

uswsusp works great on my machine except for one thing. I use a TAP device for QEMU and after resuming from suspend, it doesn't work anymore until I delete it and recreate it. This is rather annoying because if I have QEMU open, it means I have to close it before recreating the interface and then boot Windows up again. I use OpenVPN to create/delete the interface but I think that's all it does. The rest is done by the kernel. So I'm guessing something's up with the TUN/TAP driver or uswsusp itself. I'm using version 0.8. Sorry if this has already been fixed.

This is a kernel problem, adding kernel-related CCs.

Thanks,
Rafael