github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #373] MTU: issues for jail and host #267

New issue

Closed

opened 2026-05-05 05:28:01 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 05:28:01 -06:00

Owner

Originally created by @voidzero on GitHub (Mar 21, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/373

I found a problem when trying to set the mtu to 9000. (Note: a bridge is not allowed to have an mtu that is higher than that of its interfaces. So if I want to have an mtu of 9000, I set it on eth0 first and then on br0.)

So, with both eth0 and br0 set to 9000, let's connect a jail to this bridge, that has mtu 9000.

firejail --name=foo --hostname=foo --noprofile --net=br0 --ip=192.168.0.120 --defaultgw=192.168.0.1 --mtu=9000 --shell=/bin/zsh --debug --dns=8.8.8.8 -- /bin/zsh

In the debug output we see:

Parent pid 794, child pid 796
create veth veth794eth0/eth0/796
Initializing child process
MTU of br0 is 9000.
MTU of br0 is 1500.
Restoring MTU for br0
set interface br0 MTU 9000.
Warning: cannot set mtu for interface br0

When we issue ip link show dev eth0 from inside the jail, it appears that the MTU is 9000:

2: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

But when we look at the host:

% brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.xxxxxxxxxxxx       yes             eth0
                                                        veth794eth0

% ip link show dev br0
7: br0:  mtu 1500 (...)

% ip link show dev veth794eth0
16: veth794eth0@if2:  mtu 1500

As you can see, as soon as I started a jail with my regular user account, the bridge on the host dropped from mtu 9000 to 1500. This seems undesirable. Eth0 on the host is unaffected - it still has mtu 9000 -- and as soon as the jail is destroyed, the bridge on the host goes back to mtu 9000 again.

I suspect this can be fixed by setting the macvlan device on both the host and the jail to the desired MTU, before attaching it to the bridge. There are probably some safeguards that could be desirable too. Like, if the MTU is unspecified, use the MTU of the bridge (in this case I could omit --mtu 9000 because the bridge already has that).

But, it could also create a side effect that is more problematic: if the macvlan device is set to a bridge before it is attached, and that device has been set to a very low mtu, the bridge will switch to that mtu. So, if the user issues --mtu=576 it might make an admin pretty unhappy. Because of this, it's probably better to only allow MTUs to be set on bridges that are to be created by firejail, and to inherit the mtu of any existing bridge without overriding.

Or maybe, if the MTU specified is lower than the mtu of an existing bridge, just set the mtu lower inside the jail but not on the host. I don't even know if this will work, though. It's a tricky issue.

Originally created by @voidzero on GitHub (Mar 21, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/373 I found a problem when trying to set the mtu to 9000. (Note: a bridge is not allowed to have an mtu that is higher than that of its interfaces. So if I want to have an mtu of 9000, I set it on eth0 first and then on br0.) So, with both eth0 and br0 set to 9000, let's connect a jail to this bridge, that has mtu 9000. `firejail --name=foo --hostname=foo --noprofile --net=br0 --ip=192.168.0.120 --defaultgw=192.168.0.1 --mtu=9000 --shell=/bin/zsh --debug --dns=8.8.8.8 -- /bin/zsh` In the debug output we see: <pre> Parent pid 794, child pid 796 create veth veth794eth0/eth0/796 Initializing child process MTU of br0 is 9000. MTU of br0 is 1500. Restoring MTU for br0 set interface br0 MTU 9000. Warning: cannot set mtu for interface br0 </pre> When we issue `ip link show dev eth0` from inside the jail, it appears that the MTU is 9000: `2: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000` But when we look at the host: <pre> % brctl show bridge name bridge id STP enabled interfaces br0 8000.xxxxxxxxxxxx yes eth0 veth794eth0 % ip link show dev br0 7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 (...) % ip link show dev veth794eth0 16: veth794eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 </pre> As you can see, as soon as I started a jail with my regular user account, the bridge on the host dropped from mtu 9000 to 1500. This seems undesirable. Eth0 on the host is unaffected - it still has mtu 9000 -- and as soon as the jail is destroyed, the bridge on the host goes back to mtu 9000 again. I suspect this can be fixed by setting the macvlan device on both the host and the jail to the desired MTU, before attaching it to the bridge. There are probably some safeguards that could be desirable too. Like, if the MTU is unspecified, use the MTU of the bridge (in this case I could omit --mtu 9000 because the bridge already has that). But, it could also create a side effect that is more problematic: if the macvlan device is set to a bridge before it is attached, and that device has been set to a very low mtu, the bridge will switch to that mtu. So, if the user issues `--mtu=576` it might make an admin pretty unhappy. Because of this, it's probably better to only allow MTUs to be set on bridges that are to be created by firejail, and to inherit the mtu of any existing bridge without overriding. Or maybe, if the MTU specified is lower than the mtu of an existing bridge, just set the mtu lower inside the jail but not on the host. I don't even know if this will work, though. It's a tricky issue.

gitea-mirror

2026-05-05 05:28:01 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:28:07 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 22, 2016):

I'll mark it as an enhancement, I have to look into this mtu thing. On my machine I cannot even set manually mtu to 9000 on a bridge or on a regular device. I guess the kernel looks at the ethernet device and disallows mtu 9000 if it is not supported by the hardware.

@netblue30 commented on GitHub (Mar 22, 2016): I'll mark it as an enhancement, I have to look into this mtu thing. On my machine I cannot even set manually mtu to 9000 on a bridge or on a regular device. I guess the kernel looks at the ethernet device and disallows mtu 9000 if it is not supported by the hardware.

gitea-mirror commented

2026-05-05 05:28:10 -06:00

Author

Owner

@voidzero commented on GitHub (Apr 26, 2017):

A bridge can't have an mtu that's higher than its members. You can try to create a dummy device (ip link create dev dummy0 type dummy) and a bridge. Then brctl addif br0 dummy0, ip link set dev dummy0 up, ip link set dev br0 up, ip link set dev dummy0 mtu 9000, ip link set dev br0 mtu 9000.

@voidzero commented on GitHub (Apr 26, 2017): A bridge can't have an mtu that's higher than its members. You can try to create a dummy device (`ip link create dev dummy0 type dummy`) and a bridge. Then `brctl addif br0 dummy0`, `ip link set dev dummy0 up`, `ip link set dev br0 up`, `ip link set dev dummy0 mtu 9000`, `ip link set dev br0 mtu 9000`.

gitea-mirror commented

2026-05-05 05:28:12 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 19, 2018):

Is this issue now fixed?

@chiraag-nataraj commented on GitHub (Aug 19, 2018): Is this issue now fixed?

gitea-mirror commented

2026-05-05 05:28:14 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Oct 3, 2018):

Closing for now due to no response. @voidzero, please feel free to re-open if this is still an issue.

@chiraag-nataraj commented on GitHub (Oct 3, 2018): Closing for now due to no response. @voidzero, please feel free to re-open if this is still an issue.

gitea-mirror referenced this issue

2026-05-05 10:04:02 -06:00

[PR #267] [MERGED] Add alternative location for muttrc #3578

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#267

No description provided.

Rows
Columns