tun device

[zomo]

Hi everyone!

It is possible to turn on altq(queuing) on tun device in openbsd 4.3, for pppoe session from local network?

Thanks

[jggimi]

Hello, and welcome.

While I have not used pppoe, a moment of Googling found http://www.openbsdsupport.org/obsd_dsl.html which was written for OpenBSD 3.5 and updated for OpenBSD 3.7. Proceed with caution, as there were six releases and three years between it's publication and the release you are using now. I have not read the document, but it shows altq being used with tun0.

[zomo]

But i was trying to queue traffic on tun0 with any results

[jggimi]

Does tcpdump(8) show any traffic over the tun0 interface?

(I don't know ppp/pppoe, but I understand that it is tied to an Ethernet interface.)

[zomo]

tcpdump is showing traffic on specfic tun, but nothing more.

[robbak]

It seems that pf altq can work on a tun0 device, so it should be working. So it seems that you have some problems with your configuration.

The first one I can think of would be that altq lists figures in kilobytes per second, whereas DSL links talk in killobits per second. That would make your figures way too high, meaning that the altq rules would have no effect.

How do you know that it is not working? Do you get errors, or is it just that it does not seem to limit the speed?

[zomo]

I'm not using pppoe to link with dsl modem, but to authenticate user in network, but when i setup altq on for example tun0 this does not limit users bandwidth.
"pppoe is running in userland, and packets are not flowing by the kernel, so packets cannot be limited" Is it true ?

I'm queuing on altq with Kilobits/second.

[jggimi]

Is it true ?

No. You are using tun(4), which states:

Packets sent to this interface can be read by a userland process and processed as desired. Packets written by the userland process are injected back into the kernel networking subsystem.

You also clarified your use:

I'm ... using pppoe to ... authenticate user in network

Authentication is not a heavy bandwidth consumer.

1) How are you configuring your queues? Share that section of your configuration.

2) How are you measuring outbound bandwith queuing?

[zomo]

I dont have my old conf files with pppoe.

I should setup altq ont tun device, and assign queue from physical local interface on tun rules? For example to limit download bandwidth i should

user link with pppoe on tun5

altq on $LAN
altq on tun5

pass out on tun5 from any to ip_of_user queue down_queue_from_altq_on_lan

This is very basic scheme, but same way of thinking is good ?

thanks!

[robbak]

Probably. But what is $LAN, and how is down_queue_from_altq_on_lan configured?

For the purposes of what you have described, you do not need altq on the physical interface. Of course, you may need it for something else.

[zomo]

$LAN is internal interface.

I just like to know from what interface assign queues to rules on tun interface? From LAN or from tun ?

Already i dont have access to machine where I was configuring all this stuff...

[robbak]

Originally Posted by zomo

$LAN is internal interface.

I just like to know from what interface assign queues to rules on tun interface? From LAN or from tun ?

If you want to control traffic on the tun interface, then you will need rules on the tun interface. If you want to know the number of giraffes, you will need to count the giraffes. Counting the elephants won't help you.

And to repeat, "how is down_queue_from_altq_on_lan configured?"

[zomo]

Ok, my pf.conf:

altq on tun0 bandwidth 97Mb hfsc queue{ std_tun0 user_tun0 ack_tun0 }

queue std_tun0 bandwidth 20Kb priority 1 hfsc(upperlimit 220Kb default)
queue ack_tun0 bandwidth 128Kb qlimit 500 hfsc(realtime 128Kb upperlimit 256Kb)
queue user_tun0 bandwidth 512Kb qlimit 500 hfsc(upperlimit 1024Kb)

pass in quick on tun0 all tag asd queue (user_tun0 ack_tun0)
pass out quick on $EXT all tagged asd queue (user_ext ack_ext)

With this configuration seems to everything works fine

Sep 20 13:53:27.297424 rule 9/(match) [uid 0, pid 302] pass in on tun0: 172.16.0.2.1411 > 216.239.59.104.80: [|tcp] (DF) (ttl 128, id 15716, len 48)
Sep 20 13:53:27.297475 rule 10/(match) [uid 0, pid 302] pass out on re0: 83.16.229.106.52943 > 216.239.59.104.80: [|tcp] (DF) (ttl 127, id 62719, len 48)

But i cant reach transfer rate which is defined on altq definition. For example when i try to download something i have smth about 20 KB/s? Another thing, this traffic on tun0 is also getting to my standard queue on $LAN physical interface(i have little leaks on standard queue (std_lan), from my network which is no yet running with pppoe). How i check the traffic is getting to std_lan queue on $LAN interface, when i trying to download something via tun0, std_lan start increasing...I hope you understand me

# pftop
root_tun0 97M hfsc 0 0 0 0 0 0 0 0

std_tun0 20000 hfsc 0 0 0 0 0 0 0
ack_tun0 128K hfsc 174 8116 0 0 0 1 79
user_tun0 512K hfsc 2831 3890466 0 0 0 16 23820

root_em0 97M hfsc 0 0 0 0 0 0 0 0

std_lan 20000 hfsc 3887 5090192 6 4582 8 21 27507

Thanks for help

[jggimi]

1. You can only control OUTBOUND traffic queues. Inbound packets cannot be queued or limited -- they must be processed as they arrive. That is the nature of IP traffic. If you want to queue incoming traffic, you can only do that if PF is used in a router -- e.g.: traffic destined for your internal LAN may be shaped as it leaves your OpenBSD system for another.

2. I do not clearly understand your use of pppoe, but, if it is only used for authentication, and not for data transfer, as you mentioned above -- then you will only have a short handshake for authentication and authorization and no traffic worth attempting to queue.

3. pftop has a history of not keeping up with pf changes; at least in the last year or two. I do not recall it's exact state with 4.3, but it produces misleading state table values at 4.4 and -current. You might be better off using pfctl -vs state and pfctl -vs queue to ensure accurate assessment of state tables and queues.

[zomo]

1. But pf adds the keep state and flags S/SA to all rules by default, and the packets which are returning are matched to download queue..

2. I want smth like this:
First step: user dial up to my server. If login and pass is ok then step two
Second step: system creating tun* device, on which will be data transfered, and i want to limit this traffic by pf ??? Am i wrong ?

[jggimi]

If your OpenBSD system is the final destination of your users' connections, then:

Packets from your users to OpenBSD cannot be managed by queues. Packets to your users can be queued.

Example: Your user sends you a large file.

Each 1500-byte packet must be dealt with on arrival. Your system's short ack packets may be queued for their return to the user.

If your OpenBSD system is routing packets to another subnet -- commonly between your Internet connection and your LAN, then:

Traffic may be shaped as it passes through your OpenBSD system in either direction.

Example: Your externally connected user sends a large file to another computer on your local network.

Each 1500-byte packets destined to your local network may be queued as they are scheduled for your LAN. The short ack packets may be queued on their return to your user.

[jggimi]

From the PF User's Guide:

Note that queueing is only useful for packets in the outbound direction. Once a packet arrives on an interface in the inbound direction it's already too late to queue it -- it's already consumed network bandwidth to get to the interface that just received it. The only solution is to enable queueing on the adjacent router or, if the host that received the packet is acting as a router, to enable queueing on the internal interface where packets exit the router.

[robbak]

Originally Posted by zomo

But i cant reach transfer rate which is defined on altq definition. For example when i try to download something i have smth about 20 KB/s?

So your problem is, not that altq is not working, but something else somewhere else is not allowing you to reach the full bandwidth that you have specified in pf.conf?

Another thing, this traffic on tun0 is also getting to my standard queue on $LAN physical interface(i have little leaks on standard queue (std_lan), from my network which is no yet running with pppoe). How i check the traffic is getting to std_lan queue on $LAN interface, when i trying to download something via tun0, std_lan start increasing...I hope you understand me

Perfectly. Why did you think it would be any other way? tun is a virtual interface (i.e. created in sofwtware), that allows user processes (like ppp) to become a network device. In your case, the packets, wrapped in ppp headers, will exit via $LAN, and will be seen there by traffic counters and restricted by any altq rules you have on $LAN.

[zomo]

Ok i understand you, but if you put smth like that in to your pf.conf file:

1. pass in quick on $LAN from $user_ip to !$LAN tag user1 keep state flags S/SA queue (user_down ack_down)
2. pass out quick on $LAN all tagged user1 keep state flags S/SA queue (user_up ack_up)

Look, If user make connection matching to the rule number 1 when traffic will back will be put to queue user_down. Tagging allows you to mark packets after NAT to put it to appropriate ext queue.

So I limit download with pass in rule on INTERNAL interface and to limit upload, pass out rule on EXTERNAL interface and it works really good, but not with pppoe

[robbak]

I'll have to leave that to someone else. I have no idea how state and altq work together. Just note that ppp traffic to and from the tun and pppoe will hit both the tun and the lan interface, and that any limiting inbound traffic generally just won't work: All packets will be received as fast as they are sent - All that altq does is queue them all up and present them to the system at that speed. A well behaved remote host sending the packets should get the idea eventually from the delay in getting its acks back (alternately, it could just get impatient and resend the packets!), but that is all you are relying on. (I don't know if the pppoe client is 'well-behaved' in this manner or not!)