Re: [PATCH] L2TP:Adjust intf MTU, add underlay L3, overlay L2
On Wed, Sep 21, 2016 at 02:11:04pm -0700, R. Parameswaran wrote:
>
[snip]
> @@ -206,6 +209,46 @@ static void l2tp_eth_show(struct seq_file *m, void
> *arg)
> }
> #endif
[snip]
> +
> static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id,
> u32 peer_session_id, struct l2tp_session_cfg *cfg)
> {
> struct net_device *dev;
> @@ -255,11 +298,8 @@ static int l2tp_eth_create(struct net *net, u32
> tunnel_id, u32 session_id, u32 p
> }
>
Your diff has whitespace errors, probably where your MUA has decided to do
'intelligent' line wrapping.
You should (re)send from a proper MUA which does not suffer from this issue.
DF
Re: [PATCH] L2TP:Adjust intf MTU, add underlay L3, overlay L2
On Wed, Sep 21, 2016 at 02:11:04pm -0700, R. Parameswaran wrote:
>
[snip]
> @@ -206,6 +209,46 @@ static void l2tp_eth_show(struct seq_file *m, void
> *arg)
> }
> #endif
[snip]
> +
> static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id,
> u32 peer_session_id, struct l2tp_session_cfg *cfg)
> {
> struct net_device *dev;
> @@ -255,11 +298,8 @@ static int l2tp_eth_create(struct net *net, u32
> tunnel_id, u32 session_id, u32 p
> }
>
Your diff has whitespace errors, probably where your MUA has decided to do
'intelligent' line wrapping.
You should (re)send from a proper MUA which does not suffer from this issue.
DF
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Thu, Oct 04, 2007 at 07:18:47PM -0400, Chuck Ebbert wrote: > > I ran firefox setuid to a different (not my main user), uid+gid, gave > > my main account that gid as a supplemental group, and gave that uid > > access to the X magic cookie. > > You need to use runxas to get any kind of real security. Interesting script - sad how everyone reinvents equivalent things. I had been experimenting with running the whole lot under Xnest, with two extra users - one for the Xnest which had the main X cookie, and another for the browser. But found that it was just too awkward (since I use multiple browser windows as well a tabs). So I ended up trading a small security gain vs usablity. The other thing I started playing with was the NX version of Xnest, since it allows for a rootless server... DF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 01:12:46AM +0100, Alan Cox wrote: > > The value of SELinux (or indeed any system compartmentalising access and > limiting damage) comes into play when you get breakage - eg via a web > browser exploit. well, being sick of the number of times one has to upgrade the browser for exploits, I addressed it in a different way. I ran firefox setuid to a different (not my main user), uid+gid, gave my main account that gid as a supplemental group, and gave that uid access to the X magic cookie. ... which only changes the nature of any exploit that might occur - any injected code would have to go via X to attack my main account. DF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 01:12:46AM +0100, Alan Cox wrote: The value of SELinux (or indeed any system compartmentalising access and limiting damage) comes into play when you get breakage - eg via a web browser exploit. well, being sick of the number of times one has to upgrade the browser for exploits, I addressed it in a different way. I ran firefox setuid to a different (not my main user), uid+gid, gave my main account that gid as a supplemental group, and gave that uid access to the X magic cookie. ... which only changes the nature of any exploit that might occur - any injected code would have to go via X to attack my main account. DF - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Thu, Oct 04, 2007 at 07:18:47PM -0400, Chuck Ebbert wrote: I ran firefox setuid to a different (not my main user), uid+gid, gave my main account that gid as a supplemental group, and gave that uid access to the X magic cookie. You need to use runxas to get any kind of real security. Interesting script - sad how everyone reinvents equivalent things. I had been experimenting with running the whole lot under Xnest, with two extra users - one for the Xnest which had the main X cookie, and another for the browser. But found that it was just too awkward (since I use multiple browser windows as well a tabs). So I ended up trading a small security gain vs usablity. The other thing I started playing with was the NX version of Xnest, since it allows for a rootless server... DF - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't read DVD (under 2.4.[12] & 2.2.17)
On Wed, Mar 07, 2001 at 09:36:32PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Pozsar Balazs wrote:
> > Details: (dmesg)
> >
> > When I run "dvdinfo /dev/hdd" I get:
> > Disc is encrypted.
> > Layer 0[3]
> > Num Layers: 2
> > Start Sector0xd000
> > End Sector 0xd000
> > End Sector L0 0xd000
> > Layer 1[3]
> > Num Layers: 2
> > Start Sector0xd000
> > End Sector 0x1d000
> > End Sector L0 0xd000
> > hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> > hdd: packet command error: error=0x50
> > ATAPI device hdd:
> > Error: Illegal request -- (Sense key=0x05)
> > Invalid field in command packet -- (asc=0x24, ascq=0x00)
> > The failed "Send DVD Structure" packet command was:
> > "ad 00 00 00 00 00 02 00 00 54 00 00 "
> > Could not read Physical layer 2
> > Copyright: CPST=1, RMI=0xfd
>
> I don't know the program you mention, but it's definitely buggy. It
> sets byte 6 to 0x02 which is not valid at all.
The program is attempting to read from the third layer! Thats why it
fails. This value gets set from the .layer_num element supplied
in the struct dvd_physical supplied to the ioctl call.
> Byte 7 is the format code, but 0x02 is reserved there too. Who wrote
> this program? Tell him it's buggy, it's not the driver.
Originally me (a couple of years ago), and I'm not supprised at it
being buggy, it was a simple program to explore a couple of the
ioctl calls. I never got particularly sensible data from a multi-layer
DVD (maybe the firmware in my drives is dodgy).
the original code was something like:
dvd_struct d;
int layer, layers = 4;
d.physical.type = DVD_STRUCT_PHYSICAL;
for (layer = 0; layer < layers; ++layer) {
d.physical.layer_num = layer;
ioctl(fd, DVD_READ_STRUCT, );
printf("Layer %d[%d]\n", layer, layers);
display data in d.physical.layer[layer]
layers = d.physical.layer[layer].nlayers + 1;
}
This was from observations of the data returned by my DVD drive, where
the .nlayers was always returned as 0 or 1 for single or dual layer
discs, and always as 0 for flippers. Having a drive return the number
of layers as 2 doesn't agree with this. Unless his drive is simply
returning 1 based numbers, whereas mine returned 0 based numbers.
Actually I never forund the API especially sensible - this could just be
due to the data I saw back from my DVD drive.
The way I interpreted this API is that one requests the layer number to
read the data from, and that index in the array would be filled in with
data. However this seems a bit pointless - if only one layers worth of
data will be returned at a time, then why have an array of 4 entries?
Or is it intended that you should be able to read identical data from
either layer (on either side). That all layers on the disk would have
had this structure physically recorded identically, and that for a
disk with n 'layers', n elements of the array will be filled as
appropriate.
On my drive for array indicies > 0 the data in the structure elements
is always 0. It also makes no difference which layer I read (assuming
that its actually dual layer), the results of the 2 ioctl calls are
identical.
DF
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
On Tue, Sep 05, 2000 at 04:35:43AM -0600, Jeff V. Merkey wrote: > > IPX is a really good LAN protocol (but totally sucks for internet). A > full blown NCP server in-kernel that's toughtly coupled to the page > cache running over IPX would make flames shoot out of the back of a > Linux server, and make NT like look an old lady hobbling down the > street. There's no need to configure client addresses with it, and for > file and print, it's the best. I'd still prefer it over UDP. A simple UDP/IP stack should be of a comprable size to a IPX stack (if one wanted DOS support). As for the the configuration - you could use BOOTP/DHCP to get addresses or alternatly use IPv6 and link-local addresses. DF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
