multicast DNS MAC address ...dhcp and tftp servers

jenaniston · Jan 12, 2010

snort has helped me get packet info and the MAC address for a LAN diskless boot client
which turns out as both 01:00:5E:--:--:FB and 01:00:5E:--:--:16

So far the dhcp server only communicates to port 5353 of this diskless client,
while the tftp server sends packets for boot file from port 67 to port 68 of the system machine.

I have uncommented

Code:

mdns = yes

line in the tftp server /etc/xinetd.conf file - so what about . . .

Code:

# bind =

Any other ideas or experience with a multicast MAC NIC on the client for bootp ?

Thanks for any suggestions or criticism.

SirDice · Jan 12, 2010

What exactly are you trying to achieve?

jenaniston · Jan 12, 2010

address problem probably?

I need to do a LAN "thin" client / diskless type of boot - or a.k.a. PXE boot - to an unbootable laptop -
the laptop bios supports LAN boot.

Another forum said that the multicast MAC address shouldn't be a problem.

I now think I will clean up to a bare bones dhcpd.conf file -
maybe do a hardware ethernet declaration for BOTH the multicast MAC addresses, with different fixed IP address assigned to each, but of course pointing to the same /tftpboot/pxelinux.0 file.

Thus, I'd sort of treat the multicast MAC as two possible clients - for whichever one wants the boot file.
It is only the last two hex digits of the MAC that show up different during snort.

Thanks for any ideas.

jenaniston · Jan 12, 2010

dhcpd.conf addresses need changing . . . ?

multicast IP addresses are in a different range so that is where I'm at now
. . .and I haven't found any subnet calculators that work for these addresses either . . .

http://www.iana.org/assignments/multicast-addresses/

http://www.cotse.com/CIE/RFC/1700/5.htm

Any insights appreciated.

SirDice · Jan 13, 2010

Why are you using multicast to PXE boot a machine?

Try using 'regular' unicast.

jenaniston · Jan 13, 2010

I - as the dhcp server and tftp server - are not doing anything special - yet. It is the MAC layer that is "multicast" -

The client laptop's single 3com NIC has a multicast MAC address (01:00:5E xxxx:FB) or (01:00:5E xxxx:16) -
this was found by snort (and maybe even more if different ports get opened ?)

I think I have to do something in the dhcp server dhcpd.conf file to make this work - but I don't know enough about this yet.

SirDice · Jan 13, 2010

Go in the BIOS and see if you can change that MAC address. If it's set in the BIOS just try removing it. There's no reason why it's using 01:00:5E as it's OUI.

jenaniston · Jan 13, 2010

SirDice said:
Go in the BIOS and see if you can change that MAC address. If it's set in the BIOS just try removing it. There's no reason why it's using 01:00:5E as it's OUI.

The client laptop BIOS is pretty simple and I have been through it many times . . .
MAC address is not able to be set in that client laptop BIOS -
I didn't think it was something that even could be set, a usually permanent physical layer of the NIC card.

However . . . one thing does lead to another -

So I looked in one of the computers on campus that I boot up as a server and that I can change bios settings -
to see if it had any MAC address set characteristics since it has a much more extensive bios setup that I hadn't been all through . . .

I DID change a bios setting on the server side . . .(four choices- default is On)

Onboard Devices > Integrated NIC >
On - Integrated NIC is enabled
Off - Integrated NIC is disabled
On w /PXE - Integrated NIC is on (with PXE enabled)
On w/ RPL - Integrated NIC is on (with RPL enabled)

So now, with PXE enabled on the server bios, well this can only help . . . I will be trying it all this pm.

Thanks for the lead . . .

SirDice · Jan 14, 2010

jenaniston said:
So now, with PXE enabled on the server bios, well this can only help

It won't. This setting enables the server to PXE boot, not your client.

Before booting the client, run tcpdump on the server. Snort can be used but tcpdump is part of the base OS so there's no need to install anything.

# tcpdump -ni bge0 -vveX

Post some of that here so we can see what's happening. Change the network interface to yours of course.

jenaniston · Jan 15, 2010

I need to set up unicast . . . like you said

SirDice said:
Why are you using multicast to PXE boot a machine?

Try using 'regular' unicast.

Code:

 # ifconfig -a
. . .
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

You are right . . . I didn't realize the server side is involved in doing this . . . I DO want to set to a unicast . . .
I had been following LAN boot instructions that I have but I now know I don't want multicast for this simple point-to-point connection.

Among some of the tcpdump output I have already is the bad checksum :
(from before I read your last post - I will go off internet and start servers to laptop to get other tcpdump output)

Code:

10.0.0.1.mdns > 224.0.0.251.mdns: [bad udp cksum 6b02!]

a google search says I shouldn't care about this - I used tcpdump -K option to get rid of it in output but what do you think about it ?

Anyway, I just read your post and will post more tcpdump results in a bit.

Thank you very much for all your advice.

J65nko · Jan 15, 2010

For the bad checksums reported by tcpdump see
Why tcpdump sometimes drops packets, mangles DNS and shows bad checksums

Sometimes I run tcpdump on a remote machine, when I am logged in at the remote with ssh. In this situation I tell tcpdump not to capture the ssh packets

Code:

# tcpdump -ni fxp0 'not port ssh'

jenaniston · Jan 15, 2010

J65nko said:
For the bad checksums reported by tcpdump see
Why tcpdump sometimes drops packets, mangles DNS and shows bad checksums
[/code]

Thanks J65nko . . . an excerpt from that link . . .

"the network interface is calculating the checksum on send, BPF will
see a version of the packet before the checksum is calculated. If tcpdump
later attempts to verify the checksum, it still won't be calculated in the
copy it sees, and will whine."
". . .The packets to be sent out, are presented to the network interface with dummy values in the checksum field.
Before transmission over the wire, the NIC calculates the actual checksum and replaces the dummy checksum field with the correct one."

OK with the servers up and running (linux yum install in fedora12kde)
dhcp assigns 10.0.0.4 (within the dhcpd.conf range declaration) to the university dell even though set with ifconfig to get dhcpd started:

Code:

# ifconfig eth1 inet 10.0.0.1 netmask 255.255.255.0

Code:

[root@localhost ~]# service xinetd status
xinetd (pid  1268) is running...
[root@localhost ~]# service dhcpd status
dhcpd (pid  1983) is running...

results from a tcpdump (with -t option added) to clean off timestamps . . .

Code:

[root@localhost ~]# tcpdump -ni eth1 -tvveX
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
00:1a:a0:46:98:4d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 126:
 (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 112)
    10.0.0.4.mdns > 224.0.0.251.mdns: [bad udp cksum 722d!] 0 [2q] 
SRV (QM)? linux [00:1a:a0:46:98:4d]._workstation._tcp.local. 
SRV (QM)? linux._ssh._tcp.local. (84)
        0x0000:  4500 0070 0000 4000 ff11 907d 0a00 0004  E..p..@....}....
        0x0010:  e000 00fb 14e9 14e9 005c eb6c 0000 0000  .........\.l....
        0x0020:  0002 0000 0000 0000 196c 696e 7578 205b  .........linux.[
        0x0030:  3030 3a31 613a 6130 3a34 363a 3938 3a34  00:1a:a0:46:98:4
        0x0040:  645d 0c5f 776f 726b 7374 6174 696f 6e04  d]._workstation.
        0x0050:  5f74 6370 056c 6f63 616c 0000 2100 0105  _tcp.local..!...
        0x0060:  6c69 6e75 7804 5f73 7368 c033 0021 0001  linux._ssh.3.!..
00:1a:a0:46:98:4d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 204:
 (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 190)
    10.0.0.4.mdns > 224.0.0.251.mdns: [bad udp cksum aee9!] 0*- [0q]
 4/0/0 linux._ssh._tcp.local. (Cache flush) 
SRV linux.local.:22 0 0, linux.local. (Cache flush) 
AAAA fe80::21a:a0ff:fe46:984d, linux.local. (Cache flush) 
A 10.0.0.4, linux [00:1a:a0:46:98:4d]._workstation._tcp.local. (Cache flush) 
SRV linux.local.:9 0 0 (162)
        0x0000:  4500 00be 0000 4000 ff11 902f 0a00 0004  E.....@..../....
        0x0010:  e000 00fb 14e9 14e9 00aa ebba 0000 8400  ................
        0x0020:  0000 0004 0000 0000 056c 696e 7578 045f  .........linux._
        0x0030:  7373 6804 5f74 6370 056c 6f63 616c 0000  ssh._tcp.local..
        0x0040:  2180 0100 0000 7800 0e00 0000 0000 1605  !.....x.........
        0x0050:  6c69 6e75 78c0 1cc0 3300 1c80 0100 0000  linux...3.......
        0x0060:  7800 10fe 8000 0000 0000 0002 1aa0 fffe  x...............
        0x0070:  4698 4dc0 3300 0180 0100 0000 7800 040a  F.M.3.......x...
        0x0080:  0000 0419 6c69 6e75 7820 5b30 303a 3161  ....linux.[00:1a
        0x0090:  3a61 303a 3436 3a39 383a 3464 5d0c 5f77  :a0:46:98:4d]._w
        0x00a0:  6f72 6b73 7461 7469 6f6e c017 0021 8001  orkstation...!..
        0x00b0:  0000 0078 0008 0000 0000 0009 c033       ...x.........3

I have to get out of this multicast mode IP 224.0.0.251 address on the laptop
and I am currently trying to sort out if the following info can help :
https://lists.isc.org/pipermail/dhcp-users/2008-April/006219.html

"The dhcpd.conf man page outlines the "always-broadcast" command,
however the default is not to broadcast unless the client indicates
that it wants a broadcast reply.

The always-broadcast statement

always-broadcast flag;

The DHCP and BOOTP protocols both require DHCP and BOOTP
clients to set the broadcast bit in the flags field of the
BOOTP message header. Unfortunately, some DHCP and BOOTP
clients do not do this, and therefore may not receive
responses from the DHCP server. The DHCP server can be
made to always broadcast its responses to clients by
setting this flag to 'on' for the relevant scope;. . ."

SirDice · Jan 15, 2010

I thought this would be the case. You're staring blind on that multicast mac stuff. What you are seeing there is a multicast DNS announcement from your server. This has nothing to do with PXE/DHCP or the laptop you are trying to boot. You can verify this by looking at the ifconfig output and comparing the mac address with 00:1a:a0:46:98:4d (source mac address in the captures).

Lets expend the tcpdump a little so we capture only the relevant DHCP request and hopefully get the correct mac address:

# tcpdump -ni eth1 -tvveX port 67 or port 68

Run that and turn the laptop on and try to PXE boot it.

J65nko · Jan 15, 2010

The table of IPv4 multicast addresses at http://en.wikipedia.org/wiki/Multicast_address shows shows that 224.0.0.251 is a multicast DNS addresses. See http://en.wikipedia.org/wiki/Multicast_DNS

As far as I understand you are dealing with a zero-configuration networking approach originated by Apple, which is not an officially standard (yet).

BTW
http://www.daemonforums.org/showthread.php?t=4150#post29064 etc shows similar tcpdumps from an Apple Notebook and iPhone.

You say you needed to do a PXE boot on an unbootable laptop. Is this an Apple laptop?

jenaniston · Jan 15, 2010

SirDice said:
Lets expend the tcpdump a little so we capture only the relevant DHCP request and hopefully get the correct mac address:

# tcpdump -ni eth1 -tvveX port 67 or port 68

Run that and turn the laptop on and try to PXE boot it.

Well those multicast MAC only come with laptop connected by ethernet cable . . .
First here was more tcpdump before I read your last post.
This is before the dhcp server was started . . . address for dell is as I assigned by ifconfig (10.0.0.1)

There are two destination MAC addresses - with the one dell into the one laptop a point to point ethernet cable -
on different university computers into the laptop the two destination MAC are always the same.

Code:

00:1a:a0:46:98:4d > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 54:
 (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) 
 10.0.0.1 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 to_ex { }] 
 0x0000: 46c0 0028 0000 4000 0102 f9f8 0a00 0001 F..(..@......... 
 0x0010: e000 0016 9404 0000 2200 f902 0000 0001 ........"....... 
 0x0020: 0400 0000 e000 00fb ........ 
00:1a:a0:46:98:4d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 179:
 (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 165) 
 10.0.0.1.mdns > 224.0.0.251.mdns: [bad udp cksum 3553!]
 0 [7q] SRV (QM)? linux [00:1a:a0:46:98:4d]._workstation._tcp.local. 
PTR (QM)? _services._dns-sd._udp.local. PTR (QM)? _ssh._tcp.local. 
PTR (QM)? _workstation._tcp.local. TXT (QM)? linux._ssh._tcp.local. 
SRV (QM)? linux._ssh._tcp.local. TXT (QM)? linux [00:1a:a0:46:98:4d]._workstation._tcp.local. (137) 
 0x0000: 4500 00a5 0000 4000 ff11 904b 0a00 0001 E.....@....K.... 
 0x0010: e000 00fb 14e9 14e9 0091 eb9e 0000 0000 ................ 
 0x0020: 0007 0000 0000 0000 196c 696e 7578 205b .........linux.[ 
 0x0030: 3030 3a31 613a 6130 3a34 363a 3938 3a34 00:1a:a0:46:98:4 
 0x0040: 645d 0c5f 776f 726b 7374 6174 696f 6e04 d]._workstation. 
 0x0050: 5f74 6370 056c 6f63 616c 0000 2100 0109 _tcp.local..!... 
 0x0060: 5f73 6572 7669 6365 7307 5f64 6e73 2d73 _services._dns-s 
 0x0070: 6404 5f75 6470 c038 000c 0001 045f 7373 d._udp.8....._ss 
 0x0080: 68c0 3300 0c00 01c0 2600 0c00 0105 6c69 h.3.....&.....li 
 0x0090: 6e75 78c0 6000 1000 01c0 7100 2100 01c0 nux.`.....q.!... 
 0x00a0: 0c00 1000 01 ..... 
00:1a:a0:46:98:4d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 193:
 (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 179) 
 10.0.0.1.mdns > 224.0.0.251.mdns: [bad udp cksum bcec!]
 0*- [0q] 4/0/0 _workstation._tcp.local. 
PTR linux [00:1a:a0:46:98:4d]._workstation._tcp.local., _services._dns-sd._udp.local. 
PTR _ssh._tcp.local., _services._dns-sd._udp.local. PTR _workstation._tcp.local., _ssh._tcp.local. 
PTR linux._ssh._tcp.local. (151) 
 0x0000: 4500 00b3 0000 4000 ff11 903d 0a00 0001 E.....@....=.... 
 0x0010: e000 00fb 14e9 14e9 009f ebac 0000 8400 ................

jenaniston · Jan 15, 2010

Here's the first two packets of the port 67 and 68 tcpdump -
these are not reaching the laptop as far as I can tell.

Code:

[root@localhost ~]# tcpdump -ni eth1 -tvveX port 67 or port 68
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
00:1a:a0:46:98:4d > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0,
 flags [none], proto UDP (17), length 328)                                                                                               
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:1a:a0:46:98:4d,
 length 300, xid 0xddeaa827, Flags [none] (0x0000)                                                                                         
          Client-Ethernet-Address 00:1a:a0:46:98:4d                                                                     
          Vendor-rfc1048 Extensions                                                                                     
            Magic Cookie 0x63825363                                                                                     
            DHCP-Message Option 53, length 1: Discover                                                                  
            Parameter-Request Option 55, length 10:                                                                     
              Subnet-Mask, BR, Time-Zone, Default-Gateway                                                               
              Domain-Name, Domain-Name-Server, Hostname, YD                                                             
              YS, NTP                                                                                                   
        0x0000:  4510 0148 0000 0000 8011 3996 0000 0000  E..H......9.....                                              
        0x0010:  ffff ffff 0044 0043 0134 c7d9 0101 0600  .....D.C.4......                                              
        0x0020:  ddea a827 0000 0000 0000 0000 0000 0000  ...'............                                              
        0x0030:  0000 0000 0000 0000 001a a046 984d 0000  ...........F.M..                                              
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................                                              
                         ........                                                      
00:1a:a0:46:98:4d > Broadcast, ethertype IPv4 (0x0800), length 342: 
(tos 0x10, ttl 128, id 0, offset 0, flags [none],
 proto UDP (17), length328)                                                                                               
    10.0.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply,
 length 300, xid 0xddeaa827, Flags [Broadcast] (0x8000)                                                                                                            
          Your-IP 10.0.0.4                                                                                              
          Client-Ethernet-Address 00:1a:a0:46:98:4d                                                                     
          Vendor-rfc1048 Extensions                                                                                     
            Magic Cookie 0x63825363                                                                                     
            DHCP-Message Option 53, length 1: Offer                                                                     
            Server-ID Option 54, length 4: 10.0.0.1                                                                     
            Lease-Time Option 51, length 4: 43200                                                                       
            Subnet-Mask Option 1, length 4: 255.255.255.0                                                               
            BR Option 28, length 4: 10.0.0.255                                                                          
            Domain-Name Option 15, length 4: "plop"                                                                     
            Domain-Name-Server Option 6, length 4: 10.0.0.50                                                            
        0x0000:  4510 0148 0000 0000 8011 2f95 0a00 0001  E..H....../.....                                              
                              ........

J65nko · Jan 15, 2010

Jen, please read my post http://forums.freebsd.org/showpost.php?p=62070&postcount=14, I posted it posted 1 minute before your answered SirDice, so you may have missed it

SirDice · Jan 15, 2010

jenaniston said:
Here's the first two packets of the port 67 and 68 tcpdump -
these are not reaching the laptop as far as I can tell.

Actually, they originate from the laptop. You can tell by looking at the IP addresses. Since the host has no IP address (that's why it uses DHCP) it uses 0.0.0.0 as a source. It then broadcasts (255.255.255.255) a DHCP request.

From this we can safely assume the laptop's MAC address is 00:1a:a0:46:98:4d. You now need to look if the server responds with a DHCP offer. Forget about that multicast stuff, it's totally irrelevant.

SirDice · Jan 15, 2010

Oh.. Just to clear up something. How's everything connected?

I read that your server gets an IP address from the university network? How are you connecting the laptop? Does the server have a second network card?

(I'm thinking the laptop actually is getting an IP address, but instead of you supplying it it's the university's DHCP server that does it. Which, obviously, isn't configured to PXE boot your laptop :e)

jenaniston · Jan 15, 2010

J65nko said:
. . . you are dealing with a zero-configuration networking approach originated by Apple, . . .

You say you needed to do a PXE boot on an unbootable laptop. Is this an Apple laptop?

You were right I did miss your post -
as I have understood similar links - and I'll read those you posted more - I should try for some sort of a zero configuration / unicast type of dhcp server dhcpd.conf

It is a Sharp AL27 laptop with a MobileAthlon 64 cpu - internal network card is a 3COM (5c901-?) - bios setup has LAN boot enabled,
but LAN boot is not a choice in boot sequence.

SirDice said:
. . . From this we can safely assume the laptop's MAC address is 00:1a:a0:46:98:4d. . . .

I'll look more into everything you've said -
but I can post the tcpdump when on other computers (other library open later) as I did last night -
the 01:00:FE:00:00:16 and 01:00:FE:00:00:FB MAC will stay the same -
also if I tcpdump - or snort - without connection to the laptop those two MACs are gone.

You are right in that something in the university system could be playing some havoc -
but I can and do run Linux Fedora or FreeBSD live versions and servers totally unplugged from them as a seperate OS
(it maybe could be something wireless ?).

And I'll edit out a bunch of the tcpdump above to shorten the posts now that you've seen them.
I'll post with the linux server run from a different library.

Thanks.

SirDice · Jan 15, 2010

jenaniston said:
I'll post with the linux server run from a different library.

Hey! Use the BSD live cd if you have to, we're on a freebsd forum here

It's friday, just had a beer, couldn't resist :beer

jenaniston · Jan 15, 2010

SirDice said:
Hey! Use the BSD live cd if you have to, we're on a freebsd forum here

It's friday, just had a beer, couldn't resist :beer

I was expecting that . . .
I still want to but I spent a good week trying to get everything together -
the FreeBSD version I have is on DVDiso and I can't upload /install the tftp server - it comes with a 3.1.1 dhcp server though.

Yes, I would rather be doing this that way - there are some commands from the FreeBSD texts that are not used in linux.
but Fedora11/12 got me started up faster toward this . . . even if at a roadblock.

SirDice · Jan 15, 2010

No worries, main thing is to get going :e

Best thing to do is to start fresh. Forget everything you've looked at and configure the dhcp/tftp for a simple unicast PXE boot. Keep an eye on things with tcpdump. Add the -o option to store the dump, that way you can 'replay' the event. You can also load that dump into wireshark. Filter traffic using ether host 00:1a:a0:46:98:4d. That will make sure you see everything going to/from the laptop.

SirDice · Jan 15, 2010

Hmm.. Just checked this:
http://standards.ieee.org/cgi-bin/ouisearch?00-1a-a0

So, that's the Dell, not 3Com :r

While you're doing this, try to minimize all the 'noise' on your network. Turn off as much you can on the server you're using.

jenaniston · Jan 15, 2010

SirDice said:
. . . Forget everything you've looked at and configure the dhcp/tftp for a simple unicast PXE boot.

SirDice said:
. . . try to minimize all the 'noise' on your network. Turn off as much you can on the server you're using.

Thanks for all the encouragement.

Although I first cut the power - then plug the ethernet cable into the laptop for a direct point-to-point LAN -
then boot up the Dell (or an HP if here at engineering library [here MAC is 00:17:A4:------], these two points I'll make . . .

(1) these computers on campus are set up to multicast up the yin-yang,
students Skype to Asia and Europe, and watch streaming media - news, entertainment, football games etc.
So even booting another OS - the live versions of linux fedora or FreeBSD -
I still conceivable launch and configure some of this in the inetd and inetd.conf (I am just learning more about this).
I have to go back to the launch of the OS and be sure I reconfigure to get unicast to the one other computer hard connected for the LAN boot - the laptop.
Booting of live FreeBSD/PCBSD has been insightful in this.

(2) Once, I forgot to unplug from the laptop, and then removed my live version from the boot drive (CD or USB).
I then went to boot back up the university Windows Vista Enterprise and
I was prompted for my university account number and it logged me in -
I do NOT really see how it did that - I was only hard connected to the laptop by mistake.

Thanks again for all the advice . . .
enjoy Friday night and the beer !

multicast DNS MAC address ...dhcp and tftp servers

jenaniston

SirDice

Administrator

jenaniston

jenaniston

SirDice

Administrator

jenaniston

SirDice

Administrator

jenaniston

SirDice

Administrator

jenaniston

J65nko

jenaniston

SirDice

Administrator

J65nko

jenaniston

jenaniston

J65nko

SirDice

Administrator

SirDice

Administrator

jenaniston

SirDice

Administrator

jenaniston

SirDice

Administrator

SirDice

Administrator

jenaniston