Frds,

Please help me
I need to identify linux users from packet grabbed at remote booting LAN

I have linux remote booting server with more than 25 clients. Each client will able to login independly of other (typical remote booting system). So any client m/c will have any user. This linux users are having access to Internet.
Well I am doing project regarding this users. I am stuckup at one pt.
so guys please help me
If I capture the HTTP packet from network how can I identify which user sent this packet or to which user this packet is going.
Remember I dont need m/c IP address but I need the linux user.

PLEASE HELP

Well, if you're doing a "project" then you do the research. Here's some questions.
- What authority do you have wrt this network (network admin, luser)?
- What type of machine are these clients (POS displays, 'net cafe machines, thin client, regular workstations)?
- What servers, protocols, services are used to get the machine to boot up?
- Which of these servers, protocols and services handles authentication?

ok here are the ans

1. We are having only valid linux users. We are doing this project for our college and project is all about the priority wise bandwidth management. Hence linux users are categorized into root(admin) , staff lever users and student level users to whom we are assigning bandwidth priority wise.........i.e. admin will have more bandwidth ...then staff and then students.
Admin or root lever user have the highest priority and he can control this operation.
2.We are having regular workstation in our college in which 1 remote server pc is connected to 25 diskless thin clients.
3 & 4. We are using DHCP. DHCP server keeps track of all users. (i.e. it handles authentication but I am not very confirmed about it)

With all due respect but you either have not taken the time to do research in the hope of getting a fast answer or you don't have developed your analysis skills yet. Based on the nfo you presented, you have two options:

- take the easy way out. Divide physical machines into two groups: one group for administrators and staff and another group for students, assign each groups their own DHCP pool, do bandwidth shaping on those subnets.

- do more research. The honourable way since you'll be building an understanding of how things work. With that knowledge you'll be able to reconfigure and troubleshoot things more easily (efficiency), doing research enhances your independence (knowing how and where to look for nfo) and that knowledge is adaptable to other tasks at hand. A true win-win situation for all involved. The easiest way is to use use steps jotted down by somebody else, so let's try to get a theoretical top-level view of what is involved before investigating technical details. Using your favourite searchengine with "site:tldp.org +"thin client"" you should find TLDP's Thin Client: New User Guide. Here you have an overview of what's involved:
- Networking, obviously;
- PXE or BOOTP for making a workstation boot from remote;
- DHCPCd for registering the client on a network and redirecting it to the bootable image;
- TFTP for shoving the image to the client and;
- NFS to make the client load the O.S.
Notice how I linked in other HOWTO's so you can branch out and find details for those parts.


Say you've read the Thin Client HOWTO and you're interested in finding out the technical capabilities (can it do user auth?) of the DHCP protocol. Then you can get those at the official RFC repository. This "book of standards" will tell you if a certain capability is provided. Now to see if your distribution's DHCPCd package (say ISC's DHCP) DHCP protocol version provides that capability you can search the local documents like package documents (/usr/share/doc), man and info pages and configuration files for details. Resolving this: grep -i authentication -r /usr/share/doc/dhcp-4.0.0 -> References.txt -> RFC 2485: UAP -> man dhcpd-options -> option uap-servers). So if you have access to the DHCP server you can find out all by yourself and all without sniffing packets. OTOH if you're sniffing packets anyway, with the research options at hand you'll know at what OSI level to look for info, what traffic to discard and how to interprete packet payload.


To cut things short: in general the DHCP daemons scope is IP:MAC address pairings, not user auth. Next!